대기열 서비스 10만명 부하테스트 여정기(feat. AWS Support)

대기열 서비스 부하테스트를 시작하며

원더월 블로그 초창기에 대기열 서비스에 대한 글을 작성한 적이 있었습니다.

이번 포스트에서는 해당 대기열 서비스에 대한 부하테스트를 진행하며 겪었던 내용들을 간단하게 설명하고자 합니다.

대기열 서비스 구조에 대해 설명한 VWR(대기열 서비스)를 먼저 보고 오시는 것을 추천드립니다.

인프라 구조 변경

위 포스트를 보고 오신 분들은 아시겠지만, 기존의 대기열 서비스는 Api Gateway + Lambda의 구조로 이루어져 있습니다.

이 서비스는 지금까지 많은 아티스트들의 상품 판매와 이벤트에 사용되었고 22년도의 하우스 오브 원더 콘서트 티켓 판매 당시에는 수천명의 접속자를 안정적으로 처리했습니다. 하지만 회사가 성장함에 따라 대형 아티스트들이 입점하기 시작했고, 트래픽이 빠르게 늘어나면서 약 2년전에 만들었던 인프라로는 더 많은 접속자를 감당하기 어려워졌습니다.

그래서 백엔드 팀에서는 최대 동접자 10만명을 목표로 잡고 부하테스트를 진행하며 인프라 및 코드 개선을 하기로 하였습니다.

가장 먼저 개선이 필요했던 것은 Api Gateway였습니다. Api Gateway가 기본적으로 가지고 있는 Request Per Second(RPS) limit은 1만회이며 burst 할당량에 따라 더 늘어날 수 있습니다.(burst 할당량은 region별로 차이가 있습니다.)

이는 저희의 목표인 10만에 비하면 많이 부족한 수치입니다. 또한 region별로 limit이 있기 때문에 만약 같은 region에 Api Gateway가 여러개면 limit도 같이 공유하기 때문에 서로 영향을 줄 수 있고, RPS limit을 늘릴 수는 있지만 대신 Api Gateway Timeout을 줄여야 한다는 문제점이 있습니다.

그래서 Application Load Balancer(ALB)로 변경하게 되었는데 ALB는 RPS limit이 없기 때문에 한번에 접속자가 몰려 10만회의 부하가 들어와도 견딜 것이라 예상했습니다.

API는 Lambda로 배포되어 있었습니다. Lambda는 몇가지 단점이 있었는데 첫번째는 cold start입니다. 부하가 한번에 몰리는 경우 가장 큰 병목이 됩니다.

두번째로는 Lambda의 재사용에 대한 문제입니다. 동일한 부하를 주고 여러번 테스트를 진행해보았을 때, latency가 일정하지 않다는 것을 확인할 수 있었습니다. Lambda 함수가 완료된다고 해서 바로 종료되는 게 아니라 다음 함수의 호출을 예상하여 일정 시간동안 실행 환경을 유지하게 되는데요, 이 대기하는 시간이 랜덤이기 때문입니다. 예를들어 5만회의 API 콜 테스트를 일정 시간을 두고 2번 진행한다고 가정해보겠습니다. 첫번째 테스트에서는 5만개의 람다가 전부 cold start로 인한 지연이 있을 것이라고 예상할 수 있습니다. 하지만 두번째 실행한 시점에서는 이전에 실행된 5만개의 Lambda중에서 몇개가 재실행될수 있는 상태인지, 몇개가 종료되서 cold start가 되는건지의 여부는 매번 다르기 때문에 알 수가 없습니다. 게다가 사용자는 이 대기 시간을 설정할 수 없고 AWS의 내부 설정에 의해 이루어지게 됩니다.

그래서 동일 부하를 주며 진행한 테스트에서도 균등한 latency를 얻어내기 어려웠고 부하가 많아질수록 latency의 편차도 커졌습니다. 그래서 이 API들은 ECS(Fargate) 로 이전하기로 결정했습니다.

결론은 ALB + ECS 로 인프라를 이전하게 되었습니다.

테스트 방식과 시나리오

