[🔴AWS 관리형 Redis] Sentinel일까, Redis Cluster일까?

 

 

AWS 관리형 Redis는 Sentinel일까, Redis Cluster일까? 🔴

먼저 결론부터 말씀드리면, AWS의 대표적인 관리형 Redis 호환 서비스인 Amazon ElastiCache는 설정 방식에 따라 둘 다 가능합니다.

AWS ElastiCache 설정일반 Redis와 비교하면

Cluster Mode Disabled + Replica + Multi-AZ	Master/Slave + Sentinel과 유사
Cluster Mode Enabled	Redis Cluster
ElastiCache Serverless	내부적으로 Cluster Mode Enabled
노드 1대만 생성	단일 Redis, 고가용성 아님

단, 중요한 차이가 있습니다.

AWS ElastiCache에서는 사용자가 Redis Sentinel 서버를 직접 설치하거나 관리하지 않습니다.

AWS가 노드 상태 감시, Primary 승격, 장애조치, 엔드포인트 관리 등을 서비스 내부에서 처리합니다. 따라서 정확히는 Sentinel 자체가 아니라 Sentinel과 비슷한 고가용성 기능을 AWS가 대신 제공하는 구조입니다.

AWS는 현재 Redis OSS뿐 아니라 Redis 호환 오픈소스 엔진인 Valkey도 ElastiCache에서 제공하고 있습니다.

---

1. AWS의 대표적인 Redis 관리형 서비스

AWS에서 Redis와 호환되는 대표적인 서비스는 두 가지입니다.

Amazon ElastiCache

캐시 용도로 사용하는 관리형 서비스입니다.

• 로그인 세션
• API 응답 캐시
• 조회 결과 임시 저장
• 실시간 순위
• 장바구니 임시 데이터
• 데이터베이스 부하 감소

Redis 서버 설치, 장애 감지, 패치, 백업, 모니터링 등의 운영 부담을 AWS가 줄여줍니다. Amazon ElastiCache 공식 설명

Amazon MemoryDB

Redis 또는 Valkey와 호환되는 내구성 있는 인메모리 데이터베이스입니다.

ElastiCache가 주로 캐시라면, MemoryDB는 Redis 호환 구조를 주 데이터베이스처럼 사용하고 싶은 경우에 적합합니다.

ElastiCache
→ 캐시 중심
→ 일부 데이터가 사라져도 원본 DB에서 재생성 가능

MemoryDB
→ 영구 데이터 저장 중심
→ 데이터 내구성과 복구가 더 중요

이번 질문의 “AWS Redis 관리형 서비스”는 일반적으로 많이 사용하는 ElastiCache 기준으로 설명하겠습니다.

---

2. ElastiCache Cluster Mode Disabled란?

Cluster Mode Disabled는 데이터를 여러 Master에 나누지 않는 구성입니다.

Primary 1대
   ├── Replica 1
   └── Replica 2

전체 데이터가 Primary에 저장되고 Replica에는 동일한 데이터가 복제됩니다.

일반 Redis 구성과 비교하면 다음과 같습니다.

직접 구축
Master + Slave + Sentinel

AWS ElastiCache
Primary + Replica + Multi-AZ + Automatic Failover

장애가 발생하면 어떻게 될까요?

Primary가 장애 나면 AWS ElastiCache가 다음 작업을 수행합니다.

1. Primary 장애 감지
2. 정상 Replica 선택
3. Replica를 새로운 Primary로 승격
4. 복제 구조 재구성
5. Primary 엔드포인트를 새로운 Primary에 연결
6. 장애 노드를 교체하거나 복구

직접 Redis를 구축한 경우 Sentinel이 담당하는 역할을 AWS가 내부적으로 처리합니다.

핵심 포인트

직접 구축: 사용자가 Sentinel 운영
ElastiCache: AWS가 장애 감지와 Failover 관리

따라서 사용자가 EC2에 Sentinel 3대를 별도로 설치할 필요가 없습니다.

---

3. ElastiCache Cluster Mode Enabled란?

Cluster Mode Enabled는 데이터를 여러 샤드에 나누어 저장하는 Redis Cluster 구성입니다.

Shard 1
Primary 1 ── Replica 1

Shard 2
Primary 2 ── Replica 2

