백엔드 데이터 인프라 69편 — Redis Sentinel (자동 Failover · Quorum)

이 글은 백엔드 데이터 인프라 시리즈 130편 중 69편이에요. 68편 에서 Cluster 가 큰 쓰기 분산·메모리 분산이 필요한 경우 의 선택이라면, 이번 69편은 Sentinel (Redis 의 자동 장애 감지·복구 데몬) — 데이터는 단일 인스턴스 + Replication 으로 충분하지만 자동 HA 가 필요할 때 의 표준 도구.

Sentinel이 어렵게 느껴지는 이유

Sentinel 은 별도 프로세스 (Redis master/replica 외에 또 다른 것) 라 처음 보면 왜 또 인스턴스가 필요한가 가 의문.

첫째, Quorum 과 Majority 가 다릅니다. quorum = "장애 감지에 동의" 필요 sentinel 수, majority = "failover 진행 인가" 필요 sentinel 수. 둘이 따로 동작.

둘째, Sentinel 자체도 분산 시스템. Sentinel 들끼리 통신하고 합의하며 split-brain 을 막아야 해서 Sentinel 운영 자체 가 한 가지 학습 거리.

셋째, 클라이언트가 Sentinel-aware 여야. Redis master 주소 가 Sentinel 에서 동적으로 알려주는 값 이라, 클라이언트가 현재 master 를 Sentinel 에 물어보고 사용 해야. 단순 IP·port hard-coding 패턴이 failover 후 깨짐.

이 글에서 Sentinel 의 4가지 기능·Quorum/Majority·SDOWN/ODOWN·자동 failover 흐름·Spring 통합·Cluster 와의 선택까지.

Sentinel 의 4가지 기능

Sentinel 이 맡는 일은 네 가지. Monitoring 은 master·replica 들에 PING 을 보내 응답과 상태를 체크하고, Notification 은 장애가 발생하면 관리자나 외부 시스템에 스크립트로 알린다. Automatic Failover 는 master 가 죽었다고 판단되는 순간 replica 를 자동으로 promote 시키고, Configuration Provider 는 클라이언트가 현재 master 가 누구인지 물었을 때 답해주는 Service Discovery 역할을 한다.

배포 모델

+-----+
| M1  |   ← Redis master
| S1  |   ← Sentinel 1
+-----+
   |
+-----+   +-----+
| R2  |   | R3  |   ← Replicas
| S2  |   | S3  |   ← Sentinels
+-----+   +-----+

Quorum = 2 (3 Sentinels 중 2명 동의로 failover 트리거)

최소 3개 Sentinel 권장 (홀수). 2개면 Sentinel 자체가 split-brain 위험.

왜 3개?

Sentinel A 와 B 가 네트워크 분리 되어 서로 못 봄 → 둘 다 상대를 죽은 것으로 판단 → 양쪽이 각자 failover 진행 → 두 master 생기는 split-brain.

3개 이상 + quorum 2 → 한 sentinel 이 분리 되어도 나머지 2가 majority 형성 → split-brain 안전.

설정 — sentinel.conf

port 26379
sentinel monitor mymaster 192.168.1.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

각 줄의 의미를 풀어보면, monitor <name> <ip> <port> <quorum> 은 감시할 master 를 정의하면서 quorum 을 같이 명시한다. down-after-milliseconds 는 몇 ms 응답이 없으면 SDOWN 으로 마킹할지(여기선 5초)를 잡고, failover-timeout 은 failover 진행의 최대 시간(60초)을, parallel-syncs 는 한 번에 몇 개 replica 가 새 master 와 동기화 할지를 정한다(1 이면 순차).

SDOWN vs ODOWN — 장애 감지 2단계

여기가 시험 함정 자주 나오는 자리.

SDOWN (Subjectively Down) — 주관적 다운

Sentinel A 가 master 에 PING 보냄
down-after-milliseconds (5초) 응답 X
Sentinel A 가 master 를 SDOWN 마킹

