부하 테스트 정의, 툴, 시나리오

부하 테스트의 정의

부하 테스트(Load Testing)는 시스템이 특정 수준의 부하(트래픽, 요청, 데이터 처리 등)를 받을 때 성능이 어떻게 변화하는지를 평가하는 테스트 방법이다.
쉽게 말해, 사용자가 몰릴 때 서버가 얼마나 잘 버티는지를 확인하는 과정이라고 할 수 있다.

예를 들어, 온라인 쇼핑몰에서 연말 세일을 시작할 때 갑자기 수천 명의 사용자가 동시에 접속하면, 서버가 이를 감당할 수 있을까? 페이지 로딩 속도가 느려지거나, 결제가 원활하게 이루어지지 않는 문제는 없을까?
이런 문제를 사전에 발견하고 해결하기 위해 부하 테스트를 수행한다.

성능 테스트와의 차이점

출처: https://loosie.tistory.com/821

 

부하 테스트는 성능 테스트의 한 종류다. 하지만 성능 테스트에는 여러 가지 유형이 있으며, 각 유형마다 목적이 조금씩 다르다.

• 부하 테스트 : 예상되는 트래픽 수준에서 시스템이 정상적으로 동작하는지 확인하는 테스트
• 스트레스 테스트 : 시스템의 한계를 초과하는 부하를 가해 어디까지 견딜 수 있는지 확인하는 테스트
• 내구성 테스트 : 장시간 동안 일정한 부하를 가해 시스템이 안정적으로 유지되는지 확인하는 테스트
• 스파이크 테스트 : 갑자기 트래픽이 급증할 때 시스템이 어떻게 반응하는지 확인하는 테스트

부하 테스트는 일반적으로 정상적인 사용량을 기반으로 수행하는 반면, 스트레스 테스트는 시스템의 한계를 찾는 데 초점을 맞춘다. 따라서 목적에 따라 적절한 테스트를 선택하는 것이 중요하다.

부하 테스트의 주요 목표

부하 테스트를 수행하는 목적은 단순히 시스템이 버티는지 확인하는 것이 아니라, 성능 최적화와 안정성 확보에 있다.

주요 목표는 다음과 같다.

• 성능 측정: 서버 응답 시간, 처리 속도, 리소스 사용량(CPU, 메모리, 네트워크 등)을 분석하여 병목 현상 해결
• 시스템 안정성 검증: 실제 서비스 운영 중 예상되는 트래픽을 미리 시뮬레이션하여 장애 가능성 감소
• 용량 계획 지원: 서버 인프라를 얼마나 확장해야 하는지, 필요한 리소스가 어느 정도인지 결정
• 최적화 및 비용 절감: 불필요한 리소스를 줄이고, 효율적인 성능 튜닝을 통해 운영 비용 절감

부하 테스트를 수행하는 방법

부하 테스트는 단순히 많은 요청을 보내는 것이 아니라, 현실적인 테스트 시나리오를 구성하고, 테스트 환경을 구축한 후, 데이터를 분석하여 개선하는 과정이 포함된다.

1. 테스트 시나리오 수립

부하 테스트를 수행하기 전에, 어떤 상황을 가정할지를 결정해야 한다.
무작정 테스트를 수행하는 것이 아니라, 실제 사용자의 행동을 기반으로 시나리오를 설정해야 한다.

• 사용자 유형: 동시에 접속하는 사용자 수는 몇 명인가?
• 요청 패턴: 주로 실행되는 요청(로그인, 상품 조회, 결제 등)은 무엇인가?
• 부하 증가 방식: 점진적으로 트래픽을 증가시킬 것인가, 특정 순간에 급증시키는가?
• 성공 기준: 응답 시간이 몇 초 이하이면 정상인가? 최대 몇 명의 동시 접속을 감당해야 하는가?

예시 시나리오는 다음과 같이 작성할 수 있다.

• "온라인 쇼핑몰에서 1,000명의 사용자가 동시에 로그인한 후, 500명은 상품을 검색하고, 300명은 장바구니에 추가하며, 200명은 결제를 진행한다."
• "API 서버가 1초에 1,000건의 요청을 받을 때, 95% 이상의 요청이 2초 이내에 응답해야 한다."

2. 테스트 환경 구축

부하 테스트를 실행하려면 실제 환경과 유사한 환경을 준비해야 한다.

또한 부하 테스트를 위해 적절한 데이터(예: 사용자 계정, 상품 정보, 로그 기록 등)를 미리 준비해야 한다.

3. 부하 테스트 실행

테스트 환경이 준비되면, 본격적으로 부하 테스트를 실행한다.

다음과 같은 테스트 방식이 있다.

• 점진적 부하 테스트: 초기에는 낮은 트래픽으로 시작하고, 점진적으로 부하를 증가시켜 한계점을 확인.
• 최대 부하 테스트: 한 번에 최대 부하를 가해 서버가 어디까지 견딜 수 있는지 확인.
• 실제 트래픽 패턴 시뮬레이션: 실제 사용자들이 서비스를 이용하는 패턴을 반영하여 테스트 실행.

부하 테스트를 진행하는 코드를 작성할 때, 옵션을 넣어 부하 테스트 방식을 지정할 수 있다.

4. 결과 분석 및 튜닝

부하 테스트 결과를 분석하여 어떤 부분에서 성능 저하가 발생하는지를 파악하고, 이를 해결하는 과정이 필요하다.

결과 분석 시 확인할 항목은 다음과 같다.

• 응답 시간(Response Time): 평균 및 최대 응답 시간이 얼마인지 확인.
• 처리량(Throughput): 초당 처리할 수 있는 요청 수는 얼마인지 확인.
• 에러율(Error Rate): 부하가 증가할 때 요청이 실패하는 비율 확인.
• 리소스 사용량: CPU, 메모리, 네트워크 대역폭 사용량이 얼마나 되는지 확인.