Shard 3
Primary 3 ── Replica 3

예를 들어 전체 데이터가 300GB라면 다음과 같이 분산할 수 있습니다.

Shard 1: 약 100GB
Shard 2: 약 100GB
Shard 3: 약 100GB

각 샤드 안에는 하나의 Primary와 하나 이상의 Replica를 구성할 수 있습니다. AWS 콘솔에서 샤드 수와 샤드별 노드 수를 지정할 수 있습니다. AWS ElastiCache 샤드 설명

장애가 발생하면?

예를 들어 Shard 2의 Primary가 장애 나면:

Shard 1: 정상
Shard 2: Primary 장애 → Replica가 Primary로 승격
Shard 3: 정상

AWS가 해당 샤드의 Replica를 새로운 Primary로 자동 승격합니다.

Cluster Mode Enabled도 별도의 Sentinel은 필요하지 않습니다. Redis Cluster 기능과 AWS 관리 기능이 함께 장애조치를 처리합니다.

---

4. AWS ElastiCache Serverless는 어디에 속할까요?

ElastiCache Serverless는 사용자가 노드 수, 인스턴스 크기 및 샤드 구성을 직접 관리하지 않는 방식입니다.

애플리케이션
      │
단일 접속 엔드포인트
      │
AWS가 용량과 샤드 자동 관리

AWS 공식 문서상 ElastiCache Serverless의 Valkey 및 Redis OSS 캐시는 Cluster Mode Enabled로 운영되고, 내부 데이터를 여러 백엔드 샤드에 분할할 수 있습니다. 따라서 Cluster 모드를 지원하는 클라이언트가 필요합니다. AWS Serverless Redis 설정

정리하면:

ElastiCache Serverless는 사용자가 직접 노드를 구성하지 않지만, 기술적으로는 Redis Cluster 계열에 가깝습니다.

AWS가 다음 작업을 자동으로 수행합니다.

• 노드 및 샤드 관리
• 용량 확장과 축소
• 데이터 분산
• Multi-AZ 고가용성
• 장애 감지와 복구
• 단일 엔드포인트 제공

AWS 배포 방식 비교

---

5. 세 가지 방식 비교

구분Cluster Mode DisabledCluster Mode EnabledElastiCache Serverless

일반 Redis와 비교	Master/Replica + Sentinel 계열	Redis Cluster	자동 관리형 Redis Cluster 계열
데이터 분산	지원하지 않음	지원	AWS가 자동 처리
샤드 수	1개	1개 이상	자동 관리
Primary	기본적으로 1대	샤드마다 1대	사용자에게 노드 구조가 추상화됨
Replica	구성 가능	샤드마다 구성 가능	AWS가 관리
자동 Failover	Multi-AZ 설정 시 지원	Replica 구성 시 지원	기본 관리
Sentinel 직접 설치	필요 없음	필요 없음	필요 없음
수평 확장	제한적	가능	자동 확장
클라이언트	일반 Redis 연결 방식	Cluster 지원 필요	Cluster 지원 필요
운영 난이도	가장 낮은 편	상대적으로 높음	인프라 관리는 가장 단순
비용 예측	비교적 쉬움	비교적 쉬움	트래픽에 따라 변동
추천 환경	중소규모·일반 캐시	대용량·고트래픽	사용량 변동이 큰 서비스

---

6. 직접 구축 Redis와 AWS 관리형 서비스 비교

항목EC2 직접 구축AWS ElastiCache

Redis 설치	사용자가 수행	AWS 제공
버전 관리	사용자가 수행	AWS 관리 기능 제공
Sentinel 설치	직접 구성 필요	필요 없음
장애 감지	Sentinel 구성 필요	AWS가 관리
Primary 자동 승격	Sentinel 설정 필요	Automatic Failover 제공
OS 패치	사용자가 수행	기반 OS를 AWS가 관리
백업	직접 구성	스냅샷 기능 제공
모니터링	직접 구축	CloudWatch 연동
서버 접근	OS 접근 가능	Redis 엔드포인트만 접근
세부 설정 자유도	높음	일부 제한
운영 인력 부담	큼	상대적으로 작음
인프라 비용	저렴할 수 있음	관리 비용이 포함되어 높을 수 있음

---

