목차
- 환경 준비
- Docker 네트워크 구성
- Redis Master-Replica 구성
- Redis Sentinel 구성
- Failover 실습
- 장애 복구 확인
- 전체 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 클라우드 |
'Infra & Network' 카테고리의 다른 글
| [Docker | Part 2] Dockerfile + Multi-stage Build (0) | 2026.04.28 |
|---|---|
| [Docker | Part 1] Docker 핵심 구조 이해 (0) | 2026.04.23 |
| Azure Container Apps와 Private VNet 통합하기 (1) | 2025.07.28 |
| Docker Image 생성 후 Azure Container registries에 업로드하기 (1) | 2025.07.14 |
| [Azure] MAC 환경에서 Azure CLI 로그인하기 (0) | 2025.07.13 |