테스트는 Locust 툴을 사용하여 진행했습니다. 팀 내에서 주로 사용되어 많은 지식이 쌓인 상태이기도 했었고 이전에 사용해보았던 artillery에 비해서 시나리오 작성이 매우 수월했습니다. 파이썬으로 작성을 해야해서 약간의 언어 공부가 필요하긴 하지만 시나리오 작성만 하는 것이라면 전혀 문제가 되지 않습니다. Locust를 ECS(Fargate) 환경에 배포하여 테스트를 진행하였는데, 아래는 테스트 시나리오의 일부입니다.

• task1: 대기열에 본인의 정보를 넣어줍니다.
• task2: 내가 대기열에서 계속 대기해야 하는지, 아니면 통과할수 있는지 여부를 알려주는 API를 1초에 1번씩 호출합니다. task1의 결과를 task2에서 사용해야 하기 때문에 SequentialTaskSet를 적용하여 순차 실행을 보장해줍니다.

이 경우 10만명이 동시에 들어온다고 가정하면 Max RPS는 10만회가 됩니다.

class QuickstartUser(SequentialTaskSet):
    message_id = None

    @task()
    def _vwr(self):
        response = self.client.post("/test/example-send", json={"message": "Hello, World!"})
        print(response)
        self.message_id = response['MessageId']

    @task()
    def _polling(self):
        while True:
            self.client.post("/test/example-polling", json={"messageId": "Hello, World!"})
            time.sleep(1)

class AppUser(FastHttpUser):
    tasks = [QuickstartUser]

테스트 방식으로는 첫번째로 최대한 실제 상황과 비슷하게 하려고 한번에 5만, 10만의 부하를 한번에 주는 방식을 선택했었는데 특정 수치 이상으로 부하를 주면 Locust의 부하분산기에서 그 부하를 발생시키는 과정에서부터 latency가 발생하는 문제가 있었습니다. 이렇게 되면 실제로 대기열 서비스가 느린 것이 아닌데도, 초반 부하분산기에 의한 latency 때문에 p99지표가 매우 느린 것처럼 나옵니다.

수초 뒤, 초반에 발생했던 latency가 서서히 줄어듦에 따라(부하분산기의 활성화) p95, medium과 같은 지표는 안정적으로 나오게 되어 테스트 데이터를 집계하는 데에 있어서는 큰 문제가 되지 않았지만 서비스의 문제가 아닌 테스트 툴의 이슈로 이런 결과가 나온다는게 조금 아쉬웠습니다. Locust의 초반 latency에 관한 이슈는 아래 링크에서 확인할 수 있습니다.

• Locust response time high latencies at the start
• Locust response time for the first request

그래서 한가지의 방법을 더 사용해서 테스트하였습니다. 아래는 Locust에서 지원하는 지표입니다.

유저를 서서히 올려 peak까지 도달시키고 그것을 계속 유지하는 테스트를 진행하였습니다. 여기서 중점적으로 볼 것은 Total Request Per Second와 Response Time 2가지인데 이것이 계속 안정적으로 유지되는지 확인해야 합니다. 사진을 보면 유저가 급증할때 Response Time이 살짝 불안정하지만 (그래도 200ms 이하라 괜찮습니다), peak까지 올라간 이후에는 안정적인 모습을 보여줍니다.

순간적으로 들어오는 부하를 받아낸다고 하더라도 이것을 유지하다가 갑자기 cpu가 튄다거나, 어딘가에서 병목이 생겨 latency가 튀는 경우도 발생하기 때문에 부하를 유지하는 것 또한 대기열 서비스에서는 중요한 부분입니다.

이렇게 두가지 테스트를 진행하며 테스트의 신뢰도를 높였습니다.

ECS 지표는 어떤 것을 봐야 할까?

가장 중요한 부분입니다. 스펙을 산정하는 기준이 되는 것이 지표인데 어떤 지표들을 주로 보았는지 그리고 스펙 산정의 과정에 대해서 설명드리겠습니다.

아래 사진은 부하테스트를 위해 제가 임시로 만든 Cloudwatch Dashboard 중 일부입니다.

