부하테스트 개념, 툴

프로젝트/ACC Load Test Project

부하테스트 개념, 툴

dayeonsheep 2025. 3. 19. 19:02

근데 부하테스트, 스트레스 테스트, 성능 테스트가 어떤 점이 다른지 정확히 모르고 있어서 짚고 넘어가보자

개념 비교

성능테스트

정상적인 조건에서 시스템의 성능을 평가
응답 시간, 처리량 등 전반적인 성능 지표를 측정
부하테스트와 스트레스테스트를 포함하는 상위 개념

부하테스트

예상되는 실제 사용자 부하 하에서 시스템의 성능을 평가
예상되는 최대 부하 조건에서 시스템의 성능을 평가
시스템이 정상적으로 작동하는 최대 부하(최대 사용자 수나 트랜잭션 수)를 확인

적절한 부하를 발생시켜서 통계적으로써 의미있는 수치를 측정한다.
장시간의 서비스 진행여부를 확인하는 신뢰성(reliability)
실체 처리능력을 가늠하는 성능테스트(Performance)
"부하"라는 것은 매우 포괄적이므로, 부하테스트에 사용되어지는 부하의 모든 의미를 내포하는 것으로 이해하는 것이 좋다.

스트레스테스트

시스템의 한계를 넘어서는 극단적인 부하 상황에서의 동작을 평가
시스템이 붕괴되는 지점을 찾고 복구 능력을 테스트
과부하 상황에서의 시스템 동작과 복구 능력을 테스트

CPU, RAM, DISK의 환경이 갖추어지지 않은 어플리케이션에 비정상적으로 높은 부하를 발생시켜 한계점을 테스트해보는 것을 말한다.
실제로 이러한 부하가 발생시키면 VM서비스의 다운, 데이터의 소실 등의 시스템레벨의 오작동을 유발 시키는 것이 가능하다.
이러한 결점과 결함점을 찾는 것을 목표로 스트레스 테스트가 진행되어진다.
어디까지나 시스템레벨에서의 결함을 예상하는 수준으로 결과물을 파악하는 것이 중요하며, 실접속자가 발생시키는 부하량과는 매우 다른 케이스를 가질 수도 있다는 점을 유의한다.

구분	부하 테스트 (Load Test)	스트레스 테스트 (Stress Test)
부하 수준	예상되는 최대 부하 또는 그에 가까운 수준의 부하 적용	시스템의 한계를 초과하는 극단적인 부하 적용
테스트 기간	일반적으로 장시간 동안 지속적인 부하 적용	짧은 시간 동안 급격한 부하 증가 적용
결과 분석	응답 시간, 처리량, 리소스 사용률 등의 성능 지표 분석	시스템 오류, 데이터 손실, 보안 취약점 등 극한 상황에서의 시스템 동작 분석
실제 사용 사례	온라인 쇼핑몰에서 블랙프라이데이와 같은 대규모 세일 기간 동안의 예상 트래픽 시뮬레이션	DDoS 공격과 같은 예기치 못한 극단적 상황에서 시스템의 동작 테스트

구분	부하 테스트 (Load Test)	스트레스 테스트 (Stress Test)	성능 테스트 (Performance Test)
목적	시스템이 예상된 부하(사용량)에서 정상적으로 동작하는지 확인	시스템이 한계치 이상에서 어떻게 반응하는지 확인	시스템의 전반적인 성능(응답 속도, 처리량 등)을 측정
테스트 환경	예상되는 사용자 수나 요청량을 시뮬레이션	극한의 트래픽과 부하를 가해 시스템이 언제, 어떻게 실패하는지 분석	다양한 성능 지표(응답 시간, Throughput 등)를 분석
주요 지표	응답 시간, 처리량, CPU/RAM 사용량	장애 발생 지점, 시스템 복구 시간	처리량(Throughput), 응답 속도, 자원 사용률
예제	웹사이트에 동시 접속자 1000명이 있을 때 응답 속도가 일정한지 확인	웹사이트에 예상보다 훨씬 많은 트래픽을 가할 때 시스템이 다운되는지 테스트	API의 응답 시간이 특정 기준을 초과하는지 측정

부하 테스트 (Load Testing) 설명

주요 목적

성능 병목 지점 식별
시스템 용량 계획 수립
사용자 경험 개선
예상된 트래픽 수준에서 시스템이 정상적으로 동작하는지 확인
서버의 응답 시간과 처리량(Throughput)을 측정
특정 트랜잭션이 성능 저하 없이 얼마나 처리되는지 평가
CPU, 메모리, 네트워크 사용량 분석을 통한 최적화

일반적 진행 단계

테스트 목표 정의 & 부하 매개변수 결정 (동시 사용자 수 등)
- 부하 수준(예: 동시 사용자 500명)과 성능 기대치를 설정
테스트 시나리오 작성
테스트 환경 구축 및 부하 실행
- 실제 서비스 환경과 유사한 테스트 환경을 구성
- 부하 테스트 도구를 사용하여 요청을 생성
결과 분석 및 시스템 최적화
- 응답 시간, 실패율, 자원 사용률 등을 분석하여 개선점 도출

