Redis Sentinel은 Redis를 위한 간단하고 자동화된 고가용성(HA) 솔루션입니다. MongoDB의 선출(election) 방식에 익숙하다면 그 개념이 크게 다르지 않다는 것을 금방 알 수 있습니다. 기본 구조는 하나의 마스터가 N개의 슬레이브에 복제하는 형태이며, 여기에 애플리케이션 서버 또는 Redis가 실행 중인 서버에 Sentinel 데몬을 띄워 마스터의 상태를 지속적으로 감시합니다.
Sentinel이 마스터가 응답하지 않는다고 판단하면, 다른 Sentinel들에게 SDOWN(주관적 다운, Subjectively Down) 메시지를 브로드캐스트합니다. 이후 과반수(quorum)가 마스터 다운에 동의하면 ODOWN(객관적 다운, Objectively Down) 상태로 전환되고 새로운 마스터가 선출됩니다. ODOWN 상태에 도달하려면 Sentinel 과반수의 동의가 필요하기 때문에, 무승부 상황을 피할 수 있도록 항상 홀수 개의 Sentinel을 운영하는 것이 모범 사례입니다.
참고: Sentinel과 함께 사용할 때 최상의 성능을 얻으려면 Redis 2.8 브랜치 이상 버전을 사용하는 것이 강력히 권장됩니다.
동작 원리
Sentinel은 실행 중인 Redis 인스턴스들의 설정 파일을 재작성(rewrite)하는 방식으로 장애 조치(failover)를 처리합니다. 실제 시나리오를 통해 살펴보겠습니다.
마스터 "A"가 슬레이브 "B"와 "C"에 복제를 수행하고 있고, Redis에 쓰기를 하는 애플리케이션 서버 세 대에 Sentinel(s1, s2, s3)이 실행 중이라고 가정해 보겠습니다. 이때 현재 마스터인 "A"가 오프라인 상태가 됩니다. 모든 Sentinel이 "A"의 오프라인을 감지하고 서로에게 SDOWN 메시지를 전송합니다. 이후 "A"가 다운되었다는 데 합의에 도달하면 "A"는 ODOWN 상태로 지정됩니다. 그다음 누가 가장 앞서 있는지(최신 데이터를 가졌는지)를 판단하는 선출 과정이 진행되며, 이 예시에서는 "B"가 새로운 마스터로 선택됩니다.
이후 "B"의 설정 파일은 더 이상 어떤 노드의 슬레이브도 아니도록 수정됩니다. 동시에 "C"의 설정 파일은 "A"가 아닌 "B"의 슬레이브가 되도록 재작성됩니다. 여기부터는 모든 것이 정상적으로 계속运转됩니다. 만약 "A"가 다시 온라인 상태로 돌아오면, Sentinel이 이를 인식하여 "B"가 현재 마스터이므로 "A"의 설정 파일을 "B"의 슬레이브가 되도록 재작성합니다.
설정 방법
Sentinel 설정은 생각만큼 어렵지 않습니다. 사실 가장 까다로운 부분은 Sentinel 프로세스를 어디에 배치할지 결정하는 일입니다. 저는 가능하다면 애플리케이션 서버에 실행하는 것을 권장합니다. 이런 구성을 고려하고 있다면 아마 마스터에 대한 쓰기 가용성이 걱정될 텐데, Sentinel은 애플리케이션 서버가 마스터와 통신 가능한지 여부를 파악하는 통찰력을 제공합니다. 물론 Redis 인스턴스 서버에 Sentinel을 함께 실행해도 전혀 문제없습니다.
설정을 시작하려면 Redis 배포판에 포함된 예제 파일을 참고하세요. 아래 내용은 Ubuntu 14.04의 Redis 2.8.4에 포함된 sentinel.conf 예제이지만, 2.8.x 버전이라면 어디서든 동작합니다. 실무에서 유용하게 쓰는 두 줄을 맨 위에 추가했습니다:
daemonize yes
logfile /var/log/redis/redis-sentinel.log이렇게 하면 Sentinel 프로세스가 데몬 모드로 실행되고, 모든 메시지가 stdout 대신 로그 파일에 기록됩니다.
설정 파일에는 매우 많은 옵션이 있으며 대부분 잘 주석 처리되어 있습니다. 여기서는 핵심 두 가지만 짚어보겠습니다.
1. 마스터 지정하기
가장 중요한 부분은 현재 마스터의 위치를 Sentinel에게 알려주는 것입니다. 해당 설정은 다음 줄에 있습니다:
sentinel monitor mymaster 127.0.0.1 6379 2이 설정은 Sentinel에게 "mymaster"(임의의 이름이므로 원하는 대로 지정하면 됩니다)라는 이름으로 특정 IP와 포트의 마스터를 감시하도록 지시하며, 마지막 숫자는 장애 조치를 위해 quorum을 충족하는 데 필요한 Sentinel 수입니다(최소 2). 변경이 필요한 부분은 마스터의 IP 주소와, 표준 포트 6379를 사용하지 않는 경우 포트 번호입니다.
2. 다운 판정 시간 조정
다음으로 아래 설정을 조정할 수 있습니다:
sentinel down-after-milliseconds mymaster 30000이 값은 Sentinel이 마스터를 SDOWN으로 선언하기까지 기다리는 시간(밀리초)입니다. 기본값은 30초이며, 저는 보통 10초 정도로 낮추는 편입니다. 다만 너무 낮추면 장애 조치가 너무 자주 발생하는 문제가 생길 수 있으니 주의하세요.
그 외 옵션들도 살펴볼 만합니다. 특히 장애 조치 발생 시 알림을 받고 싶다면 notification script(알림 스크립트) 옵션이 유용합니다.
sentinel.conf를 원하는 대로 구성했다면, 다음 명령으로 데몬을 시작합니다:
redis-server /path/to/sentinel.conf --sentinel장애 조치 테스트
모든 Sentinel이 온라인 상태가 되면, 드라이 런(dry run) 방식으로 장애 조치를 테스트하여 설정이 올바른지 확인할 수 있습니다.
먼저 redis-cli로 Sentinel에 접속합니다:
redis-cli -p 26379Sentinel에 대한 정보를 확인하려면 다음 명령을 실행합니다:
127.0.0.1:26379> INFO이 명령을 통해 현재 마스터가 누구인지, 슬레이브가 몇 개인지, 몇 개의 Sentinel이 감시 중인지 등의 정보를 얻을 수 있습니다.
장애 조치를 테스트하려면 다음 명령을 실행하기만 하면 됩니다:
127.0.0.1:26379> SENTINEL failover mymaster이 명령은 현재 마스터에 강제로 ODOWN을 발생시켜 장애 조치를 유발합니다. 잠시 후 "INFO" 명령을 다시 실행하면 새로운 마스터가 지정된 것을 확인할 수 있습니다.
마무리
이 글이 Redis와 Sentinel의 동작 방식을 이해하는 데 도움이 되었기를 바랍니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!