Sentinel(센티널)
레디스는 따로 백업 설정을 하지 않으면 모든 데이터가 사라지게 되고 서비스 전체 장애로 이어지게 되는데, 이를 방지하기 위해 레디스는 센티넬이라는 고가용성 솔루션을 제공한다.
모니터링: 마스터 / 복제본 인스턴스 상태 실시간 확인
자동 페일오버: 마스터의 비정상 상태를 감지해 복제본 중 하나를 새로운 마스터로 승격
인스턴스 구성 정보 안내: 센티넬은 클라이언트에게 현재 구성의 마스터 인스턴스 정보를 제공하여, 클라이언트가 자동으로 마스터 인스턴스를 찾을 수 있도록 지원
분산 시스템에서의 센티널
센티널 네트워크를 통해 모니터링 결과와 장애 감지 정보를 공유하며, 특정 노드에 장애가 발생했다고 판단될 때 다수의 센티널이 이에 동의해야만 페일오버 절차를 시작한다.
쿼럼(Quorum)
쿼럼은 마스터 노드가 장애 상태임을 객관적으로 판단하기 위해 최소 몇 개의 센티널이 해당 마스터를 도달 불가능하다고 동의해야 하는지를 의미한다.
일반적으로 쿼럼 수는 센티널 인스턴스의 과반수 이상으로 설정하는 것이 권장
3대의 센티널이 운영 중이라면 쿼럼은 2 이상으로 설정해, 최소 2개의 센티널이 장애를 감지하면 실제 장애로 판단
실제 페일오버를 수행은 리더 센티널이 담당 수행
쿼럼은 장애 감지에만 사용되며, 실제 페일오버를 수행하기 위해서는 센티넬 프로세스의 과반수가 동의한 센티널 리더가 페일오버를 수행
Redis 센티널의 고가용성을 확보하기 위해서는 센티널 인스턴스를 다음과 같이 분산 배포하는 것이 중요하다.
서버 및 가용 영역 분산: 각 인스턴스는 서로 다른 물리적 서버 또는 가용 영역에 배포
최소 3대 이상의 센티널 인스턴스 운영: 쿼럼을 이용한 과반수 선출 개념을 사용하기 때문에 3대 이상의 홀수로 구성을 권장
센티널 인스턴스 배치 방법
안정적인 고가용성 환경을 구축하려면, 센티넬 인스턴스는 최소 3대 이상의 홀수로 구성하고, 각 인스턴스는 서로 다른 물리적 서버나 가용 영역(Availability Zone)에 분산하여 배포해야 한다.
각 서버에는 하나의 Redis 인스턴스(마스터 또는 레플리카)와 하나의 센티널 인스턴스를 함께 배치
센티널 인스턴스가 서로 다른 서버에 위치하게 되어, 서버 장애 시에도 센티널 다수결(쿼럼)을 통한 장애 감지 및 자동 페일오버 가능
구성 예시(3 Servers)
Server A: Redis Master + Sentinel
Server B: Redis Replica (Slave) + Sentinel
Server C: Redis Replica (Slave) + Sentinel
자동 페일오버 과정
마스터 장애 상황 감지
각 센티널은 주기적으로
PING명령어를 사용하여 마스터 노드의 상태를 확인down-after-milliseconds기간 동안 응답이 없거나 비정상 응답이면 해당 센티널은sdown상태(subjectively down)로 판단
sdown->odown실패 상태로 전환sdown을 감지한 센티넬은 다른 센티널 노드들에게 장애 사실을 전파전파를 받은 센티널들은 해당 마스터에 대한 상태를 확인하고, 쿼럼 값 이상의 센티널이 동의하면
odown상태(objectively down)로 전환
에포크(epoch) 증가
장애가 확정되면 각 센티널은 페일오버를 위한 새로운 에포크(epoch) 값을 증가시켜 고유한 페일오버 시도를 구분
odown이 확정되면 각 센티널은 새로운 페일오버 라운드를 구분하기 위해current-epoch를 증가(처음엔 1)각 센티널은 해당 에포크에서 한 후보에게만 투표할 수 있으며, 에포크 값은 서로 다른 페일오버 시도를 식별하는 버전 역할 수행
센티널 리더 선출
센티널들은 동일 에포크에서 리더가 될 의사를 표명하고 상호 투표 수행
과반수의 표를 얻은 센티널이 리더가 됨
복제본 선정 및 마스터 승격
리더 센티널은 후보 복제본들 중 승격 대상을 선정
redis.conf파일에 명시된replica-priority낮은 복제본마스터로부터 많은 데이터를 수신한 복제본
선정한 복제본에
SLAVEOF NO ONE명령어를 수행해, 기존 마스터로부터 복제를 중단
복제 연결 변경
나머지 복제본들에
REPLICAOF <new-master-ip> <port>를 전송해 새 마스터를 따라가도록 재구성
스플릿 브레인(Split Brain)
스플릿 브레인은 네트워크 단절(Network Partition)로 인해 분산 시스템이 두 개 이상의 독립적인 그룹으로 나뉘고, 각 그룹이 자신이 유일한 정상 그룹이라고 착각하여 발생하는 문제다.
센티널 환경에서 스플릿 브레인이 발생하면, 네트워크가 분리된 각 파티션 내의 센티널들이 서로 통신하지 못하게 됨
각 파티션이 독립적으로 장애를 감지하고 페일오버를 수행할 수 있음
결과적으로 두 개 이상의 마스터가 동시에 존재하는 상황 발생
최종적으로 두 마스터 간 데이터 불일치 및 데이터 유실로 이어질 수 있음
네트워크 파티션으로 인해 Partition A(마스터 + Sentinel A)와 Partition B(레플리카 2대 + Sentinel B, Sentinel C)로 나뉘는 상황의 예시는 다음과 같다.
+---------------------------+ +---------------------------+
| Partition A | | Partition B |
| | | |
| +---------------------+ | | +---------------------+ |
| | Sentinel A | | | | Sentinel B | |
| +---------------------+ | | +---------------------+ |
| +---------------------+ | | +---------------------+ |
| | Redis Master | | | | Redis Replica | |
| +---------------------+ | | +---------------------+ |
| | | +---------------------+ |
| | | | Sentinel C | |
| | | +---------------------+ |
| | | +---------------------+ |
| | | | Redis Replica | |
| | | +---------------------+ |
+---------------------------+ +---------------------------+네트워크 단절 상황
마스터 노드와 Sentinel A가 포함된 네트워크 영역 A, 복제본 노드 2대와 Sentinel B, Sentinel C가 포함된 네트워와 영역 B) 간 네트워크 단절 발생
두 네트워크 영역은 서로를 인식하지 못함
센티널 동작 과정
Sentinel B와 Sentinel C는 마스터 노드에 접근하지 못해 마스터를 비정상으로 판단하고 Failover를 시작
과반수(3대 중 2대)인 Sentinel B와 C가 같은 파티션에 있어 복제본 중 하나를 새로운 마스터로 승격
스플릿 브레인 발생
네트워크 단절이 지속되는 동안 기존 마스터(Partition A)와 새로 승격된 마스터(Partition B)가 동시에 마스터 역할 수행
두 개의 독립 마스터가 존재하면서 데이터 불일치 발생
+------------------------------------------------------------+
| 클라이언트 연결 |
+------------------------------------------------------------+
| |
| 기존 클라이언트 새로운 클라이언트 |
| |
| +-------------------+ +-------------------+ |
| | | | | |
| | 기존 마스터 (A) | | 새로운 마스터 (B) | |
| | | | | |
| +---------+---------+ +---------+---------+ |
| | | |
| | | |
| +---------v---------+ +---------v---------+ |
| | Sentinel A | | Sentinel B, C | |
| +-------------------+ +-------------------+ |
| |
+------------------------------------------------------------+기존 연결된 클라이언트의 동작
기존 마스터에 연결된 클라이언트는 네트워크 단절의 영향을 받지 않으면 계속 기존 마스터에 쓰기를 수행
기존 마스터의 데이터는 승격된 새로운 마스터와 동기화되지 않음
새로운 클라이언트의 동작
새로운 클라이언트는 Sentinel에 현재 마스터 주소를 요청
단절 상황에서 Sentinel B/C는 승격된 새 마스터의 주소를 반환하므로, 새로운 클라이언트는 새 마스터에 쓰기를 수행
네트워크 복구 후
네트워크가 복구되면 기존 마스터는 Sentinel B/C의 결정에 따라 새 마스터의 복제본으로 재구성
이 과정에서 기존 마스터(이제 복제본)의 데이터가 초기화되며, 단절 기간 동안 기존 마스터에 기록된 데이터는 유실될 수 있음
방지 대책
레디스는 스플릿 브레인으로 인한 데이터 유실을 최소화하기 위한 설정을 제공한다.
min-replicas-to-write <count>: 마스터가 쓰기 작업을 처리하기 위해 최소한 연결되어 있어야 하는 복제본의 수min-replicas-max-lag <seconds>: 복제본의 복제 지연(lag)이 이 설정 시간을 초과하면 마스터는 쓰기 작업을 거부
이 설정들을 통해 마스터는 자신에게 연결된 복제본이 일정 수 미만이거나 복제가 너무 지연되면, 스스로를 읽기 전용(read-only) 상태로 전환하여 데이터 불일치가 심화되는 것을 막는다.
참고자료
Last updated
Was this helpful?