Amazon ElastiCache

같은 상품 정보나 세션 데이터를 요청마다 원본 데이터베이스에서 다시 읽으면 응답이 느려지고 DB 부하가 먼저 치솟습니다. 읽기 패턴이 반복되는데도 매번 원본에 가면 트래픽이 늘수록 병목이 더 빨리 옵니다.

초기에는 애플리케이션 서버 안에서 프로세스 메모리로 캐시를 운영하거나, EC2에 Redis를 직접 설치해서 썼습니다. 문제는 노드가 죽으면 캐시가 통째로 날아가는데, 수동으로 새 노드를 띄우고 데이터를 다시 채우는 동안 원본 DB로 트래픽이 몰려 장애가 연쇄적으로 번진다는 점이었습니다. 트래픽이 늘어 샤딩을 도입하면 노드를 추가하거나 빼는 재구성 과정에서 키 재배치가 필요했고, 그 동안 캐시 미스가 급증해 서비스 지연이 발생하는 일도 잦았습니다. 백업, 패치, 장애 전환까지 직접 관리하다 보니 캐시 레이어 운영이 본래 목적인 '지연 시간 줄이기'보다 더 큰 부담이 됐습니다. 그래서 캐시도 데이터베이스처럼 장애 전환, 확장, 패치를 서비스가 맡아주는 관리형 모델이 필요해졌고, ElastiCache가 그 자리를 채웠습니다.

ElastiCache는 Redis와 Memcached를 관리형으로 제공하고, 애플리케이션이 먼저 캐시를 조회한 뒤 없을 때만 원본 저장소를 조회하게 만듭니다. Redis는 캐시 외에도 큐와 메시지 브로커 성격으로 확장할 수 있고, 서버리스 옵션은 다중 AZ 중복 저장과 자동 확장을 붙여 캐시 용량 계획 부담을 줄여 줍니다.

ElastiCache와 DynamoDB는 둘 다 빠른 조회에 쓰이지만 역할이 다릅니다. ElastiCache는 원본 데이터 앞단의 캐시이고, DynamoDB는 그 자체가 영구 저장소가 되는 데이터베이스입니다. 원본 저장소 부하를 줄이고 응답 시간을 낮추는 게 목적이면 ElastiCache를 보고, 캐시가 아니라 본 저장소 자체를 설계하는 문제면 DynamoDB를 보면 됩니다.

세션 저장, 자주 조회되는 키, 랭킹, 저지연 읽기 최적화, 초고속 임시 상태 저장에 적합합니다. 원본 데이터베이스를 대체하기보다 보완하는 계층으로 봐야 합니다.