Redis 운영

Redis 운영 (Redis administration)

프로덕션에서 Redis를 구성하고 관리할 때 알아두면 좋은 조언을 모은 페이지예요.

출처: https://redis.io/docs/latest/operate/oss_and_stack/management/admin/

Redis 설정 팁

Linux

Redis를 Linux 운영체제를 사용해 배포하세요. Redis는 OS X에서도 테스트되고, 가끔은 FreeBSD와 OpenBSD 시스템에서도 테스트돼요. 하지만 스트레스 테스트가 가장 많이 수행되고 실제 배포가 가장 많이 이뤄지는 곳은 Linux예요.

Linux 커널의 overcommit 메모리 설정을 1로 맞추세요. /etc/sysctl.conf에 다음을 추가하세요:

vm.overcommit_memory = 1

그런 다음 재부팅하거나 다음 명령을 실행해 설정을 활성화하세요:

sysctl vm.overcommit_memory=1

자세한 내용은 FAQ: Background saving fails with a fork() error on Linux? 를 참고하세요.

Linux 커널 기능인 Transparent Huge Pages가 Redis의 메모리 사용과 지연에 영향을 주지 않도록 다음 명령을 실행해 비활성화하세요:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

추가 맥락은 Latency Diagnosis - Latency induced by transparent huge pages 를 참고하세요.

메모리

스왑(swap)이 활성화되어 있고 스왑 파일 크기가 시스템 메모리 용량과 같게 설정되어 있는지 확인하세요. Linux에 스왑이 설정되어 있지 않고 Redis 인스턴스가 실수로 너무 많은 메모리를 소비한다면, 메모리가 부족해졌을 때 Redis가 크래시하거나 Linux 커널의 OOM killer가 Redis 프로세스를 죽일 수 있어요. 스왑이 활성화되어 있으면 지연 스파이크를 감지하고 대처할 수 있어요.

인스턴스에 명시적인 maxmemory 옵션 한도를 설정해서, 시스템 메모리 한도에 가까워졌을 때 실패하는 대신 오류를 보고하도록 하세요. maxmemory는 Redis의 데이터 외 오버헤드와 단편화 오버헤드까지 계산해서 설정해야 해요. 예를 들어 여유 메모리가 10GB라고 생각된다면 8이나 9로 설정하는 식이에요.

쓰기(Write) 중심 애플리케이션에서 Redis를 사용하고, RDB 파일을 디스크에 저장하거나 AOF 로그를 다시 쓰는 동안에는 Redis가 평소보다 최대 2배의 메모리를 사용할 수 있어요. 추가 메모리는 저장 과정 중 쓰기에 의해 수정된 메모리 페이지 수에 비례하므로, 이 시간 동안 접근한 키(또는 집계 타입 항목)의 수에 자주 비례해요. 메모리 크기를 그에 맞게 잡으세요.

문제 해결에 도움을 받으려면 LATENCY DOCTOR와 MEMORY DOCTOR 명령을 참고하세요.

이미징 (Imaging)

daemontools 아래에서 실행할 때는 daemonize no를 사용하세요.

복제 (Replication)

Redis가 사용하는 메모리 양에 비례해, 사소하지 않은(non-trivial) 복제 백로그(replication backlog)를 설정하세요. 백로그가 있으면 복제본(replica)이 primary(마스터) 인스턴스와 훨씬 쉽게 동기화할 수 있어요.

복제를 사용한다면, 잘못하면 지속성(persistence)이 비활성화되어 있어도 Redis가 RDB 저장을 수행해요. (이 내용은 diskless 복제에는 적용되지 않아요.) 마스터에 디스크 사용량이 없다면 diskless 복제를 활성화하세요.

복제를 사용한다면, 마스터에 지속성이 활성화되어 있거나, 크래시 시 자동으로 재시작되지 않도록 하세요. 복제본은 마스터의 정확한 사본을 유지하려 하므로, 마스터가 빈 데이터 세트로 재시작하면 복제본도 함께 비워져요.

보안 (Security)

