02. Amazon ElastiCache

Amazon ElastiCache

Amazon ElastiCache 는 AWS 의 완전 관리형 분산 인메모리 캐싱 서비스로 Redis 또는 Memcached 엔진을 지원한다. 인메모리 DB 의 고성능 및 낮은 지연 시간 특성을 활용하여 읽기 집약적인 워크로드에서 DB의 부하를 줄이거나 애플리케이션을 stateless 로 만드는 데 사용할 수 있다.

Use Case - DB Cache

애플리케이션이 ElastiCache 에 쿼리
데이터가 없으면 RDS 에서 가져와 ElastiCache 에 저장
캐시는 최신 데이터만 사용되도록 무효화 전략이 필요

Use Case - User Session Store

사용자가 애플리케이션 중 하나에 로그인
애플리케이션이 세션 데이터를 ElastiCache 에 작성
사용자가 다른 애플리케이션 인스턴스에 접속
해당 인스턴스가 세션 데이터를 가져와 사용자 로그인 상태 유지

Redis vs Memcached

Redis

읽기 확장 및 고가용성을 위한 Read Replica 를 추가하여 Multi-AZ 로 구성이 가능하다.
Master 에 장애가 발생하면 Read Replica 가 Master 로 승격되는 Auto-Failover 를 지원한다.
AOF 지속성을 사용한 데이터 내구성
Amazon S3 에 Snapshot 저장을 통한 백업 및 복원을 지원하여 데이터 영구 보존 역시 가능하다.
Sets 및 Sorted Sets 지원

Memcached

데이터 파티셔닝(샤딩)을 위한 Multi-node
HA 없음
비영구적
백업 및 복원 없음
멀티스레드 아키텍처

Patterns for ElastiCache

Lazy Loading
- 모든 읽기 데이터가 캐시됨, 캐시의 데이터가 오래될 수 있음
Write Through
- DB에 쓸 때 캐시에 데이터 추가 또는 업데이트 (오래된 데이터 없음)
Session Store
- 캐시에 임시 세션 데이터 저장 (TTL 기능 사용)

Cache Security

ElastiCache 는 Redis용 IAM 인증 지원
ElastiCache 의 IAM 정책은 AWS API 레벨 보안에만 사용됨
Redis Auth
- Redis 클러스터 생성 시 비밀번호/토큰 설정 가능
- 캐시에 대한 추가 보안 계층 (SG 위에)
- SSL 전송 중 암호화 지원
Memcached
- SASL 기반 인증 지원

ElastiCache Redis OSS 7 Upgrade

ElastiCache 같은 Managed Service 는 EoL 이전에 버전 업그레이드를 하지 않으면 Premium 지원을 위한 추가 요금이 발생한다. 때문에 26년 1월에 표준 지원을 종료하는 Redis OSS v5 나 27년 1월에 표준 지원을 종료하는 Redis OSS v6 버전의 엔진을 사용하는 경우 미리 Redis OSS v7 으로 업그레이드해주는 것이 좋다.

공식문서에 따르면 기본적으로 ElastiCache Redis 업그레이드는 데이터 보존과 다운타임이 발생하지 않도록 설계되어있다. 하지만 혹시 모를 데이터 유실을 방지하기 위해 업그레이드가 진행되기 전에 백업 Snapshot 을 떠놓는 것이 Best Practice 다.

Upgrade

resource "aws_elasticache_replication_group" "example" {
  replication_group_id = "example"
  description          = "example description"
  node_type            = "cache.t2.micro"
  num_cache_clusters   = 2
  port                 = 6379
  subnet_group_name    = aws_elasticache_subnet_group.example.name
  security_group_ids   = [aws_security_group.example.id]
  parameter_group_name = "default.redis7"
  engine_version       = "7.1"

  transit_encryption_enabled = true
  auth_token                 = "abcdefgh1234567890"
  auth_token_update_strategy = "ROTATE"
}

ElastiCache 를 업그레이드하기 위해선 Engine Version 과 버전에 맞는 Param Group 을 준비해야 한다. Param Group 은 AWS 에서 기본으로 제공하는 default.redis7 default.redis7.cluster.on 등이 존재한다. .cluster.on 류는 ElastiCache Cluster Mode 를 활성화했을 때 사용할 수 있다.

Terraform Apply 이후 업그레이드가 바로 진행되지 않을 수 있는데, 이는 ElastiCache Maintenance Window 가 업그레이드 등 변경 가능 시간을 제약하기 때문이다. 해당 클러스터를 사용하는 클라이언트의 사용패턴에 따라 Maintenance Window 가 상이할 수 있다. Maintenance Window 가 시작되면 Redis 7 을 호스팅하는 새로운 노드들이 순차적으로 클러스터에 조인한다.

Verification

메트릭	설명	데이터 유실 여부 판단 포인트
`aws.elasticache.curr_items`	Redis 내 전체 키 개수	업그레이드 전후 값이 비슷하면 데이터 보존됨.
`aws.elasticache.evictions`	메모리 부족으로 강제 삭제된 키 수	업그레이드 직후 spike가 있으면 일부 데이터 날아갔을 가능성 있음.
`aws.elasticache.cache_hits` / `aws.elasticache.cache_misses`	캐시 조회 성공/실패 횟수	업그레이드 직후 `miss`가 급증하면 데이터 flush 의심 가능.
`aws.elasticache.bytes_used_for_cache`	캐시에 실제 저장된 데이터 크기(byte)	업그레이드 후 갑자기 줄면 캐시가 비워졌을 가능성 높음.
`aws.elasticache.new_connections`	새로 생성된 Redis 클라이언트 연결 수	업그레이드 후 spike 있으면 재연결 발생 가능 (정상적인 failover).
`aws.elasticache.replication_bytes`	복제본과의 동기화된 데이터 양	업그레이드 시 replication 이 재시작되면 증가 가능 (정상 범위).
Datadog Resources 를 활용하여 ElastiCache Redis 의 메트릭을 확인할 수 있다. 이를 통해 업그레이드 중 데이터 유실이 발생했는지 확인할 수 있다. Datadog 연동 시 위 메트릭 외에도 더 다양한 메트릭을 지원한다. 자세한 내용은 공식문서를 참조하자.

