#10 🔄 복제·고가용성: Replication·Sentinel

"Redis 서버 한 대가 다운되면 서비스가 멈추나요?" — 복제와 Sentinel로 장애에 강한 고가용성 구성을 만들어 봅니다.

🔥 "서버 한 대 죽으면 서비스가 멈추나요?"

새벽 2시, 갑자기 Redis 서버가 죽었습니다. 캐시도, 세션도, 실시간 기능도 모두 멈춥니다. 사용자들은 오류 화면을 보고, 고객 센터 전화가 빗발칩니다. 이런 상황을 막으려면 어떻게 해야 할까요?

답은 이중화(Redundancy)입니다. 메인 서버(Primary)와 똑같은 데이터를 가진 복사본(Replica)을 항상 준비해 두는 것이죠. Primary가 죽으면 Replica가 즉시 역할을 이어받습니다. 이것이 고가용성(High Availability, HA)의 기본 원리입니다.

Redis는 복제(Replication)로 Primary의 데이터를 Replica에 자동으로 동기화합니다. 그리고 Sentinel이라는 별도 프로세스가 Primary의 상태를 감시하다가, 장애가 감지되면 자동으로 Replica를 새 Primary로 승격시킵니다(Failover).

이번 편에서는 Primary-Replica 복제 구성을 직접 만들어보고, Sentinel의 역할을 이해합니다.

🔁 핵심 개념 1: 복제(Replication) 동작 방식

Redis 복제는 비동기 복제입니다. Primary가 쓰기를 처리하고, 변경사항을 Replica에게 전달합니다. Replica는 받은 변경사항을 적용해 Primary와 동일한 상태를 유지합니다.

┌─────────────────────────────────────────┐
│ 클라이언트 (쓰기) → Primary (6379) │
│ ↓ 복제 스트림 │
│ Replica 1 (6380) ← 읽기 분산 가능 │
│ Replica 2 (6381) ← 읽기 분산 가능 │
└─────────────────────────────────────────┘

복제 동기화 과정

단계	설명
1. 초기 연결	Replica가 REPLICAOF 명령으로 Primary에 연결
2. 전체 동기화	Primary가 RDB 스냅샷을 생성해 Replica에 전송
3. 부분 동기화	이후 변경사항을 실시간으로 전달 (replication backlog)
4. 재연결 시	짧은 연결 끊김이면 부분 동기화, 길면 전체 동기화

⚠️ 복제는 비동기!
Primary가 쓰기를 완료하는 순간 Replica에 즉시 반영되지는 않습니다. 아주 짧은 지연이 있습니다. Primary가 갑자기 죽으면 아직 Replica에 전달되지 못한 데이터는 유실될 수 있습니다. 이를 "복제 지연(Replication Lag)"이라고 합니다.

🛡️ 핵심 개념 2: Sentinel — 자동 장애 복구

복제만으로는 자동 복구가 되지 않습니다. Primary가 죽었을 때 누군가 "Primary가 죽었다"고 판단하고, Replica를 새 Primary로 만들어야 합니다. 이 역할을 하는 것이 Sentinel입니다.

Sentinel은 크게 4가지 역할을 합니다: 모니터링(Primary/Replica 상태 감시), 알림(장애 발생 시 알림), 자동 Failover(Primary 대체), 설정 제공(클라이언트에게 현재 Primary 주소 알려줌).

Sentinel은 최소 3개를 운영해야 합니다. Sentinel이 다수결(Quorum)로 "Primary가 죽었다"고 판단하기 때문에, 1개면 잘못된 판단(Split Brain)이 생길 수 있습니다.

┌──────────────────────────────────────────────────┐
│ Sentinel1 Sentinel2 Sentinel3 │
│ ↓감시 ↓감시 ↓감시 │
│ Primary(6379) ← 죽으면 → Replica(6380) 승격 │
│ ↓ 새 Primary │
│ 클라이언트 → Sentinel에게 현재 Primary 주소 질문 │
└──────────────────────────────────────────────────┘

Sentinel의 주요 기능

기능	설명
Monitoring	PING으로 Primary/Replica 생존 여부 주기적 확인
Notification	장애 발생 시 운영자에게 API/이메일 알림
Automatic Failover	Primary 죽으면 자동으로 최적의 Replica 승격
Configuration Provider	클라이언트가 현재 Primary 주소를 Sentinel에게 질문

🔬 Lab 9: Docker로 Primary-Replica 구성

Bash

# Lab 9 — Primary-Replica 구성

# 1. Redis 전용 네트워크 생성
docker network create redis-net

# 2. Primary 실행
docker run -d \
  --name redis-primary \
  --network redis-net \
  -p 6379:6379 \
  redis:8.6.1

# 3. Replica 실행
docker run -d \
  --name redis-replica \
  --network redis-net \
  -p 6380:6379 \
  redis:8.6.1

# 4. Replica를 Primary에 연결
docker exec -it redis-replica redis-cli \
  REPLICAOF redis-primary 6379

# 5. 복제 상태 확인
docker exec -it redis-primary redis-cli INFO replication
# role: master
# connected_slaves: 1
# slave0: ip=172.x.x.x, port=6379, state=online, offset=..., lag=0

redis-cli — 복제 동작 확인

# Primary에 데이터 쓰기
docker exec -it redis-primary redis-cli SET repl:test "복제 테스트"

# Replica에서 읽기 (복제 확인)
docker exec -it redis-replica redis-cli GET repl:test
# → "복제 테스트" (Primary에서 복제됨!)

# Replica는 기본적으로 읽기 전용
docker exec -it redis-replica redis-cli SET repl:write "시도"
# → READONLY You can't write against a read only replica.

