Latency와 Throughput

Overview

Latency는 한 요청이 끝나는 시간이고 Throughput은 일정 시간에 완료한 요청 수다.

핵심 원리

평균만 보면 긴 꼬리 지연을 놓치므로 p95, p99와 오류율을 함께 본다.

flowchart LR; I[Incoming Rate] --> S[System]; S --> O[Completion Rate]; S --> Q[Queue]

실무에서 발생하는 문제

평균만 보면 일부 사용자의 긴 대기가 숨는다. Queue가 쌓이면 처리량이 잠시 유지돼도 P99와 Timeout이 급격히 악화되고 재시도가 추가 부하를 만든다.

Trade-off

Batching과 병렬성은 처리량을 높일 수 있지만 개별 지연, Memory, 순서 제어 비용을 늘린다. 서비스 목표는 평균이 아니라 SLO와 허용 가능한 Tail로 정한다.

흔한 오해

낮은 평균 Latency와 높은 처리량이 항상 함께 움직이지 않는다. 측정 구간, 동시 사용자, 실패 요청 포함 여부가 다르면 숫자를 직접 비교할 수 없다.

Interview Questions

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

왜 필요한가

Latency는 한 작업의 완료 시간, Throughput은 단위 시간의 완료량이다. Capacity 한계에 가까워질수록 Queue 대기가 급증하므로 두 지표를 Saturation과 함께 봐야 한다.

내부 동작

요청 도착률이 처리율보다 높으면 Queue가 계속 늘어난다. 평균 동시 작업 수는 Little's Law의 L = λW로 관계를 설명할 수 있다. 병렬화는 직렬 구간과 공유 자원 한계 때문에 무한히 확장되지 않는다.

Example

초당 100요청이 각각 평균 200ms 머문다면 시스템 안 평균 요청은 약 20개다. P99가 2초라면 일부 구간에서 훨씬 큰 동시성·자원 점유가 생기므로 평균만으로 Pool을 잡지 않는다.

Production Considerations

P50/P95/P99, RPS, Error Rate, Queue Depth, CPU/Memory/Connection을 같은 시간축으로 본다. Client와 Server Histogram의 범위와 단위를 맞추고 Timeout·취소 요청도 지표에 포함한다.

Related Topics

부하 테스트, Connection Pool, Observability로 측정과 용량 계획을 연결한다.