Infra & Network

[Redis HA | Part 1] Redis Master-Replica + Sentinel 구성

hrbds 2026. 4. 22. 14:13

목차

  1. 환경 준비
  2. Docker 네트워크 구성
  3. Redis Master-Replica 구성
  4. Redis Sentinel 구성
  5. Failover 실습
  6. 장애 복구 확인
  7. 전체 HA 흐름 요약

1. 환경 준비

환경 확인

docker --version
docker compose version
docker info | grep -E "Memory|CPUs"

2. Docker 네트워크 구성

커스텀 네트워크 생성

docker network create redis-cluster-net

네트워크 확인

docker network ls
docker network inspect redis-cluster-net

핵심 개념

  • 같은 네트워크 안의 컨테이너끼리는 컨테이너 이름으로 DNS 통신 가능
  • AWS VPC 안의 EC2 인스턴스끼리 통신하는 원리와 동일
  • 외부(Mac)에서 컨테이너 내부 접근 시 → 같은 네트워크의 컨테이너를 Bastion Host처럼 경유

3. Redis Master-Replica 구성

아키텍처

redis-cluster-net
├── redis-master    (6379) - 읽기/쓰기
├── redis-replica-1 (6379) - 읽기전용 + Master 백업
└── redis-replica-2 (6379) - 읽기전용 + Master 백업

Master 실행

docker run -d \
  --name redis-master \
  --network redis-cluster-net \
  redis:7.2 \
  redis-server --appendonly yes

Replica 실행

# Replica-1
docker run -d \
  --name redis-replica-1 \
  --network redis-cluster-net \
  redis:7.2 \
  redis-server --replicaof redis-master 6379 --appendonly yes

# Replica-2
docker run -d \
  --name redis-replica-2 \
  --network redis-cluster-net \
  redis:7.2 \
  redis-server --replicaof redis-master 6379 --appendonly yes

복제 상태 확인

docker exec -it redis-master redis-cli info replication

복제 동작 확인

# Master에 데이터 쓰기
docker exec -it redis-master redis-cli set mykey "hello-replication"

# Replica에서 읽기 (자동 복제 확인)
docker exec -it redis-replica-1 redis-cli get mykey
docker exec -it redis-replica-2 redis-cli get mykey

# Replica에 쓰기 시도 (읽기전용 확인)
docker exec -it redis-replica-1 redis-cli set testkey "write-to-replica"
# (error) READONLY You can't write against a read only replica.

 

주요 모니터링 지표 (info replication)

항목 설명 실무 알람 기준

connected_slaves 연결된 Replica 수 2 미만 시 알람
lag 복제 지연 10 이상 시 알람
repl_offset 복제 위치 Master와 차이 벌어지면 알람
master_replid Master 고유 ID 변경 시 전체 재동기화 발생

부분 동기화 vs 전체 재동기화

상황 backlog replid 동기화 방식

네트워크 순단 살아있음 동일 부분 동기화 ✅
프로세스 재시작 (정상종료) 살아있음 유지 가능 부분 동기화 ✅
컨테이너/서버 재시작 소멸 새로 발급 전체 재동기화 ❌
서버 크래시 소멸 새로 발급 전체 재동기화 ❌

실무 재시작 절차 (Master)

# 1. Replica 동기화 상태 확인 (lag=0 확인)
redis-cli info replication

# 2. 반드시 정상 종료 (replid 보존)
redis-cli shutdown save   # save: RDB 스냅샷 저장 후 종료
                          # shutdown nosave 절대 금지

# 3. 재시작 후 Replica 재연결 확인
redis-cli info replication

 

Master-Replica 한계

  • Master 장애 시 쓰기 불가 (READONLY)
  • 수동으로 Replica를 Master로 승격시켜야 함
  • 그 사이 서비스 장애 지속 → Sentinel로 자동화 필요

4. Redis Sentinel 구성

아키텍처

redis-cluster-net
├── redis-master      (6379)
├── redis-replica-1   (6379)
├── redis-replica-2   (6379)
├── sentinel-1        (26379) - 감시 전용
├── sentinel-2        (26379) - 감시 전용
└── sentinel-3        (26379) - 감시 전용

Sentinel을 홀수(3대)로 운영하는 이유

Sentinel 1대 → 자체가 SPOF (단일장애점)
Sentinel 2대 → 1대 죽으면 과반수 확보 불가 (50%)
Sentinel 3대 → 1대 죽어도 2대가 과반수 (2/3) ✅

sentinel.conf 작성

mkdir -p ~/redis-ha/sentinel
cd ~/redis-ha/sentinel

