ElastiCache Serverless 내 시스템에 어울릴까?

10 min readMay 14, 2024

ElastiCache Serverless란?

2023년 11월 27일 ElastiCache 서비스에 새로운 Serverless 옵션 정식 출시가 발표되었습니다. ElastiCache Serverless를 통해 1분 이내에 가용성과 확장성이 뛰어난 캐시를 생성할 수 있으며, 여러 가용 영역(AZ) 전체에서 데이터를 중복 저장하며 99.99% 가용성 서비스 수준 계약(SLA)을 제공합니다. ElastiCache Serverless는 Redis 버전 7.1과 Memcached 버전 1.6.22 이상을 지원하며, 모든 AWS 상용 리전에서 사용할 수 있습니다. 캐시 노드 유형, 샤드 수, 복제본 수 또는 AZ에서의 노드 배치 등 작업부하에 대한 캐시 용량 계획이나 전문 지식 없이도 사용할 수 있습니다. ElasticCache Serverless는 애플리케이션의 메모리, CPU, 네트워크 리소스 사용량을 지속적으로 모니터링하고, 작업 부하의 접근 패턴 변화에 대응하여 자동으로 확장합니다.

비용

vCPU 시간과 전송된 데이터를 모두 포함하는 단위인 ElastiCache Processing Units(ECPU)에 대해 비용을 지불하며, 읽기 및 쓰기에는 전송되는 데이터 킬로바이트(KB)당 1 ECPU가 필요합니다. 예를 들어 3.2KB의 데이터를 전송하는 GET 명령은 3.2 ECPU를 사용합니다.

저장된 데이터는 기가바이트-시간 단위로 요금이 청구되며, 최소 1GB 데이터가 측정 단위입니다.

저장된 데이터 : USD 0.151 / GB-hour
ElastiCache 처리 장치(ECPU) : USD 0.0042 / million ECPUs
1KB = 1ECPU 이므로 1백만(millon) ECPU 처리량은 1GB의 데이터를 의미 합니다., 즉 USD 0.0042 / GB 로 단순화가 가능합니다.
1개월(30일 기준) 최소 유지 비용은 USD 108(저장된 데이터) + ECPU 처리비용 입니다.
1개월동안 1TB를 읽고 썼다면, ECPU 처리비용 USD 4.2 입니다.
위 요금은 서울 리전 기준입니다.

ElastiCache Serverless는 30일 동안 100% 사용을 했을 때, 최소 $108 비용이 발생합니다. Ondemand cache.t4g.micro(2 vCPU/0.5GiB) 노드 1개를 30일 동안 사용했을 때 $34 발생하는 것과 비교하면 더 큰 비용이 발생을 합니다.

단순히 사용량이 적은 노드를 Serverless로 전환하여 비용을 절약하기에는 어려운 면이 있습니다.

사내에 ElastiCache 클러스터를 사용 중인 시스템을 기준으로 서버리스로 전환시 비용절감이 가능한지 계산해 봤습니다. 이 시스템은 cache.m6g.large 캐시 노드를 사용하고 있으며, 2개의 샤드로 구성되어 있고, 샤드당 2개의 노드로 구성되어 있습니다. 캐시노드 4개로 구성되어 있으므로, USD 95.13(m6g.large 한달요금) X 4개 = USD 384.52 의 한달 요금이 부과된다고 볼 수 있습니다. 메모리 용량은 6.38 GiB(1024바이트단위) 이며, GB(1000바이트 단위)로 환산하면 6.85 GB 입니다.

4/18일 기준 1달을 기준으로 Redis 지표를 조회하면 Sum 으로는 28,611%, Average 로는 3.31% 를 사용중입니다. 메모리에 저장되어있는 평균 데이터량은 6.85GB X 3.31% = 0.226735 GB가 평균 메모리 사용량 입니다.

