AWS ElastiCache vs MemoryDB: 실제로 어떤 것이 필요하신가요?
발행: (2025년 12월 25일 오전 08:50 GMT+9)
5 min read
원문: Dev.to
Source: Dev.to
결정 가이드
데이터가 일시적인가요 (재생성 가능하거나 손실될 수 있나요)?
- YES → ElastiCache 사용 (≈ $12 / 월,
cache.t4g.micro기준) - NO → MemoryDB 사용 (≈ $25 +/ 월, 영구 저장소)
이것이 전체 결정입니다.
jo4.io에 ElastiCache를 선택한 이유
Redis가 필요한 경우:
| Use case | Impact if Redis dies |
|---|---|
Rate‑limiting counters (user:123:requests:minute) | Counters reset to 0 – users get a fresh minute; not a big deal |
| Session caching | Sessions expire – users log in again; minor inconvenience |
| Temporary feature flags | Flags reload from the database; brief hiccup |
Since all of these are ephemeral, ElastiCache is the appropriate choice.
MemoryDB를 고려해야 할 때
MemoryDB는 Redis가 진실의 출처를 담당하는 시나리오에 적합합니다:
- 재계산이 불가능한 리더보드/랭킹
- Redis가 데이터베이스인 실시간 인벤토리
- 잃을 수 없는 세션 데이터(예: 금융 애플리케이션)
- 메시지 손실이 거래 손실로 이어지는 메시지 큐
MemoryDB의 장점
- 다중 AZ 내구성(노드 장애 시 데이터 유지)
- 트랜잭션 로그 내구성(쓰기 내용이 영구 저장)
- 시점 복구
비용 비교 (소규모 프로덕션 워크로드)
| 서비스 | 노드 유형 | 월간 예상 비용 |
|---|---|---|
| ElastiCache | cache.t4g.micro | ~$12 |
| ElastiCache | cache.t4g.small | ~$24 |
| MemoryDB | db.t4g.small | ~$25 |
| MemoryDB | db.r6g.large | ~$200+ |
MemoryDB는 마이크로 티어를 제공하지 않으므로 최소 비용이 더 높습니다.
예시: ElastiCache 클러스터용 Terraform
resource "aws_elasticache_cluster" "redis" {
cluster_id = "jo4-prod-redis"
engine = "redis"
engine_version = "7.1"
node_type = "cache.t4g.micro"
num_cache_nodes = 1
port = 6379
parameter_group_name = "default.redis7"
subnet_group_name = aws_elasticache_subnet_group.redis.name
security_group_ids = [aws_security_group.redis.id]
# Daily snapshot, 7‑day retention (even for ephemeral data)
snapshot_retention_limit = 7
snapshot_window = "02:00-03:00"
maintenance_window = "sun:03:00-sun:04:00"
}ElastiCache의 한 가지 장점: VPC 내부에서 접근할 경우 인증이 필요하지 않습니다.
예시: Spring Boot Redis 설정 (YAML)
spring:
data:
redis:
host: ${REDIS_HOST}
port: ${REDIS_PORT}
timeout: 5000
# No password needed – security group controls accessRedis Cloud와 비교
| 기능 | Redis Cloud | VPC 내 ElastiCache |
|---|---|---|
| 인증 | 사용자명/비밀번호, TLS, 자격 증명 회전 | 비밀번호 불필요 (보안 그룹이 접근 제어) |
| 네트워크 의존성 | 외부 서비스 | 외부 의존성 없음 |
| 지연 시간 | 높음 (인터넷) | 낮음 (VPC 내부) |
마이그레이션 팁 (Redis Cloud → ElastiCache)
- 연결 설정 업데이트: 호스트, 포트, 그리고 제거 인증.
- 캐시가 비어 시작한다는 것을 받아들이고 – 앱이 빈 캐시를 정상적으로 처리하도록 설계하세요.
- 속도 제한 및 캐싱의 경우, 데이터가 일시적이므로 마이그레이션이 간단합니다.
사용 사례 매트릭스
| 사용 사례 | 권장 서비스 | 이유 |
|---|---|---|
| Rate limiting | ElastiCache | 일시적이며 재생성 가능 |
| Session cache | ElastiCache | 손실 시 재인증 가능 |
| Page cache | ElastiCache | 손실 시 재렌더링 가능 |
| Leaderboard (source of truth) | MemoryDB | 순위를 재생성할 수 없음 |
| Shopping cart (no DB backup) | MemoryDB | 사용자 데이터는 손실되지 않아야 함 |
| Real‑time inventory | MemoryDB | 비즈니스 핵심 |
| Pub/Sub messaging | Depends | 메시지 손실 = 금전 손실 → MemoryDB |
요약
- ElastiCache: 빠르고 저렴하며, 데이터 손실이 허용되는 캐싱 및 속도 제한에 이상적입니다.
- MemoryDB: 내구성이 뛰어나지만 비용이 더 많이 들며, Redis가 주요 데이터 저장소인 경우에 적합합니다.
과도하게 고민하지 마세요. 데이터를 다시 생성할 수 있다면 ElastiCache를 선택하세요.