두 구성 모두 Redis 장애에 대비할 수 있지만, 가장 큰 차이는 데이터를 저장하는 방식입니다.
Sentinel 구성은 전체 데이터를 그대로 복제하고, Redis Cluster는 데이터를 여러 서버에 나누어 저장합니다.
1. 핵심 차이부터 쉽게 보기
Master/Slave + Sentinel
Sentinel 3대
상태 감시·장애조치
│
▼
Master 1대 ──────▶ Replica 1
└──────▶ Replica 2- Master 한 대가 전체 데이터를 저장
- Replica가 Master의 전체 데이터를 복제
- Sentinel이 Master 장애를 감지
- 장애 발생 시 Replica 중 하나를 새로운 Master로 승격
즉, 데이터 복제와 자동 장애조치 중심의 구성입니다.
Redis Cluster
Master 1 ── Replica 1
Master 2 ── Replica 2
Master 3 ── Replica 3데이터를 여러 Master에 나누어 저장합니다.
Master 1: 데이터 A
Master 2: 데이터 B
Master 3: 데이터 C각 Master에는 장애에 대비한 Replica가 연결됩니다.
즉, 데이터 분산 저장과 자동 장애조치를 함께 제공하는 구성입니다.
2. 가장 중요한 차이: 데이터 분산 여부
Sentinel 구성
Master가 전체 데이터를 저장합니다.
예를 들어 전체 Redis 데이터가 30GB라면:
Master : 전체 데이터 30GB
Replica 1 : 전체 데이터 30GB
Replica 2 : 전체 데이터 30GB서버 3대가 모두 동일한 데이터를 가지고 있습니다.
따라서 실제 데이터는 30GB지만, 복제본까지 포함하면 최소 90GB 수준의 메모리가 필요합니다. 운영 여유 공간까지 고려하면 더 큰 메모리가 필요합니다.
또한 쓰기 요청이 Master 한 대에 집중됩니다.
모든 쓰기 요청 → Master 1대Master의 CPU, 네트워크 또는 메모리 한계에 도달하면 단순히 서버를 추가하는 것만으로 쓰기 성능을 확장하기 어렵습니다.
Redis Cluster 구성
Redis Cluster는 데이터를 여러 Master에 나누어 저장합니다.
전체 데이터가 90GB이고 Master가 3대라면 단순한 예시는 다음과 같습니다.
Master 1 : 약 30GB
Master 2 : 약 30GB
Master 3 : 약 30GB각 Master에 Replica를 한 대씩 구성하면:
Master 1 30GB ── Replica 1 30GB
Master 2 30GB ── Replica 2 30GB
Master 3 30GB ── Replica 3 30GB데이터와 요청이 여러 Master로 분산되므로:
- 한 서버의 메모리 한계를 넘는 데이터 저장 가능
- 쓰기 부하 분산 가능
- 처리량 수평 확장 가능
- 일부 서버 장애 시 자동 Failover 가능
3. 구성 요소 비교
| 기본 목적 | 고가용성 및 자동 장애조치 | 데이터 분산과 고가용성 |
| Master 수 | 일반적으로 1대 | 일반적으로 3대 이상 |
| 데이터 저장 | Master 한 대에 전체 저장 | 여러 Master에 분산 저장 |
| Replica | 전체 데이터 복제 | 담당 Master 데이터만 복제 |
| 자동 Failover | Sentinel이 처리 | Cluster 자체에서 처리 |
| Sentinel 필요 여부 | 필요 | 필요 없음 |
| 샤딩 | 지원하지 않음 | 자동 샤딩 지원 |
| 쓰기 부하 분산 | 어려움 | 가능 |
| 수평 확장 | 제한적 | 가능 |
| 구성 난이도 | 비교적 간단 | 상대적으로 복잡 |
| 클라이언트 요구사항 | Sentinel 지원 필요 | Cluster 지원 필요 |
| 적합한 환경 | 중소규모·단일 Redis 데이터 | 대용량·고성능 서비스 |
4. 서버 구성은 몇 대가 필요할까요? 🖥️
Master/Slave + Sentinel 권장 구성
일반적인 예시는 다음과 같습니다.
Redis 데이터 노드
- Master 1대
- Replica 2대
Sentinel
- Sentinel 3개여기서 중요한 것은 Sentinel이 반드시 별도의 고사양 서버를 사용해야 하는 것은 아니라는 점입니다.
Sentinel은 Redis 데이터를 저장하지 않고 상태를 감시하므로 상대적으로 자원 사용량이 작습니다.
구성 방법은 크게 두 가지입니다.
방법 A: Redis 서버에 Sentinel 함께 설치
서버 1: Master + Sentinel
서버 2: Replica + Sentinel
서버 3: Replica + Sentinel총 서버 수는 3대입니다.
비용을 줄일 수 있지만, 서버와 Sentinel 장애 영역이 완전히 분리되지 않는다는 점을 고려해야 합니다.
방법 B: Sentinel을 별도 서버에 설치
Redis 서버 3대
Sentinel 서버 3대총 6대가 필요합니다.
Sentinel 서버는 작은 사양을 사용할 수 있지만, 서버·OS·모니터링 등 관리 대상은 늘어납니다.
Redis Cluster 권장 구성
운영 환경에서는 일반적으로 다음과 같이 구성합니다.
Master 3대
Replica 3대총 6개의 Redis 노드입니다.
Master 1 ── Replica 1
Master 2 ── Replica 2
Master 3 ── Replica 3Master 한 대가 장애 나면 해당 Master의 Replica가 새로운 Master로 승격됩니다.
별도의 Sentinel은 필요하지 않습니다.
테스트 목적이라면 3개 Master만 구성할 수 있지만, Replica가 없으면 장애 시 데이터를 대신할 노드가 없으므로 운영 환경의 고가용성 구성으로는 부족합니다.
5. 비용은 어느 쪽이 더 저렴할까요? 💰
정확한 금액은 서버 사양, 클라우드 사업자, 관리형 Redis 사용 여부, 데이터 용량과 트래픽에 따라 달라집니다.
따라서 먼저 상대적인 비용을 비교해 보겠습니다.
소규모 환경의 비용 비교
예를 들어 데이터가 10GB이고 트래픽이 많지 않다고 가정해 보겠습니다.
Sentinel 구성
Master 1대
Replica 2대
Sentinel은 같은 서버에 배치필요한 서버는 총 3대입니다.
Redis Cluster 구성
Master 3대
Replica 3대일반적인 고가용성 구성에서는 총 6개 Redis 노드가 필요합니다.
따라서 소규모 환경에서는 대체로 Master/Slave + Sentinel 구성이 저렴합니다.
대규모 환경의 비용 비교
데이터가 매우 크다면 상황이 달라집니다.
예를 들어 Redis에 300GB를 저장한다고 가정해 보겠습니다.
Sentinel 구성
Master 한 대가 전체 데이터를 저장해야 하므로 각 노드가 300GB 이상의 데이터를 처리해야 합니다.
Master : 300GB 이상
Replica 1 : 300GB 이상
Replica 2 : 300GB 이상Redis 운영 여유 공간과 장애조치 과정까지 고려하면 각 서버에 데이터 크기보다 훨씬 많은 메모리가 필요할 수 있습니다.
결국 고용량 메모리 서버 3대가 필요합니다.
Redis Cluster 구성
데이터를 Master 3대 이상에 분산할 수 있습니다.
Master 1 : 약 100GB
Master 2 : 약 100GB
Master 3 : 약 100GBReplica까지 포함하면 서버 수는 많아지지만, 한 서버에 요구되는 메모리는 상대적으로 작습니다.
따라서 대용량 환경에서는 Cluster가 처음에는 복잡해 보여도 다음 측면에서 유리할 수 있습니다.
- 상대적으로 작은 서버를 여러 대 사용 가능
- 서버 추가로 용량 확장 가능
- 쓰기 처리량 분산 가능
- 초고사양 단일 서버 의존성 감소
즉, 서버 수만 보고 비용을 비교하면 안 됩니다.
6. 비용 항목별 비교 📊
| 초기 서버 비용 | 비교적 낮음 | 비교적 높음 |
| 최소 운영 노드 | 보통 Redis 3대 | 보통 Redis 6개 노드 |
| Sentinel 비용 | 별도 구성 시 발생 | 필요 없음 |
| 서버당 메모리 | 전체 데이터를 담아야 함 | 데이터를 나누어 저장 가능 |
| 네트워크 비용 | 전체 데이터 복제 | 샤드별 Replica로 복제 |
| 운영 복잡도 | 비교적 낮음 | 높음 |
| 애플리케이션 수정 비용 | 상대적으로 적음 | Cluster 호환성 검토 필요 |
| 확장 비용 | 서버 수직 확장 중심 | 노드 추가 수평 확장 가능 |
| 장애 대응 비용 | 자동 Failover 가능 | 자동 Failover 가능 |
| 장기 대규모 운영 | 한계가 있을 수 있음 | 상대적으로 유리 |
7. 단순 비용 계산 예시
이해를 돕기 위한 가상의 계산입니다.
서버 한 대의 월 비용을 다음과 같이 가정해 보겠습니다.
- 일반 Redis 서버: 월 30만 원
- Sentinel 전용 소형 서버: 월 5만 원
Sentinel을 Redis 서버에 함께 설치
Redis 서버 3대 × 30만 원
= 월 90만 원Sentinel을 별도 서버에 설치
Redis 서버 3대 × 30만 원 = 90만 원
Sentinel 서버 3대 × 5만 원 = 15만 원
총 월 105만 원Redis Cluster 6노드 구성
Redis 노드 6대 × 30만 원
= 월 180만 원이 가정에서는 Sentinel 구성이 저렴합니다.
하지만 Cluster에서는 데이터가 분산되므로 Sentinel 구성과 동일한 사양의 서버가 필요하지 않을 수도 있습니다.
예를 들어 작은 서버를 사용할 수 있다면:
Cluster 노드 6대 × 20만 원
= 월 120만 원이처럼 실제 비용은 다음 조건을 넣어 계산해야 정확합니다.
- 전체 데이터 크기
- 데이터 증가량
- 초당 읽기·쓰기 요청 수
- 서버당 메모리
- 네트워크 트래픽
- 백업 용량
- 관리형 서비스 비용
- 운영 인력과 장애 대응 비용
8. 성능은 어느 구성이 유리할까요? 🚀
읽기 성능
두 구성 모두 Replica를 활용해 읽기 요청을 분산할 수 있습니다.
하지만 Replica에서 읽으면 복제 지연으로 인해 방금 저장한 최신 데이터가 바로 조회되지 않을 수 있습니다.
강한 데이터 일관성이 필요한 요청은 Master에서 읽는 방식이 필요할 수 있습니다.
쓰기 성능
쓰기 성능은 Redis Cluster가 유리합니다.
Sentinel 구성
모든 쓰기 → Master 한 대Master의 처리 성능이 전체 쓰기 성능의 한계가 됩니다.
Redis Cluster
쓰기 A → Master 1
쓰기 B → Master 2
쓰기 C → Master 3여러 Master가 쓰기 요청을 나누어 처리하므로 전체 처리량을 높일 수 있습니다.
다만 특정 키에 요청이 몰리면 하나의 샤드만 과부하되는 Hot Key 문제가 발생할 수 있습니다.
9. Redis Cluster가 무조건 좋은 것은 아닙니다 ⚠️
Redis Cluster는 확장성이 좋지만 그만큼 고려할 사항도 많습니다.
여러 키를 동시에 사용하는 명령어 제한
Cluster에서는 키가 서로 다른 Master에 저장될 수 있습니다.
예를 들어 다음 두 키가 서로 다른 샤드에 저장되어 있다고 가정해 보겠습니다.
user:1001 → Master 1
order:1001 → Master 2여러 키를 한 번에 처리하는 일부 명령어, Lua 스크립트 또는 트랜잭션은 키가 같은 해시 슬롯에 있어야 정상적으로 동작할 수 있습니다.
필요한 경우 Hash Tag를 사용해 관련 키를 같은 슬롯에 배치해야 합니다.
user:{1001}
order:{1001}중괄호 안의 값이 같으면 같은 해시 슬롯에 배치되도록 설계할 수 있습니다.
애플리케이션 클라이언트 호환성
애플리케이션이 사용하는 Redis 라이브러리가 Cluster 모드를 지원해야 합니다.
Cluster에서는 접속한 노드에 원하는 키가 없으면 다른 노드로 이동하라는 응답을 받을 수 있습니다. 클라이언트가 이를 이해하고 올바른 노드로 다시 요청해야 합니다.
운영 난이도 증가
다음 항목을 추가로 관리해야 합니다.
- 해시 슬롯 분배
- 노드 추가와 제거
- 데이터 재분배
- 샤드별 사용량 불균형
- Hot Key
- Cross-slot 오류
- Cluster 지원 클라이언트
- 다중 키 명령어와 트랜잭션 제한
따라서 데이터가 작고 성능도 충분한데 무조건 Cluster를 도입하면 운영 복잡도와 비용만 증가할 수 있습니다.
10. Sentinel 구성의 주의점
Sentinel 구성도 완벽한 것은 아닙니다.
Master 한 대의 성능 한계
모든 쓰기가 한 Master에 집중되므로 수평 확장이 어렵습니다.
전체 데이터가 한 노드에 들어가야 함
Master와 각 Replica가 전체 데이터를 저장해야 합니다.
비동기 복제로 인한 데이터 유실 가능성
Master의 최신 데이터가 Replica로 전달되기 전에 장애가 발생하면 일부 데이터가 유실될 수 있습니다.
애플리케이션의 Sentinel 지원 필요
Sentinel이 새로운 Master를 승격하더라도 애플리케이션이 기존 Master IP만 바라보면 자동으로 복구되지 않습니다.
애플리케이션과 Redis 클라이언트가 Sentinel을 통해 현재 Master를 찾도록 구성해야 합니다.
11. 어느 구성이 더 유리할까요? 🎯
Master/Slave + Sentinel이 유리한 경우
다음 조건이라면 Sentinel 구성이 적합합니다.
- 데이터가 한 Redis 서버의 메모리에 충분히 들어감
- 쓰기 부하가 Master 한 대의 성능 범위에 있음
- 빠른 수평 확장이 필요하지 않음
- 구성과 운영을 단순하게 유지하고 싶음
- 초기 인프라 비용을 줄이고 싶음
- 기존 애플리케이션 구조를 크게 변경하기 어려움
- 자동 장애조치가 가장 중요한 목적임
예를 들면 다음과 같습니다.
- 사내 업무 시스템
- 로그인 세션 저장소
- 일반적인 웹서비스 캐시
- 중소규모 쇼핑몰
- 데이터 크기와 트래픽이 예측 가능한 서비스
대부분의 중소규모 서비스라면 Master/Replica + Sentinel로 시작하는 것이 비용과 운영 측면에서 현실적입니다.
Redis Cluster가 유리한 경우
다음 조건이라면 Redis Cluster가 적합합니다.
- 데이터가 한 서버의 메모리 용량을 초과함
- 데이터가 계속 빠르게 증가함
- 쓰기 요청량이 매우 많음
- 여러 Master로 요청을 분산해야 함
- 서버를 추가하는 방식으로 확장해야 함
- 대규모 사용자와 트래픽을 처리해야 함
- 애플리케이션이 Cluster 모드를 지원함
- Cluster 운영 경험과 모니터링 체계를 갖추고 있음
예를 들면 다음과 같습니다.
- 대규모 게임 서비스
- 대형 쇼핑 플랫폼
- 실시간 광고 시스템
- 대규모 사용자 세션 처리
- 대용량 캐시 시스템
- 초당 요청량이 매우 높은 서비스
12. 상황별 추천표 ✅
| Redis 한 대로 성능은 충분하지만 장애 대비가 필요함 | Master/Replica + Sentinel |
| 비용을 최대한 줄여야 함 | Master/Replica + Sentinel |
| 운영 인력이 많지 않음 | Master/Replica + Sentinel |
| 데이터가 한 서버 메모리에 충분히 들어감 | Master/Replica + Sentinel |
| 전체 데이터가 한 서버 용량을 초과함 | Redis Cluster |
| 쓰기 성능이 한 Master의 한계에 도달함 | Redis Cluster |
| 서버 추가 방식으로 계속 확장해야 함 | Redis Cluster |
| 여러 키를 묶는 명령과 트랜잭션이 많음 | Sentinel 우선 검토 |
| 대규모 트래픽과 데이터 증가가 예상됨 | Redis Cluster |
| 단순한 자동 장애조치만 필요함 | Master/Replica + Sentinel |
13. 최종 결론
두 구성을 한 문장으로 정리하면 다음과 같습니다.
Master/Slave + Sentinel은 하나의 Redis 데이터를 안전하게 복제하고 자동 복구하는 구성이고, Redis Cluster는 데이터를 여러 Redis 서버에 분산하여 용량과 처리 성능까지 확장하는 구성입니다.
비용과 운영 난이도를 기준으로 보면:
소규모·중간 규모
→ Master/Replica + Sentinel이 유리
대용량·고트래픽·수평 확장 필요
→ Redis Cluster가 유리특별한 대용량 또는 고성능 요구사항이 없다면 처음부터 Redis Cluster를 선택할 필요는 없습니다. 일반적으로는 Master 1대 + Replica 2대 + Sentinel 3개로 시작하는 편이 경제적이고 관리하기 쉽습니다.
반대로 다음 두 가지 중 하나라도 해당한다면 Redis Cluster를 본격적으로 검토하는 것이 좋습니다.
- 전체 Redis 데이터가 한 서버의 안전한 메모리 범위를 넘어가는 경우
- 쓰기 요청량이 단일 Master의 처리 한계에 도달한 경우
결국 선택 기준은 단순히 “어느 기술이 더 좋으냐”가 아닙니다.
자동 장애복구만 필요한지, 아니면 데이터와 성능까지 여러 서버로 분산해야 하는지를 기준으로 선택해야 합니다.
'[HAN-ENG]' 카테고리의 다른 글
| [AWS] RDS for MySQL과 Aurora MySQL 차이 쉽게 알아보기 🐬 (0) | 2026.07.19 |
|---|---|
| [🔴AWS 관리형 Redis] Sentinel일까, Redis Cluster일까? (0) | 2026.07.19 |
| [🔴Redis Master/Slave + Redis Sentinel 구성] 초보자도 쉽게 이해하기 !! (0) | 2026.07.19 |
댓글