1. 서론

Sentinel은 사전적인 의미로 보면 보초병, 감시병이라는 뜻이다. 이름에서부터 어떠한 역할인지 느껴진다.

Sentinel은 Redis의 Automatic Failure Solution이라고 표현되기도 한다. 초창기에 Redis에는 failover 개념이 없었다. 따라서 다른 방식으로 failover를 구성하여 사용하게 되었는데 ZooKeeper를 이용한 아키텍처도 그 중 하나였다. 물론 여기에는 Redis 인스턴스 별 관리의 어려움 등 문제가 있었다. 


2. 본론

Redis의 고가용성 구성을 위해 필수적인 Redis Sentinel. 그 주요 기능은 다음과 같다.

2-1. 방식

Redis 클러스터의 MASTER 및 SLAVE 인스턴스를 항상 점검하여 예상대로 작동하는지 확인한다. Sentinel이 주어진 클러스터의 MASTER 노드에서 장애를 감지하면 장애 조치 프로세스를 시작한다. 결과적으로 Sentinel은 SLAVE 인스턴스를 선택하고이를 MASTER로 승격하며, 궁극적으로 다른 나머지 SLAVE 인스턴스는 새 MASTER 인스턴스를 사용하도록 자동으로 재구성된다.

2-2. Monitoring

Redis Master, Slave가 잘 동작하고 있는지 모니터링한다.

2-3. Notification

비정상인 Redis 인스턴스가 있다면 API를 통하여 알린다.

2-4. Automatic failover

Master가 비정상이라면 Slave를 Master로 승격시킨다. 그리고 남은 Slave들이 새로운 Master로 연결되도록 설정하며, Redis를 사용하는 응용은 접속 시 새로운 Master 주소를 부여 받는다.

2-5. Configuration provide

 클라이언트는 현재 Redis Master의 주소를 얻기 위하여 Sentinel에 접속한다. 만일 failover되면, Sentinel은 새로운 주소를 알린다.


3. Quorum

Quorum은 MASTER에 도달 할 수없는 사실에 대해 동의해야 Sentinel의 수다. 그러나 Quorum은 오류를 감지하는 용도로만 사용된다. 실제적으로 failover를 수행하려면 Sentinel 중 하나가 장애 조치를 위해 선출 된 리더가 되어야 하고 진행할 권한이 있어야한다. 이것은 대다수의 Sentinel 프로세스 투표에서만 발생한다.


4. 상태

Sentinel은 당연히 Redis들이 설치되어 있어야 사용이 가능하다. "Redis가"가 아니고 "Redis들이"라고 언급한 바와 같이 복수개의 Redis가 설치되어 있어야 한다. 그리고 최소한 하나의 Master, 하나의 Slave 구조로 이루어져 있어야 Sentinel의 의미가 있다.

Sentinel은 Redis의 상태를 아래와 같이 둘로 구분한다.

4-1. Subjectively Down (SDOWN)

하나의 Sentinel이 문제가 있다고 판단한다. (참고로 ping 명령을 이용하여 주기적으로 체크한다) 그러나 이것만으로 failover를 하지는 않는다. 아래의 Objectively Down이 되어야 failover가 된다.

4-2. Objectively Down (ODOWN)

최초에 문제가 있어서 Subjectively Down, 그리고 다른 Sentinel의 과반수 이상에서 역시 문제가 있다고 동의하면 비로소 Objectively Down 상태가 되어 failover된다.


5. 기타 잡지식

  • Sentinel은 기본 26379 포트를 사용한다.
  • 3개 이상, 홀수개로 만드는 것을 권장한다. (새로운 Master를 선출하기 위한 투표를 위함)

 

관련 유용한 링크 : http://objectrocket.com/blog/how-to/introduction-to-redis-sentinel

 

오늘은 여기까지 알아보고 다음에 실제 설치하는 과정을 살펴보도록 하겠다.