홈/엔지니어/데이터베이스/Redis Sentinel — 고가용성과 자동 페일…
데이터베이스고급linuxredissentinelha

Redis Sentinel — 고가용성과 자동 페일오버 구성

Redis Sentinel로 마스터-레플리카 모니터링, 자동 페일오버, 서비스 디스커버리를 구성합니다. quorum 동작 원리와 클라이언트 연동, 운영 함정까지 실습으로 정리합니다.

목차
  1. Redis Sentinel 이란?
  2. 권장 토폴로지
  3. 1. Redis 복제 구성
  4. 2. Sentinel 설정
  5. 3. 동작 확인
  6. 4. SDOWN과 ODOWN — 페일오버 판정 흐름
  7. 5. 페일오버 강제 테스트
  8. 6. 클라이언트 연동
  9. 7. 운영 시 함정
  10. 정리

Redis Sentinel 이란?

Redis Sentinel은 Redis 마스터-레플리카 구성을 감시하고, 마스터 장애 시 레플리카를 자동으로 승격(failover)해 주는 고가용성 솔루션입니다. 별도 프로세스로 동작하며 다음 역할을 수행합니다.

  • 모니터링: 마스터·레플리카가 살아 있는지 지속 점검
  • 알림: 장애 발생 시 이벤트 통지
  • 자동 페일오버: 마스터 다운 시 레플리카 승격
  • 서비스 디스커버리: 클라이언트에 현재 마스터 주소 제공

Sentinel은 데이터 샤딩이 아닙니다. 데이터 분산이 목적이라면 Redis Cluster를 사용하세요. Sentinel은 "단일 마스터의 가용성"을 책임집니다.


권장 토폴로지

가장 흔한 구성은 마스터 1 + 레플리카 2 + Sentinel 3 입니다.

노드IP역할
node1192.168.1.21Redis Master + Sentinel
node2192.168.1.22Redis Replica + Sentinel
node3192.168.1.23Redis Replica + Sentinel

Sentinel은 반드시 홀수(3 이상) 로 두어야 합니다. 그래야 네트워크 분할 시 다수결(quorum)로 정확히 한쪽만 페일오버를 진행할 수 있습니다.


1. Redis 복제 구성

먼저 일반적인 마스터-레플리카를 만듭니다.

마스터(node1) redis.conf:

Config
bind 0.0.0.0 -::1
port 6379
requirepass MasterAuth!2026
masterauth MasterAuth!2026
appendonly yes

레플리카(node2, node3) redis.conf:

Config
bind 0.0.0.0 -::1
port 6379
requirepass MasterAuth!2026
masterauth MasterAuth!2026
replicaof 192.168.1.21 6379
appendonly yes

masterauth 와 requirepass 를 모든 노드에 동일하게 설정해야 페일오버 후 새 마스터에도 정상 연결됩니다. 복제 상태는 다음으로 확인합니다.

Bash
redis-cli -a MasterAuth!2026 info replication
CODE
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.22,port=6379,state=online,offset=...

2. Sentinel 설정

각 노드의 sentinel.conf:

Config
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 60000

quorum 은 "페일오버를 시작할지 합의하는 데 필요한 Sentinel 수"이고, 실제 페일오버 실행은 전체 Sentinel 과반(majority) 의 투표가 추가로 필요합니다. Sentinel 3대라면 quorum 2가 표준입니다.

실행:

Bash
redis-sentinel /etc/redis/sentinel.conf
# 또는 systemd
sudo systemctl enable --now redis-sentinel

3. 동작 확인

Bash
redis-cli -p 26379 sentinel master mymaster
redis-cli -p 26379 sentinel replicas mymaster
redis-cli -p 26379 sentinel sentinels mymaster

현재 마스터 주소만 빠르게 묻기:

Bash
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
# 1) "192.168.1.21"
# 2) "6379"

4. SDOWN과 ODOWN — 페일오버 판정 흐름

단계약어의미
주관적 다운SDOWN한 Sentinel이 마스터 응답 없음으로 판단
객관적 다운ODOWNquorum 수만큼 Sentinel이 SDOWN에 동의
리더 선출—Sentinel들이 페일오버 리더를 투표로 선출
승격—리더가 적합한 레플리카를 새 마스터로 승격

레플리카 승격 우선순위는 replica-priority(낮을수록 우선, 0은 승격 제외), 복제 오프셋(최신 데이터), Run ID 순으로 결정됩니다.


5. 페일오버 강제 테스트

Bash
# 마스터 강제 종료
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로 전환된 것입니다. 수동 페일오버도 가능합니다.

Bash
redis-cli -p 26379 sentinel failover mymaster

6. 클라이언트 연동

애플리케이션은 마스터 IP를 직접 박으면 안 됩니다. Sentinel에 마스터 주소를 물어 연결하는 Sentinel-aware 클라이언트를 써야 합니다.

Python
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 이상), 분리된 호스트
quorumSentinel 3대 → 2
down-after5000ms 부근
인증requirepass + masterauth 전 노드 동일
유실 방지min-replicas-to-write / max-lag
클라이언트Sentinel-aware + 재시도
모니터링journalctl, +switch-master 추적

Sentinel은 quorum과 과반 선출이라는 두 단계 합의로 split-brain을 막습니다. 홀수 배치, 인증 일관성, Sentinel-aware 클라이언트 이 세 가지만 지켜도 안정적인 단일 마스터 HA를 운영할 수 있습니다.

#redis#sentinel#ha#failover
편집 안내 · Editorial Note

AI 도구가 초안 작성에 사용될 수 있습니다. 명령어의 실행 여부와 검증 환경은 각 가이드에 기재된 근거를 확인하세요. 적용 전 사용 중인 버전의 공식 문서를 확인하고, 오류는 이메일로 알려주세요. 이메일로 제보

주제 관련 공식 문서(자동 연결 · 문장별 근거 아님)Redis 공식 문서 ↗

질문 & 답변 (Q&A)

이 가이드에 대해 궁금한 점을 질문해보세요. 확인 후 답변드립니다.