기본적으로 Redis는 어떤 인증도 요구하지 않고 모든 네트워크 인터페이스를 리슨해요. Redis를 인터넷이나 공격자가 접근할 수 있는 다른 곳에 노출해 두면 이건 아주 큰 보안 문제예요. 예를 들어 이 공격을 참고해 얼마나 위험한지 확인하세요. Redis를 보호하는 방법에 대한 정보는 보안 페이지를 확인하세요.

EC2에서 Redis 실행하기

  • PV 기반 인스턴스가 아니라 HVM 기반 인스턴스를 사용하세요.
  • 오래된 인스턴스 패밀리를 사용하지 마세요. 예를 들어 m1.medium with PV 대신 m3.medium with HVM을 사용하세요.
  • EC2 EBS 볼륨과 Redis 지속성을 함께 사용할 때는 주의해서 다뤄야 해요. EBS 볼륨은 때때로 높은 지연 특성을 갖기 때문이에요.
  • 복제본이 마스터와 동기화할 때 문제가 있다면 새로운 diskless 복제를 시도해 볼 수 있어요.

다운타임 없이 Redis 인스턴스 업그레이드/재시작하기

Redis는 서버에서 오래 실행되는 프로세스로 설계됐어요. CONFIG SET 명령으로 재시작 없이 많은 구성 옵션을 수정할 수 있어요. 또한 Redis를 재시작하지 않고도 AOF에서 RDB 스냅샷 지속성으로, 또는 그 반대로 전환할 수 있어요. 자세한 내용은 CONFIG GET * 명령의 출력을 확인하세요.

가끔은 재시작이 필요한 경우도 있어요. 예를 들어 Redis 프로세스를 새 버전으로 업그레이드하거나, CONFIG 명령에서 지원하지 않는 구성 파라미터를 수정해야 하는 경우요.

다음 단계를 따라 다운타임을 피하세요.

  1. 새 Redis 인스턴스를 현재 Redis 인스턴스의 복제본으로 설정하세요. 이를 위해 다른 서버가 필요하거나, 두 개의 Redis 인스턴스를 동시에 실행하기에 충분한 RAM을 가진 서버가 필요해요.
  2. 단일 서버를 사용한다면, 복제본이 마스터 인스턴스와 다른 포트에서 시작되도록 하세요. 그렇지 않으면 복제본을 시작할 수 없어요.
  3. 복제 초기 동기화가 완료될 때까지 기다리세요. 복제본의 로그 파일을 확인하세요.
  4. INFO를 사용해 마스터와 복제본의 키 수가 같은지 확인하세요. redis-cli로 복제본이 예상대로 동작하고 명령에 응답하는지 확인하세요.
  5. CONFIG SET slave-read-only no로 복제본에 쓰기를 허용하세요.
  6. 모든 클라이언트가 새 인스턴스(복제본)를 사용하도록 구성하세요. 전환 중 어떤 클라이언트도 기존 마스터에 쓸 수 없도록 CLIENT PAUSE 명령을 쓰는 것이 좋다는 점에 유의하세요.
  7. 마스터가 더 이상 어떤 쿼리도 받지 않는 것을 확인했다면(MONITOR 명령으로 확인 가능), REPLICAOF NO ONE 명령으로 복제본을 마스터로 승격한 다음 마스터를 종료하세요.

Redis Sentinel이나 Redis Cluster를 사용하고 있다면, 새 버전으로 업그레이드하는 가장 간단한 방법은 복제본을 하나씩 업그레이드하는 것이에요. 그런 다음 수동 장애 조치(failover)를 수행해 업그레이드된 복제본 중 하나를 마스터로 승격하고, 마지막 복제본을 승격하면 돼요.

NOTE: Redis Cluster 4.0은 클러스터 버스 프로토콜 수준에서 Redis Cluster 3.2와 호환되지 않아, 이 경우 전체 재시작이 필요해요. 하지만 Redis 5 cluster bus는 Redis 4와 하위 호환돼요.

더 알아보기 (Learn more)