7. AWS ElastiCache 비용 비교 💰

ElastiCache 비용은 크게 두 방식으로 계산됩니다.

노드 기반 방식

Cluster Mode Disabled와 Cluster Mode Enabled 모두 선택한 캐시 노드의 사용 시간에 따라 비용이 발생합니다.

월 비용 ≈ 노드 시간당 요금 × 노드 수 × 월 사용시간

여기에 다음 비용이 추가될 수 있습니다.

• 백업 스토리지
• 리전 또는 AZ 간 데이터 전송
• 스냅샷 저장
• 로그 저장
• 추가 모니터링

AWS 공식 설명에 따르면 노드 기반 ElastiCache는 각 캐시 노드의 사용 시간에 따라 과금됩니다. ElastiCache 요금 체계

Cluster Mode Disabled 비용 예시 구조

Primary 1대
Replica 1대
────────────
총 2개 노드 비용

Replica를 2대 사용한다면:

Primary 1대
Replica 2대
────────────
총 3개 노드 비용

Cluster Mode Enabled 비용 예시 구조

3개 샤드에 Replica를 각각 1대 구성하면:

Primary 3대
Replica 3대
────────────
총 6개 노드 비용

동일한 노드 사양만 단순 비교하면 Cluster Mode Enabled가 더 비쌉니다.

하지만 Cluster는 데이터를 여러 노드에 분산하므로 더 작은 노드 유형을 사용할 수 있습니다. 따라서 반드시 2노드 대비 6노드라서 정확히 3배라고 볼 수는 없습니다.

---

Serverless 방식

Serverless는 미리 노드를 선택하지 않고 다음 사용량을 중심으로 과금합니다.

• 저장된 데이터: GB-hours
• 처리 요청: ECPU
• 백업 또는 데이터 전송 관련 비용

즉, 사용량이 적을 때는 비용을 줄일 수 있지만 요청량과 저장 데이터가 계속 많으면 노드 기반보다 비싸질 수도 있습니다.

Serverless 비용
= 데이터 저장량
+ 요청 처리량
+ 부가 비용

AWS는 Serverless가 자동으로 용량을 확장하기 때문에 갑작스럽게 트래픽이 증가하는 서비스에 유리하다고 설명합니다. 반면 일정한 부하가 계속되는 서비스는 노드 기반과 비용을 비교해야 합니다.

---

8. 비용 관점에서 어느 방식이 유리할까요?

① 데이터가 작고 트래픽이 일정한 경우

추천:

Cluster Mode Disabled
Primary 1대 + Replica 1대
Multi-AZ + Automatic Failover

장점:

• 노드 수가 적음
• 비용 예측이 쉬움
• 구조가 단순함
• 자동 장애조치 가능
• Redis Cluster의 복잡성을 피할 수 있음

대부분의 중소규모 업무 시스템이나 웹서비스 캐시라면 가장 현실적인 구성입니다.

---

② 데이터가 크고 쓰기 요청이 많은 경우

추천:

Cluster Mode Enabled
여러 Shard + 샤드별 Replica

장점:

• 데이터를 여러 Primary에 분산
• 쓰기 처리량 분산
• 한 노드의 메모리 한계를 넘어 확장 가능
• 온라인으로 샤드 추가 및 재분배 가능

AWS ElastiCache는 Cluster Mode Enabled에서 샤드를 추가·제거하고 데이터를 재분배하는 수평 확장을 지원합니다. AWS Cluster Mode 확장 설명

초기 비용은 상대적으로 크지만 대용량 환경에서는 초고사양 단일 노드에 의존하는 것보다 유리할 수 있습니다.

---

③ 트래픽 변화가 매우 큰 경우

추천:

ElastiCache Serverless

예를 들면 다음과 같습니다.

• 특정 시간에만 사용자가 몰림
• 이벤트 기간에 트래픽 급증
• 신규 서비스라 사용량 예측이 어려움
• 개발·테스트 환경
• 인프라 용량 계획이 어려움

사용량에 맞춰 자동 확장되는 것이 장점이지만, 지속적으로 높은 트래픽을 처리한다면 노드 기반 예약형 구성이 더 경제적일 수 있습니다.

---

9. 기능 및 비용 종합 평가

평가 항목Mode DisabledMode EnabledServerless

