Redis 장애 복구(Failover) 매커니즘 분석: Sentinel vs Cluster

Redis 운영의 핵심은 "Master 노드가 죽었을 때 서비스가 얼마나 빨리, 자동으로 복구되느냐"임. 구성 방식에 따라 장애를 감지하고 복구하는 주체와 프로세스가 완전히 다름.

각 방식별 Failover 메커니즘을 상세히 정리함.

---

1. Standalone (Replication Only)

가장 기초적인 Master-Replica 구조임. 자동 복구가 불가능하다는 것이 핵심.

장애 복구 프로세스 (수동)

1. 장애 발생: Master 노드 다운.
2. 서비스 중단: Application에서 쓰기(Write) 작업 실패 발생.
3. 관리자 개입:
   • 개발자/엔지니어가 알람을 보고 접속.
   • Replica 노드에 직접 접속하여 승격 명령어 실행.

   # Replica 노드에서 실행하여 Master로 승격
   REPLICAOF NO ONE

4. 설정 변경: Application 서버의 Redis 연결 설정을 새로운 Master IP로 변경 후 배포/재시작.

특징

• Down Time이 긺: 사람이 직접 대응해야 하므로 야간이나 휴일 장애 시 서비스 중단 시간이 매우 길어질 수 있음.
• 감시 주체 없음: 별도의 헬스 체크 시스템이 없으면 장애 인지가 늦음.

---

2. Redis Sentinel (센티널)

별도의 감시 프로세스(Sentinel)가 관리자를 대신해 장애를 감지하고 복구함.

장애 복구 프로세스 (자동)

1. 장애 감지 (SDOWN -> ODOWN):
   • Sentinel 인스턴스가 Master에게 주기적으로 PING을 날림.
   • 응답이 없으면 해당 Sentinel은 SDOWN(Subjective Down, 주관적 다운)으로 인지.
   • 설정된 Quorum(정족수) 이상의 Sentinel들이 "얘 죽은 거 맞다"고 동의하면 ODOWN(Objective Down, 객관적 다운)으로 확정.
2. 리더 선출: Sentinel들끼리 투표하여 Failover를 진행할 '리더 Sentinel'을 선출함.
3. Failover 실행:
   • 리더 Sentinel이 건강한 Replica 중 하나를 선택.
   • 해당 Replica에게 REPLICAOF NO ONE 명령어를 전송해 Master로 승격시킴.
   • 나머지 Replica들이 새 Master를 바라보도록 설정 변경 (REPLICAOF new-master-ip port).
4. Client 전파:
   • Client는 Sentinel에게 현재 Master 주소를 질의하다가 변경된 주소를 받게 됨 (Pub/Sub 메커니즘 활용).

특징

• 감시 주체: 별도의 redis-sentinel 프로세스.
• 클라이언트 지원 필수: Application 코드(라이브러리)가 Sentinel 기능을 지원해야 함. (직접 Redis IP를 박는 게 아니라 Sentinel IP 리스트를 설정함).

---

3. Redis Cluster (클러스터)

Sentinel 없이 노드들끼리 서로 감시(P2P)하며 집단지성으로 복구함.

장애 복구 프로세스 (자동 - Gossip Protocol)

1. 상호 감시: 클러스터 내 모든 Master 노드는 서로 mesh 구조로 연결되어 PING/PONG을 주고받음 (Gossip Protocol).
2. 장애 감지 (PFAIL -> FAIL):
   • Node A가 Node B에게 응답을 못 받으면 PFAIL(Possible Fail)로 마킹.
   • 다른 Master 노드들에게도 Gossip 메시지로 Node B 상태를 물어봄.
   • 과반수 이상의 Master가 PFAIL이라 판단하면 FAIL 상태로 확정하고 클러스터 전체에 브로드캐스팅.
3. 승격 투표:
   • 죽은 Master의 Replica가 이를 감지하고 승격 선거를 시작. ("나 Master 할게 투표 좀 해줘")
   • 살아있는 다른 Master 노드들이 투표(Vote)함.
4. Failover 실행:
   • 과반수 표를 얻은 Replica가 Master로 승격.
   • 자신이 담당할 Hash Slot 정보를 갱신하고 클러스터 설정(Epoch)을 업데이트.

특징

• 감시 주체: Redis Master 노드 자신들 (Sentinel 불필요).
• 리다이렉션: 클라이언트는 아무 노드나 접속했다가, 해당 Key가 다른 노드에 있으면 MOVED 에러와 함께 올바른 주소로 리다이렉트됨.

---

4. 요약 비교

구분	Standalone	Sentinel	Cluster
자동 복구	불가능 (수동)	가능	가능
감시 주체	(없음)	Sentinel 프로세스	Redis 노드 간 (Gossip)
장애 판단	사람	Sentinel 간 투표 (Quorum)	Master 간 투표 (과반수)
클라이언트	IP 변경 후 재배포 필요	Sentinel 라이브러리 지원 필요	Smart Client (리다이렉트 처리) 필요
복잡도	낮음	중간	높음

결론

• Sentinel: 별도의 감시반(보디가드)을 고용해서 지키게 하는 방식.
• Cluster: 구성원들끼리 서로 생존 신고하며 빈자리를 채우는 자치적인 방식.