ECS의 경우는 cpu, memory의 max값을 위주로 보았습니다. memory의 경우 크게 튀는 부분은 없었고, cpu의 경우는 60%를 임계치로 두고 스펙을 조정했습니다. 임계치의 경우는 서비스의 목적과 client의 민감도에 따라 달라지기 때문에 명확한 정의를 내리기 어려워 내부적으로 판단하여 정하는 것이 좋습니다.

Network Bandwidth(대역폭)도 중요한 지표 중에 하나인데 대기열 서비스는 굉장히 작은 패킷을 송수신하기 떄문에 해당 지표에 거의 영향을 미치지 않았습니다. 참고로 AWS에서는 공식적으로 ECS의 스펙에 따른 대역폭을 공개하고 있지 않습니다. 그래서 몇몇 분들이 직접 대역폭에 대한 테스트를 진행하고 공유해 주신 게시물 보고 판단할 수 있었는데, 저는 딜리셔스 기술블로그 - ECS Fargate 성능 측정하기를 참고했습니다.

ElastiCache는 워낙 많은 양의 부하를 견딜 수 있다고 알려져 있어서, ECS에서 병목이 안 생기도록 신경을 좀 더 썼었습니다. Locust로 RPS를 계속 확인하면서 RPS가 많이 밀린다 싶으면 task의 개수를 늘리는 스케일 아웃 방식을 사용했습니다.

ElastiCache(Redis) 지표는 어떤 것을 봐야 할까?

ElastiCache의 경우 대기열 서비스에서 메인 저장소로 사용되는 리소스입니다. 많은 지표들을 모니터링하였는데 그 과정에서 AWS Support의 도움을 많이 받았습니다.

대표적인 지표 2가지는 CPUUtilization, EngineCPUUtilization 입니다. 각 지표의 정의를 먼저 말씀드리자면 EngineCPUUtilization는 Redis 메인 thread의 CPU 사용률, CPUUtilization는 전체 호스트(Redis가 포함된 가상컴퓨터 전체)에 대한 CPU 사용률을 의미합니다. AWS 공식문서에 따르면 vCpu가 4개 이상인 경우 EngineCPUUtilization를 모니터링 하는 것을 추천하고 있습니다.

그 이유는 Redis의 서브 thread가 cpu에 영향을 미치기 때문입니다. 서브 thread는 비동기 작업에 사용되거나 백업시에 사용됩니다. vCpu가 4개 이상이라면 일반적으로 메인 thread가 사용하는 vCpu 이외에 3개의 vCpu가 있음을 의미합니다. 이렇게 여유 vCpu가 있는 경우 메인 thread가 성능이 부족한 상황(EngineCPUUtilization이 높으나 CPUUtilization은 낮음)이 일반적이기에 EngineCPUUtilization을 기준으로 모니터링할 것을 권장하고 있습니다. EngineCPUUtilization은 메인 thread의 부하가 발생하는 상황에 높아지며 CPUUtilization은 OS 레벨에서 전체 vCpu의 부하가 높아지는 상황에 높아지게 됩니다

그렇다면 vCpu가 4개 미만인 경우는 왜 CPUUtilization를 모니터링 하는것이 좋을까요? 위에서 언급한 서브 thread 동작에 의해 메인 thread가 사용하고 있는 vCpu의 cpu 시간을 소비하여 EngineCPUUtilization의 영향이 있을 수 있기 때문입니다. 그래서 EngineCPUUtilization만 봐서는 정확히 어떤 것이 지표에 영향을 미치는지 판단할 수 없게 됩니다.

각 지표에 영향을 미치는 작업은 아래와 같은데 이 링크를 참고했습니다. ElastiCache for Redis 클러스터에서 CPU 사용량이 많거나 증가하는 이유는 무엇입니까?

• EngineCPUUtilization (메인 thread의 부하가 발생하는 상황): 시간 복잡도가 높은 명령 (keys, hkeys, hgetall, sort 등)을 수행하는 경우, 부하가 많이 발생하는 경우, new connections이 많이 발생하는 경우
• CPUUtilization (OS 레벨에서 전체 vCpu의 부하가 높아지는 상황): 네트워크 트래픽 혹은 커넥션이 많은 경우

