스타트업의 부하 테스트 AtoZ

들어가며

빠른 성장이 요구되는 스타트업에서 성능 테스트를 해가며 개발하기는 쉽지 않습니다. 또한 한정된 리소스를 보유한 스타트업에서 완벽하고 모든 상황에 대응 가능한 아키텍처를 준비하기는 어렵기도 하고, 동시에 준비할 필요성도 적습니다.

저희 원더월에서 서비스하고 있는 fromm에서도 유사한 고민을 갖고 있었습니다. 팬덤 메시징 플랫폼 특성상 아티스트가 한번 메시지를 발신하면 대량의 팬들이 한번에 앱에 접속하는 트래픽 유형을 갖고 있습니다. 하지만 최근 급격히 증가한 트래픽 때문에 기존에는 단순히 하드웨어 스펙을 조정하는 것으로 문제를 해결하였지만 점점 한계치에 도달하였고 비용도 큰 폭으로 치솟고 있었습니다. 그래서 저희는 대규모 팬덤을 갖고 있는 저희 입점 아티스트와 팬들이 원활하게 서비스를 활용할 수 있게 준비하기 위하여 부하 테스트를 진행하게 되었습니다.

이번 글에서는 부하 테스트를 진행해본 경험이 적은 엔지니어를 위해 전반적인 이해도를 높이기 위한 목적으로 작성하였습니다. 그래서 우선 부하 테스트를 진행하는 절차를 소개해 드리겠습니다. 그리고 해당 절차에서 중요한 것과 놓치기 쉬운 것들을 정리해보았습니다(제가 엄청 놓쳤습니다). 마지막으로는 테스트를 진행하는데 유용한 팁을 정리하여 소개해보도록 하겠습니다.

모든 상황을 커버하기는 어렵지만 부하 테스트를 준비하는 엔지니어들이 테스트 전반의 청사진을 그리는 데 도움이 되길 바라며 이 글을 작성합니다. 끝으로 꽤 오랜 시간 동안 테스트를 진행하는 것에도 넉넉한 시간과 비용을 할당해준 저희 팀과 회사에게 감사 인사를 보내드립니다.

부하 테스트 진행 절차

부하 테스트를 진행하는 순서를 크게 나누면 다음과 같습니다.

0. 테스트 툴 선정

1. 테스트 시나리오 정의

2. 목표 지표 정리 ( 응답 속도, 유저수 )

3. 인프라 파악

4. 테스트 준비

5. 테스트 진행 & 결과 기록

6. 개선 방향 정리 & 결과 적용

다음에는 각각의 항목에 대하여 간단히 소개해 드리겠습니다.

0. 테스트 툴 선정

일단 툴이 정해져 있으면 뒤에 진행할 내용을 빠르게 진행하기 쉽습니다. 저는 GUI보다 코드로 작성하는 것을 선호하고, 대량의 트래픽 테스트로 확장이 쉬운 locust를 AWS Fargate 환경에 올려 사용했습니다. 오픈 소스를 사용해야 하는 상황이라면 웬만하면 언어를 신경 쓰지 말고 사용자 많고 스타 수 높은 툴로 가는 것을 추천해 드립니다. 어차피 짜여진 시나리오를 툴에 설정하는 과정은 크게 어렵지 않습니다. 관련 내용은 마지막에 Appendix에 다시 한 번 소개해 드리도록 하겠습니다.

중요한 것

• 요구되는 트래픽이 높으면 Cloud 환경에서 쉽게 확장 가능한지 확인
• 사용자가 많은 툴인지 (JMeter, nGrinder, locust, k6 등)

놓치기 쉬운 것

• 힙스터 툴 사용 지양하기

1. 테스트 시나리오 정의

