아마존 ElastiCache
더 많은 작업
- Amazon ElastiCache; ElastiCache; 아마존 일래스티캐시
- Valkey, Redis OSS, Memcached 엔진을 완전 관리형으로 제공하는 AWS의 인메모리 캐시·키-값 저장소 서비스
아마존 ElastiCache는 자주 읽는 데이터를 메모리에 올려 두고 마이크로초~밀리초 단위로 돌려주는 서비스이다. 데이터베이스 앞에 두어 같은 조회를 반복하지 않게 하거나, 웹 애플리케이션의 세션을 여러 서버가 공유하게 하거나, 순위표·카운터처럼 빠르게 바뀌는 값을 다룰 때 쓴다. 노드 설치, 패치, 장애 노드 교체, 모니터링을 AWS가 맡는다.
사용 형태는 두 가지이다. ElastiCache Serverless는 노드나 클러스터를 설계하지 않고 캐시 이름만 정하면 1분 안에 만들어지고, 메모리·컴퓨팅·네트워크 사용량에 따라 자동으로 확장된다. 데이터를 여러 가용 영역에 자동 복제하며 캐시마다 99.99% 가용성 SLA가 붙는다. 노드 기반 클러스터는 노드 유형, 샤드 수, 복제본 수를 직접 정해 세밀하게 통제한다.
| 구분 | Valkey·Redis OSS | Memcached |
|---|---|---|
| 데이터 구조 | 문자열, 해시, 리스트, 집합, 정렬 집합, 지리 공간 인덱스 등 복잡한 자료구조 | 단순 키-값(문자열·객체) |
| 복제·고가용성 | 샤드마다 주 노드와 읽기 복제본(최대 5개), 다중 AZ 자동 장애 조치 | 복제 없음. 노드가 죽으면 그 노드의 데이터는 사라짐 |
| 데이터 분할 | 클러스터 모드를 켜면 여러 샤드로 분할, 온라인 리샤딩 | 여러 노드에 분산(클라이언트가 키를 나눔) |
| 백업·복원 | 스냅샷 백업과 복원 지원 | 서버리스 캐시만 지원, 노드 기반 클러스터는 미지원 |
| 멀티스레드 | 아님 | 멀티스레드, 코어가 많은 큰 노드 활용 |
| 게시/구독(Pub/Sub) | 지원 | 미지원 |
| 기타 | 역할 기반 접근 제어, 데이터 계층화(메모리+SSD), Valkey 최신 버전의 벡터 검색 등 | 가장 단순한 모델 |
| 맞는 경우 | 고가용성, 영속성, 복잡한 자료구조, 순위표, 세션 저장소 | 단순 객체 캐시, 노드를 쉽게 늘리고 줄이는 수평 확장 |
Valkey는 Redis의 라이선스 변경 뒤 Linux Foundation과 Redis OSS 개발자들이 Redis OSS 7.2 계열을 포크해 만든 오픈소스 키-값 엔진이다. Redis OSS와 호환되는 명령과 자료구조를 그대로 쓰며, ElastiCache에서는 Redis OSS와 같은 기능 범주(복제, 다중 AZ, 클러스터 모드, 백업)를 제공한다. 최신 버전에서는 메모리 효율 개선, 블룸 필터, 벡터 검색 같은 기능이 추가되었다. 새로 Redis 계열 캐시를 만든다면 Valkey를 먼저 검토할 만하다.
Redis OSS 엔진을 쓰는 ElastiCache이다. 현재 AWS 문서의 공식 표기는 "ElastiCache for Redis OSS"이다. 클러스터 모드 비활성(샤드 1개, 주 노드 1개와 복제본)과 클러스터 모드 활성(여러 샤드로 데이터 분할) 중에서 고른다. 다중 AZ를 켜면 주 노드 장애 시 복제본이 자동 승격되고 기본 엔드포인트의 DNS가 새 주 노드를 가리키므로 애플리케이션을 고칠 필요가 없다.
멤캐시드 엔진을 쓰는 ElastiCache이다. 구조가 가장 단순하고 멀티스레드로 동작해 큰 노드의 여러 코어를 활용한다. 노드를 추가·제거해 수평 확장하기 쉽지만 복제와 영속성이 없어 데이터가 사라져도 원본에서 다시 채울 수 있는 순수 캐시에만 쓴다.
| 전략 | 동작 | 장점 | 단점 |
|---|---|---|---|
| 지연 로딩(lazy loading, cache-aside) | 캐시를 먼저 보고, 없으면(캐시 미스) DB에서 읽어 캐시에 넣는다 | 실제로 요청된 데이터만 캐시. 노드가 교체돼도 지연만 늘 뿐 동작은 유지 | 미스마다 왕복 3번(캐시 조회, DB 조회, 캐시 쓰기)의 지연. DB가 바뀌어도 캐시는 갱신되지 않아 오래된 데이터가 남음 |
| 쓰기 연동(write-through) | DB에 쓸 때 캐시도 함께 갱신한다 | 캐시 데이터가 항상 최신 | 읽히지 않을 데이터까지 캐시에 쌓임. 쓰기마다 지연 추가. 새 노드는 쓰기가 일어나기 전까지 비어 있음 |
| TTL 추가 | 캐시 항목에 만료 시간을 둔다 | 오래된 데이터와 쓸모없는 항목을 자동으로 정리 | 만료 직후 미스가 몰리면 DB 부하가 순간적으로 증가 |
실무에서는 지연 로딩과 쓰기 연동을 함께 쓰고 TTL을 붙여 둘의 단점을 보완하는 경우가 많다.
다음은 지연 로딩과 TTL을 함께 쓰는 예이다.
def get_customer(customer_id):
key = f"customer:{customer_id}"
cached = cache.get(key)
if cached is not None:
return cached # 캐시 적중
record = db.query("SELECT * FROM customers WHERE id = %s", customer_id)
cache.set(key, record, ex=300) # 300초 TTL로 저장
return record
- DB 읽기 부하 감소: 아마존 RDS나 아마존 Aurora 앞에 두어 반복 조회를 캐시에서 처리한다. 읽기 복제본을 늘리는 것보다 응답이 빠르고, 같은 쿼리가 반복되는 경우 비용도 줄어든다.
- 세션 저장소: 로드 밸런서 뒤의 여러 웹 서버가 세션을 공유하게 해서 서버를 무상태로 만든다. 고정 세션(sticky session) 없이 오토 스케일링을 할 수 있다.
- 순위표·카운터: Valkey·Redis OSS의 정렬 집합으로 실시간 순위를 계산한다.
- 메시지·실시간 처리: Pub/Sub, 스트림 자료구조로 가벼운 메시징을 한다.
- 노드 기반 클러스터는 VPC 안에 만들고 보안 그룹으로 접근을 제한한다. 서버리스 캐시는 VPC 연결 외에, 최신 Valkey에서 IAM 인증과 TLS를 강제하는 퍼블릭 엔드포인트도 고를 수 있다.
- 전송 중 암호화(TLS)와 저장 데이터 암호화를 지원한다. Valkey·Redis OSS는 AUTH 토큰이나 역할 기반 접근 제어로 사용자를 인증한다.
- 엔진 버전은 올릴 수만 있고 내릴 수 없다.
- 같은 조회가 반복돼 DB가 느려지거나 읽기 부하가 크면 ElastiCache를 앞에 두는 것이 정답인 경우가 많다. 쓰기 부하 문제에는 캐시가 해답이 아니다.
- 고가용성, 복제, 장애 조치, 백업, 복잡한 자료구조(정렬 집합 순위표 등)가 필요하면 Valkey 또는 Redis OSS, 단순하고 멀티스레드인 캐시면 Memcached를 고른다.
- 여러 웹 서버의 사용자 세션 공유는 ElastiCache(또는 다이나모DB)에 세션을 두는 방식이다.
- 캐시 데이터가 오래돼 문제가 되면 쓰기 연동이나 TTL, 캐시 공간 낭비와 미스 지연이 문제면 지연 로딩의 특성을 떠올린다.
- 캐시 용량 계획과 운영을 줄이려면 ElastiCache Serverless를 고른다.
- 캐시가 아니라 주 데이터베이스로 쓸 내구성 있는 인메모리 DB가 필요하면 아마존 MemoryDB를 고른다(AWS 특수 목적 데이터베이스 참고).