저는 2vCpu를 가진 m6g.large 스펙으로 테스트를 진행하였는데 위 내용을 토대로 보면 CPUUtilization를 중점적으로 모니터링 하는 것은 맞으나 부하가 많이 발생할수록 EngineCPUUtilization에 영향을 미치기 때문에 둘 다 확인해야 한다는 것을 알 수 있었습니다.

그렇다면 부하가 많아졌을 때, Redis의 스펙은 어떤 지표를 기준으로 보고 정해야 하고 어떤 방식(스케일 업/아웃)을 사용해서 스펙을 조절해야 할까요? 스케일 업/아웃의 기준은 아래와 같습니다.

• 스케일 업
  • 데이터 용량(memory가 부족한 경우)
  • 네트워크 대역폭이 부족한 경우
• 스케일 아웃
  • EngineCPUUtilization과 같은 명령어 처리에 대한 리소스가 부족한 경우

대기열 서비스의 경우 memory나 네트워크 대역폭이 모자라지는 않았습니다. 네트워크 대역폭의 경우 NetworkByteIn/NetworkByteOut 지표의 합계를 모니터링하였습니다. Redis는 burst 대역폭이 존재하는 인스턴스가 있기 떄문에 burst를 사용중인지도 확인을 꼭 해봐야 합니다. 이는 Network I/O Allowance Exceeded 지표로 확인할 수 있는데, 이 지표가 0 초과인 경우 burst를 사용했다는 의미입니다.

저는 부하가 많아질수록 EngineCPUUtilization의 지표가 계속 상승하는 것을 확인하였기 때문에 위에 언급한 기준에 따라 replica node를 추가하여 부하를 분산시키는 스케일 아웃 방식을 선택하였고 replica를 추가할수록 각 node의 EngineCPUUtilization의 지표가 떨어지는 것을 확인할 수 있었습니다.

EngineCPUUtilization 지표를 보고 Redis 성능 개선을 위해 스케일 업을 해야하는게 아닌가 하고 생각할 수 있는데 redis는 싱글 스레드로 동작합니다. ElastiCache 스케일 업을 하면 vCPU 갯수, 메모리, 네트워크 성능이 증가하지만 단일 vCPU의 성능은 바뀌지 않습니다. 그렇기 때문에 EngineCPUUtilization 지표의 개선을 기대하기는 어렵습니다. 실제로 동일 부하를 유지하고 스펙업을 몇번 진행해 본 적이 있었는데 EngineCPUUtilization의 지표의 개선이 없는 것을 확인할 수 있었습니다. (대신 OS 레벨에서의 cpu상태를 나타내는 CPUUtilization 지표는 vCpu가 많아질수록 반비례하여 줄어드는 것을 확인했습니다. ElastiCache의 스펙은 이곳에서 확인해볼 수 있습니다.

위에서 언급한 지표 외에도 SetTypeCmds, SetTypeCmdsLatency, Evictions, GetTypeCmdsLatency 등의 다양한 지표를 모니터링하였습니다. 이곳에서 전부 설명하기엔 양이 너무 많아서 Redis 지표를 참고하시면 좋을 것 같습니다.

마치며

위에서 설명한 방식대로 부하테스트를 진행하였고 목표였던 10만명까지 무리없이 받아낼 수 있는 스펙을 정할 수 있었습니다.

부하테스트를 진행하시는 분들이 이 글을 보고 많은 도움을 받았으면 좋겠습니다.

더 궁금하신 게 있으신 분은 저희팀 선형님께서 작성하신 [AWS 기술 블로그] Wonderwall 은 부하 테스트를 어떻게 진행했을까?도 같이 읽어보시면 좋을 것 같습니다.

백엔드 팀에서는 저희와 함께 서비스의 품질을 높이기 위해 고민하고 함께 성장해나갈 개발자를 찾고 있습니다. 관심 있으신 분들은 바로 밑에 있는 채용페이지를 통해 언제든지 지원 부탁드립니다.

감사합니다.