Amazon ElastiCache Serverless란?
Amazon ElastiCache 서비스의 새로운 Serverless 옵션은 2023년 11월 27일에 정식 출시됐습니다. ElastiCache Serverless는 1분 이내에 가용성과 확장성이 뛰어난 캐시를 생성할 수 있고, 여러 가용 영역(Availability Zone, AZ, 각 리전 내에 격리된 위치로 개별 데이터센터로 구성, 이하 AZ) 전체에서 데이터를 중복 저장하며 99.99%의 가용성 서비스 수준 계약(Service Level Agreement, SLA, 여러 고객에게 제공되는 동일한 서비스를 자세히 설명하는 계약)을 제공합니다. ElastiCache Serverless는 Redis(Remote DIctionary Server, 빠른 오픈 소스인 메모리 키 값 데이터 구조 스토어) 버전 7.1과 Memcached 버전 1.6.22 이상을 지원하며, 모든 AWS 상용 리전(Region, AWS 서비스가 제공되는 서버의 물리적인 국가/도시 단위의 위치)에서 사용할 수 있습니다. 또한 캐시 노드(루트와 서브트리로 구성된 데이터 상하위 계층을 나타내는 위치의 항목) 유형, 샤드(shard, 데이터베이스를 물리적으로 분할했을 때, 분할된 파티셔닝을 가르키는 말) 수, 복제본 수 또는 AZ에서의 노드 배치 등 작업부하(Word load, 작업수행에 따라 작업자에게 요구되는 육체적, 정신적 기능 정도)에 대한 캐시 용량 계획이나 전문 지식이 없어도 사용할 수 있습니다. ElastiCache Serverless는 애플리케이션의 메모리, CPU, 네트위크 리소스 사용량을 지속적으로 모니터링하고 작업부하의 접근 패턴 변화에 대응해 자동으로 확장합니다.
ElastiCache Serverless 비용
ElastiCache Serverless의 비용 단위는 vCPU(Virtual CPU, 클라우드 환경에서 가상의 CPU 리소스) 시간과 전송된 데이터를 모두 포함하는 단위인 ElastiCache Processing Units(ECPU)에 대해 비용을 지불하며, 읽기 및 쓰기에는 전송되는 데이터 킬로바이트(KB)당 1ECPU가 필요합니다. 예를 들어, 3.2KB의 데이터를 전송하는 GET 명령은 3.2 ECPU를 사용하는데요. 저장된 데이터는 기가바이트(GB)–시간 단위로 요금이 청구되며, 측정 단위는 최소 1GB 데이터입니다.
서울 리전 기준 요금으로 예시를 들어보겠습니다.
1. 저장된 데이터 : 0.151 USD / GB-hour
2. ElastiCache 처리 장치(ECPU) : 0.0042 USD / million ECPUs
• 1KB는 1ECPU 이므로 1백만(million) ECPU 처리량은 1GB의 데이터를 의미합니다. 즉, 0.0042 USD /GB로 단순화할 수 있습니다.
3. 1개월(30일 기준) 최소 유지 비용은 108 USD(저장된 데이터)와 ECPU 처리비용의 합입니다.
4. 1개월동안 ITB를 읽고 썼다면, ECPU 처리비용은 4.2 USD입니다.
ElastiCache Serverless를 30일 동안 100% 사용하면, 최소 108 USD의 비용이 발생합니다. Ondemand cache.t4g.micro(2 vCPU/0.5GiB) 노드 1개를 30일 동안 사용했을 때 34 USD가 발생하는 것과 비교하면 더 큰 비용이 발생하는 것입니다. 이처럼 단순히 사용량이 적은 노드를 Serverless로 전환해 비용을 절약하기에는 어려운 면이 있습니다.
자사에서 ElastiCache 클러스터를 사용하는 시스템을 기준으로 Serverless로 전환 시 비용절감이 가능한지 계산해 봤습니다. 이 시스템은 cache.m6g.large 캐시 노드를 사용하고 있고 2개의 샤드로 구성돼 있습니다. 이 샤드는 개당 2개의 노드로 구성돼 있는데요. 캐시노드 4개로 구성돼 있으므로, 95.13 USD (m6g.large 한 달 요금) X 4개를 계산하면, 384.52 USD의 한 달 요금이 부과된다고 볼 수 있습니다. 메모리 용량은 6.38 GiB(1,024바이트 단위) 이며, GB(1,000바이트 단위)로 환산하면 6.85GB가 나오는 것을 알 수 있습니다.
본 글을 작성한 4월 18일을 기준으로, 한 달 동안의 Redis 지표를 조회했을 때 Sum은 28,611%, Average는 3.31%를 사용하는 걸 확인할 수 있었습니다. 메모리에 저장된 평균 데이터량은 6.58GB X 3.31%였는데요. 즉, 0.226735GB가 평균 메모리 사용량입니다.
네트워크 용량은 한 달 기준 수신 네트워크바이트 2.69GB, 송신 네트워크바이트 1152.1GB로 총 1154.79GB의 네트워크를 사용했습니다. 위 사용량을 Serverless 요금으로 환산하면 아래와 같습니다.
• 메모리 사용 요금 : 1GB, 108 USD
• 네트워크 사용 요금 : 0.0042 X 6GB, 총 4.85 USD
• 총 요금(메모리 사용 요금+네트워크 사용 요금) : 112.85 USD
종합하면, 사용량이 적은 노드를 Serverless로 대체하면, 월 384.52 USD에서 112.85 USD로 비용이 약 71% 감소하는데요. 규모가 있는 ElastiCache Redis 노드를 대체할 때, 비용 절감 효과가 있는 것을 확인할 수 있습니다. 성능에서도 안정적으로 대체할 수 있을지 확인하기 위해 진행한 성능테스트 결과는 아래와 같습니다.
성능 모니터링과 Pre-Scaling
성능 모니터링을 위한 지표로는 메모리 사용량(BytesUsedForCache, 데이터 세트, 버퍼 등에 대해 Redis에서 할당한 총 바이트 수)과 CPU 사용량(ECPU), 그리고 캐시 지표(CacheMissRate, CacheHitRate, CacheHits, CacheMisses, ThrottledRequests)가 있으며 이는 Amazon CloudWatch에서 확인할 수 있습니다. 각 Serverless 캐시의 CPU, Memory, Network 등 리소스 사용률을 지속적으로 모니터링하고, 리소스가 제한되면 새 샤드를 추가하거나 규모를 축소합니다. 또한 스토리지와 초당 ECPU의 최대 사용량을 설정해 캐시 비용을 제어할 수 있는데요. 예를 들어, A회사에서 새로운 서비스 출시 후 로그인이 5배 증가할 것으로 예상된다면, 사전크기조정(Pre-Scaling)을 통해 캐시에 대해 최소 지원용량 제한을 설정할 수 있습니다. Pre-Scaling은 콘솔, API(Application Programming Interface, 애플리케이션들이 서로 정보를 주고받을 때 사용하는 언어나 메시지 형식), CLI(Command-Line Interface, 명령줄 인터페이스, 글자를 입력해 컴퓨터에 명령을 내리는 방식)를 통해 수행할 수 있습니다. 이때 설정된 용량은 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분 정도의 시간이 소요되는 것을 확인할 수 있었습니다. ECPU는 1KB로, 바이트(Byte)로 환산하면 최대 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)를 지원합니다.
테스트 예상 결과는 두 가지였습니다.
1) Spike 형태의 트래픽이 발생해 목표 부하가 이를 감당하지 못하고 Error 발생
2) 점진적인 부하가 발생, 10분 내외로 Scale Out 돼 목표 부하를 감당.
Redis에 Set 하는 오브젝트의 크기는 224MB로 1~3,000까지의 Key를 부여한 3,000건의 데이터를 사전에 준비했습니다. Set/Get은 호출하기 위해 2:8 비율로 구성했는데요. 이때 Get은 랜덤하게 1~3,000번의 오브젝트를 요청하고 Set은 Get한 응답을 다시 Set하도록 구성했습니다. 실제 테스트를 진행한 결과 요청당 평균 송수신 바이트는 236.3B였습니다. 즉, 목표 부하가 초당 2MB/s에 부합하는 8,465 RPS(Request Per Second)였습니다.
목표 부하 테스트
목표 부하 테스트 진행 시 23분간 573만 건의 부하를 주었습니다. 그중 2건(502 Bad Gateway)의 에러 외에는 모두 성공했으며, 30분에서 31분 사이에 응답지연이 발생하다가 안정적인 응답속도를 다시 회복했습니다. 30초마다 100개의 스레드가 추가돼 20분 뒤에 총 4,000개의 스레드에서 Request를 발생하도록 했습니다. 이때 ElastiCache Serverless는 Scale Out되지 않은 기본 캐시 상태였습니다. 1분당 108MB에 가까운 부하를 지속적으로 받으면 ElastiCache Serverless가 Scale Out을 통해 응답속도가 안정적으로 변하는지 관찰했는데요. [그림 1]과[그림 2]와 같이 쓰기 요청 지연이 초기에 증가하다가 8:30에 감소하는 것을 확인할 수 있었습니다. 해당 시점에 Scale Out이 발생한 것으로 추측됩니다.
1차 Spike 테스트(Scale Out 상태)
[그림 3]은 목표 부하 테스트 이후 Scale Out된 상태에서 Spike 테스트를 진행한 이미지입니다. 총 144만 건의 부하를 주었고, 1분 만에 Peak를 찍고 1분 뒤 종료되도록 총 2분의 부하를 주었습니다. 테스트 결과, 실패 건은 발생하지 않았습니다.
2차 Spike 테스트(Scale in 상태)
[그림 4]는 새로 생성된 초기 상태의 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배 늘어납니다. AWS에선 Scale Out에 소모되는 시간이 10~12분이라고 설명하고 있지만, 실제 테스트에서는 7분 후에 Scale Out되는 것을 확인할 수 있었습니다. 그러므로 몇 분 내에 분당 108MB를 초과하는 Spike 형태의 트래픽이 발생한 경우라면 처리가 어려울 수 있습니다. 다만, 예측된 이벤트라면 Pre-Scaling을 통해 데이터 처리가 가능한 규모까지 대응이 가능합니다. AWS 문서상 Pre-Scaling은 60분 이내에 처리된다고 설명하고 있고 완료되면 이벤트 알림을 받을 수 있습니다. ElastiCache Serverless는 Provisioning된 자원만큼 비용을 지불하는 것이 아니라 사용된 자원만큼 비용을 지불하기 때문에, 비용 측면의 이점이 있습니다. 다만 사용량이 적은 캐시 노드의 Serverless 전환을 목표로 한다면 비용이 오히려 증가할 수 있으니 주의해야 합니다.
글 ㅣ LG CNS 마이크로서비스개발팀 이동해 책임
글 ㅣ LG CNS 대한항공 AM 팀 유치송 총괄
