Wonderwall 은 부하 테스트를 어떻게 진행했을까?

엔터테크 기업 (주)노머스는 종합 아티스트 IP 서비스 ‘원더월’을 선두로, “예술이 세상을 바꾼다(Art Changes Life)”라는 슬로건을 바탕으로 아티스트 IP 기반의 콘텐츠, 커머스, 공연, 팬덤 플랫폼 등을 포함한 다양한 서비스를 통해 견고한 밸류 체인을 구축하고 있습니다. 아티스트들은 그들의 철학과 작업 노하우를 담은 ‘원더월 클래스’, 아티스트의 차별화된 MD를 기획하는 ‘원더월 아트랩’, 국내외 최정상 아티스트들의 놀라운 무대를 선보이는 ‘원더월 스테이지’, 그리고 팬덤과의 소통을 가능하게 하는 ‘프롬(fromm)’ 등을 통해 전 세계의 유저들과 만나고 있습니다.

빠른 성장을 지향하는 스타트업에서는 성능 테스트를 실시간으로 진행하며 개발하는 것이 마냥 쉬운 일이 아닙니다. 특히, 제한된 자원을 가진 스타트업에게 모든 가능성에 대응할 수 있는 아키텍처를 구축하는 것은 어려울 뿐만 아니라, 그러한 준비가 항상 필요한 것도 아닙니다.

프롬 서비스 역시 이러한 고민을 안고 있었습니다. 아티스트가 메시지를 발송하면 수많은 팬들이 일시에 앱에 접속하면서 발생하는 대규모 트래픽에 대응해야 했습니다. 최근에는 트래픽이 급격히 증가함에 따라 기존의 하드웨어 스펙 조정만으로는 한계에 부딪히고, 비용 또한 급등하는 상황에 이르렀습니다. 이에 저희는 대규모 팬덤을 보유한 아티스트와 팬들이 서비스를 원활히 이용할 수 있도록 부하 테스트를 실시하기로 결정했습니다.

이 게시글은 부하 테스트에 익숙하지 않은 스타트업 엔지니어들이 전반적인 이해를 높일 수 있도록 돕기 위해 작성되었습니다. 우선, 부하 테스트를 진행하는 과정을 설명하고, 그 과정에서 중요하거나 간과하기 쉬운 사항들을 정리했습니다. 또한, 테스트를 보다 효과적으로 진행할 수 있는 유용한 팁들을 공유하겠습니다.

부하 테스트 수행

부하 테스트는 애플리케이션 또는 시스템이 실제 운영 환경에서 예상되는 부하, 즉 사용자 요청의 양이나 데이터 처리량 등을 처리할 수 있는지 평가하기 위한 과정입니다. 이 테스트는 시스템의 성능 한계를 결정하고, 다양한 부하 수준에서의 응답 시간과 자원 사용량을 측정함으로써, 시스템이 사용자의 요구 사항을 충족시킬 수 있는지 확인하는 데 목적이 있습니다. 부하 테스트를 통해 애플리케이션의 탄력성, 안정성 및 확장성을 검증할 수 있습니다.

부하 테스트 진행 절차 소개

Wonderwall 팀은 부하 테스트 과정을 다음과 같이 정리했습니다.

• 1단계: 테스트 도구 선택
• 2단계: 테스트 시나리오 정의
• 3단계: 테스트 목표 성능 및 오류에 대한 임계값 정의
• 4단계: 인프라 준비
• 5단계: 테스트 준비
• 6단계: 단계별/탄력성 테스트
• 7단계: 성능 평가 및 결과 적용

1 단계: 테스트 도구 선택

다음은 Wonderwall 팀에서 고려한 테스트 도구입니다.

