AWS re:Invent 2023 - [LAUNCH] Introducing Amazon ElastiCache Serverless (DAT342)

AWS Events·AWS re:Invent 2023 2023·2023년

AI 요약

AWS re:Invent 2023의 DAT342 론칭 세션으로, capacity planning 부담을 완전히 없앤 Amazon ElastiCache Serverless를 소개한다. 사용자가 보는 단순함(이름만 주면 캐시 생성)부터 내부 구조(단일 엔드포인트 프록시·Caspian·heat 관리)까지 깊이 파고든다.

핵심 포인트

인스턴스 타입·샤드·replica를 고르지 않고 1분 내 캐시 생성, Redis 7.1·Memcached 1.6 호환, 캐시당 5TB, 99.99% SLA
예측 알고리즘으로 자동 수직·수평 스케일, 용량이 아닌 실제 사용량(ECPU·GB-hour)에 per-use 과금
Rust 프록시 기반 단일 엔드포인트로 토폴로지 변경을 숨기고, in-place 리사이징 EC2 'Caspian'과 power-of-two heat balancing으로 효율·격리 확보

왜 읽나트래픽 변동이 큰 워크로드에서 캐시 운영 부담을 줄이려는 엔지니어와, 서버리스 캐시의 내부 설계가 궁금한 이에게 유용하다.

챕터별 상세

010:00 – 6:02

캐시와 ElastiCache 기초 — Redis·Memcached

PM AB 와 엔지니어링 매니저 Yuron 이 'ElastiCache Serverless' 세션을 연다. 캐시는 데이터를 빠르고 낮은 지연으로 접근하도록 저장하는 것으로, 보통 비싸거나 느린 DB·서비스 앞에 두고 가장 자주 접근하는 데이터를 담아 성능을 높인다. ElastiCache 는 AWS의 대표 캐싱 서비스로 오픈소스 엔진 Memcached 와 Redis 두 가지와 호환되며 수십만 고객이 쓴다. RDS·Aurora·DynamoDB 앞에 두어 느린 읽기를 가속하고, 모든 데이터를 메모리에 둬 DB를 확장하거나 read replica를 늘리는 것보다 비용 효율적이다.

Redis 는 단순하면서도 유연·강력한 API와 sorted set·hashmap·stream·pubsub 같은 인메모리 자료구조를 갖춰 캐싱을 넘어 리더보드·스트리밍 등에 쓰이며 복제·cluster mode로 확장된다. Memcached 는 단순하고 빠른 API로 초고속이 필요할 때 쓰는, Redis 다음으로 인기 있는 엔진이다.

Serverless를 만든 통증점을 짚는다. 가장 큰 문제는 capacity planning이 어렵다 는 것이다. 피크보다 약간 높게 잡으면 예상 밖 피크에 성능이 무너지고, 저트래픽 시간엔 쓰지 않는 용량에 돈을 낸다. 수동 스케일은 임계값(메모리·CPU) 설정이 어렵고, 특히 sorted set 워크로드는 RPS가 늘어도 CPU가 선형으로 늘지 않아 까다롭다. Memcached 의 고가용성도 엔진이 기본 지원하지 않아 클러스터 두 개·프록시·resharding을 고객이 직접 처리해야 한다.

이를 해결하려 ElastiCache Serverless 를 내놨다. capacity planning을 완전히 없애 인스턴스 타입·샤드·replica 수를 고르지 않고, 1분 안에 캐시를 만들며 운영 부담을 AWS가 떠안는다. 설계 철학은 '이름만 주면 캐시를 만들어 준다'이며, 보안상 꼭 필요한 레버만 남겼다 — VPC 와 접근 AZ 선택(cross-AZ 지연 회피), 그리고 항상 켜진 전송·저장 암호화의 키 선택이다. Redis 7.1·Memcached 1.6 과 호환되고 캐시당 최대 5TB까지 커진다.

가장 큰 이점은 capacity planning 제거다. ElastiCache가 수직·수평으로 자동 확장해 던지는 트래픽을 알아서 맞추며, 메모리·네트워크·컴퓨트 사용률을 끊임없이 관측하고 예측 알고리즘 으로 다음 몇 분을 내다본다. 초당 5만 요청에서 스파이크가 오면 제자리에서 scale-up으로 받아 내는 동시에 단일 자릿수~10분 걸리는 scale-out을 미리 시작한다.

과금은 per-use 다. 용량이 아니라 실제 사용에 과금하며, 저장 데이터는 GB-hour, 요청은 ECPU(elastic processing unit) 로 계산한다. set/get이 1KB를 옮기면 1 ECPU, 2.3KB면 3 ECPU처럼 전송 데이터에 비례하고, sorted set 상위 조회처럼 vCPU 시간을 더 쓰는 명령은 그 배수만큼 매긴다. 기본으로 모든 캐시에 four nines(99.99%) SLA를 주고 여러 AZ에 복제하며, PCI·HIPAA 등 컴플라이언스도 그대로 지원한다.

스케일 시 클라이언트가 새 토폴로지를 재발견해야 하는 문제를, 클라이언트가 단일 노드처럼 보는 단일 엔드포인트 로 푼다. network load balanced 프록시 계층 이 모든 연결을 받아 실제 캐시 노드에 명령을 실행하므로, 노드가 사라져도 프록시가 토폴로지를 다시 발견해 매끄러운 가용성 곡선을 보인다. 읽기는 read-from-replica 시 sub-millisecond, 쓰기는 p50 1100·1900μs 수준이며 초당 수백만 요청·5TB까지 확장된다.

스케일링은 세 단계다. 초 단위 detection(예측으로 선제 scale-out), 1분 내 provisioning(대기 노드 목록 warm pooling), 그리고 슬롯 단위로 hot·cold를 판별해 병렬로 옮기는 data rebalancing(사용률 50%에서 스케일). 기반은 Caspian 으로, 메모리·CPU를 in-place로 빠르게 키우고 줄이는 새 EC2이며 협력적 오버서브스크립션 으로 비용을 해치지 않는다. async 폴링의 live aggregated view 로 hot Caspian을 찾아 heat balancing 하되 가장 hot한 노드는 건드리지 않고 두 번째로 hot한 노드 를 power of two random choices 로 옮기고, CPU는 cgroup·메모리는 hot plug로 noisy neighbor isolation 을 둔다. 프록시는 Rust 로 작성했고 multiplexing 으로 처리량을 3.5배 높였다. best practice로 read-from-replica(클라이언트 옵션만 켜면 로컬 AZ 우선 읽기)를 들고 Python Redis 예제로 마무리한 뒤 Q&A를 연다.