부하테스트 개념 및 부하테스트 툴 종류
부하테스트란?
시스템이 얼마나 많은 트래픽이나 요청을 안정적으로 처리할 수 있는 지 테스트 하는 것입니다.
서비스를 운영에 배포하기 전이나 특정 이벤트를 앞두고 있을 때 부하테스트를 진행하면,
얼마나 많은 사용자 요청을 안정적으로 처리할 수 있는지 미리 파악할 수 있습니다.
부하테스트 활용 사례
트래픽이 늘어나서 서버가 터져서 죽는 것을 미리 감지하고 대처할 수 있습니다.
예를 들어, 초당 100개의 사용자 요청만 감당 가능한 시스템이라면
사용자 요청 수가 80개로 올라갈 쯤 서버 사양 업그레이드를 고려해볼 수 있습니다.
오버 스펙 고사양 컴퓨터로 트래픽을 처리하면 서버 비용이 크기 때문에
필요한 만큼의 적절한 컴퓨터 사양을 선택하는 것이 중요합니다.
처리량 (Throughput)
부하테스트에서 시스템이 단위 시간 동안 실제로 처리한 요청/트랜잭션 수입니다.
단위는 TPS (초당 처리한 트랜잭션 수) 또는 RPS (초당 처리한 요청 수)를 많이 사용합니다.
1초에 최대 100개의 API 요청을 처리하는 서비스의 최대 쓰루풋은 100 RPS입니다.
전체 시스템 최대 처리량 개선 방법
시스템 전체 인프라에서 처리량이 가장 낮은 병목 지점에 의해 최대 처리량이 제한됩니다.
병목이 아닌 구간은 개선해도 전체 시스템 최대 처리량이 증가하지 않습니다. ★
요청이 밀리며 처리량 정체 구간이 발생하는 병목 지점을 찾아 개선해야 합니다.
병목 지점의 최대 처리량이 전체 시스템의 최대 처리량을 제한하는 예시
백엔드 서버가 초당 1,000개 요청, 병목 지점인 DB가 초당 300개 요청을 처리할 수 있는 경우
1초에 1,000개의 요청이 들어온다면, 700개의 초과 요청은 대기하거나 처리되지 못하므로
전체 시스템의 최대 처리량은 300 RPS로 제한됩니다.
지연시간 (Latency)
API에 요청을 보낸 시점부터 응답을 받을 때까지 걸리는 시간을 의미합니다.
부하테스트에서 평균 응답 시간이 2.5초면 평균 레이턴시가 2.5초라고 표현합니다.
시스템 전체 인프라에서 순차 처리되는 각 구간의 지연시간이 누적되어 전체 레이턴시에 영향을 줍니다.
p95/p99 레이턴시
- p95 = 500ms : 전체 요청 중 95%의 응답시간이 500ms 이하
- p99 = 1000ms : 전체 요청 중 99%의 응답시간이 1초 이하
가용성 (Availability, 서비스 정상 가동률)
가용성이 99.99%인 시스템은 1년에 약 53분 정도의 서비스 중단이 발생할 수 있습니다.
시스템 이중화 설계를 하면, 장애가 발생해도 서비스 다운 타임을 크게 줄이고 가용성을 높일 수 있습니다.
병목 지점 (Bottleneck Point)
전체 시스템의 처리량이나 응답 속도를 제한하여 전체 성능 저하에 가장 큰 영향을 주는 구간입니다.
DB 쿼리, 디스크 I/O, 네트워크, 커넥션 풀, 락 경합, 외부 API 등도 병목이 될 수 있습니다.
전체 시스템 성능을 효과적으로 개선하려면 정체가 발생한 병목 지점을 찾아 우선적으로 개선해야 합니다.
특정 병목 지점 성능을 개선하면, 다른 곳에서 새로운 병목 지점이 발생할 수 있습니다.
부하테스트 진행 방법
부하테스트 목표 설정
부하테스트는 예상 접속자 수, 요청량을 기반으로 목표 쓰루풋을 설정하고 진행합니다.
서비스 특성에 맞게 목표 평균 레이턴시와 p95/p99 레이턴시도 함께 설정하는 것이 좋습니다.
시스템에 목표 수준의 부하를 가했을 때, 목표 처리량을 안정적으로 처리하면서
사용자 요청에 대한 응답 시간 등 성능 기준을 만족하는지 확인하는 것을 목표로 합니다.
부하테스트 진행 시 주의사항
1분 간격으로 기록되는 모니터링 도구로 일관된 결과값을 얻어서 정확한 성능을 측정하려면,
충분한 측정 구간을 확보할 수 있도록 5분 이상 부하를 유지하는 것이 좋습니다.
데이터베이스는 저장된 데이터 양, 인덱스 상태 등에 따라 성능 차이가 많이 나므로
운영 환경과 비슷하게 데이터를 구성해두고 부하테스트를 진행해야 정확한 결과값을 얻을 수 있습니다.
운영 DB 복제본을 떠서 부하테스트를 진행하기도 합니다.
운영 환경에서 부하테스트를 하면 실제 서비스 성능에 악영향을 끼칠 수 있기 때문에,
운영과 분리된 독립적인 환경을 구성하여 부하테스트를 진행해야 합니다.
부하테스트 결과해석 및 성능 개선 후 재진단
목표 쓰루풋을 2000 TPS로 설정하였는데, 부하테스트 진행 중 결과 해석 시
현재 시스템 최대 쓰루풋이 1500 TPS로 확인되면 병목 지점 파악 및 성능 개선이 필요합니다.
병목 지점을 개선해야 전체 시스템의 최대 처리 성능을 높일 수 있습니다. ★
개선 후 다시 부하테스트를 진행하여, 2000 TPS에서 목표 레이턴시와 실패율도 만족하는지 확인하면 좋습니다.
설정했던 목표치를 달성할 때까지 병목 지점 개선 및 부하테스트를 반복하면 됩니다.
목표치에 도달하면 최종 검증 후 해당 시스템 구조를 실제 서비스 환경에 적용할 수 있습니다.
병목 지점 찾는 방법
전체적인 트래픽 흐름을 한 눈에 파악할 수 있도록 인프라 전체 구성을 그림으로 그려둡니다.
부하테스트 후 시스템 성능 개선을 하려면 병목 지점을 찾는 게 핵심이므로,
트래픽이 거쳐가는 인프라 아키텍처 구성을 파악하면 좋습니다.
부하테스트 진행 중 인프라 구성 요소들을 실시간으로 모니터링하면 병목 지점을 찾을 수 있습니다.
처리량 정체, 레이턴시 증가 등이 발생하는 시점에 CPU, 메모리 메트릭 등을 확인합니다.
부하테스트 중 사용률이 한계에 가깝게 측정되는 특정 자원이 병목 지점일 가능성이 높습니다.
https://0songha0.github.io/test/2026-08-19-1
AWS CloudWatch 등 모니터링 도구를 사용하면 병목 지점을 한눈에 파악하기 좋습니다.
EC2 서버가 병목 지점인 경우 성능 개선 방법
- 애플리케이션 로직에서 비효율적인 코드 개선
- 정적 파일 서버 분리 (S3, Cloudfront 등)
- 로드밸런서 활용하여 수평적 확장 (서버 이중화)
- 수직적 확장
RDS가 병목 지점인 경우 성능 개선 방법
- 비효율적인 SQL 쿼리 튜닝
- 인덱스 활용
- 필요에 따른 역정규화
- 캐시 서버 도입 (ElastiCache, Redis 등)
- 수직적 확장
- 읽기 전용 DB 도입 (Read Replica)
시스템 성능 개선 전략
수평적 확장 (스케일아웃)
서버 수를 확장하고 로드밸런서를 통해 트래픽을 분산하여 처리 성능과 가용성을 높이는 방식입니다.
수직적 확장 (스케일업)
CPU, 메모리 등 서버 사양을 업그레이드하는 방식입니다.
확장 시 다운타임이 발생할 수 있으며, 하드웨어 사양에 따른 확장 한계가 있습니다.
캐싱
자주 사용되는 데이터, 콘텐츠를 메모리, CDN 등 임시 공간에 저장해두는 방식입니다.
원본 데이터가 있는 곳까지 가지 않고 더 빠르게 조회할 수 있습니다.
Redis로 데이터를 메모리에 캐싱하거나, CloudFront 등 CDN으로 S3 파일을 사용자와 가까운 엣지 서버에 캐싱할 수 있습니다.
ElastiCache 등 캐시 서버에 DB 조회 결과를 저장해두고, 같은 요청 시 캐시에서 응답하면 DB 부하도 줄일 수 있습니다.
DB 성능 개선
인덱스 활용, SQL 튜닝, 필요에 따른 역정규화 등을 우선 적용하여 DB 성능 개선을 하는 것이 좋습니다.
데이터베이스를 여러 대로 확장하면 데이터 복제에 따른 부하가 증가할 수 있으므로,
DB 사양을 높이고도 추가적인 성능 개선이 필요하거나 읽기 요청이 많은 경우 읽기 전용 DB 도입을 고려합니다.
최신 데이터 즉시 반영이 필요하지 않은 읽기 쿼리는 복제 지연이 발생할 수 있는 Read Replica를 주로 활용합니다.
부하테스트 툴 종류
부하테스트 툴으로 K6, nGrinder, JMeter, Locust, ab 등이 있습니다.
부하테스트 원리를 이해하면 툴 사용법이나 성능 지표를 분석하는 방식은 비슷합니다.
부하테스트 도구는 부하를 발생시키고 데이터를 수집하는 수단이므로
어떤 툴을 사용하는지보다 결과 데이터를 정확하게 해석하고,
병목 지점을 찾아 적절한 방식으로 성능을 개선하는 역량이 더 중요합니다.
K6
적은 리소스로 많은 가상 사용자를 생성하여 많은 요청을 보낼 수 있는 부하테스트 툴입니다.
사용법이 간단해 쉽게 테스트 가능하고 정확도가 높아 현업에서 많이 사용됩니다.