• Locust: Python으로 작성되어 있으며, 사용이 간편하고, AWS에서도 권장하는 넓은 사용자 풀을 가지고 있습니다. Amazon ECS Fargate Spot을 이용한 저렴한 분산 부하 테스트가 가능하며, Web UI를 통해 트래픽 변화를 쉽게 모니터링할 수 있습니다. 결론적으로 Wonderwall 팀에서 가장 추천하는 도구입니다. 또한, 부하 테스트 관련 요청을 했을 때 담당 AWS Solutions Architect 분도 추천할 정도로 사용자 풀이 넓고 생태계 발전이 잘 되어 있습니다.
• k6: JavaScript로 시나리오를 작성할 수 있으며, Grafana에서 제공하는 k6 Cloud를 통해 비용을 지불하고 테스트할 수 있습니다. 다만 k6 Cloud 한정으로 대량 부하 발생 시 k6 Cloud에서 단일머신을 활용하기 때문에 부하발생기의 성능이 따라오지 못하는 이슈가 있을 수 있습니다.
• Artillery: Yaml과 JavaScript로 시나리오를 작성할 수 있으며, AWS Lambda와 Fargate를 활용한 분산 부하 테스트에 적합합니다. 그러나 자체 테스트 결과 잦은 오류가 발생해서 완전히 성숙한 단계에 이르지는 못했다고 판단했습니다. (24.01.31 기준)
• 기타 유명한 도구로는 Apache JMeter, nGrinder, Gatling 등이 있습니다.

부하 테스트를 위한 툴 선택은 전체 테스팅 프로세스의 시작점이며, 효율적인 진행을 위해 매우 중요합니다. Wonderwall 팀은 GUI보다 코드로 시나리오를 작성하는 방식을 선호하며, 확장성이 뛰어나고 AWS Fargate 환경에서도 용이하게 사용할 수 있는 Locust를 선택했습니다. 오픈 소스 도구를 사용할 경우, 커뮤니티 지원이 활발하고 사용자가 많은 도구를 선택하는 것이 좋습니다. 이러한 도구들은 대체로 설정이 간단하며, 필요한 트래픽 양에 따라 클라우드 환경에서 쉽게 확장할 수 있는지 확인하는 것이 중요합니다. 단순히 멋져보이는 힙스터 도구의 사용을 지양해야 합니다.

2 단계: 테스트 시나리오 정의

부하 테스트를 시작하기 위한 첫 번째 단계로, 테스트 대상인 애플리케이션의 API 서버에 대해 호출되는 모든 API를 정리하는 것이 중요합니다. 이 과정에서 목표는 애플리케이션의 전체 기능과 서비스 범위를 파악하여, 실제 운영 환경에서 발생할 수 있는 다양한 상황을 모두 포함하는 시나리오를 구성하는 것입니다. 테스트 시나리오의 정의는 부하 테스트 도구에 설정을 적용하면서 동시에 진행할 수 있으며, 대부분의 부하 테스트 도구들은 이러한 시나리오 설정을 지원합니다.

아래는 Wonderwall 팀이 작성한 시나리오의 예시입니다.

from locust import HttpUser, between, task
import time

class QuickstartUser(HttpUser):
    wait_time = between(1, 2)

    @task
    def hello_world(self):
        self.client.get("/hello")
        self.client.get("/world")
    
    @task(3)
    def view_item(self):
        for item_id in range(10):
            self.client.get(f"/item?id={item_id}", name="/item")
            time.sleep(1)

    def on_start(self):
        self.client.post("/login", json={"username": "foo", "password": "bar"})

Wonderwall 팀에서 고려했던 주요사항은 다음과 같습니다.

• 완전성: 테스트 시나리오는 애플리케이션의 모든 기능과 API 호출을 포괄해야 하며, 어떠한 경우도 빠트리지 않도록 해야 합니다. 이를 통해 애플리케이션의 전반적인 성능과 안정성을 종합적으로 평가할 수 있습니다.
• 이해도: 시나리오가 실제로 어떤 역할을 하는지, 애플리케이션의 어떤 기능과 관련이 있는지에 대해 90% 이상 이해하는 것이 필수적입니다. 이는 시나리오를 통해 실제 사용자의 행동 패턴과 비슷한 상황을 재현하려는 목적을 달성하기 위함입니다. 특히 시나리오를 코드로 작성할 때 각 태스크의 가중치 값을 프레임워크가 지원하는 방식으로 적절하게 조정합니다. (예: view_item 태스크 가중치는 3)

