지연 시간과 처리량 (p50/p95/p99)

평균은 느린 요청을 숨깁니다. 그리고 사용자는 평균을 경험하지 않습니다.

응답이 100밀리초인 요청 99개와 10초인 요청 1개가 있으면 평균은 199밀리초입니다. 지표는 건강해 보이지만 100명 중 1명은 10초를 기다립니다.

한 화면이 여러 API 를 부르면 더 커집니다. API 10개를 부르는 화면이라면 각 API 의 p99 가 1%여도 화면 하나가 느릴 확률은 10%에 가깝습니다. 개별 지표가 좋아 보여도 사용자 체감은 그렇지 않은 이유입니다.

흔한 실수: p99 를 목표로만 두고 p50 을 버리는 것. p50 이 나쁘면 전원이 느린 것이고 원인이 다릅니다. 둘을 함께 봐야 어떤 문제인지 구분됩니다.

전체가 느린 것이 아니라 일부 요청만 느린 것입니다. 그 일부의 공통점을 찾습니다.

순서는 분해하기 쉬운 것부터입니다. 서버별, 엔드포인트별, 사용자별로 나눠 보면 대개 한쪽에 몰려 있습니다. 몰려 있지 않고 고르게 흩어져 있으면 GC 나 잠금처럼 시점 의존적인 원인입니다.

흔한 실수: 평균 자원 사용률을 보고 여유 있다고 판단하는 것. p99 문제는 순간적인 경합이라 1분 평균에서는 보이지 않습니다. 짧은 간격의 지표나 트레이스를 봐야 합니다.

자원이 포화에 가까워지면 대기 줄이 생기기 때문입니다. 대기 시간은 이용률이 100%에 가까워질수록 급격히 늘어납니다.

그래서 처리량과 지연은 함께 좋아지지 않습니다. 처리량을 끝까지 끌어올리면 지연은 반드시 나빠집니다.

대응은 이용률에 여유를 두는 것입니다. 목표를 60에서 70% 정도로 잡고 그 이상이면 증설합니다. 그리고 처리량 목표와 지연 목표를 함께 정합니다.

흔한 실수: 부하 테스트에서 초당 처리량 최대치만 보고 용량을 정하는 것. 그 지점은 이미 지연이 무너진 곳입니다. 지연 목표를 만족하는 최대 처리량이 실제 용량입니다.

평균하면 안 됩니다. 백분위수는 평균할 수 없는 값입니다.

서버 A 의 p99 가 100밀리초, B 가 500밀리초라고 해서 전체 p99 가 300밀리초인 것이 아닙니다. 전체 p99 는 두 서버의 요청을 모두 합친 분포에서 다시 계산해야 합니다.

실무에서는 두 번째를 씁니다. 각 서버가 구간별 건수를 히스토그램으로 보고하면 그것을 더해 전체 분포를 만들 수 있습니다. 이것이 합산 가능한 형태로 지표를 남기는 이유입니다.

흔한 실수: 대시보드가 서버별 p99 를 평균해서 보여주는데 그것을 전체 p99 로 읽는 것. 한 서버만 나쁠 때 그 값이 희석되어 문제가 감춰집니다.