locust로 작성한 시나리오 (https://github.com/locustio/locust/blob/master/examples/locustfile.py)

부하 테스트의 시작입니다. 테스트 시나리오를 정의해야 합니다. 앱 서비스를 운영하는 API 서버를 예로 들면 앱에서 호출하는 API를 정리해 봅니다. 대부분의 부하 테스트 툴은 시나리오 설정을 지원하니 툴에 시나리오를 셋팅하며 시나리오를 정리하는 것도 좋은 방법입니다.

중요한 것

• 되도록 하나도 빼놓지 않고 모든 경우 고려하기
• 시나리오가 어떤 역할을 하는지 90% 이상 이해 필수

2. 목표 지표 정리 ( 응답 속도, 유저수 )

시나리오 설정이 완료되었으면 응답 속도나 목표 동시 접속자 수와 같은 지표를 설정합니다. 접속자 수는 보통 VU(Virtual User)로 많이 표기합니다. 응답 속도는 보통 p50, p95, p99 같은 지표 안에 몇 ms를 목표하는지 설정합니다. 팀원과 충분한 논의를 거쳐 “초당 VU 10만명이 10초동안 들어왔을 때 latency p95 200ms” 등으로 논의해 봅시다.

중요한 것

• 현재 서비스가 원활할 때 응답 속도를 파악하며 기준 잡아보기
• 기존 데이터 기반으로 기준 계산하기

3. 인프라 파악

세번째는 인프라 파악입니다. 현재 테스트 대상이 되는 클라우드 인프라 리소스 등을 모두 체크해 봅니다. API 서버의 경우 API별로 파악하고 있으면 더욱 좋습니다. 특정 API 성능이 안 나올 때 어떤 인프라에 문제가 있는지 확인하기 용이합니다.

중요한 것

• 모든 인프라 리소스 체크해두기

놓치기 쉬운 것

• 이건 당연히 문제없지! 라고 생각한 부분에서 병목이 딱 생김

4. 테스트 준비

테스트 준비 단계입니다. 각 서비스의 항목에 맞추어 필요한 리소스를 준비해야 합니다. 실제 운영환경과 완전히 동일한 상태를 만드는 것이 중요합니다. DB 같은 항목도 쿼리 성능에 차이가 있을 수 있으니 운영환경의 DB를 복제해서 사용하도록 합시다.

중요한 것

• 실제 운영 환경 복제 (API 서버, DB 등)
• 테스트용 유저 데이터 추가

5. 테스트 진행 & 결과 기록

이제 실제 테스트를 진행하며 결과를 기록하는 단계입니다. 변수 통제를 철저히 하고 테스트를 진행하는 것이 시간을 아끼는 데 도움이 됩니다. 지표에 너무 매몰되어 오랜 시간을 잡아먹는 것을 지양하도록 합시다. 어차피 실제 시나리오와 100% 일치하는 테스트를 진행하기는 어렵습니다.

중요한 것

• 테스트 대상 리소스 변경이 빠르게 이뤄질 수 있는 환경 구축하기
• 리소스의 모든 하드웨어를 병목 대상 후보로 두기 ( CPU, Memory, Network, Storage 등 )

놓치기 쉬운 것

• 부하 발생기 본인이 병목인 경우가 자주 있으므로 모니터링 항상 진행
• Network는 괜찮겠지? 하면 매우 안 괜찮음

6. 개선 방향 정리 & 결과 적용

마지막으로 개선 방향을 정리하고 결과를 실제 운영 환경에 적용하는 단계입니다. 개선 방향은 아키텍처 변경, 서비스 로직 변경 등이 주로 있습니다. 해당 결과를 모두 운영 환경에 한번에 적용하기보단 점진적으로 배포해가며 모니터링을 통해 적용하여 나가는 것을 추천해 드립니다.

유용한 팁

마지막으로 부하 테스트를 진행하며 얻은 여러 가지 유용한 팁을 정리해보았습니다. 저희는 AWS 환경에서 Node.js API 서버를 대상으로 테스트를 진행하였고, ECS Fargate, RDS Aurora, Elasticache Redis 등을 사용하고 있습니다. 트래픽 종류는 단시간에 대량의 트래픽이 들어오는 스파이크성 트래픽을 중점적으로 테스트하였습니다.

공통

• 클라우드 사용자의 경우 문제 원인을 찾기 어려울 때 서포트 플랜을 최대한 활용하는 것이 중요 (본인의 경우 AWS과 미팅만 3차례 진행)
• 일반적인 경우, 테스트 1회당 1개의 변수만 바꾸는 것 추천
• 돈 아끼지 말고 빠르게 진행하는 것이 오히려 최종적으로 돈과 시간을 아끼는 길
• Scale up: 하드웨어 성능 업그레이드 (수직 확장), Scale out: 하드웨어 개수 늘리기 (수평 확장)

AWS ECS Fargate

• 주요 변수: CPU, Memory, (Network)
• Fargate가 내부적으로 ec2를 띄우는 구조라 확인할 수 없는 Network Bandwidth limt을 적용받음 (AWS Support 문의 답변 결과)
• 빠른 테스트 진행을 위해 컨테이너가 빠르게 뜨도록 설정 (참고자료)

AWS RDS Aurora (Postgres)

• 주요 변수: CPU, Memory, DB Connection count, Network
• Serverless 주요 변수: Serverless Capacity
• 모니터링은 Performance Insight(이하 PI)와 Monitoring 탭에서 주로 진행
• PI에 LWLock:lock_manager이 관측될 경우 connection pool이 문제가 되는 경우가 있으므로 RDS Proxy 적용 고려
• PI CPU 대기가 길다면 문제가 되는 쿼리의 최적화 지점을 살펴보거나 Scale up/out 진행
• 대량의 테스트 데이터가 들어갔다면 vacuum analyze 쿼리 실행

AWS Elasticache (Redis)

• 주요 변수: Memory, CPU, Network
• 스파이크 테스트 중 상상치 못하게 Network 지연이 크게 발생해 문제 원인을 찾기 힘든 경우가 있었음

Appendix. 부하 테스트 툴

1. LOCUST (https://locust.io)

가장 추천하는 툴 입니다. Python으로 제작된 툴로 가볍고, 해당 언어로 시나리오 작성이 가능합니다. JavaScript 개발자인 제 기준에도 시나리오 작성이 쉬워 부담이 없었습니다. 또한, 부하 테스트 관련 요청을 했을 때 AWS의 엔지니어분도 사용하고 계실 정도로 사용자 풀이 넓고 생태계 발전이 잘 되어 있습니다.

그리고 ECS Spot Fargate를 사용해 저렴한 가격으로 Distributed load testing이 가능한 example이 AWS 공식 레포에 올라와 있습니다. 마지막으로 상단 이미지처럼 빌트인으로 Web UI를 제공해 트래픽을 변경해가며 지표들을 살펴보기 좋게 제공하고 있습니다.

2. k6 (https://k6.io)

JavaScript로 시나리오 작성 가능합니다. 그리고 Grafana에서 제공하는 k6 Cloud 환경에서 비용을 지불하고 테스트를 진행할 수 있습니다. 다만 k6 Cloud 한정으로 대량 부하 발생 시 k6 Cloud에서 단일머신을 활용하기 때문에 부하발생기의 성능이 따라오지 못하는 이슈가 간혹 있을 수 있습니다.

3. Artillery (https://www.artillery.io)

Yaml과 JavaScript로 시나리오 작성 가능합니다. AWS Lambda와 Fargate를 사용하는 태생적으로 Distributed load testing이 가능한 좋은 컨셉의 툴이지만 아직 잦은 오류 등으로 인해 성숙함이 갖춰지지는 않은 라이브러리라고 생각합니다. (24.01.31 기준)

그외 유명한 툴은 Apache JMeter, nGrinder, Gatling 등이 있습니다.

마치며

지금까지 스타트업에서 부하 테스트를 진행하는 엔지니어를 위한 내용을 소개해보았습니다. 최대한 실용적인 가이드가 될 수 있게 글을 작성하였는데 해당 목적이 독자분들에게 잘 전달되었으면 좋겠습니다.

끝으로 저처럼 처음 부하 테스트를 진행하는 분에게 도움이 되셨으면 좋겠다는 마음으로 이번 글을 마무리 짓도록 하겠습니다. 원더월에는 이처럼 다양한 기술적 챌린지가 존재하고 있느니 함께 해결해나가고 싶은 분들은 채용 공고를 확인하시고 지원 부탁드리겠습니다. 감사합니다.