레디스: Redis
레디스 6 - Redis 데이터 복제와 클러스터 개념
https://youtu.be/5sjBKsJQmxo?si=JhGTlDqUx70LRbed Redis를 단일 서버로만 사용하면 가장 큰 문제가 하나 생긴다.
서버가 죽으면 데이터도 같이 사라진다.
이 문제를 해결하기 위해 Redis는 다음과 같은 구조를 제공한다.
- Replication (복제)
- Sentinel (자동 장애 대응)
- Cluster (확장 + 고가용성)
이번 글에서는 그중 핵심인 Replication과 Cluster 구조를 이해한다.
레디스 6 : Redis 데이터 복제와 클러스터 개념
1. Replication (복제)
Replication은 말 그대로 데이터를 다른 Redis 서버에 복사하는 구조다.
기본 구조
- Master (Primary) : 쓰기 담당
- Replica (Slave) : 읽기 + 복제
Client → Master → Replica
특징
- Master는 1개
- Replica는 여러 개 가능
- Master 데이터 변경 → Replica로 자동 전파
- Replica는 읽기 전용
왜 필요한가?
- 장애 대비 (데이터 유실 방지)
- 읽기 성능 분산 (Read Scaling)
동작 방식
- Replica가 Master에 연결
- 초기 전체 데이터 복제 (Full Sync)
- 이후 변경사항만 전달 (Partial Sync)
문제점 (중요)
Replication만 사용하면 치명적인 한계가 있다.
Master 장애 발생 시:
- 자동 전환 ❌
- 수동으로 Replica를 Master로 승격해야 함
즉,
Replication만으로는 무중단 서비스가 불가능
해결: Sentinel
이 문제를 해결하기 위해 Redis는 Sentinel을 제공한다.
Sentinel 역할:
- Master 상태 모니터링
- 장애 감지
- Replica → Master 자동 승격
- 클라이언트에 새로운 Master 정보 제공
👉 즉, Replication + Sentinel = 기본적인 HA 구조
Replication 설정
Replica 서버에서 설정한다.
sudo vi /etc/redis/redis.conf
replicaof <마스터IP> <마스터포트>
# 예시
replicaof 127.0.0.1 6379
설정 후 재시작:
sudo systemctl restart redis-server
2. Redis Cluster
Cluster는 Replication의 확장 버전이다.
Replication + 샤딩(Sharding, 데이터 분산)
왜 Cluster가 필요한가?
단일 Redis 서버의 한계:
- 메모리 한계
- CPU 한계
- 장애 시 전체 서비스 영향
Cluster가 해결하는 것
- 데이터 분산 저장 (샤딩)
- 서버 수평 확장 (Scale-out)
- 일부 노드 장애 시 전체 서비스 유지
Cluster 구조
Redis Cluster는 슬롯 기반 분산 구조를 사용한다.
- 전체 키 공간 → 16384 슬롯으로 나눔
- 각 노드가 일부 슬롯을 담당
Key → Hash → Slot → Node
Master - Replica 구조
Cluster에서도 Replication이 함께 사용된다.
- Master: 데이터 저장
- Replica: 장애 대비
장애 발생 시
- Master 장애 발생 → Replica 자동 승격
- 👉 Sentinel 없이도 자동 failover 가능
Cluster 특징 (중요 포인트)
1. 최소 3개 Master 필요
- 정상적인 장애 대응을 위해 최소 3개 노드 필요
2. Database 제한
- Cluster에서는 DB 0만 사용 가능
- (
SELECT 1같은 기능 사용 불가)
3. 포트 구조
- 기본 포트: 6379
- 클러스터 통신 포트: 6379 + 10000 = 16379
👉 두 포트 모두 열어야 함
Cluster 설정
redis.conf 설정
sudo vi /etc/redis/redis.conf
필수 설정
protected-mode no
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 10000
appendonly yes
설정 설명
cluster-enabled yes → 클러스터 활성화
cluster-config-file → 노드 정보 저장 파일 (자동 생성)
cluster-node-timeout → 노드 간 통신 타임아웃
appendonly yes → 데이터 유실 방지 (AOF 활성화)
서버 재시작
sudo systemctl restart redis-server
클러스터 생성
redis-cli --cluster create \
IP1:PORT IP2:PORT IP3:PORT
Replica 포함:
--cluster-replicas 1
정리: Replication vs Cluster
| 구분 | Replication | Cluster |
|---|---|---|
| 목적 | 데이터 복제 | 확장 + 복제 |
| 장애 대응 | 수동 (Sentinel 필요) | 자동 |
| 확장성 | 없음 | 있음 |
| 구조 | Master-Replica | Sharding + Replica |
| DB 기능 | 사용 가능 | 0번만 사용 |
실무 관점 핵심 정리
- Replication만 쓰면 반쪽짜리 HA
- Sentinel까지 붙여야 진짜 HA
- Cluster는 규모 커질 때 선택
대부분 서비스는:
- 초기 → Single + Replica
- 성장 → Sentinel
- 대규모 → Cluster
그리고 가장 중요한 한 줄:
Redis를 “어떻게 확장할지”는 데이터 크기보다 장애 전략이 먼저 결정한다
