Percentile, Histogram과 Coordinated Omission

Overview

p99는 관측값 99%가 그 값 이하였다는 뜻이지 최악이나 “99% 사용자”를 자동으로 뜻하지 않는다. Histogram 해상도와 측정 도착 모델이 틀리면 Tail Latency가 실제보다 좋아 보인다.

핵심 용어

왜 필요한가

평균 100ms라도 1%가 10초면 대규모 서비스에서 많은 사용자가 느림을 겪는다. 그러나 p99 하나도 요청 종류, Sample 수, Window, 실패 포함 여부가 다르면 비교할 수 없다.

핵심 원리와 내부 동작

Histogram은 원시 값을 모두 저장하지 않고 Bucket Count로 Percentile을 근사한다. 가장 높은 Bucket에 몰리면 정확한 Tail을 알 수 없으므로 SLO 주변 Bucket을 세밀하게 둔다. Open Model은 예정 도착률을 유지해 지연 중 생겼어야 할 요청을 표현한다.

sequenceDiagram; participant G as Closed Generator; participant S as Slow Server; G->>S: request; Note over S: 5초 정지; S-->>G: response; G->>S: next request; Note over G,S: 기다린 5초 동안 예정 요청이 생성되지 않아 누락

Example

100,000건이면 p99 바깥에 약 1,000건이 있다. p99=800ms만 말하지 말고 오류·Timeout 포함 여부, p99.9, 최대 Bucket, Sample 수를 함께 적는다. Timeout 5초 요청을 “실패”로만 세고 Latency에서 빼지 않는다.

실무에서 발생하는 문제와 Trade-off

너무 세밀한 Bucket은 Metric Cardinality/비용을 늘리고 거친 Bucket은 Tail을 뭉갠다. Instance별 p99를 평균내면 전체 p99가 아니다. 짧은 Window는 변동이 크고 긴 Window는 순간 장애를 희석한다.

흔한 오해

• p99는 최대값이 아니다.
• 99%의 고유 사용자가 만족했다는 뜻이 아니다. 한 사용자가 많은 Request를 만들 수 있다.
• Percentile끼리는 단순 평균할 수 없다.
• Timeout을 제외하면 느린 요청이 사라져 성능이 좋아 보일 수 있다.

Production Considerations

SLO 경계 중심 Bucket, Sample 수, Outcome Label을 설계한다. Client와 Server Histogram을 모두 보고 부하 발생기 CPU·Socket 포화를 감시한다. Open Model 또는 보정 가능한 Recorder를 사용하고 원시 결과를 보관한다.

다른 사람에게 설명한다면

30초: “p99는 요청 관측값 99%의 상한이며 최대값이 아닙니다. Bucket이 거칠거나 시스템이 느릴 때 Generator도 요청을 멈추는 Coordinated Omission이 있으면 Tail이 실제보다 좋아 보입니다. Timeout과 실패도 포함해 봐야 합니다.”

2분: 평균이 Tail을 숨기는 예, Histogram 근사, Closed Generator의 누락 Timeline, Bucket·Window·Sample 조건을 설명한다.

Interview Questions

1. p99는 무엇을 의미하고 무엇을 의미하지 않는가?
2. Instance별 p99 평균이 잘못인 이유는?
3. Coordinated Omission은 어떻게 생기는가?
4. Timeout 요청을 어떻게 집계할 것인가?

Related Topics

Latency·TPS·RPS, 부하 테스트를 함께 본다.