한 sentinel 의 주관적 판단. 아직 failover 트리거 X.

ODOWN (Objectively Down) — 객관적 다운

Sentinel A 가 SDOWN 마킹 후 다른 Sentinel 들에게 알림
다른 Sentinel 들 중 quorum 수만큼 동의하면
master 를 ODOWN 마킹

quorum 수가 동의 → ODOWN → failover 시작.

Quorum vs Majority

여기가 정말 중요한 자리. Quorum 은 ODOWN 마킹에 필요한 sentinel 수(예: 2)이고, Majority 는 실제 failover 진행 인가에 필요한 sentinel 수, 즉 전체의 과반수 다.

5개 Sentinel, quorum=2 인 경우:
- 2개 sentinel 이 동의 → ODOWN (장애 감지 단계)
- 그러나 failover 진행은 3개 이상 (majority) 필요

Quorum 작게 잡으면 = 민감한 장애 감지 / 너무 작으면 = false positive (잠시 네트워크 hiccup 으로 불필요한 failover).

권장 — 전체 Sentinel 의 과반 가까이 (5개면 quorum 3).

자동 Failover 흐름

1. master 가 down-after-milliseconds 동안 응답 X
   → SDOWN by Sentinel A
2. Sentinel A 가 다른 Sentinel 들에게 sentinel is-master-down-by-addr 보냄
3. quorum 수만큼 동의 → ODOWN
4. Sentinel 들 중 leader 선출 (Raft-like 알고리즘)
5. Leader 가 replica 중 가장 적합한 것 선택 (priority·offset 기준)
6. 선택된 replica 에 REPLICAOF NO ONE → 새 master 됨
7. 다른 replica 들에 REPLICAOF <new_master>
8. 클라이언트가 Sentinel 에 새 master 물어봄 (Service Discovery)

전체 ~10~30초. 클라이언트 측 잠시 에러 + 재연결.

적합한 Replica 선택 기준

여러 replica 중 누가 새 master 가 될지는 세 가지 기준으로 정해진다. 먼저 replica-priority 가 가장 낮은 (0 제외) 것을 본 다음, 거기서 master 와의 offset 이 가장 큰 (최신 데이터를 가진) 쪽을 고르고, 그래도 동률이면 Run ID 가 사전순 가장 작은 것을 선택한다.

replica-priority 0 으로 박으면 failover 후보 제외. 분석 전용 replica 같은 곳에 박음.

클라이언트 통합 — Sentinel-aware

Python (redis-py)

from redis.sentinel import Sentinel

sentinel = Sentinel([
    ('sentinel-1', 26379),
    ('sentinel-2', 26379),
    ('sentinel-3', 26379),
], socket_timeout=0.5)

# 현재 master 가져오기
master = sentinel.master_for('mymaster', socket_timeout=0.5)
master.set('key', 'value')

# 읽기는 replica 에서
slave = sentinel.slave_for('mymaster', socket_timeout=0.5)
slave.get('key')

핵심 — 클라이언트가 Sentinel 에 master 물어보고 사용. Failover 후 자동 재라우팅.

Spring Data Redis

spring:
  data:
    redis:
      sentinel:
        master: mymaster
        nodes:
          - sentinel-1:26379
          - sentinel-2:26379
          - sentinel-3:26379

Lettuce·Jedis 둘 다 Sentinel 지원. 자동 failover 감지 + 재연결.

Sentinel vs Cluster — 결정 기준

여기까지 따라오셨다면 한 가지 의문 — "Cluster 도 자동 failover 되는데 둘 다 자동 HA? 차이가?". 답:

선택

메모리가 30GB 미만이고 HA 만 필요하면 단순함을 우선해 Sentinel 로 가고, 메모리가 30GB 를 넘거나 쓰기 TPS (초당 처리 트랜잭션 수) 가 매우 크면 분산이 필요해 Cluster 가 답이다.

