Load Testing

Overview

높은 숫자를 만드는 행사가 아니라 예상 Workload에서 병목과 회복 능력을 확인하는 실험이다.

핵심 용어

핵심 원리

목표와 SLO, Workload Model, 관찰 Metric, Ramp-up, 병목 가설, 재시험 순서로 진행한다.

flowchart TD; G[Goal and SLO] --> W[Workload]; W --> M[Metrics]; M --> R[Ramp Up]; R --> B{Bottleneck}; B --> E[Evidence and Retest]

실무에서 발생하는 문제

현실과 다른 데이터 분포, Warm-up 누락, 부하 발생기 포화는 잘못된 결론을 만든다. 오류 요청을 처리량으로 세거나 Coordinated Omission으로 긴 지연을 놓칠 수도 있다.

Trade-off

큰 한 번의 Test는 최대치를 찾기 쉽지만 원인 분리가 어렵다. 단계적 부하는 변곡점과 복구를 보여주지만 Scenario와 관측 준비가 필요하다.

흔한 오해

목표 RPS를 달성했다는 사실만으로 성공이 아니다. Error Rate, Tail Latency, 데이터 정합성, Test 종료 후 Queue 회복까지 SLO 안이어야 한다.

다른 사람에게 설명한다면

30초: “부하 테스트는 RPS 숫자 경쟁이 아니라 실제 Workload에서 SLO를 지키는 최대 지점과 실패 방식을 찾는 실험입니다. p99·오류율뿐 아니라 Queue, Pool, DB와 발생기 포화도 함께 봅니다.”

2분: Open/Closed Model, Ramp-up·Spike·Soak, 중단 기준과 동일 조건 Before/After, Attempt가 아닌 Success TPS 해석을 설명한다.

Interview Questions

• 이 기술이 해결하는 핵심 문제는 무엇인가?
• 내부에서는 어떤 순서로 동작하는가?
• 운영 환경에서 어떤 지표와 실패 모드를 확인해야 하는가?

왜 필요한가

Production 이전에 Capacity 변곡점과 병목, 과부하 시 실패 방식을 확인한다. 정상 부하뿐 아니라 Spike, Soak, Dependency 지연, Cold Cache를 재현한다.

내부 동작

Open Model은 외부 도착률을 유지하고 Closed Model은 가상 사용자가 응답 뒤 다음 요청을 보낸다. 느려질 때 Closed Model의 실제 도착률이 줄 수 있으므로 목적에 맞게 선택한다. 부하 발생기 자체 CPU/Network도 감시한다.

Example

50→100→200 RPS로 단계 상승시키며 각 단계에서 10분 안정화한다. P99, 오류, Queue, Pool, DB 지표를 기록하고 중단 기준을 넘으면 즉시 종료한다. Test 데이터는 Hot Key와 일반 분포를 구분한다.

Production Considerations

운영과 같은 Timeout, Retry, 데이터 크기, Cache 상태를 사용한다. Test가 외부 시스템이나 실사용자에게 영향을 주지 않게 격리하고, 결과에는 Version·환경·Scenario·원시 지표를 남겨 재현 가능하게 한다.

Related Topics

Latency와 Throughput, Connection Pool, Redis 캐시 전략을 함께 검증한다.