# 복제 지연 확인
docker exec -it redis-primary redis-cli INFO replication | grep lag

🚨 Docker/NAT 환경 주의사항

Docker의 bridge 네트워크에서 Sentinel을 구성할 때, Sentinel이 클라이언트에 알려주는 Primary 주소가 컨테이너 내부 IP일 수 있습니다. 외부에서 접근하는 클라이언트는 이 주소로 연결할 수 없습니다. 실제 운영에서는 sentinel announce-ip 옵션으로 외부 접근 가능한 IP를 명시해야 합니다.

🛡️ Sentinel 구성 개요 (개념 실습)

Sentinel은 별도 프로세스로 실행됩니다. 최소 3개를 권장하며, 각 Sentinel은 sentinel.conf 파일로 설정합니다.

sentinel.conf — 최소 설정 예시

# sentinel.conf
port 26379
daemonize no

# 모니터링할 Primary 설정
# sentinel monitor    
# quorum: "Primary 죽음"으로 판단하는 Sentinel 최소 동의 수
sentinel monitor mymaster 127.0.0.1 6379 2

# Primary 응답 없음 판단 시간 (밀리초)
sentinel down-after-milliseconds mymaster 5000

# Failover 타임아웃
sentinel failover-timeout mymaster 10000

# Failover 후 동시에 재동기화할 Replica 수
sentinel parallel-syncs mymaster 1

Bash — Sentinel 실행 (개념 확인용)

# Sentinel 실행
redis-sentinel /path/to/sentinel.conf

# 또는
redis-server /path/to/sentinel.conf --sentinel

# Sentinel 상태 확인
redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL slaves mymaster
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

💡 Sentinel과 ACL
Redis 8.x에서 Sentinel은 ACL(Access Control List)을 통한 인증을 지원합니다. Primary/Replica에 패스워드가 설정된 경우 sentinel.conf에도 sentinel auth-pass mymaster password를 추가해야 합니다. 공식 Sentinel 문서에서 인증 설정을 반드시 확인하세요.

⚠️ 실전 팁: 복제와 Sentinel 사용 시 체크사항

체크 항목	이유
Sentinel 최소 3개 운영	다수결 판단, Split-Brain 방지
Replica 읽기 분산 활용	Primary 부하 감소 (단, 복제 지연 주의)
비동기 복제 → 데이터 유실 가능	AOF + Replica 조합으로 내구성 강화
Failover 후 클라이언트 재연결	redis-py, node-redis의 Sentinel 지원 사용
Docker/NAT에서 announce-ip 설정	Sentinel이 올바른 주소 반환하도록

📌 10편 핵심 요약

1. 복제(Replication): Primary → Replica 비동기 동기화, 읽기 분산 가능
2. REPLICAOF: Replica를 Primary에 연결하는 명령
3. Sentinel: 모니터링 + 알림 + 자동 Failover + 설정 제공, 최소 3개 권장
4. 비동기 복제: Primary 장애 시 최근 데이터 유실 가능성 있음
5. Sentinel vs Cluster: Sentinel은 HA(고가용성), Cluster는 수평 확장 — 목적이 다름

✅ 10편 체크리스트

• Docker 네트워크로 Primary-Replica를 연결했다
• Primary에 데이터를 쓰고 Replica에서 읽어 복제를 확인했다
• Replica는 기본적으로 읽기 전용임을 확인했다
• INFO replication으로 복제 상태를 확인했다
• Sentinel의 4가지 역할(모니터링/알림/Failover/설정 제공)을 설명할 수 있다
• Sentinel과 Cluster의 차이(HA vs 샤딩)를 설명할 수 있다

🧠 퀴즈 3문항

Q1. Redis 복제는 동기식인가요, 비동기식인가요?

📡 비동기식입니다. Primary가 쓰기를 완료한 후 Replica에 변경사항을 전달합니다. 따라서 Primary 장애 시 아직 전달되지 못한 최근 데이터는 유실될 수 있습니다.

Q2. Sentinel을 왜 최소 3개 운영해야 하나요?

🗳️ Sentinel은 다수결(Quorum)로 Primary 장애를 판단합니다. 1개면 네트워크 순간 단절에도 잘못된 Failover가 발생할 수 있습니다. 3개 중 2개 이상 동의 시 Failover를 진행하면 Split-Brain 문제를 방지할 수 있습니다.

Q3. Sentinel과 Redis Cluster의 차이는 무엇인가요?

🔑 Sentinel은 단일 Primary의 고가용성을 위한 장애 복구 시스템입니다. Cluster는 데이터를 여러 노드에 분산 저장하는 수평 확장 시스템입니다. "장애 대비"가 필요하면 Sentinel, "메모리 부족"이 문제라면 Cluster를 선택하세요.

📝 과제 3가지

1. 복제 지연 측정: Primary에 1000개의 SET을 연속으로 실행한 후 INFO replication의 slave lag을 확인하세요.
2. 수동 Failover 시뮬레이션: Primary 컨테이너를 중지하고, Replica에서 REPLICAOF NO ONE으로 독립 Primary로 전환하세요.
3. 읽기 분산: Replica에 연결하고 GET 명령이 정상 동작하는 것을 확인하세요. SET을 시도하면 오류가 나는 것도 확인하세요.

📚 Redis 입문 시리즈 전체 목록

• 1편: Redis 시작하기
• 2편: 키·TTL·만료
• 3편: Strings
• 4편: Hashes
• 5편: Lists·Sets
• 6편: Sorted Sets
• 7편: Pub/Sub vs Streams
• 8편: 동시성 제어
• 9편: 퍼시스턴스
• 10편: 복제·고가용성 ← 현재
• 11편: 클러스터
• 12편: 보안·성능·관측