정의
서비스에 현실적인 트래픽을 걸어 성능·안정성 한계를 측정하는 실험입니다.
“서버가 잘 돌아간다”는 말은 모호합니다. 부하테스트는 이 모호함을 수치로 바꾸는 과정입니다. 예를 들어 “초당 300 요청까지는 p95 200ms 안에 처리, 500 요청부터는 오류율 증가”처럼 용량(capacity)을 숫자로 확정합니다.
특히 백엔드 실무에서는 신규 기능 출시, 인프라 변경(캐시/DB/로드밸런서), 트래픽 급증 이벤트(프로모션/공고/이벤트) 전에 장애를 미리 재현하고 병목을 찾아내는 목적이 큽니다.
핵심 메시지
“부하테스트의 목표는 서버를 괴롭히는 것이 아니라,
병목을 드러내고 개선 후 다시 검증하는 것이다.”
부하테스트에서 보는 지표
성능은 평균이 아니라 분포(Percentile)로 봅니다.
💡 TIP / 참고사항
평균 응답시간이 50ms라도 p99가 3초면 “사용자는 느리다”고 느낍니다.
그래서 부하테스트는 보통 p95/p99를 기준으로 합격/불합격을 판단합니다.
부하테스트 종류
부하테스트는 목적에 따라 시나리오가 달라집니다.
📌 Load Test
- 현실 트래픽 수준에서 성능/지표 확인
- “우리 서비스는 RPS 몇까지 가능한가?”
🔥 Stress Test
- 한계를 넘겨서 언제/어떻게 무너지는지 확인
- 장애 패턴(타임아웃, 5xx, 큐 적체)을 관찰
⏳ Soak Test
- 오래(수시간~수일) 트래픽을 유지해 누수/열화를 확인
- 메모리 릭, 커넥션 누수, GC 악화 같은 “시간 기반 문제”
실전 절차
부하테스트는 “가설 → 실험 → 분석 → 개선 → 재검증” 루프입니다.
1
목표(SLO)부터 정한다 예: p95 200ms 이하, 오류율 0.1% 이하, 목표 RPS 300
2
시나리오(사용자 행동)를 만든다 로그인→조회→결제처럼 실제 비율(읽기/쓰기)을 반영
3
부하를 점진적으로 올린다(Ramp-up) 갑자기 올리면 원인 분리가 어려움 (캐시 워밍업도 고려)
4
관측(Observability)을 켠다 APM/로그/메트릭으로 CPU·GC·DB 커넥션·슬로우쿼리 확인
5
병목을 개선하고, 같은 시나리오로 재검증한다 성능 개선은 “전/후 비교”로 증명해야 함
💡 TIP / 참고사항
부하테스트에서 “서버 CPU 30%인데 느려요” 같은 상황이 자주 나옵니다.
이때는 대개 DB 커넥션 풀 고갈, 외부 API 타임아웃, 락 경합, GC, 스레드 풀 대기가 원인입니다. (CPU만 보고 판단하면 놓칩니다.)
실제 예시 (간단 시나리오)
“조회 80% + 생성 20%” 같은 현실 비율을 반영합니다.
// (개념 예시) 부하테스트 시나리오 구성 아이디어
// - 80%: GET /articles (조회)
// - 20%: POST /articles (생성)
// - Ramp-up: 1분에 50 → 100 → 200 RPS로 증가
// - 목표: p95 200ms, error rate < 0.1%
// 테스트에서 반드시 같이 봐야 하는 것
// 1) 서버: CPU, Heap, GC time, Thread pool queue
// 2) DB: connection pool, slow query, lock wait
// 3) 네트워크: timeout, retry, 외부 API latency
👍 GOOD (부하테스트가 잘된 상태)
- SLO(목표 지표)가 숫자로 명확함
- 현실 시나리오(트래픽 비율/데이터 분포)를 반영
- 관측 지표(APM/로그/메트릭)로 원인 추적 가능
- 개선 전/후 결과가 비교 가능하게 기록됨
👎 BAD (자주 망하는 패턴)
- 목표 없이 “일단 때려본다” → 결과 해석 불가
- 실서비스와 다른 데이터/캐시 상태로 테스트
- timeout/retry 설정이 달라 장애가 과장/왜곡
- 관측 없이 결과만 보고 “서버 증설”로 결론
✅ 핵심 요약
- ✔️ 부하테스트는 현실 트래픽으로 성능/안정성 한계를 측정하는 실험이다.
- ✔️ 핵심 지표는 RPS(처리량), p95/p99(지연), 오류율이며, 평균만 보면 안 된다.
- ✔️ “가설→테스트→병목 분석→개선→재검증” 루프로 결과를 전/후 비교할 수 있어야 한다.
728x90