초기 비용 부담	낮음	높음	사용량에 따라 낮을 수 있음
비용 예측 가능성	높음	높음	상대적으로 낮음
운영 편의성	높음	보통	매우 높음
자동 장애조치	지원	지원	지원
대용량 확장	제한적	매우 유리	자동 처리
쓰기 성능 확장	제한적	매우 유리	자동 처리
애플리케이션 호환성	유리	사전 확인 필요	Cluster 지원 필요
트래픽 급증 대응	수동 확장 필요	확장 가능	가장 편리
장기 고정 부하 비용	유리한 편	규모에 따라 유리	불리할 수 있음
소규모 서비스	추천	과도할 수 있음	사용 패턴에 따라 추천

---

10. AWS에서 확인해야 할 설정 ✅

ElastiCache를 사용한다고 해서 무조건 고가용성이 보장되는 것은 아닙니다.

AWS 콘솔에서 다음 항목을 확인해야 합니다.

Cluster Mode Disabled인 경우

• Replica가 1대 이상 존재하는지
• Primary와 Replica가 서로 다른 AZ에 배치됐는지
• Multi-AZ가 활성화됐는지
• Automatic Failover가 활성화됐는지
• 애플리케이션이 Primary Endpoint를 사용하는지
• 읽기 분산 시 Reader Endpoint를 사용하는지
• 백업과 스냅샷 보존기간이 설정됐는지

노드가 Primary 1대뿐이라면 관리형 서비스라도 고가용성 구성이 아닙니다.

Primary 1대만 사용
→ 장애 시 AWS가 노드를 다시 만들 수는 있음
→ 즉시 승격할 Replica가 없으므로 복구가 느릴 수 있음

Cluster Mode Enabled인 경우

• 필요한 샤드 수가 적절한지
• 각 샤드에 Replica가 있는지
• Primary와 Replica가 서로 다른 AZ에 있는지
• Automatic Failover가 활성화됐는지
• 클라이언트가 Redis Cluster를 지원하는지
• 다중 키 명령어와 Lua 스크립트가 Cluster와 호환되는지
• 특정 샤드에 요청이 몰리는 Hot Key가 없는지

---

11. 어떤 구성을 추천할까요? 🎯

일반적인 사내 시스템, 로그인 세션, API 캐시 또는 데이터베이스 조회 캐시라면 다음 구성이 합리적입니다.

Amazon ElastiCache for Valkey 또는 Redis OSS
Cluster Mode Disabled
Primary 1대 + Replica 1대
Multi-AZ 활성화
Automatic Failover 활성화
백업 활성화

이 구성은 직접 구축 환경의 다음 구조에 해당합니다.

Master + Slave + Sentinel

다만 Sentinel 운영은 AWS가 대신합니다.

데이터가 한 노드의 메모리 용량을 초과하거나 단일 Primary의 쓰기 성능이 부족하다면 다음 단계로 Cluster Mode Enabled를 선택하는 것이 좋습니다.

Cluster Mode Enabled
여러 Shard
샤드마다 Replica 1대 이상
Multi-AZ
Automatic Failover

사용량을 예측하기 어렵고 운영 인력을 최소화하려면 Serverless를 검토할 수 있습니다.

---

최종 결론

AWS 관리형 Redis인 Amazon ElastiCache는 어느 한쪽에만 속하는 서비스가 아닙니다.

Cluster Mode Disabled
→ Master/Replica + Sentinel과 유사
→ Sentinel 역할은 AWS가 대신 수행

Cluster Mode Enabled
→ Redis Cluster 구성
→ 데이터 샤딩과 자동 장애조치 제공

ElastiCache Serverless
→ AWS가 자동 관리하는 Cluster Mode Enabled 방식

비용과 운영 편의성을 함께 고려하면 일반적으로 다음처럼 선택할 수 있습니다.

중소규모·고정 트래픽: Cluster Mode Disabled
대용량·고성능: Cluster Mode Enabled
트래픽 예측이 어렵고 변동이 큼: ElastiCache Serverless

그리고 단순 캐시가 아니라 Redis 호환 시스템을 주 데이터베이스로 사용하면서 높은 데이터 내구성까지 요구한다면 Amazon MemoryDB를 별도로 검토하는 것이 좋습니다.