[Redis] Redis 성능 튜닝

개요

Redis 성능을 향상하기 위해 아래와 같은 조치를 취할 수 있습니다.

• 메모리가 한계에 도달했을 때 조치 사항을 설정하는 Eviction 정책 설정
• Redis는 시스템 환경 특히 네트워크 환경에 영향을 많이 받기 때문에 시스템 튜닝을 통한 성능 향상
• SLOWLOG 모니터링을 통해 느린 쿼리 튜닝

 

이외에도 서버 튜닝이 있으나 서버 튜닝의 경우 보통 레디스 설치 시 제공되는 기본 아키텍처를 적용하면 크게 문제가 되지 않을 것이기 때문에 생략하겠습니다.

 

Eviction 정책

Eviction 정책은 앞서 언급했듯이 Redis 서버 메로리가 한계에 도달했을 때 어떤 조치를 취할지를 결정합니다.

궁극적으로는 처음부터 메모리가 부족한 상황을 만들지 않는 것이 중요하지만 이러한 장애는 예상치 못할 때 발생하기 때문에 미리 정책을 수립하는 것 또한 중요합니다.

여기서 유의해야 할 점은 레디스 서버를 persistence 즉, DB처럼 사용할 경우 데이터 영속성을 위해 데이터를 지우는 eviction 정책을 설정하면 안 되고 cache로 사용할 때 적절한 eviction policy를 설정해야 합니다.

 

최대 메모리 설정 및 eviction policy 설정 키 값

 

redis.conf 설정 파일 내 maxmemory 값을 수정하여 메모리 사용 한도를 설정 가능합니다.

32bit 설정의 경우 OS 자체 제한 때문에 3GB가 디폴트 값이며 64bit 설정의 경우 디폴트 값이 0으로 설정되며 실질적으로 무제한으로 설정이 됩니다.

eviction 정책은 maxmemory-policy 값을 통해 수정이 가능하며 디폴트 값은 noevicition으로 메모리 한계에 도달하면 아무런 조치 없이 에러가 발생합니다.

 

maxmemory-policy 옵션은 아래와 같습니다.

• noeviction: 추가 데이터 저장 없이 에러 발생
• allkeys-lru: 일반적으로 사용되는 값으로 가장 최근에 사용된 키들을 남기고 나머지를 삭제 (Least Recently Used)
• allkeys-lfu: 가장 빈번하게 사용된 키들을 남기고 나머지를 삭제 (Least Frequently Used)
• volatile-lru: LRU를 사용하되 expire 필드 값이 true로 설정된 항목들 중에서만 삭제
• volatile-lfu: LFU를 사용하되 expire 필드 값이 true로 설정된 항목들 중에서만 삭제
• allkeys-random: 키들이 균등하게 사용된다는 보장 시 사용하는 정책으로 랜덤 하게 삭제
• volatile-random: expire 필드 값이 true로 설정된 항목들 중에서 랜덤 하게 삭제
• volatile-ttl: expire 필드 값이 true로 설정된 항목들 중에서 짧은 TTL 순으로 삭제

 

* volatile은 레디스 서버를 persistence와 caching 모두 사용할 때 유리한 정책으로 캐싱 데이터에만 expire 필드를 적용해 삭제하는 방식으로 주로 사용

 

redis-conf 내 maxmemory 및 maxmemory-policy

 

시스템 튜닝

레디스 서버는 시스템 환경에 영향을 많이 받기 때문에 redis-benchmark 유틸리티를 이용해 Redis의 성능을 측정 후 적절한 시스템 튜닝이 필수입니다. 

• 특히 네트워크 환경에 영향을 많이 받음

 

redis-benchmark 옵션은 아래와 같으며 redis-conf 내 maxmemory 값을 변경하며 테스트를 진행하면 각 명령어의 성능 및 메모리 사용량을 파악할 수 있습니다.

 

옵션	설명	디폴트 값
-h [hostname]	호스트명	127.0.0.1
-p [port]	포트번호	6379
-s [socket]	레디스 서버의 유닉스 서버 소켓	-
-c [clients]	동시 접속 할 가상 클라이언트 수	50
-n [requests]	각 명령의 테스트 횟수	10000
-d [size]	데이터 크기	3
-k [boolean]	가상 클라이언트의 접속 유지 여부	0: 유지 X, 1: 유지
-r [keyspacelen]	랜덤키의 범위	-
-P [numreq]	파이프라인당 요청할 명령어 갯수	0: 파이프라인 사용 X
-q	진행 상황 없이 테스트 결과만 출력	-
--csv	테스트 결과만 csv 포맷으로 출력	-
-l	break를 걸기 전까지 계속 수행	-
-t [tests]	쉼표로 구분 된 테스트 명령어의 목록	-
-l	명령 전송 없는 연결 생성 후 break 입력 시까지 대기	-

 

예시

 

redis-benchmark -p 7777 -d 1000 -r 10000 -n 100000 -q -t \ get, set, lpush, lpop, sadd, spop

 

 

Redis 성능에 영향을 미치는 요소들

 

Redis 성능에 주로 영향을 미치는 요소들은 아래와 같습니다.

• Network bandwidth & latency
• CPU
• RAM 속도 & 대역폭
• 가상화 환경의 영향
• 디스크 블록 사이즈
• Client Keep Alive Time 설정

 

이외에도 NUMA & THP 설정 해제, Key 만료를 통한 대기시간 최소화 등이 있는데 이는 아래 블로그를 참고 바랍니다.