대부분의 일반 백엔드 환경은 Sentinel 로 충분. Cluster 는 정말 큰 환경 에만.

한계·실무 함정

1. Sentinel 자체 가용성

Sentinel 들도 프로세스가 죽거나 네트워크 분리 될 수 있어요. 3개 미만이면 위험. Sentinel 노드도 별도 failure domain 에 분산.

2. quorum 너무 작게 잡음

false positive 위험. 짧은 네트워크 hiccup 으로 불필요한 failover. quorum 전체의 과반 권장.

3. down-after-milliseconds 너무 짧게

5초 미만 으로 잡으면 잠시 GC pause·네트워크 지연으로 failover 트리거. 30~60초 권장.

4. Notification script 안 설정

장애 발생해도 운영자가 모름. sentinel notification-script 또는 외부 모니터링 시스템 연동 필수.

5. Failover 도중 데이터 손실

비동기 복제 → master 죽기 직전 복제 안 된 쓰기 손실. RPO (Recovery Point Objective, 복구 시점 목표) ≠ 0. 진짜 0 손실 필요 시 다른 솔루션.

시험 직전 한 번 더 — Redis Sentinel 함정 압축 노트

• Sentinel = 단일 인스턴스 + Replication 환경의 자동 HA
• 4가지 기능 = Monitoring · Notification · Automatic Failover · Service Discovery
• 최소 3개 Sentinel + 홀수 권장
• 2개 = split-brain 위험
• 설정 = sentinel.conf, 포트 기본 26379
• monitor <name> <ip> <port> <quorum> 으로 master 등록
• SDOWN = 한 sentinel 의 주관적 다운 판단
• ODOWN = quorum 수의 sentinel 동의 → 객관적 다운
• Quorum = ODOWN 마킹 동의 수
• Majority = failover 진행 인가 수 = 전체의 과반
• Quorum 작게 = 민감 / 너무 작게 = false positive
• 권장 = 전체의 과반 가까이 (5개면 quorum 3)
• 자동 failover = SDOWN → ODOWN → Leader 선출 → 적합한 replica promote → 다른 replica 재설정 → Service Discovery
• 전체 ~10~30초
• Replica 선택 기준 = replica-priority (낮을수록 우선) → offset (큰 것 우선) → Run ID
• replica-priority 0 = failover 후보 제외
• 클라이언트 = Sentinel-aware (Master IP hard-coding X)
• 패턴 = Sentinel 들 목록 + master name 으로 동적 라우팅
• Spring Data Redis = sentinel.master + sentinel.nodes 설정
• Sentinel vs Cluster — Sentinel = 단일 인스턴스 HA / Cluster = 샤딩 + HA
• 선택 — <30GB + HA = Sentinel / >30GB = Cluster
• 대부분 환경 = Sentinel 충분
• 함정 — quorum 너무 작 = false positive
• 함정 — down-after-milliseconds 너무 짧 = GC pause 로 failover
• 권장 = 30~60초
• 함정 — Notification script 누락 = 장애 모름
• 함정 — 비동기 복제 → failover 시 데이터 손실 가능 (RPO ≠ 0)

공식 문서: Redis Sentinel 에서 자세한 설정·운영 가이드를 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 64편 — Twitter Clone 패턴 + Fanout 전략
• 65편 — Secondary Indexing 패턴 (RDB 인덱스 모방)
• 66편 — Redis Persistence (RDB · AOF · Hybrid)
• 67편 — Redis Replication (Master-Replica)
• 68편 — Redis Cluster (Sharding · 16384 슬롯 · Hash Tag)

다음 글:

• 70편 — Redis ACL (사용자·권한 관리)
• 71편 — Redis TLS (전송 암호화 · mTLS)
• 72편 — Redis 메모리 최적화 (Encoding · Hash 압축 · Fragmentation)
• 73편 — Spring Data Redis (RedisTemplate · @Cacheable)
• 74편 — RedisJSON (JSON.SET · JSONPath · PG JSONB 비교)