Maintenance Window 가 시작되면 Upgrade 가 진행되고 aws.elasticache.new_connections 과 aws.elasticache.replication_bytes 등에 Spike 가 감지된다. Redis7 을 호스팅하는 새로운 노드가 클러스터에 조인하고 기존 클라이언트들이 재연결하는 과정에서 관측되는 지표다.

ElastiCache Network Bandwitdh Throttling

ElastiCache Network Bandwidth

캐시 노드 유형	vCPU	메모리	Baseline	Burst	시간당 요금
`cache.r7g.large`	2	13.07 GiB	0.937 Gbps	12.5 Gbps	USD 0.2296
`cache.r7g.xlarge`	4	26.32 GiB	1.876 Gbps	12.5 Gbps	USD 0.4601
`cache.r7g.2xlarge`	8	52.82 GiB	3.75 Gbps	15 Gbps	USD 0.9193
`cache.r7g.4xlarge`	16	105.81 GiB	7.5 Gbps	15 Gbps	USD 1.8386
ElastiCache 의 네트워크 대역폭은 상시 보장되는 Baseline 대역폭과 크레딧을 소모하여 증폭할 수 있는 최대 Burst 대역폭으로 구성된다. Inbound, Outbound 크레딧 버킷은 분리돼 있고, Burst 는 공유 자원이다. Network I/O 크레딧은 노드 시작 시 최대치를 받고, Baseline 미만으로 쓰는 동안 적립된다. 트래픽이 Baseline 대역폭을 넘으면 크레딧을 소모해 최대 Burst 대역폭까지 증폭하고, 크레딧이 떨어지면 Baseline 으로 강제 복귀한다.

평소보다 많은 트래픽이 장기간 지속될 경우 CPU, 메모리에 여유가 있어도 크레딧이 소진되면 Baseline 대역폭으로 강제 제한(Throttling)이 걸리기 때문에 대역폭 한계로 인한 Redis 헬스체크, 커넥션, 커맨드 실패가 서비스 장애로 이어질 수 있다.

실제 장애 사례

평소 Outbound 는 0.49Gbps 로 cache.r7g.large 기준 Baseline 0.937 Gbps 미만으로 사용 → 크레딧 적립
피크 2.0Gbps, 평소 4배에 달하는 Baseline 초과 트래픽 발생 → Burst 크레딧으로 약 2시간 버팀
크레딧 소진, Baseline 으로 강제 제한 -> Baseline 초과분 패킷이 shaping(드롭, 지연) -> Redis 응답 지연, 유실
Redis 커맨드 타임아웃 → 커넥션 풀 고갈, 새 커넥션 실패 → 앱 Readiness Probe 실패
Readiness 실패 Pod 는 Service 엔드포인트에서 빠져 트래픽을 받지 못함

주요 메트릭

메트릭	설명	예시 값
`NetworkBaselineUsageInPercentage`	Baseline 대비 인바운드 사용률	쓰기, 복제가 많으면 상승
`NetworkBaselineUsageOutPercentage`	Baseline 대비 아웃바운드 사용률	평소 ~50%, 피크 200%+ (100% 초과 = 크레딧 소모 중)
`NetworkBaselineMaxUsageInPercentage` / `NetworkBaselineMaxUsageOutPercentage`	초당 최대 Burst 사용률	순간 마이크로버스트 감지용
Throttling 전에 미리 잡는 선행지표, 100% 초과면 Burst 크레딧을 소모하는 중이다.

메트릭	설명	예시 값
`NetworkBandwidthInAllowanceExceeded` / `NetworkBandwidthOutAllowanceExceeded`	대역폭 한계 초과로 shaping(드롭)된 패킷 수	평소 0 → 장애 시 분당 수천
`NetworkConntrackAllowanceExceeded`	추적 커넥션 수 한계 초과로 새 연결이 실패해 드롭된 패킷 수	커넥션 폭증 시 0 초과
`NetworkPacketsPerSecondAllowanceExceeded`	초당 패킷 수(PPS) 한계 초과	작은 요청 폭주 시 0 초과
Throttling 이 이미 발생 중임을 보여주는 지표. 평소 0 이고, 0 을 넘으면 패킷이 드롭되는 중이다.

CPU, 메모리 지표와 더불어 위 네트워크 지표까지 주의 깊게 보자. NetworkBaselineUsageOutPercentage 가 지속적으로 100% 에 근접하거나 초과하면, 곧 *AllowanceExceeded 가 0 → 양수로 튀며 Throttling 이 시작된다고 보면 된다.

예방법

더 많은 Baseline 을 보장하는 노드타입으로 스케일업
모니터링 설정으로 NetworkBaselineUsageOutPercentage 임계(예: 80%) 또는 *AllowanceExceeded 0 초과 시 알람
Redis 앞에 인메모리 캐시(e.g. Java Caffeine)를 둬서 캐시 계층화
protobuf, Snappy 등을 활용하여 페이로드 압축

meatsby.github.io

Explorer