각 시나리오는 실제 사용자의 행동을 모델링하며, 사용자가 애플리케이션을 사용하는 동안 발생할 수 있는 다양한 시나리오를 포괄해야 합니다. 이렇게 정리된 시나리오를 부하 테스트 도구에 설정함으로써, 애플리케이션의 성능과 안정성을 종합적으로 평가할 수 있는 기반을 마련할 수 있습니다.

3 단계: 테스트 목표 성능 및 오류에 대한 임계값 정의

시나리오 설정 후, 다음 단계로는 목표 성능 지표를 정리하는 것이 필요합니다. 이 과정에서는 특히 응답 속도와 목표로 하는 동시 사용자 수(가상 사용자, VU)와 같은 중요한 지표들에 대한 목표 값을 설정합니다. 응답 속도는 퍼센타일 지표(p50, p95, p99)를 사용해, 예를 들어, 95%의 요청이 몇 밀리초(ms) 이내에 응답을 받아야 하는지를 결정합니다.

Wonderwall 팀에서 고려했던 주요사항은 다음과 같습니다.

• 현재 서비스 응답 속도 파악: 서비스가 현재 원활하게 운영되고 있을 때의 응답 속도를 측정하고 이를 기반으로 목표 성능 지표를 설정합니다. 이를 통해 현실적이면서도 도전적인 목표를 설정할 수 있습니다.
• 기존 데이터를 기반으로 한 기준 계산: 과거 데이터 분석을 통해, 특정 사용자 수(VU)에 대한 시스템의 응답 속도와 성능을 이해하고, 이를 바탕으로 목표 지표를 정립합니다.

팀원들과의 충분한 논의를 통해 이러한 목표들이 실제 운영 환경에서의 사용자 경험을 개선하고, 시스템의 한계를 확인하는 데 도움이 될 수 있도록 설정해야 합니다. 목표 지표 설정 과정은 부하 테스트의 방향성을 제시하고, 테스트 결과를 해석하는 데 있어 중요한 기준점을 마련해 줍니다.

4 단계: 인프라 파악

인프라 파악 단계에서는 부하 테스트 대상인 클라우드 인프라의 모든 리소스를 면밀히 검토하고 문서화하는 것이 중요합니다. 이 과정은 테스트 중 발견될 수 있는 성능 문제나 병목 현상을 특정 인프라 요소에 빠르게 연결시키는 데 도움이 됩니다. 특히, API 서버의 경우 각 API별로 사용하는 리소스와 의존성을 정확히 파악하는 것이 필수적입니다.
Wonderwall 팀에서 고려했던 주요사항은 다음과 같습니다.

• 모든 인프라 리소스 체크: 서버(예: EC2 인스턴스, Lambda 함수), 데이터베이스(RDS, DynamoDB 등), 네트워크 구성 요소(로드 밸런서, API 게이트웨이 등), 그리고 추가적인 서비스(S3, SQS, SNS 등)를 포함한 클라우드 인프라의 모든 리소스를 체크리스트에 포함시키십시오.
• API별 리소스 파악: 각 API가 사용하는 인프라 리소스와 의존성을 구체적으로 파악합니다. 이는 특정 API에서 성능 문제가 발생했을 때, 문제의 원인을 빠르게 진단하고 해결하는 데 도움이 됩니다.

놓치기 쉬운 것:

• ‘문제없을 것’이라고 가정한 부분 검토: 종종 가장 기본적이거나 당연하다고 여겨지는 인프라 구성 요소(예: 네트워크 연결, SSD I/O 성능 등)에서 예상치 못한 병목 현상이 발생할 수 있습니다. 따라서, 모든 인프라 요소를 꼼꼼히 검토하고, 성능 이슈의 가능성을 미리 파악하는 것이 중요합니다.