네트워크 용량은 1달 기준 수신 네트워크바이트 2.69GB, 송신 네트워크바이트 1152.1GB로 총 1154.79GB의 네트워크를 사용했습니다. 위 사용량을 Serverless의 요금으로 환산해 보면 아래와 같습니다.

메모리 사용요금 : 1GB USD 108
네트워크 사용요금 : 0.0042 X 6GB = UDS 4.85
총 요금 : USD 112.85

종합하면, Serverless 로 대체 시 월 USD 384.52 에서 USD 112.85 로 약 71% 감소합니다. 규모가 있는 ElastiCache Redis 노드를 대체시 비용 절감 효과가 있음을 확인할 수 있었습니다. 성능에서도 안정적으로 대체가 될지 검토가 필요하여 성능테스트를 진행해 봤습니다.

성능 모니터링과 Pre-scaling

성능 모니터링을 위한 지표로는 메모리 사용량(BytesUsedForCache), CPU 사용량(ElastiCacheProcessingUnits), 캐시 지표(CacheMissRate, CacheHitRate, CacheHits, CacheMisses 및 ThrottledRequests)이 있으며 Amazon CloudWatch 에서 확인 할 수 있습니다. 각 Serverless 캐시에 대해 CPU, Memory, Network 등의 리소스 사용률을 지속적으로 추적해서, 이러한 리소스가 제한되면 새 샤드를 추가하거나 규모를 축소합니다.

스토리지와 초당 ECPU의 최대 사용량을 설정하여 캐시 비용을 제어할 수 있습니다.

예를 들어, 어떤 회사에서 새로운 서비스 출시 후 1분 이내 로그인이 5배 증가할 것으로 예상되는 경우, 사전크기조정(pre-scaling)을 통해 캐시에 대해 최소 지원용량 제한을 설정할 수 있습니다. Pre-scaling 은 콘솔, API, CLI를 통해 수행할 수 있으며, 설정된 용량은 1시간이내 사용할 수 있습니다.

ElastiCache Serverless는 빈 캐시에서 초당 30K ECPU를 지원하고, 복제본에서 읽기 기능을 사용할 경우 최대 90K 초당 ECPU를 지원합니다. ElastiCache는 10~12분마다 초당 ECPU를 두 배로 늘릴 수 있습니다. 만약 예정된 이벤트가 이 Scaling 속도를 초과할 것으로 예상되면 최소 ECPU/초를 최대 이벤트가 발생하기 최소 60분 전에 설정하는 것이 좋습니다.

실제 Pre-scaling을 최소 초당 ECPU를 5백만(5,000,000)으로 설정해서 진행해보니 Pre-scaling 되는데 20분~30분 정도의 시간이 소요되는 것을 확인할 수 있었습니다. Byte로 환산(ECPU=1KB)하면 최대 15GB/s 즉, 분당 900GB 의 데이터 처리가 가능한 것으로 볼 수 있습니다.

성능 테스트 환경 구성

목표 부하는 초당 2MB/s, 분당 120MB 를 목표로 삼았으며, ElastiCache Serverless의 ECPU로 환산하면 2M ECPU(초당), 120MB ECPU(분당)의 Spike 트래픽을 감당할 수 있는지를 검증하려고 합니다.

ElastiCache Serverless는 빈 캐시에서 최대성능은 단일노드로 구성되어 있다면, 30K/s(ECPU) X 60초 = 분당 1.8M(ECPU)를 최대 지원하며, Read Replica가 구성되어 ReadOnly connection으로 읽기요청을 처리한다면, 90K/s(ECPU) X 60초 = 분당 5.4M(ECPU)를 최대 지원합니다.

Spike 형태의 트래픽이라면 목표 부하는 감당하지 못하고 Error가 발생할 수 있을 것으로 예상되며, 점진적인 부하 증가라면 10분 내외로 scale out 되어 목표 부하를 감당할 것으로 예상 됩니다.