cat > sentinel.conf << 'EOF'
port 26379
sentinel monitor mymaster <MASTER_IP> 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
EOF

Master IP 확인 방법

docker inspect redis-master | grep IPAddress

sentinel.conf 주요 설정

설정 값 설명

port 26379 Sentinel 전용 포트
sentinel monitor quorum 2 3대 중 2대 동의 시 failover
down-after-milliseconds 5000ms 5초 응답 없으면 장애 판단
failover-timeout 60000ms 60초 내 failover 완료 안되면 실패
parallel-syncs 1 failover 후 1대씩 순차 동기화

Sentinel 3대 실행

for i in 1 2 3; do
  docker run -d \
    --name sentinel-$i \
    --network redis-cluster-net \
    -v ~/redis-ha/sentinel/sentinel.conf:/etc/redis/sentinel.conf \
    redis:7.2 \
    redis-sentinel /etc/redis/sentinel.conf
done

Sentinel 상태 확인

# Master 감시 상태
docker exec -it sentinel-1 redis-cli -p 26379 sentinel masters

# Replica 목록 확인
docker exec -it sentinel-1 redis-cli -p 26379 sentinel replicas mymaster

주요 확인 항목

"flags" "master"         → 정상 (장애 시 s_down, o_down)
"num-slaves" "2"         → Replica 2대 인식
"num-other-sentinels" "2"→ 다른 Sentinel 2대 인식 (총 3대)
"quorum" "2"             → failover 과반수 기준
"master-link-status" "ok"→ Master 연결 정상
"slave-priority" "100"   → 승격 우선순위 (0이면 승격 제외)

5. Failover 실습

실시간 모니터링 (터미널 A)

docker logs -f sentinel-1

Master 강제 종료 (터미널 B)

docker stop redis-master

Failover 로그 타임라인

+sdown master mymaster <IP> 6379
→ Sentinel 1대가 Master 장애 감지 (주관적 판단)

+new-epoch 1
→ 새로운 failover 라운드 시작

+vote-for-leader <sentinel_id> 1
→ Sentinel끼리 failover 리더 투표

+odown master mymaster <IP> 6379 #quorum 2/2
→ 과반수(2/2) 동의, 공식 장애 확정

+switch-master mymaster <구Master_IP> 6379 <새Master_IP> 6379
→ 새 Master 승격 완료 (약 1초 내)

+slave slave <구Master_IP>:6379 @ mymaster <새Master_IP> 6379
→ 구 Master, 복구 시 Replica로 편입 예정

Failover 후 쓰기 확인

# 새 Master에 쓰기 (정상 동작 확인)
docker exec -it redis-replica-1 redis-cli set afterfailover "I am new master"
docker exec -it redis-replica-1 redis-cli get afterfailover

6. 장애 복구 확인

구 Master 재시작

docker start redis-master

복구 후 상태 확인 (30초 후)

docker exec -it redis-replica-1 redis-cli info replication

복구 결과

role: master              → 새 Master 유지
connected_slaves: 2       → 구 Master가 Replica로 자동 편입 ✅
master_replid2: <구ID>    → 구 Master ID 기억 (부분 동기화 활용)
second_repl_offset: <값>  → 구 Master였을 때 마지막 offset

기타 컨테이너 관리 명령어

# 실행 중인 컨테이너 목록
docker ps

# 전체 컨테이너 IP 확인
docker ps -q | xargs docker inspect --format '{{.Name}} {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

# 네트워크 기준 전체 확인
docker network inspect redis-cluster-net

# 중지된 컨테이너 포함 전체 확인
docker ps -a

# 컨테이너 정리
docker rm -f <컨테이너명>

7. 전체 HA 흐름 요약

① 정상 운영
   Master ← 쓰기/읽기
   Replica x2 ← 읽기 + 실시간 복제
   Sentinel x3 ← 주기적 헬스체크

② Master 장애 발생
   Sentinel이 5초 내 감지 (s_down)
   Sentinel 3대가 투표 (quorum 2/2 동의)
   Replica 중 1대를 Master로 자동 승격 (1초 내)

③ 자동 복구
   구 Master 재시작 시 자동으로 새 Master의 Replica로 편입
   전체 과정에서 사람이 개입할 필요 없음

HA 구성 방식 비교

구성 Failover 샤딩 수평확장 적합한 규모

Master-Replica 수동 개발/스테이징
Sentinel 자동 ✅ 중소규모
Redis Cluster 자동 ✅ 중대형 서비스
ElastiCache 자동 ✅ AWS 클라우드