이 단계의 목표는 부하 테스트를 수행하기 전에 시스템의 현재 상태를 정확히 이해하고, 가능한 모든 리소스와 그 한계를 명확히 파악하는 것입니다. 이를 통해 테스트 중 발생할 수 있는 문제를 예측하고, 실제 테스트 결과를 바탕으로 효율적인 문제 해결과 성능 최적화 방안을 도출할 수 있습니다.

5 단계: 테스트 준비

테스트 준비 단계에서는 부하 테스트를 위해 실제 운영 환경을 가능한 한 정확히 복제해야 합니다. 이는 API 서버, 데이터베이스(DB) 등 모든 관련 서비스 항목에 해당합니다. 운영 환경의 데이터베이스를 복제하여 사용함으로써, 실제 운영 시 발생할 수 있는 쿼리 성능의 차이점을 테스트에서도 고려할 수 있습니다.

Wonderwall 팀에서 고려했던 주요사항은 다음과 같습니다.

• 실제 운영 환경 복제: API 서버, 데이터베이스(DB) 등의 환경을 정확히 복제합니다.
• 테스트용 유저 데이터 추가: 실제 운영 환경과 유사한 유저 데이터를 테스트 환경에 추가합니다.

6 단계: 단계별/탄력성 테스트

테스트 진행 단계에서는 정의된 시나리오에 따라 실제 부하 테스트를 실행하고, 그 결과를 체계적으로 기록합니다. 테스트 중에는 모든 변수를 통제하고, 예상치 못한 병목 현상을 발견하기 위해 다양한 리소스의 성능을 모니터링합니다.

Wonderwall 팀에서 고려했던 주요사항은 다음과 같습니다.

• 변경 가능한 리소스 환경: 테스트 대상 리소스의 변경이 신속하게 이루어질 수 있도록 환경을 구축합니다.
• 모든 하드웨어 리소스 모니터링: CPU, 메모리, 네트워크, 스토리지 등 모든 하드웨어 리소스를 병목 현상의 후보로 고려하고 모니터링합니다.

놓치기 쉬운 것:

• 부하 발생기 자체가 병목이 되지 않도록 주의하며, 항상 모니터링을 진행합니다.
• 네트워크 성능에 대한 기대치를 낮춰야 합니다. 네트워크 성능 이슈라 자주 발생합니다.

7 단계: 성능 평가 및 결과 적용

부하 테스트 결과를 바탕으로 개선 방향을 정리하고, 이를 실제 운영 환경에 적용하는 마지막 단계입니다. 이 때, 아키텍처 변경이나 서비스 로직의 수정 등이 포함될 수 있습니다. 변화를 일시에 적용하기 보다는 점진적으로 배포하며, 각 단계에서 성능 모니터링을 통해 효과를 검증하는 접근 방식을 권장합니다.

이 과정을 통해 실제 운영 환경의 성능과 안정성을 향상시킬 수 있으며, 사용자 경험을 개선하는 데 기여할 수 있습니다. 부하 테스트는 지속적인 성능 모니터링과 함께 주기적으로 반복해야 하는 과정입니다. 이를 통해 시스템의 성능을 지속적으로 개선하고, 변경되는 사용자 요구와 트래픽 패턴에 효과적으로 대응할 수 있습니다.

부하 테스트 시 유용한 팁

Wonderwall 팀이 부하 테스트를 진행하며 얻은 여러 가지 유용한 팁을 AWS 환경과 Node.js API 서버, 그리고 ECS Fargate, RDS Aurora, Amazon ElastiCache for Redis를 사용하는 상황에 맞춰 정리해보겠습니다. 특히 스파이크 트래픽, 즉 단시간에 대량의 트래픽이 들어오는 상황에 중점을 두었습니다.

AWS Support 및 Solutions Architect 팀