Redis에 Set하는 오브젝트의 크기는 224B이며 3,000건의 데이터를 1~3,000까지의 Key를 부여한 데이터를 사전에 준비하였습니다. Set / Get 을 호출하게 은 2:8의 비율로 구성하였고, Get은 랜덤하게 1~3,000 번의 오브젝트를 요청하고, Set은 Get한 응답을 다시 Set하도록 구성하였습니다. 실제 테스트 결과 요청당 평균 송수신 Bytes 는 236.3B 였습니다. 즉, 목표 부하는 초당 2MB/s 에 부합하는 8,465 RPS(Request Per Second) 입니다.

목표 부하 테스트

23분간 573만건의 부하를 주었으며, 2건(502 Bad Gateway)의 에러 외에는 모두 성공 되었으며, 30분에서 31분 사이 응답지연이 발생하다가 안정적인 응답속도를 다시 회복하고 있습니다. 30초마다 100개의 쓰레드가 추가되어 20분 뒤에 총 4000개의 쓰레드에서 Request를 발생하도록 하였습니다. 이때 ElastiCache Serverless는 Scale Out 되지 않은 기본 캐시 상태입니다.

1분당 108MB에 가까운 부하를 지속적으로 받으면 ElastiCache Serverless 가 Scale out 을 통해 응답속도가 안정적으로 변하는지 관찰하였습니다.

쓰기 요청 지연이 초기에 증가하다가 8:30에 감소하는 것을 확인했습니다. 해당 시점에 Scale out이 발생한 것으로 추측이 됩니다.

1차 Spike 테스트(Scale out 상태)

목표 부하 테스트 이후 Scale out 된 상태에서 Spike 테스트를 진행했습니다. 총 144만 건의 부하를 주었고, 1분 만에 Peak를 찍고 1분 뒤 종료 되도록 총 2분의 부하를 주었습니다. 실패 건은 발생하지 않았습니다.

2차 Spike 테스트(Scale in 상태)

새로 생성된 초기 상태의 ElastiCache Serverless를 대상으로 진행했습니다. 1차와 동일한 테스트 시나리오를 사용하였으며 총 105만건의 부하를 주었고, 1분 만에 Peak를 찍고 1분 뒤 종료 되도록 총 2분의 부하를 주었습니다. 1건(502 Bad Gateway)의 에러 외에는 모두 성공 하였습니다.

테스트 결과 요약

Spike 형태의 트래픽은 1분당 최소 108MB 의 데이터 처리량을 기대해 볼 수 있으며, 부하가 점진적으로 증가하면 Auto Scaling도 부드럽게 10분마다 2배의 scale out 을 기대할 수 있습니다.

Serverless는 Scale out이 되면 처리 용량이 2배가 됩니다. Scale out에 소모되는 시간이 AWS에서는 10분~12분 소요되는 것으로 설명하고 있지만, 실제 테스트에서는 7분 후 Scale out 되는 것을 확인할 수 있었습니다. 그러므로 몇 분 내에 분당 108MB 를 초과하는 Spike 형태의 트래픽이 발생하는 경우라면 처리가 어려울 수 있습니다.

또한 Scale out이 네트워크 대역폭의 증설이 되는 것은 아니므로 대용량의 트래픽이 발생하는 경우에는 네트워크 에러가 발생할 수 있습니다.

예측된 이벤트라면 Pre-scaling을 통해 데이터 처리가 가능한 규모까지 대응이 가능합니다. Pre-scaling은 AWS 60분 이내에 처리되고, 완료되면 이벤트 알림을 받을 수 있습니다.

ElastiCache Serverless 는 Provisioning 된 자원 만큼 비용을 지불하는 것이 아니라 사용된 자원 만큼 비용을 지불하기 때문에, 비용 측면의 이점이 있습니다. 다만 사용량이 적은 캐시 노드의 Serverless 전환을 목표로 한다면 비용이 오히려 증가할 수 있습니다.