개요
Redis Sentinel은 Redis Cluster를 사용하지 않는 환경에서 Redis의 고가용성을 제공합니다.
Redis Sentinel은 모니터링, 알림, 클라이언트 구성 제공자 등의 부수적인 작업도 수행합니다.
Sentinel의 핵심 기능
Sentinel의 주요 기능은 다음과 같습니다:
1. 모니터링 (Monitoring)
- 마스터와 복제본 인스턴스가 예상대로 작동하는지 지속적으로 확인
2. 알림 (Notification)
- API를 통해 시스템 관리자나 다른 컴퓨터 프로그램에게 모니터링되는 Redis 인스턴스에 문제가 발생했을 때 알림
3. 자동 장애 조치 (Automatic failover)
- 마스터가 예상대로 작동하지 않으면 복제본을 마스터로 승격
- 다른 추가 복제본들을 새 마스터를 사용하도록 재구성
- Redis 서버를 사용하는 애플리케이션에게 연결할 새 주소를 알림
4. 구성 제공자 (Configuration provider)
- 클라이언트 서비스 검색을 위한 권한 소스 역할
- 클라이언트는 Sentinel에 연결하여 특정 서비스를 담당하는 현재 Redis 마스터의 주소를 요청
- 장애 조치가 발생하면 Sentinel이 새 주소를 보고
분산 시스템으로서의 Sentinel
Redis Sentinel은 분산 시스템입니다:
여러 Sentinel 프로세스가 협력하여 작동하도록 설계되었습니다. 다중 Sentinel 프로세스 협력의 장점:
- 오탐 확률 감소: 여러 Sentinel이 마스터를 사용할 수 없다고 합의해야 장애 감지
- 장애 복원력: 모든 Sentinel 프로세스가 작동하지 않아도 시스템이 동작 (단일 실패 지점 방지)
Sentinel 빠른 시작
Sentinel 버전
현재 버전은 Sentinel 2입니다:
- 초기 Sentinel 구현을 더 강력하고 예측 가능한 알고리즘으로 재작성
- Redis 2.8부터 안정적인 릴리스 제공
- Redis 2.6의 Sentinel 1은 더 이상 사용하지 않음
Sentinel 실행
두 가지 방법으로 Sentinel을 실행할 수 있습니다:
# 방법 1: redis-sentinel 실행 파일 사용
redis-sentinel /path/to/sentinel.conf
# 방법 2: redis-server를 Sentinel 모드로 실행
redis-server /path/to/sentinel.conf --sentinel중요한 요구사항:
- 구성 파일 사용이 필수 (현재 상태 저장을 위해)
- 구성 파일이 없거나 쓰기 권한이 없으면 Sentinel이 시작되지 않음
- 기본적으로 TCP 포트 26379에서 수신 대기
- 다른 Sentinel 인스턴스와 통신하려면 해당 포트가 열려있어야 함
배포 전 필수 지식
- 최소 3개의 Sentinel 인스턴스 필요 (강력한 배포를 위해)
- 독립적으로 실패할 수 있는 컴퓨터/VM에 배치 (다른 물리 서버 또는 가용성 영역)
- 비동기 복제로 인한 데이터 손실 가능성 존재
- 클라이언트에서 Sentinel 지원 필요
- 정기적인 테스트 필수 (개발/운영 환경에서)
- Docker/NAT 환경에서 주의: 포트 매핑으로 인한 자동 검색 문제
Sentinel 구성
기본적인 sentinel.conf 설정 예시:
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5구성 매개변수 설명
기본 모니터링 설정:
sentinel monitor <master-name> <ip> <port> <quorum>- quorum: 마스터 장애를 인정하는 데 필요한 Sentinel 수
- down-after-milliseconds: 인스턴스를 다운으로 간주하기 전 대기 시간(밀리초)
- failover-timeout: 장애 조치 시간 제한
- parallel-syncs: 장애 조치 후 동시에 재구성할 수 있는 복제본 수
예시 배포 시나리오
시나리오 1: 기본 3박스 설정 (권장)
+----+
| M1 |
| S1 |
+----+
|
+----+ | +----+
| R2 |----+----| R3 |
| S2 | | S3 |
+----+ +----+
Configuration: quorum = 2장점:
- 간단하고 조정하기 쉬움
- 각 박스가 Redis와 Sentinel을 모두 실행
주의사항:
- 네트워크 파티션 시 이전 마스터에 연결된 클라이언트의 데이터 손실 위험
시나리오 2: 클라이언트 박스의 Sentinel
+----+ +----+
| M1 |----+----| R1 |
| | | | |
+----+ | +----+
|
+------------+------------+
| | |
+----+ +----+ +----+
| C1 | | C2 | | C3 |
| S1 | | S2 | | S3 |
+----+ +----+ +----+
Configuration: quorum = 2특징:
- Redis 박스가 2개뿐일 때 사용
- 클라이언트와 동일한 관점에서 마스터 가용성 판단
장애 상태: SDOWN vs ODOWN
SDOWN (Subjectively Down)
- 개별 Sentinel의 주관적 다운 상태
- 구성된 시간 동안 PING에 대한 유효한 응답을 받지 못할 때
ODOWN (Objectively Down)
- 객관적 다운 상태
- 충분한 수의 Sentinel(quorum 이상)이 SDOWN에 동의할 때
- 실제 장애 조치를 트리거하는 상태
Sentinel API
주요 명령어
# 마스터 상태 확인
SENTINEL master mymaster
# 현재 마스터 주소 조회
SENTINEL get-master-addr-by-name mymaster
# 복제본 목록 조회
SENTINEL replicas mymaster
# Sentinel 목록 조회
SENTINEL sentinels mymaster
# 런타임 구성 변경
SENTINEL set mymaster down-after-milliseconds 1000장애 조치 테스트
# 마스터를 30초 동안 사용 불가능하게 만들어 테스트
redis-cli -p 6379 DEBUG sleep 30인증 설정
ACL 인증 (Redis 6+)
sentinel auth-user <master-name> <username>
sentinel auth-pass <master-name> <password>패스워드 인증
sentinel auth-pass <master-name> <password>고급 개념
Quorum과 다수결
- Quorum: ODOWN 상태로 플래그하는 데 필요한 Sentinel 수
- 다수결: 실제 장애 조치 수행을 위해서는 과반수의 승인 필요
예시: 5개 Sentinel, quorum = 2
- 2개 Sentinel이 동의하면 장애 조치 트리거
- 하지만 실제 수행을 위해서는 3개 이상의 승인 필요
구성 에포크 (Configuration Epochs)
- 각 장애 조치마다 고유한 버전 번호 할당
- 구성 충돌 방지 및 일관성 보장
- 더 높은 버전이 항상 우선
복제본 선택 우선순위
복제본 선택 기준 (순서대로):
- replica-priority 값 (낮을수록 우선)
- 복제 오프셋 (더 많은 데이터를 받은 것 우선)
- 실행 ID (사전식 순서로 더 작은 것)
Docker/NAT 환경 설정
문제점
- Docker의 포트 매핑으로 인한 자동 검색 실패
- NAT 환경에서 실제 IP와 논리적 IP의 차이
해결책
# 복제본이 마스터에게 알릴 IP와 포트 설정
replica-announce-ip 5.5.5.5
replica-announce-port 1234
# Sentinel이 다른 Sentinel에게 알릴 IP와 포트 설정
sentinel announce-ip <ip>
sentinel announce-port <port>TILT 모드
TILT 모드는 Sentinel이 비정상적인 상황을 감지했을 때 들어가는 특별한 "보호" 모드입니다.
진입 조건
- 타이머 인터럽트 간 시간 차이가 음수이거나 예상보다 클 때 (2초 이상)
- 컴퓨터 시간이 예상치 못하게 변경되거나 시스템이 매우 바쁠 때
TILT 모드에서의 동작
- 모든 작업 중단
SENTINEL is-master-down-by-addr요청에 부정적으로 응답- 30초 동안 정상 상태가 지속되면 종료
TILT 모드 확인
redis-cli -p 26379 info
# sentinel_tilt_since_seconds 필드 확인 (-1이면 정상)데이터 일관성과 파티션
최종 일관성 시스템
Redis + Sentinel은 최종 일관성 시스템입니다:
- 병합 함수: "마지막 장애 조치가 승리"
- 이전 마스터의 데이터는 현재 마스터 데이터로 대체
- 승인된 쓰기 손실 가능성 항상 존재
데이터 손실 최소화
# 최소 1개 복제본에 쓸 수 없으면 쓰기 중단
min-replicas-to-write 1
min-replicas-max-lag 10이 설정으로 파티션된 이전 마스터는 10초 후 쓰기를 중단합니다.
모니터링과 알림
Pub/Sub 메시지
채널 __sentinel__:hello를 통한 이벤트 알림:
# 모든 이벤트 구독
PSUBSCRIBE *
# 주요 이벤트들:
# +sdown: 주관적 다운 상태
# +odown: 객관적 다운 상태
# +failover-state-select-slave: 장애 조치 시작
# +switch-master: 마스터 변경 완료성능 최적화
디스크리스 복제
# 전체 재동기화 시 디스크 없이 직접 네트워크로 전송
repl-diskless-sync yes
repl-diskless-sync-delay 5백로그 크기 조정
# 부분 재동기화를 위한 백로그 크기
repl-backlog-size 1mb
repl-backlog-ttl 3600트러블슈팅 가이드
일반적인 문제들
- 포트 26379가 막혀있음: 방화벽 설정 확인
- Quorum 설정 오류: 홀수 개의 Sentinel 사용 권장
- 네트워크 파티션:
min-replicas-to-write설정으로 완화 - 클라이언트 지원 부족: Sentinel 지원 라이브러리 사용
디버깅 명령어
# Sentinel 상태 확인
SENTINEL masters
SENTINEL slaves mymaster
SENTINEL sentinels mymaster
# 구성 확인
SENTINEL ckquorum mymaster
# 구성 강제 저장
SENTINEL flushconfig실제 운영 권장사항
배포 체크리스트
- 최소 3개의 Sentinel 인스턴스
- 독립적인 장애 도메인에 배치
- 클라이언트 Sentinel 지원 확인
- 정기적인 장애 조치 테스트
- 모니터링 및 알림 설정
- 백업 및 복구 절차 수립
성능 고려사항
- 쿼럼 크기: 네트워크 안정성과 응답성의 균형
- 타임아웃 설정: 네트워크 지연시간을 고려한 조정
- 백로그 크기: 네트워크 불안정성에 따른 조정
요약
Redis Sentinel은 비클러스터 환경에서 Redis의 고가용성을 제공하는 강력한 도구입니다.
주요 장점:
- 자동 장애 조치
- 간단한 설정
- 클라이언트 투명성
주요 제한사항:
- 최종 일관성만 보장
- 단일 마스터 구조
- 복잡한 네트워크 요구사항
올바른 설정과 테스트를 통해 안정적인 고가용성 Redis 시스템을 구축할 수 있습니다.
출처: Redis 공식 문서 - High availability with Redis Sentinel (opens in a new tab)