• Support 플랜 활용: AWS와 같은 클라우드 환경에서 문제 원인을 찾기 어려울 때는 서포트 플랜을 적극 활용합니다. AWS Support 플랜을 통해 AWS Solutions Architect 팀과 Support 팀과 함께 여러 차례 미팅을 통해 부하 테스트 시에 겪은 문제의 해결을 도모할 수 있습니다. Support 케이스를 제출할 때 상황에 대해 구체적으로 설명해주시면 빠르고 자세한 분석이 가능합니다. 예를 들어, 부하 테스트 방식, 시나리오, 목적 등에 대해 기재해주시면 Support Engineer들이 고객분들의 입장에서 분석하기 수월해집니다. 추가로, 각 제품별로 케이스를 올려주시면 보다 전문적인 답변을 제공 받으실 수 있습니다.
• AWS SA 전문가 활용: AWS는 담당 Account Manager를 통해 AWS와 관련된 다양한 기술 문의를 할 수 있습니다. 이를 통해 메일을 통한 담당 SA의 답변을 받아볼 수 있으며, 상황에 따라 미팅도 가능합니다.

Amazon ECS Fargate

• 네트워크 대역폭 한계: Fargate는 내부적으로 EC2 인스턴스를 사용하며, 네트워크 대역폭에 한계가 있을 수 있습니다. AWS Support 팀과 상담을 통해 네트워크 대역폭 한계를 확인하고 지침을 받습니다.
• 컨테이너 시작 최적화: 빠른 테스트 진행을 위해 컨테이너가 신속하게 시작하도록 설정을 최적화가 필요합니다.

Amazon Aurora PostgreSQL

• 주요 모니터링 지표: RDS 콘솔의 모니터링 탭에서 제공되는 CloudWatch 지표를 통해 CPU, Memory, Connections 및 Storage Throughput과 Network Throughput 등 주요 지표를 모니터링할 수 있습니다. 이와 더불어 Enhanced Monitoring 활성화를 통해 OS 지표에 대한 자세한 확인이 가능하며 Performance Insights를 활용해 성능 최적화를 검토할 수 있습니다.
• 성능 최적화: Performance Insights를 활성화하면 DB Load와 대기 이벤트에 대한 확인이 가능합니다. 많이 발생하는 대기 이벤트와 연관 된 쿼리를 확인하여 쿼리를 최적화하거나 워크로드의 개선 및 스케일 업/아웃에 대한 검토 자료로 활용할 수 있습니다.
  예를 들어, LWLock:lock_manager 대기 이벤트가 관찰되면 RDS Proxy 적용을 고려해볼 수 있습니다. 대기 이벤트에 대한 내용은 AWS의 공식 문서에서 자세히 확인할 수 있습니다.
• 쿼리 실행 계획: 사용자는 EXPLAIN 명령을 통해 쿼리의 실행 계획을 확인할 수 있습니다. 특정 쿼리로 인해 리소스가 많이 사용되거나 성능이 저하된다면 쿼리의 실행 계획을 출력하여 성능에 영향을 미치는 사항을 확인할 수 있습니다.
• Auto Scaling: Aurora RDS는 리더 인스턴스에 대해 Auto Scaling을 설정할 수 있습니다. 평균 CPU 사용률이나 데이터 베이스 연결 수를 추적하여 자동으로 스케일 인/아웃 동작을 지원하며, 최대 15대의 Aurora 복제본을 생성할 수 있습니다.
• Vacuum: PostgreSQL에서는 vacuum이 굉장히 중요한 요소입니다. 대량의 데이터가 삽입된 후에는 vacuum analyze 명령을 통해 통계 정보를 수집하여 옵티마이저가 적절한 쿼리 실행 계획을 수립할 수 있도록 해야합니다. vacuum analyze 명령 외에도 vacuum, vacuum full 명령을 통해 테이블의 단편화를 제거하여 테이블 탐색에 대한 효율을 최적화할 수 있으며 vacuum freeze 명령을 통해 트랜잭션 ID를 반환하여 Transaction ID wraparound 문제를 방지할 수 있습니다.
  PostgreSQL에서는 정해진 threshold를 만족하면 autovacuum이 자동으로 수행되지만 pg_stat_all_tables 혹은 pg_stat_user_tables 뷰를 통해 가장 최근 수행 된 vacuum 작업에 대한 이력을 확인하고 수동으로 vacuum 수행을 고려해볼 수 있습니다.