이렇게 발견된 성능 저하 문제는 DB 쿼리 최적화, 캐싱 도입, 로드 밸런싱, 오토 스케일링 도입 등으로 해결할 수 있다.

 

부하 테스트 툴

대표적인 부하 테스트 툴로는 JMeter, Locust, k6 등이 있다.

JMeter

JMeter는 Apache Software Foundation에서 개발한 오픈소스 부하 테스트 도구이다.

웹 애플리케이션(API, 데이터베이스, 웹 서비스 등)에 대한 부하 테스트를 수행할 수 있으며 GUI 모드와 CLI 모드 모두 지원한다.

또한 HTTP, FTP, TCP 등 다양한 프로토콜을 지원한다.

https://jmeter.apache.org/

Apache JMeter - Apache JMeter™

 

Locust

Locust는 Python 기반의 부하 테스트 도구로, 코드 기반으로 테스트 시나리오를 작성할 수 있다.

이벤트 기반으로 동작하여 성능이 뛰어나며 웹 UI를 제공하여 실시간으로 테스트 진행 상황을 모니터링할 수 있다.

https://locust.io/

Locust.io

k6

k6는 Grafana에서 만든 Go 언어 기반의 부하 테스트 도구로, JavaScript를 사용해 스크립트를 작성할 수 있다.

CLI 기반으로 동작하며, 실시간 모니터링 기능을 제공한다.

클라우드 기반 테스트(k6 Cloud)을 지원하는 것이 특징이다.

https://k6.io/

Load testing for engineering teams | Grafana k6

 

 

 

부하 테스트 진행 사례: Wonderwall

AWS 기술 블로그에 기고된 모범 부하 테스트 사례를 살펴보았다.

https://aws.amazon.com/ko/blogs/tech/wonderwall-perform-load-testing/

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

 

1단계: 테스트 도구 선택

Wonderwall 팀은 부하 테스트 도구로 Locust를 선택했다.

선정 이유는 다음과 같다.

• 코드로 시나리오를 작성하는 방식 선호
• 확장성이 뛰어나고 AWS Fargate 환경에서도 사용 간편
• 커뮤니티 지원이 활발하고 사용자가 많은 오픈 소스 도구

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

부하 테스트를 시작하기 위한 첫 번째 단계로, 테스트 대상인 애플리케이션의 API 서버에 대해 호출되는 모든 API를 정리해야 한다.

애플리케이션의 전체 기능과 서비스 범위를 파악하여 실제 운영 상황에서 발생할 수 있는 다양한 상황을 모두 포함하는 시나리오를 구성하기 위함이다.

 

Wonderwall 팀에서 고려한 주요사항은 다음과 같다.

• 완전성: 테스트 시나리오는 애플리케이션의 모든 기능과 API 호출을 포괄해야 하며, 어떠한 경우도 빠트리지 않아야 한다.
• 이해도: 시나리오가 실제로 어떤 역할을 하는지, 애플리케이션의 어떤 기능과 관련이 있는지 이해해야 한다.

이렇게 정리된 시나리오를 부하 테스트 도구에 설정함으로써, 애플리케이션의 성능과 안정성을 종합적으로 평가할 수 있는 기반을 마련할 수 있다.

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

시나리오 설정 후, 다음 단계로는 목표 성능 지표를 정리하는 것이 필요하다.

이 과정에서는 특히 응답 속도와 목표로 하는 동시 사용자 수(가상 사용자, VU)와 같은 중요한 지표들에 대한 목표 값을 설정한다.

응답 속도는 퍼센타일 지표(p50, p95, p99)를 사용해, 예를 들어, 95%의 요청이 몇 밀리초(ms) 이내에 응답을 받아야 하는지를 결정해야 한다.

목표 지표는 현재 서비스의 응답 속도를 파악하고, 기존 데이터를 기반으로 설정하여 부하 테스트 결과 해석의 기준점이 된다.

4 단계: 인프라 파악

현재 테스트 대상이 되는 클라우드 인프라 리소스 등을 모두 체크한다.

API 서버의 경우 API별로 파악하고, 특정 API 성능이 저하될 때 어떤 인프라에 문제가 있는지 확인하기 위해 모든 인프라 리소스를 체크해야 한다.

5단계: 테스트 준비

각 서비스의 항목에 맞추어 필요한 리소스를 준비한다.

실제 운영환경과 완전히 동일한 상태를 만드는 것이 중요하므로, DB 같은 항목도 쿼리 성능에 차이가 있을 수 있어 운영환경의 DB를 복제하여 사용하는 것이 좋다.

또한, 테스트용 유저 데이터를 추가하여 실제 환경과 유사한 조건을 마련한다.

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

테스트를 진행하며 변수 통제를 철저히 하고, 테스트 대상 리소스 변경이 빠르게 이루어질 수 있는 환경을 구축해야 한다.

리소스의 모든 하드웨어를 병목 대상 후보로 두고, 부하 발생기가 병목이 되지 않도록 모니터링을 항상 진행한다.

또한, 네트워크의 상태를 지속적으로 확인하여 안정적인 테스트 환경을 유지한다.

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

부하 테스트 결과를 바탕으로 개선 방향을 정리하고, 이를 실제 운영 환경에 적용하는 마지막 단계이다.

부하 테스트 결과를 통해 아키텍처 변경이나 서비스 로직이 수정될 수 있는데, 이때 변화를 한번에 적용하는 것보다는 점진적으로 배포하여 각 단계에서의 성능 모니터링으로 효과를 검증하는 방식을 권장한다.