Redis Sentinel 구조 완전 정리 — 개념 · 구성 요소 · 페일오버 흐름

 

Redis Sentinel 구조 완전 정리 — 개념 · 구성 요소 · 페일오버 흐름

Redis Sentinel은 Redis의 고가용성(HA)을 담당하는 컴포넌트입니다.

이번 글에서는 Sentinel의 역할, 아키텍처(마스터/슬레이브/센티넬),

자동 장애 감지·선출·페일오버 과정, 구성·운영 팁 및 주의사항을 예제와 함께 정리했습니다.

 

한눈에 요약

• Sentinel은 Redis 인스턴스(마스터/복제본)를 모니터링하고, 장애 발생 시 자동으로 새로운 마스터를 선출하고 클라이언트에게 새 마스터의 정보를 줍니다.
• 핵심 컴포넌트: Sentinel 프로세스(다수 권장), 마스터, 슬레이브(복제본).
• 페일오버 주요 단계: 감지(suspect) → 확정(odown) → 협의(선출) → promote(슬레이브→마스터) → reconfig(다른 슬레이브/센티넬 재설정).
• 운영 팁: 홀수 개의 Sentinel, 적절한 quorum·down-after-milliseconds 설정, 모니터링·알림과 복제 지연(Replication lag) 검토.

1. Sentinel이란 무엇인가?

Redis Sentinel은 Redis 클러스터(Standalone 기반)의 고가용성을 제공하기 위한 관리 프로세스입니다. Sentinel은 다음 역할을 수행합니다:

• 마스터·슬레이브 상태의 지속 모니터링
• 마스터 장애 감지 및 자동 페일오버 수행
• 클라이언트와 애플리케이션에 현재 마스터 정보를 제공(예: SENTINEL get-master-addr-by-name)
• 구성(참고: Sentinel은 자체적으로 복제 데이터를 저장하지 않고 설정 상태를 서로 교환)

2. 아키텍처와 구성 요소

기본 구성

• Master — 쓰기 주 노드
• Slave(Replica) — Master의 복제본(읽기, 장애 시 승격 대상)
• Sentinel — 독립 실행 프로세스. 다수의 Sentinel이 클러스터를 감시하고 합의로 페일오버 결정

추천 토폴로지: 최소 3대 이상의 Sentinel(홀수 권장)과 복제본 1~2대 이상을 두는 것이 안정적입니다.

3. 자동 페일오버 흐름 (단계별)

1. 감시(Monitoring) — Sentinel은 주기적으로 마스터/슬레이브에 PING을 보내 상태 확인.
2. 감지(Suspect) — 특정 Sentinel이 응답 없음(또는 장애 징후)을 포착하면 그 마스터를 'subjectively down(SDOWN)'으로 표시.
3. 확정(Consensus) — 여러 Sentinel이 동일 증상을 보고하면 해당 노드는 'objectively down(ODOWN)'으로 간주(쿼럼 필요).
4. 선출(Election) — ODOWN 상태면 Sentinel들이 새로운 마스터 후보를 선출(leader 선출)해 가장 적합한 슬레이브를 promote 대상으로 선택.
5. 승격(Promote) — 선택된 슬레이브를 마스터로 승격(promote slave to master)하고, 나머지 슬레이브들을 새 마스터에 재구성(reconfigure replication).
6. 통지(Notify) — Sentinel은 애플리케이션/운영자에게 이벤트(페일오버 시작/완료 등)를 알리도록 설정 가능(알람/웹훅 등 외부 연동 필요).

중요: 페일오버는 자동이지만 네트워크 분할(분할 브레인)·복제 지연·클라이언트 재연결 로직 등은 운영자가 충분히 고려해야 합니다.

4. sentinel.conf 기본 예제

아래는 sentinel 설정의 핵심 옵션 예시입니다.

# 모니터할 마스터 지정
sentinel monitor mymaster 10.0.0.1 6379 2

# 다운으로 간주하기 전 대기(ms)
sentinel down-after-milliseconds mymaster 5000

# 선출에 필요한 quorum (센티넬 개수의 과반 권장)
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
# 기타 알람·로그 설정
sentinel auth-pass mymaster yourRedisPassword
sentinel known-replica mymaster 10.0.0.2 6379

설명: 위에서 quorum(여기선 '2')는 Sentinel 중 최소 몇 대가 다운을 인지해야 ODOWN으로 간주할지 결정합니다. 실제 환경에 맞춰 조정하세요.

5. 애플리케이션(클라이언트) 관점에서의 처리

• 클라이언트는 Sentinel에 조회하여 현재 마스터를 얻을 수 있음: SENTINEL get-master-addr-by-name mymaster
• 또는 Redis 클라이언트 라이브러리가 Sentinel 지원을 제공할 경우(자동 재연결 및 마스터 조회) 이를 사용하면 편리
• 페일오버 중 쓰기 요청은 실패할 수 있으므로 재시도(backoff) 로직과 idempotency 고려 필요

6. 모니터링·알람·운영 팁

• Sentinel 로그와 Redis INFO 명령어로 상태 감시(예: INFO replication, INFO sentinel)
• Prometheus + Redis exporter, Grafana 대시보드로 메트릭 수집(슬레이브 지연, 연결 수, 메모리 등)
• 페일오버 이벤트는 이메일/슬랙/웹훅으로 알림 연동 권장
• 정기적인 장애 복구 연습(Chaos testing)으로 페일오버 시나리오 검증

7. 주의사항 & 한계

• 분할 브레인(네트워크 파티션) — Sentinel이 분산된 네트워크에서 오판을 할 수 있으므로 quorum·down-after 값을 신중히 설정
• 복제 지연(Replication lag) — 승격 대상이 최신 데이터인지 확인 필요. 큰 지연이 있는 경우 데이터 손실 가능성 존재
• 단일 장애 지점(Single point of failure) — Sentinel 자체를 단 1대로 운영하면 안 됨. 최소 3대 권장
• 클러스터 기능과는 별개 — Redis Cluster 기능(샤딩+HA)과 Sentinel은 다른 목적. 대규모 샤딩 필요시 Redis Cluster 사용 고려

8. 배포·운영 체크리스트

1. Sentinel은 홀수대로(예: 3,5) 분산 배치
2. down-after-milliseconds, failover-timeout, parallel-syncs 값 튜닝
3. 슬레이브는 가능한 서로 다른 호스트/가용영역에 배치
4. 애플리케이션은 Sentinel으로부터 마스터 조회/재연결 로직 구현
5. 모니터링/알림 및 페일오버 복구 시나리오 문서화

마무리 — Sentinel은 HA의 강력한 도구지만 '설계와 테스트'가 핵심

Redis Sentinel은 비교적 가벼운 방식으로 자동 장애 감지와 페일오버를 제공해 서비스 가용성을 높입니다. 하지만 올바른 quorum 설정, 충분한 Sentinel·Replica 수, 복제 지연 관리, 클라이언트 재연결 로직 등 운영적인 준비가 없다면 오작동/데이터 손실 위험이 있으니 반드시 사전 테스트와 모니터링 체계를 갖추세요.

내 Redis 구성 진단 요청하기