https://assu10.github.io/dev/2022/10/09/redis-tuning/#1-%EC%84%B1%EB%8A%A5-%ED%8A%9C%EB%8B%9D-%ED%8F%AC%EC%9D%B8%ED%8A%B8

Redis - Redis 튜닝

 

Network bandwith & latency

레디스의 throughput은 주로 네트워크에 의해 결정되는 경우가 많기 때문에 운영 환경에 띄우기 전에 배포 환경의 네트워크 대역폭과 실제 throughput을 체크하는 것을 권장합니다.

 

CPU

레디스는 싱글 쓰레드로 동작하기 때문에 CPU 성능이 중요하며 멀티 쓰레드가 아니기 때문에 코어 수보다는 큰 cache를 가진 빠른 CPU를 선호합니다.

 

RAM 속도 & 대역폭

10KB 이하 데이터 항목들에 대해서는 큰 영향이 없으나 저희 팀이 개발한 서비스처럼 20KB~50KB 이상 학습 데이터를 저장해야 하는 경우 RAM 속도 및 대역폭도 고려 요소 중 하나입니다.

 

가상화 환경의 영향

VM에서 실행되는 경우 워낙 다양한 요소에 의해 영향이 생길 수 있으므로 확인 필요합니다.

• non-local dist
• 오래된 하이퍼바이저의 느린 fork 구현
• etc

 

디스크 블록 사이즈

포맷된 디스크 블록 사이즈가 향후 레디스 서버 전용 메모리 영역의 블록 사이즈로 결정되며 AOF 및 RDB 파일의 블록 사이즈를 결정하는 기준이 되고 포맷 시점에 한번 결정되면 다시 포맷하기 전까지 변경이 불가능하기 때문에 분석과 설계를 통해 신중히 결정해야 합니다.

디스크 블록 사이즈는 해당 서버에 설치된 리눅스 서버의 용도와 데이터 저장량 등을 고려하여 결정해야 합니다.

• TPS가 높고 CRUD 작업이 메인으로 수행될 경우 기본 값보다 한 단계 낮게 설정
• 배치 작업 및 소수의 사용자가 조회 위주의 데이터를 처리하는 용도일 경우 한 단계 높게 설정

 

Client Keep Alive Time 설정

클라이언트가 레디스 서버에 접속한 후 일정 시간이 지나면 해당 세션은 종료되고 다시 재접속을 하는 도중 즉시 접속이 불가한 상태일 때 Wait Time이 발생합니다.

이와 같은 문제점을 해결하기 위해 클라이언트가 일정 시간 동안 작업을 수행하지 않더라도 세션을 설정된 Client Keep Alive Time만큼 유지시킴으로써 재접속을 피하고 Wait Time을 줄일 수 있습니다.

 

성능에 영향을 미치는 레디스 설정

 

redis.conf 내 여러 가지 설정 중 성능에 영향을 미치는 주요한 설정은 아래와 같이 세 가지가 있습니다.

• rdbcompression: 디폴트 값은 yes이며 RDB 파일을 압축할지 여부이며 시스템 자원인 CPU를 절약하고 싶은 경우 no로 설정
• rdbchecksum: 디폴트 값은 yes이며 사용 시 무결성 체크를 하여 안정성을 높일 수 있으나 파일 저장/로드 시에 10% 정도의 오버헤드가 존재하여 성능 저하가 발생할 수 있음
• save: RDB 파일 생성 시 fork() 메서드를 호출하여 별도 프로세스를 띄우므로 시스템 자원이 소모되어 성능에 영향이 있음

 

SLOWLOG 설정

레디스 서버는 redis.conf 내 slowlog-log-slower-than 설정값보다 오래 걸린 명령어들을 slowlog에 수집하여 제공합니다.

측정 기준인 수행시간에 I/O 동작은 제외하고 기준이 millisecond가 아닌 microsecond이기 때문에 1,000,000이 1초입니다.

또한, slowlog-max-len 설정 값을 통해 로그 최대 길이를 제한할 수 있습니다.

 

테스트를 위해 5 microsecond로 설정

 

수집한 로그의 개수를 확인하기 위해서는 slowlog len 명령어를 그리고 조회를 위해서는 slowlog get [count] 명령어를 실행하면 됩니다.

 

 

로그는 순서는 아래와 같습니다.

1) 일렬번호

2) 시간

3) 소요시간

4) 명령어

5) 클라이언트 IP

6) 클라이언트명

 

비고

레디스 서버 설치 시 메모리 영역, 프로세스 영역, 그리고 파일 영역으로 구성되는 기본 아키텍처가 생성되며 이는 아래와 같습니다.

 

https://assu10.github.io/dev/2022/10/09/redis-tuning/#1-%EC%84%B1%EB%8A%A5-%ED%8A%9C%EB%8B%9D-%ED%8F%AC%EC%9D%B8%ED%8A%B8

 

해당 구조가 최적화되지 않은 상태에서 프로세스가 실행되면 Redis 서버 성능이 저하되고 이에 대한 원인 분석 및 대응하는 것을 서버 튜닝이라고 합니다.

 

더 자세한 내용은 블로그를 참고해 주시길 바랍니다.

 

참고

백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리 초격자 패키지 Online - 고성능 서비스를 위한 Redis 활용 및 아키텍처

 

Redis - Redis 튜닝

 

https://m.blog.naver.com/theswice/221498409357

redis-benchmark를 이용한 성능테스트