부하 테스트에 많이 쓰이는 툴과 서비스

부하 테스트 도구	유형	특징	장점	단점
JMeter	오픈소스	강력한 커뮤니티 지원, 다양한 프로토콜 지원(HTTP, FTP, JDBC 등)	확장성, 다양한 플러그인 지원	UI가 다소 복잡, 초보자에게 진입 장벽 있음
Gatling	오픈소스	Scala 기반, 코드 기반 스크립팅 지원	코드 기반으로 유지보수 용이, 고성능	설정이 복잡할 수 있음
Locust	오픈소스	Python 기반, 동적 시뮬레이션 지원	Python으로 간편한 스크립팅	UI 제공 안 됨, 그래픽 분석 기능 부족
k6	오픈소스	JavaScript 기반, CLI 중심	클라우드 환경에서도 테스트 가능, 경량화	고급 분석 기능 부족
Artillery	오픈소스	Node.js 기반, CLI 방식	간단한 설정으로 빠르게 부하 테스트 가능	대규모 테스트에는 부적합
LoadRunner	상용	강력한 분석 기능, 기업용 솔루션, 엔터프라이즈급 애플리케이션, 분산 테스팅	다양한 프로토콜 지원, 고급 보고 기능, 전문적인 지원	유료 라이선스 필요
AWS Load Testing	클라우드	AWS 환경에서 최적화된 부하 테스트	서버리스 방식으로 실행 가능	AWS 서비스에 종속적
LoadView	오픈소스	클라우드 기반, 실제 브라우저 테스트, 웹사이트, 웹 애플리케이션, API	사용 편의성, 24/7 전문가 지원	오픈소스 대비 비용 발생
ngrinder	오픈소스	GUI, CIL(Groovy, Jython로 코딩), HTTP 지원	다양한 프로토콜 지원, 분산 테스트 실행, 실시간 모니터링 등을 제공, 한국어 지원	설치 및 초기 설정이 복잡하며, 고급 기능 활용 시 학습 곡선이 가파를 수 있음

부하 테스트 툴별 서비스 예시 및 사용 방법

1. Apache JMeter

서비스 예시: 대규모 웹사이트 트래픽 테스트, REST API 성능 측정, 웹 애플리케이션, API, 데이터베이스 테스트
사용 방법:
1. JMeter 다운로드 및 설치
2. 테스트 시나리오 작성 (Thread Group 추가)
3. HTTP Request 설정
4. Listener 추가하여 응답 시간 및 실패율 분석
5. 테스트 실행 및 결과 분석
GUI, CLI(XML로 작성, java로 실행) 모두 지원
장점:
- 다양한 프로토콜 지원 (HTTP, WebSocket, FTP 등)
- GUI 및 CLI 실행 가능
- CSV 데이터를 활용한 테스트 가능
- 커스터마이징 가능
단점:
- 다소 무거운 성능 (많은 자원 사용)
- 설정이 복잡할 수 있음 (GUI 등)

2. Gatling

서비스 예시: 온라인 쇼핑몰의 동시 접속자 증가에 따른 응답 시간 측정, 웹 애플리케이션, API 테스트
사용 방법:
1. Gatling 설치 후 Scala 기반 스크립트 작성
2. 요청 정의 및 시뮬레이션 설정
3. CLI에서 테스트 실행
4. HTML 리포트 분석
장점:
- 코드 기반으로 유지보수 용이
- HTML 리포트 자동 생성
- 효율적인 리소스 사용, 실시간 보고
단점:
- Scala 언어 학습 필요

3. Locust

서비스 예시: API 서버 부하 테스트
사용 방법:
1. Python 기반 스크립트 작성 (사용자 시뮬레이션)
2. 실행 후 웹 UI에서 실시간 모니터링
3. 결과 분석 및 튜닝
장점:
- Python으로 간단한 스크립팅 가능
- 분산 테스트 가능
단점:
- 그래픽 분석 기능 부족

4. k6

서비스 예시: 마이크로서비스 환경에서 API 성능 테스트
사용 방법:
1. JavaScript 기반 테스트 스크립트 작성
2. CLI에서 테스트 실행
3. Grafana 등과 연동하여 모니터링
장점:
- 클라우드 기반 테스트 가능
- CI/CD 파이프라인과 쉽게 연동 가능
단점:
- UI 없음, CLI 기반

5. AWS Load Testing

서비스 예시: AWS Lambda, API Gateway 부하 테스트
사용 방법:
1. AWS Fargate 또는 Lambda를 사용하여 테스트 설정
2. CloudWatch로 성능 모니터링
3. 결과 분석 후 리소스 조정
장점:
- AWS 환경에 최적화됨
- 별도 인프라 필요 없음
단점:
- AWS 서비스 종속적

요약