Amazon ElastiCache for Redis

• 네트워크 지연 주의: 스파이크 테스트 중 예상치 못한 네트워크 지연이 크게 발생할 수 있습니다. 이 경우, 문제의 원인을 정확히 파악하기 위해 네트워크 성능을 철저히 모니터링해야 합니다. 이 때 Amazon CloudWatch를 사용하여 성능 지표를 모니터링하고 로그를 분석합니다. 이를 통해 시스템의 성능 병목 현상을 식별하고 해결할 수 있습니다.
• Redis의 SingleThread 특성: Redis는 SingleThread 사용하므로, 한 번에 하나의 vCPU만 사용됩니다. 때문에 대량의 쿼리가 발생하거나 Slow 쿼리가 처리될 때 응답 속도가 저하될 수 있습니다. 이런 경우, 여러 노드로 분산하여 처리하는 것이 좋으며, 이를 통해 Engine CPU 와 Network Allowance Exceeded(네트워크 성능 한계치를 넘을때 발생하는 기록)로 인한 속도 저하를 완화하거나 개선 할 수 있습니다. 또 더 큰 타입으로의 Scale-Up보다는, 여러 더 작은 타입의 인스턴스로 Scale-Out하는 것이 Engine CPU를 여러 노드로 분산시키고 네트워크 사용량을 여러 노드로 분산하는 데 유리합니다.
• 키 관리 최적화: Redis에서는 작고 표준화된(동일한 크기와 타입을 가진) 키를 사용하는 것이 성능에 유리합니다. 크기가 큰 키는 성능에 불리할 수 있습니다. redis-cli --bigkeys 명령어를 사용하여 샘플 키들을 검사하고, 너무 큰 키로 인해 발생하는 성능 저하가 없는지 확인하는 것이 좋습니다.

공통

• 변수 단일화: 테스트를 진행할 때는 한 번에 하나의 변수만 변경하며 테스트하는 것이 권장됩니다. 이렇게 하면 어떤 변경이 성능에 영향을 미치는지 명확하게 알 수 있습니다.
• 비용 투자: 단기적으로 비용이 들어가더라도 빠르게 테스트를 진행하여 문제를 해결하는 것이 장기적으로 시간과 비용을 절약하는 방법입니다.
• 확장 전략: 성능 문제에 대응하기 위해 스케일 업(수직 확장)과 스케일 아웃(수평 확장) 중 적합한 전략을 선택합니다.

마무리

Wonderwall 팀에서 소개한 부하 테스트 가이드는 AWS 환경에서 Node.js API 서버를 대상으로 한 부하 테스트의 기획, 준비, 실행, 모니터링 및 최적화에 관한 실용적인 정보를 제공합니다. 부하 테스트의 목적 설정부터 인프라 파악, 테스트 준비, 실제 테스트 실행, 그리고 결과 분석 및 적용까지의 전 과정에 걸쳐 구체적이고 실질적인 조언을 담고 있습니다.

추가로 애플리케이션 부하 테스트를 위한 AWS 규범적 지침은 부하 테스트를 수행하는 다양한 방법과 답변할 수 있는 질문에 대해 살펴봅니다. 또한 테스트를 실행할 때 함정을 방지하는 데 도움이 되는 부하 테스트의 의미에 대해서도 설명합니다. 마지막으로 몇 가지 도구와 그 적용 가능성에 대해 다룹니다.

부하 테스트는 단순히 시스템의 한계를 찾는 것을 넘어서, 애플리케이션의 안정성과 성능을 지속적으로 개선하고 사용자 경험을 향상시키는 중요한 과정입니다. 모든 경우를 완벽하게 대비할 수는 없지만, Wonderwall 팀의 경험이 엔지니어들이 부하 테스트의 전반적인 개요를 이해하는 데 도움이 되기를 바랍니다. 마지막으로, 긴 시간 동안의 테스트를 위해 충분한 시간과 자원을 제공해준 저희 팀과 회사, AWS 팀에게 감사의 말씀을 전합니다.