Redis Sentinel 이란?
Redis Sentinel은 Redis 마스터-레플리카 구성을 감시하고, 마스터 장애 시 레플리카를 자동으로 승격(failover)해 주는 고가용성 솔루션입니다. 별도 프로세스로 동작하며 다음 역할을 수행합니다.
- 모니터링: 마스터·레플리카가 살아 있는지 지속 점검
- 알림: 장애 발생 시 이벤트 통지
- 자동 페일오버: 마스터 다운 시 레플리카 승격
- 서비스 디스커버리: 클라이언트에 현재 마스터 주소 제공
Sentinel은 데이터 샤딩이 아닙니다. 데이터 분산이 목적이라면 Redis Cluster를 사용하세요. Sentinel은 "단일 마스터의 가용성"을 책임집니다.
권장 토폴로지
가장 흔한 구성은 마스터 1 + 레플리카 2 + Sentinel 3 입니다.
| 노드 | IP | 역할 |
|---|---|---|
| node1 | 192.168.1.21 | Redis Master + Sentinel |
| node2 | 192.168.1.22 | Redis Replica + Sentinel |
| node3 | 192.168.1.23 | Redis Replica + Sentinel |
Sentinel은 반드시 홀수(3 이상) 로 두어야 합니다. 그래야 네트워크 분할 시 다수결(quorum)로 정확히 한쪽만 페일오버를 진행할 수 있습니다.
1. Redis 복제 구성
먼저 일반적인 마스터-레플리카를 만듭니다.
마스터(node1) redis.conf:
bind 0.0.0.0 -::1
port 6379
requirepass MasterAuth!2026
masterauth MasterAuth!2026
appendonly yes레플리카(node2, node3) redis.conf:
bind 0.0.0.0 -::1
port 6379
requirepass MasterAuth!2026
masterauth MasterAuth!2026
replicaof 192.168.1.21 6379
appendonly yesmasterauth 와 requirepass 를 모든 노드에 동일하게 설정해야 페일오버 후 새 마스터에도 정상 연결됩니다. 복제 상태는 다음으로 확인합니다.
redis-cli -a MasterAuth!2026 info replication# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.22,port=6379,state=online,offset=...2. Sentinel 설정
각 노드의 sentinel.conf:
port 26379
bind 0.0.0.0
# 감시할 마스터: <이름> <ip> <port> <quorum>
# quorum 2 = 2개 Sentinel이 다운에 동의해야 페일오버 시작
sentinel monitor mymaster 192.168.1.21 6379 2
# 마스터 인증(requirepass 사용 시 필수)
sentinel auth-pass mymaster MasterAuth!2026
# 응답이 없으면 주관적 다운(SDOWN)으로 판단할 시간(ms)
sentinel down-after-milliseconds mymaster 5000
# 페일오버 중 동시에 새 마스터와 동기화할 레플리카 수
sentinel parallel-syncs mymaster 1
# 페일오버 전체 타임아웃(ms)
sentinel failover-timeout mymaster 60000quorum 은 "페일오버를 시작할지 합의하는 데 필요한 Sentinel 수"이고, 실제 페일오버 실행은 전체 Sentinel 과반(majority) 의 투표가 추가로 필요합니다. Sentinel 3대라면 quorum 2가 표준입니다.
실행:
redis-sentinel /etc/redis/sentinel.conf
# 또는 systemd
sudo systemctl enable --now redis-sentinel3. 동작 확인
redis-cli -p 26379 sentinel master mymaster
redis-cli -p 26379 sentinel replicas mymaster
redis-cli -p 26379 sentinel sentinels mymaster현재 마스터 주소만 빠르게 묻기:
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
# 1) "192.168.1.21"
# 2) "6379"4. SDOWN과 ODOWN — 페일오버 판정 흐름
| 단계 | 약어 | 의미 |
|---|---|---|
| 주관적 다운 | SDOWN | 한 Sentinel이 마스터 응답 없음으로 판단 |
| 객관적 다운 | ODOWN | quorum 수만큼 Sentinel이 SDOWN에 동의 |
| 리더 선출 | — | Sentinel들이 페일오버 리더를 투표로 선출 |
| 승격 | — | 리더가 적합한 레플리카를 새 마스터로 승격 |
레플리카 승격 우선순위는 replica-priority(낮을수록 우선, 0은 승격 제외), 복제 오프셋(최신 데이터), Run ID 순으로 결정됩니다.
5. 페일오버 강제 테스트
# 마스터 강제 종료
redis-cli -h 192.168.1.21 -a MasterAuth!2026 debug sleep 30
# 또는 프로세스 정지로 다운 유발
sudo systemctl stop redis-server # node1에서
# Sentinel 로그에서 페일오버 추적
journalctl -u redis-sentinel -f+switch-master mymaster 192.168.1.21 6379 192.168.1.22 6379 로그가 보이면 마스터가 node2로 전환된 것입니다. 수동 페일오버도 가능합니다.
redis-cli -p 26379 sentinel failover mymaster6. 클라이언트 연동
애플리케이션은 마스터 IP를 직접 박으면 안 됩니다. Sentinel에 마스터 주소를 물어 연결하는 Sentinel-aware 클라이언트를 써야 합니다.
from redis.sentinel import Sentinel
sentinel = Sentinel(
[('192.168.1.21', 26379), ('192.168.1.22', 26379), ('192.168.1.23', 26379)],
socket_timeout=0.5,
sentinel_kwargs={'password': None},
)
master = sentinel.master_for('mymaster', password='MasterAuth!2026', socket_timeout=0.5)
replica = sentinel.slave_for('mymaster', password='MasterAuth!2026')
master.set('key', 'value')
print(replica.get('key'))페일오버 직후 짧은 시간 동안 쓰기가 실패할 수 있습니다. 애플리케이션은 재시도 로직을 반드시 갖추세요.
7. 운영 시 함정
- min-replicas-to-write: 마스터에
min-replicas-to-write 1,min-replicas-max-lag 10을 설정하면 레플리카가 모두 떨어졌을 때 쓰기를 거부해 split-brain 유실을 줄입니다. - Sentinel은 같은 노드에 두지 않기: 가능하면 별도 호스트. 최소한 마스터 1대 다운으로 Sentinel 과반이 함께 죽지 않게 배치합니다.
- 시간 동기화(NTP): down-after 판정은 타이밍에 민감합니다.
- 방화벽: 6379(데이터)와 26379(Sentinel) 양쪽 포트를 모두 열어야 합니다.
정리
| 항목 | 권장 값/방법 |
|---|---|
| Sentinel 수 | 홀수(3 이상), 분리된 호스트 |
| quorum | Sentinel 3대 → 2 |
| down-after | 5000ms 부근 |
| 인증 | requirepass + masterauth 전 노드 동일 |
| 유실 방지 | min-replicas-to-write / max-lag |
| 클라이언트 | Sentinel-aware + 재시도 |
| 모니터링 | journalctl, +switch-master 추적 |
Sentinel은 quorum과 과반 선출이라는 두 단계 합의로 split-brain을 막습니다. 홀수 배치, 인증 일관성, Sentinel-aware 클라이언트 이 세 가지만 지켜도 안정적인 단일 마스터 HA를 운영할 수 있습니다.
이 가이드는 AI 도구를 활용해 초안을 구성하고 사람이 명령어·문맥을 검토해 발행했습니다. 운영체제와 도구 버전에 따라 결과가 달라질 수 있으므로 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요.
질문 & 답변 (Q&A)
이 가이드에 대해 궁금한 점을 질문해보세요. 확인 후 답변드립니다.