JMeter: 전통적인 부하 테스트 도구, 다양한 프로토콜 지원
- Apache JMeter를 이용한 부하 테스트 및 리포트 생성 : https://creampuffy.tistory.com/209
Gatling: 코드 기반 테스트에 적합
Locust: Python 기반의 가벼운 부하 테스트 도구
k6: JavaScript 기반, 클라우드 및 CI/CD 연동 최적화
AWS Load Testing: AWS 환경에서 부하 테스트에 적합

툴 선택 기준:

오픈소스 vs 상용: 예산 고려
- 오픈소스 부하테스트 툴 비교 2024 : https://testguild.com/load-testing-tools/
기술 스택: Python이라면 Locust, JavaScript라면 k6
테스트 환경: AWS라면 AWS Load Testing
jvm 위에서 동작하면 jmeter, ngrinder 무겁고 느릴 수 있다 -> k6, locust이 경량화
- k6 vs JMeter, 어느 성능 테스트 도구를 써야 할까? : https://velog.io/@yongtae923/k6-vs-JMeter#k6-%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A5%BC-%EC%9C%84%ED%95%9C-%ED%9A%A8%EC%9C%A8%EC%A0%81%EC%9D%B8-%EC%84%B1%EB%8A%A5-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EB%8F%84%EA%B5%AC
- Load Tests: Locust vs Jmeter : https://azevedorafaela.com/2020/05/23/load-tests-locust-vs-jmeter/

위에서는 어떤 툴이 있는지 개념이 뭔지 간단히 알아보았으니

좀 더 자세하게

https://it-roheerumi.tistory.com/195

[성능 테스트] 04. 부하 테스트 도구와 활용

# 학습 목표 시스템의 가용성과 확장성을 평가할 수 있다. 부하 테스트의 목적을 이해할 수 있다. Throughput과 Latency의 개념을 이해할 수 있다. 시스템의 병목이 발생하는 주요 원인과 대책을 이해

it-roheerumi.tistory.com

이 분의 정리를 참고했다

어떤 부분을 확장할 것인가? : 확장성에 대한 특징 파악

- Throughput은 시간당 처리량으로, 시스템의 성능 지표는 RPS(request per second), TPS(transaction per second)와 같은 단위로 표현됨

- Throughput은 데이터 전송량에 포커스를 맞춘 성능 지표

- 한편 볼륨의 성능을 측정할 경우에는 IOPS(Input/Output per second)라는 단위를 사용함
- 성능을 측정할 때는, 인프라 내의 구성요소(티어)로 구분된 각 요소를 구분하지 않고 통합해서, 특정 작업이 얼마만큼의 Throughput을 갖는지를 측정

확장할 때 고려할 수 있는 부분

1000rps에서 2000rps로 성능을 두 배 개선하기 위해서는, 웹서버를 확장해야 할까? DB 서버를 확장해야 할까?
시스템 구성 변경 시 다운타임은 얼마나 허용되는가? 서비스 정지 없이 가능한가?
현재 시스템에서 낼 수 있는 최대 성능(limit)은 어디까지인가?

부하가 많이 발생할 때 시스템에 일어나는 문제 요소

응답 속도 (latency = 처리 시간) 저하
시스템 잠금(lock) 경합
부하 발생시 애플리케이션 또는 서버 에러 발생
데이터 일관성 문제와 손실

-> 해결할 수 있을만큼의 부하 수용 범위를 파악해야 함

Throughput과 Latency

웹 애플리케이션 성능 지표로서 throughput 예

1초에 처리하는 HTTP 요청 수 (rps)
네트워크로 전송되는 데이터 전송 속도 (스트리밍 서비스와 같이 대역폭이 중요한 경우)

Latency

사용자가 어떤 웹페이지를 보기위한 Latency는 사용자의 인터넷 환경, 브라우저 등의 개별환경 변수가 존재함. 즉 네트워크를 통한 왕복 시간도 포함
하지만 성능 테스트를 진행할 때에는, 사용자 환경에 따른 변인을 통제하거나, 애초에 네트워크 상황을 고려하지 않고 테스트를 진행

부하테스트 계획

부하 테스트 전에 서비스 수준 목표(SLO)를 설정하는 것이 좋음 -> 척도 표준화 및 목표 설정

Latency에 중점을 둔 SLO 예시	Throughput에 중점을 둔 SLO 예시
- GET 호출의 90%는 1ms 이내에 완료해야 함 - GET 호출의 99%는 10ms 이내에 완료해야 함 - GET 호출의 99.9%는 100ms 이내에 완료해야 함	- throughput은 순간적으로 요청이 치솟는 peak 트래픽에서의 처리량을 바탕으로 함
	<1일 기준으로 RPS를 계산하고자 할 때의 시나리오 예시> - DAU 5만명, 1명당 평균 접속 횟수 20회 - 1일 평균 접속 수에 대한 피크 트래픽 배율 : 보통 평균의 2-3배 - 안전 계수 (얼마만큼 넉넉하게 프로비저닝 할 것인지) -> 3배 => 피크 트래픽 배율을 3배로 하고 계산하면 이 경우 하루가 총 86400초 이므로 RPS는 약 100RPS => 도출한 SLO : 서비스는 100RPS를 달성해야 함