Redis 클러스터 구성 방식은 크게 세 가지로 나뉩니다: Redis Cluster, Master/Slave 복제 구조, 그리고 Sentinel 기반 자동 장애 복구 방식입니다.
Sentinel 아키텍처 개요
Sentinel은 Redis 2.4 버전부터 내장된 고가용성(HA) 솔루션으로, 마스터 노드의 상태를 지속적으로 모니터링하고 장애 발생 시 자동으로 페일오버를 수행합니다. 하나의 Sentinel 인스턴스는 여러 마스터-슬레이브 그룹을 동시에 감시할 수 있으며, 마스터가 비정상 상태로 판단되면 적절한 슬레이브를 새로운 마스터로 승격시킵니다.
Sentinel 배포 시 홀수 개의 인스턴스를 권장하는 이유는 분산 합의 알고리즘에서 과반수 투표를 통해 잘못된 장애 판단을 방지하기 위함입니다.
핵심 동작 메커니즘
주기적 작업 스케줄
Sentinel은 세 가지 주기적 작업을 수행합니다:
- 10초 간격: 마스터와 슬레이브에 INFO 명령 실행으로 토폴로지 정보 수집
- 2초 간격:
__sentinel__:hello채널을 통한 센티널 간 정보 교환 (pub/sub) - 1초 간격: 다른 센티널 및 Redis 노드에 PING 명령 전송 (하트비트)
Subjective Down (SDOWN)
개별 Sentinel 인스턴스가 특정 노드를 비정상으로 판단하는 상태입니다. down-after-milliseconds 설정 시간 동안 PING 응답이 유효하지 않으면 해당 노드는 SDOWN으로 표시됩니다. 유효한 응답은 다음과 같습니다:
+PONG-LOADING-MASTERDOWN
Objective Down (ODOWN)
다수의 Sentinel이 동일한 마스터를 SDOWN으로 판단하고 상호 확인을 완료하면 ODOWN 상태로 전환됩니다. 이 상태에서만 실제 페일오버가 시작됩니다.
ODOWN 판정을 위해서는 sentinel monitor 설정의 quorum 값만큼의 Sentinel 동의가 필요합니다. 예를 들어 5개의 Sentinel이 있고 quorum이 2로 설정되어 있어도, 실제 페일오버를 위해서는 과반수인 3개의 Sentinel 승인이 필요합니다.
리더 선출 및 페일오버 프로세스
Raft 기반 리더 선출
Sentinel은 Raft 합의 알고리즘을 사용하여 페일오버를 담당할 리더 Sentinel을 선출합니다. 선출 규칙은 다음과 같습니다:
- 모든 Sentinel은 동등한 선출 자격을 가집니다
- 각 Sentinel은 한 번의 선거에서 단 한 번만 투표할 수 있습니다
- 먼저 투표 요청을 받은 Sentinel을 리더로 선출하는 선착순 방식
- 과반수 이상의 표를 획득하면 리더로 확정됩니다
페일오버 단계
+try-failover: 페일오버 조건 충족, 리더 선출 대기+elected-leader: 리더 Sentinel 선출 완료+failover-state-select-slave: 새 마스터 후보 선정 시작+selected-slave: 적합한 슬레이브 확정+failover-state-send-slaveof-noone: 슬레이브를 마스터로 전환+promoted-slave: 새 마스터 승격 완료+failover-state-reconf-slaves: 나머지 슬레이브 재구성+switch-master: 모든 Sentinel이 새 마스터 모니터링 시작
슬레이브 우선순위 평가 기준
새 마스터로 승격될 슬레이브는 다음 기준으로 평가됩니다:
- replica-priority 값: 숫자가 낮을수록 우선순위 높음 (0은 마스터 선출 제외)
- 복제 오프셋: 마스터와의 데이터 동기화 정도
- 실행 ID: 동일 조건 시 작은 값 우선
다음 조건에 해당하는 슬레이브는 후보에서 제외됩니다:
- SDOWN/ODOWN 상태인 슬레이브
- 마스터와 5초 이상 응답 없는 슬레이브
- 마스터와 연결이
down-after-milliseconds × 10이상 단절된 슬레이브
설정 파일 구성
핵심 설정 항목
# 마스터 모니터링 설정
sentinel monitor <cluster-name> <master-ip> <port> <quorum>
# 주관적 다운 판정 시간 (밀리초)
sentinel down-after-milliseconds <cluster-name> <timeout>
# 동시 동기화 슬레이브 수
sentinel parallel-syncs <cluster-name> <count>
# 페일오버 타임아웃 (밀리초)
sentinel failover-timeout <cluster-name> <timeout>
# 인증 비밀번호
sentinel auth-pass <cluster-name> <password>
설정 버전 관리
Sentinel은 설정 변경 시 버전 번호(epoch)를 부여하여 관리합니다. 페일오버가 성공하면 새로운 epoch가 생성되고, 이 설정은 pub/sub 널을 통해 모든 Sentinel에 전파됩니다. 높은 버전 번호의 설정이 항상 우선 적용됩니다.
실전 배포 가이드
환경 구성
3노드 구성 예시:
| 노드 | Redis | Sentinel |
|---|---|---|
| node-alpha (10.0.1.10) | 6379 | 26379 |
| node-beta (10.0.1.11) | 6379 | 26379 |
| node-gamma (10.0.1.12) | 6379 | 26379 |
Redis 서버 설정
마스터 노드 (node-alpha):
bind 0.0.0.0
port 6379
daemonize yes
pidfile /var/run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis
# AOF 지속성 설정
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
# 슬레이브 관련 (마스터에서도 설정 필요 - 장애 복구 후 슬레이브 역할 가능)
slave-priority 100
슬레이브 노드 (node-beta, node-gamma):
bind 0.0.0.0
port 6379
daemonize yes
# 마스터 복제 설정
replicaof 10.0.1.10 6379
# 읽기 전용 모드
slave-read-only yes
slave-priority 100
Sentinel 설정
모든 노드에 동일하게 적용:
port 26379
daemonize yes
pidfile /var/run/redis/redis-sentinel.pid
logfile /var/log/redis/redis-sentinel.log
dir /var/lib/redis-sentinel
# 모니터링 대상 마스터
sentinel monitor mycluster 10.0.1.10 6379 2
# 10초 내 응답 없으면 SDOWN
sentinel down-after-milliseconds mycluster 10000
# 페일오버 타임아웃 60초
sentinel failover-timeout mycluster 60000
# 동시 동기화 슬레이브 1개
sentinel parallel-syncs mycluster 1
자동화 설치 스크립트
#!/bin/bash
# redis_ha_setup.sh
REDIS_VERSION="7.0.12"
INSTALL_PREFIX="/usr/local"
CONFIG_DIR="/etc/redis"
DATA_DIR="/var/lib/redis"
LOG_DIR="/var/log/redis"
install_redis() {
cd /tmp
wget https://download.redis.io/releases/redis-${REDIS_VERSION}.tar.gz
tar xzf redis-${REDIS_VERSION}.tar.gz
cd redis-${REDIS_VERSION}
make BUILD_TLS=yes
make PREFIX=${INSTALL_PREFIX} install
# 디렉토리 생성
mkdir -p ${CONFIG_DIR} ${DATA_DIR} ${LOG_DIR}
# 설정 파일 복사
cp redis.conf ${CONFIG_DIR}/
cp sentinel.conf ${CONFIG_DIR}/
# 권한 설정
useradd -r -s /bin/false redis 2>/dev/null || true
chown -R redis:redis ${DATA_DIR} ${LOG_DIR}
}
configure_sentinel_service() {
cat > /etc/systemd/system/redis-sentinel.service <<'EOF'
[Unit]
Description=Redis Sentinel
After=network.target
[Service]
User=redis
Group=redis
ExecStart=/usr/local/bin/redis-sentinel /etc/redis/sentinel.conf --sentinel
ExecStop=/usr/local/bin/redis-cli -p 26379 shutdown
Restart=always
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable redis-sentinel
}
case "$1" in
install)
install_redis
;;
sentinel-service)
configure_sentinel_service
;;
*)
echo "Usage: $0 {install|sentinel-service}"
exit 1
;;
esac
운영 및 모니터링
핵심 Sentinel 명령어
# 마스터 정보 조회
redis-cli -p 26379 sentinel masters
# 특정 마스터의 슬레이브 목록
redis-cli -p 26379 sentinel slaves mycluster
# 현재 마스터 주소 확인
redis-cli -p 26379 sentinel get-master-addr-by-name mycluster
# 수동 페일오버 실행
redis-cli -p 26379 sentinel failover mycluster
# 센티널 상태 정보
redis-cli -p 26379 info sentinel
이벤트 구독
클라이언트는 Sentinel의 pub/sub 채널을 구독하여 실시간 이벤트를 수신할 수 있습니다:
# 모든 이벤트 구독
redis-cli -p 26379 psubscribe '*'
# 주요 이벤트 패턴
+sdown # 주관적 다운 감지
-sdown # 주관적 다운 복구
+odown # 객관적 다운 감지
-odown # 객관적 다운 복구
+switch-master # 마스터 전환 완료
Python 클라이언트 연결 예시
from redis.sentinel import Sentinel
# Sentinel 연결 설정
sentinel_hosts = [
('10.0.1.10', 26379),
('10.0.1.11', 26379),
('10.0.1.12', 26379)
]
sentinel = Sentinel(
sentinel_hosts,
socket_timeout=0.5,
socket_connect_timeout=0.5
)
# 마스터 연결 (쓰기 작업)
master = sentinel.master_for(
'mycluster',
socket_timeout=0.5,
decode_responses=True
)
master.set('key', 'value')
# 슬레이브 연결 (읽기 작업)
slave = sentinel.slave_for(
'mycluster',
socket_timeout=0.5,
decode_responses=True
)
value = slave.get('key')
Java Spring Boot 설정
spring:
redis:
sentinel:
master: mycluster
nodes:
- 10.0.1.10:26379
- 10.0.1.11:26379
- 10.0.1.12:26379
password: ${REDIS_PASSWORD:}
lettuce:
pool:
max-active: 8
max-idle: 8
min-idle: 0
장애 시나리오 처리
네트워크 분할 (Split-Brain)
네트워크 분할 상황에서 두 개의 Sentinel 그룹이 각각 페일오버를 시도하는 것을 방지하기 위해, Sentinel은 epoch 기반의 버전 관리를 사용합니다. 더 높은 epoch를 가진 설정이 우선권을 가지며, 이를 통해 최종 일관성을 보장합니다.
구성 복구
Sentinel은 비정상 상태의 노드를 지속적으로 모니터링하며, 복구된 노드에 대해 자동으로 적절한 역할을 재할당합니다:
- 이전 마스터가 복구되면 새 마스터의 슬레이브로 재구성
- 잘못된 마스터를 바라보는 슬레이브는 올바른 마스터로 재지정
주의사항 및 모범 사례
- Sentinel 수량: 최소 3개, 운영 환경에서는 5개 권장
- 물리적 분산: 서로 다른 랙/가용영역에 배치
- IP 주소 설정: Sentinel 모니터링 설정에는 실제 IP 사용, localhost/127.0.0.1 지양
- 설정 파일 관리: 실행 중인 Sentinel의 설정 파일을 직접 복사하지 말고, 템플릿에서 새로 생성
- 인증 설정: 마스터와 슬레이브 모두에
requirepass와masterauth동시 설정