처리량(Throughput)

처리량은 시스템이 단위 시간당 얼마나 많은 작업을 해내는지를 나타냅니다. API라면 초당 요청 수(RPS), 결제 시스템이라면 초당 트랜잭션 수(TPS), 큐 컨슈머라면 초당 메시지 수입니다. 처리량은 용량을 측정하고, 지연 시간(latency)은 개별 작업 하나에 걸리는 시간을 측정합니다. 성능을 설명하려면 이 둘에 오류율까지 모두 필요합니다.

처리량, 지연 시간, 동시성의 관계

안정 상태의 시스템에서는 리틀의 법칙(Little’s Law)이 세 값을 연결합니다.

concurrent requests in flight = throughput × average response time

Example: 200 requests/second × 0.25 seconds = 50 requests in flight

동작 사이에 쉬는 가상 사용자를 쓰면 think time(사용자 대기 시간)이 한 사이클에 더해집니다. 즉 처리량 ≈ 사용자 수 ÷ (응답 시간 + think time)입니다. 따라서 응답 시간 0.5초, think time 4.5초인 사용자 100명은 초당 100건이 아니라 약 20건의 요청을 만들어 냅니다. “사용자 1,000명으로 테스트했다”는 말이 think time과 그 결과 나온 요청률을 함께 밝히기 전까지는 별 의미가 없는 이유가 여기에 있습니다.

부하가 늘어날 때 처리량의 모습

부하가 늘면 처음에는 처리량도 그에 맞춰 올라갑니다. 그러다 어느 시점에 CPU, 커넥션 풀, 싱글 스레드 컴포넌트 같은 자원이 포화되면 처리량은 평평해지고 지연 시간은 가파르게 오릅니다. 더 밀어붙이면 시스템이 큐잉, 재시도, 타임아웃에 힘을 쓰느라 처리량이 오히려 떨어질 수 있습니다. 이 정체 구간을 찾는 것이 스트레스 테스트의 주된 결과물이며, 이것이 실질적인 용량을 정의합니다.

테스트 팁

• 목표는 처리량과 지연 시간을 함께 정하십시오. “p95 300ms 미만, 오류 1% 미만으로 500 RPS”는 테스트할 수 있지만 “높은 트래픽을 감당한다”는 테스트할 수 없습니다.
• 성공한 작업만 세십시오. 2,000 RPS에 응답하더라도 그중 절반이 500 오류라면, 유용한 작업을 2,000 RPS 처리하고 있는 것이 아닙니다.
• 가능하면 도착률(arrival-rate) 기반 부하를 쓰십시오. 고정된 요청률을 생성하면 시스템이 그 속도를 유지할 수 있는지 바로 드러납니다. 고정된 사용자 풀은 응답이 느려지면 조용히 요청을 덜 보냅니다.
• 부하 생성기를 점검하십시오. 테스트를 돌리는 머신의 CPU가 100%라면, 측정한 것은 시스템이 아니라 부하 생성기의 처리량입니다.
• 레이트 리밋에 유의하십시오. 게이트웨이가 429를 반환하면 측정되는 처리량에 상한이 생깁니다. 리미터를 테스트하는지, 그 뒤의 서비스를 테스트하는지 정하십시오.