Alice는 기다림을 싫어합니다

 (brooker.co.za)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 서비스 평균 요청 시간이 100ms이고 MTTR이 1분 미만이어도, 사용자는 긴 요청과 긴 장애에 더 오래 갇히기 때문에 평균 대기 시간을 훨씬 길게 느낌
  • 운영자는 요청·장애를 사건 단위로 집계하지만, Alice와 Alex 같은 사용자는 초·분 단위의 체감 시간으로 기다림을 계산함
  • 이 차이는 검사 역설(inspection paradox) 때문이며, 사용자가 경험하는 분포는 원래 지연 분포 f(t)가 아니라 t로 가중된 분포가 됨
  • 복구 시간 중앙값이 30분, p99가 600분인 로그정규 분포에서는 MTTR이 1시간을 조금 넘는 수준이어도 고객 체감 평균 복구 시간은 약 6시간까지 늘어남
  • 꼬리 지연과 긴 복구 시간은 고객 경험을 지배할 수 있으며, 절단 평균(trimmed mean)은 오른쪽 꼬리의 중요한 정보를 버릴 위험이 있음

요청 단위 평균과 사용자 체감 평균의 간극

  • Alice는 웹 서비스를 사용하며, 대부분의 사람처럼 시간을 초와 분으로 느낌
  • 운영자는 평균 요청이 100ms에 완료된다고 보지만, Alice의 평균 대기 시간은 1초가 될 수 있음
  • 장애에서도 같은 차이가 생김
    • 운영자는 MTTR이 1분 미만이라고 말할 수 있음
    • Alex가 체감하는 평균 장애 시간은 1시간일 수 있음
  • 두 측정은 동시에 맞을 수 있음
    • 긴 요청이나 긴 장애는 운영자 집계에서는 하나의 사건임
    • 사용자의 시간에서는 지속된 길이만큼 더 큰 비중을 차지함

검사 역설이 만드는 t-가중 분포

  • 이 현상은 검사 역설로 볼 수 있음
  • 사용자는 지연 분포 f(t) 자체가 아니라, t로 가중된 버전을 경험함
  • MTTR 또는 평균 요청 시간이 E[X]일 때 사용자가 경험하는 평균은 다음과 같음
    • E_a[X] = E[X²] / E[X]
    • E_a[X] = E[X] + Var(X) / E[X]
  • 분산이 클수록 사용자가 체감하는 평균은 운영 지표의 평균보다 더 크게 벌어짐

30분 중앙값과 600분 p99 예시

  • 중앙값 지연 또는 복구 시간과 99퍼센타일 값을 넣으면 로그정규 분포를 맞추고, 서비스 지표와 고객 체감 값을 비교할 수 있음
  • 예시 값은 다음과 같음
    • 중앙값 TTR: 30분
    • p99 TTR: 600분, 즉 100개 이벤트 중 1개는 복구에 10시간 걸림
  • 이 경우 MTTR은 1시간을 조금 넘지만, 고객이 경험하는 평균 복구 시간은 약 6시간이 됨

꼬리 지연과 절단 평균의 함정

  • 꼬리 지연과 긴 복구 시간을 이해해야 하는 이유는 여러 가지가 있으며, multiple samples도 그중 하나임
  • 서비스 시간에서는 타임아웃 후 재시도(timeout-and-retry) 가 일부 지연을 숨길 수 있음
    • 단, 실행 중인 요청이 락이나 다른 독점 리소스를 잡고 있지 않아야 함
  • 복구 시간에는 이런 숨김이 불가능해 꼬리의 두꺼움이 고객 경험에 더 직접적으로 드러남
  • trimmed mean 같은 절단 측정값은 고객 경험을 지배하는 오른쪽 꼬리의 형태를 가리는 문제가 있음
  • 절단 측정값을 선호하지 않는 또 다른 이유는 Little’s Law와 용량 사용량과 관련되며, 관련 글은 이전에 다룬 글에 있음

로그정규 분포 사용에 대한 주의

  • 로그정규 분포는 수치 계산 편의를 위해 선택됨
  • lognormal(μ, σ²)가 lognormal(μ + σ², σ²)가 되는 성질이 있고, 0 근처에서 잘 동작함
  • 지연이나 복구 시간 지표에 로그정규 분포가 특히 좋은 선택이라고 보기는 어려움
  • 이런 문제는 일반적으로 비모수적 방식으로 접근하는 편이 낫다고 봄

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 제목을 Latency and the inspection paradox처럼 더 정보가 있는 쪽으로 바꾸는 게 나을 듯함
    지금 제목은 사실상 전달하는 정보가 0에 가깝다 😅

    • 저자 입장에서는 약간 모호한 제목이 꽤 유용함
      제목만 읽고 본문은 안 읽은 사람들의 답글을 줄여주기 때문임

  • 흥미롭지만, 저자가 왜 이게 참인지 t-weighted라는 용어와 수식 말고는 설명하지 않아서 잘 이해가 안 됨
    대학 통계 수업을 오래전에 잊어버린 사람도 이해할 수 있게 더 명확히 설명해줬으면 좋겠음

    • 모니터링 대시보드가 있다고 해보면, 보통은 모든 요청을 동일하게 취급해서 평균 지연 시간을 계산함 
      mean = (sum of all latencies) / (number of requests)
      이게 E[X]이고, 각 요청의 가중치는 1/N임
      Alice가 체감하는 지연 시간은 시간 기준이라서, 아마 여기서 시간 가중(t-weighted) 이 나온 것 같음
      Alice가 지연 시간이 x_1, x_2, ..., x_M인 M개의 요청을 보냈다고 하면, “Alice의 전체 대기 시간 중 임의의 1초를 골랐을 때, 그 순간 기다리고 있는 요청의 지연 시간은 얼마인가?”라고 물을 수 있음
      이때 요청 i는 x_i / (Σ_j x_j)만큼 기여하므로 긴 요청일수록 더 많이 반영됨
      그래서 시간 가중 평균은 다음과 같음 
      E_a[X] = Σ_i x_i (x_i / Σ_j x_j) = Σ_i x_i^2 / Σ_j x_j  
= (Σ_i x_i^2 / N) / (Σ_j x_j / N)  
= E[X^2] / E[X]
      간단한 예로, 지연 시간이 1초인 요청 하나와 10초인 요청 하나가 있으면 일반 평균은 5.5초지만, 시간 가중 평균은 1 * (1 / 11) + 10 * 10 / 11 = 9.18s가 됨

  • 관련해서 The Inspection Paradox is Everywhere 도 볼 만함

  • 나도 실제로 비슷한 생각을 해본 적이 있음
    이 문제를 이해하기 가장 쉬운 예는 버스 승객에게 버스에 몇 명이 타고 있는지 묻는 조사라고 봄
    그러면 “버스가 꽉 찼다”는 답은 훨씬 많이 얻지만, 버스가 비어 있을 때는 누구에게도 물을 수 없음
    모든 버스가 비어 있고 딱 한 대만 붐빌 수도 있음
    목표가 사용자 관점에서 상황을 분석하는 것이라면 이 통계가 맞다고 생각함

    • 그래프 이론에도 비슷한 결과가 있는데, 거의 모든 사람의 친구들은 자기보다 친구가 더 많다는 것임
      연결이 많은 노드는 연결이 적은 노드보다 다른 노드의 인접 리스트에 더 자주 등장하기 때문임

  • 이 주제가 와닿는다면 Gil Tene's "How not to measure latency"를 강력히 추천함

답변달기