Redis는 메모리 기반 인메모리 데이터 저장소로, 고성능과 낮은 지연 시간을 제공하지만 단일 서버 구성 시 장애 발생 가능성이 존재합니다. 이를 해결하기 위해 Redis는 Sentinel 아키텍처를 통해 자동 장애 복구(Automatic Failover) 기능을 제공하며, 마스터 노드 장애 시 슬레이브 중 하나를 자동으로 승격시켜 서비스 중단을 최소화할 수 있습니다.

Sentinel의 주요 기능

• 마스터 모니터링: 주기적으로 마스터에 핑(PING) 요청을 보내 응답 여부를 확인합니다.
• 장애 감지 및 장애 조치(Failover): 마스터 응답 실패 시 다수의 Sentinel이 동의하면 슬레이브 중 하나를 새로운 마스터로 승격시킵니다.
• 클라이언트 통보: Pub/Sub 메커니즘을 통해 클라이언트에게 새 마스터의 주소를 알립니다.
• 구성 업데이트: 재구성 후 관련 설정 파일(redis.conf, sentinel.conf)이 자동 갱신됩니다.

작동 원리

Sentinel은 독립된 프로세스로 실행되며, Redis 서버와 분리되어 운영됩니다. 클라이언트(예: Java의 Jedis 또는 Lettuce)는 초기 연결 시 Sentinel에 쿼리하여 현재 마스터의 IP와 포트를 조회합니다. 마스터 변경이 발생하면 Sentinel은 +switch-master 이벤트를 발행하고, 클라이언트는 이를 수신해 자동으로 새 마스터에 재연결합니다.

테스트 환경 구성

호스트명	IP 주소	역할
node1	192.168.1.6	마스터, Sentinel
node2	192.168.1.7	슬레이브, Sentinel
node3	192.168.1.8	슬레이브, Sentinel

설정 절차

1. 모든 노드에 Redis 설치 및 활성화

yum install -y redis
systemctl enable redis
systemctl start redis

2. 마스터 노드(node1) 설정 수정

bind 0.0.0.0
protected-mode no

방화벽이 활성화된 경우 Redis 기본 포트 허용:

firewall-cmd --permanent --add-port=6379/tcp
firewall-cmd --reload

3. 슬레이브 노드(node2, node3) 설정

두 슬레이브 모두 다음 설정 추가:

bind 0.0.0.0
protected-mode no
replicaof 192.168.1.6 6379

변경 후 Redis 재시작:

systemctl restart redis

4. Sentinel 구성 (모든 노드 공통)

/etc/redis-sentinel.conf 파일 수정:

protected-mode no
port 26379
daemonize yes
sentinel monitor mymaster 192.168.1.6 6379 2
sentinel down-after-milliseconds mymaster 10000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 60000

• monitor: 마스터 그룹 이름(mymaster), IP, 포트, 장애 판단을 위한 최소 투표 수(2).
• down-after-milliseconds: 10초 이상 응답 없을 시 SDOWN(주관적 다운) 처리.
• parallel-syncs: 동시 동기화 가능한 슬레이브 수 제한.
• failover-timeout: 장애 조치 시도 간 최소 간격.

5. Sentinel 서비스 시작 및 방화벽 설정

systemctl enable redis-sentinel
systemctl start redis-sentinel

Sentinel 통신용 포트 개방:

firewall-cmd --permanent --add-port=26379/tcp
firewall-cmd --reload

복제 상태 확인

마스터(node1)에서 복제 정보 조회:

redis-cli info replication

출력 예시:

# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.7,port=6379,state=online,...
slave1:ip=192.168.1.8,port=6379,state=online,...

슬레이브에서도 마스터 연결 상태 확인 가능:

redis-cli info replication

role:slave
master_host:192.168.1.6
master_link_status:up

장애 조치 테스트

마스터(node1) 강제 종료:

systemctl stop redis

약 10~30초 후 Sentinel들이 ODOWN(객관적 다운) 판단 후 장애 조치 수행. 새로운 마스터 선택 완료 후, 나머지 두 노드는 새 마스터를 바라보도록 자동 재구성됩니다.

예: node3가 새 마스터로 승격된 후, node2에서 상태 확인:

role:slave
master_host:192.168.1.8

원래 마스터(node1) 재시작 시 자동으로 슬레이브로 재등록:

systemctl start redis

role:slave
master_host:192.168.1.8

Sentinel 상태 점검

Sentinel 포트(26379)로 접속해 모니터링 상태 확인:

redis-cli -h 192.168.1.8 -p 26379 info sentinel

# Sentinel
sentinel_masters:1
master0:name=mymaster,status=ok,address=192.168.1.8:6379,slaves=2,sentinels=3

주관적 다운(SDOWN) vs 객관적 다운(ODOWN)

• SDOWN (Subjectively Down): 특정 Sentinel이 단독으로 마스터에 접근 불가라고 판단하는 상태. 네트워크 일시적 장애일 수 있음.
• ODOWN (Objectively Down): 다수의 Sentinel이 SDOWN을 보고하고, 설정된 투표 수(quorum) 이상이 동의할 때 진입하는 상태. 이 시점에서 장애 조치(failover)가 트리거됩니다.

quorum 값은 일반적으로 전체 Sentinel 수의 과반수 이상이며, 홀수 대수 구성이 추천되어 브레인 스플릿(brain split) 문제를 방지합니다.