평균은 아무것도 의미하지 않는다: 지연 시간 문제를 디버깅하는 데이터 시각화
The mean means nothing: data visualization to debug a latency problem
새로운 캐시 계층을 도입한 후 평균 지연 시간이 오히려 증가하자 우리는 회기를 결정했다. 하지만 백분위수와 CDF(누적 분포 함수) 를 분석하니, 실제 대다수 요청은 빨라졌지만 일부는 훨씬 느려진 이중 분포가 드러났다. 단일 숫자만 믿으면 중요한 사실을 놓칠 수 있다. 데이터의 전체적인 모양을 시각화해야 진짜 원인을 파악할 수 있다.
두 개의 CDF 곡선이 교차하는 것은, 단일 백분위수로 요약할 수 없는 변화의 확실한 신호이다.
HN 토론
17- tzone
개인적으로 생각하기에, 평균은 수집할 수 있는 통계치 중 가장 해로운 것 중 하나입니다. 평균이 유용한 유일한 용도는 총 처리량(total throughput)을 구하는 것이므로, 그 목적으로만 총 처리량 통계치를 수집하는 것이 훨씬 낫습니다. 총 처리량은 평균과 달리 혼란을 주거나 수많은 실수를 유발하지 않기 때문입니다.
평균 통계치에는 많은 문제가 있습니다. 사람들이 자주 오해한다는 점뿐만 아니라, 수집과 그래프화 과정에서도 문제가 발생합니다. 사람들이 종종 최종 그래프를 평균들의 평균과 같은 형태로 만들어버리는데, 이렇게 되면 더욱 쓸모없고 완전히 무의미해집니다.
메트릭/모니터링 시스템이 적절한 분포나 백분위수를 수집하고 그래프로 그릴 수 없다면, 반드시该系统를 변경해야 합니다.
- danbruc
CDF 대신 저는 1에서 CDF를 뺀 값을 선호합니다. 이는 특정 시점에 아직 완료되지 않은 요청의 비율입니다. 이렇게 하면 로그-로그 플롯을 그려서 CDF에서는 보이지 않던 꼬리 부분의 세부 사항까지 모두 보여줄 수 있습니다. CDF에서는 꼬리 부분이 본질적으로 1에 수평선으로 나타나기 때문입니다.
- ndr
중앙값도 99/100 백분위수보다 더 큰 오류를 일으킵니다. 많은 워크로드에서 동일한 클라이언트가 여러 개의 병렬 요청을 보내고, 종종 가장 느린 요청을 기다리기 때문입니다.
Jeff Dean 의 글 [0] 을 참조하세요.
인용:
""
규모에 의해 증폭되는 컴포넌트 수준의 변동성
대규모 온라인 서비스에서 지연 시간을 줄이는 일반적인 기법은 여러 다른 머신에 걸쳐 하위 작업을 병렬화하는 것입니다. 여기서 각 하위 작업은 대규모 데이터셋의 일부와 함께 배치됩니다. 병렬화는 루트에서 수많은 리프 서버로 요청을 분산시키고, 요청 분배 트리를 통해 응답을 병합함으로써 이루어집니다. 이러한 하위 작업들은 서비스가 반응적으로 느껴지기 위해 엄격한 기한 내에 모두 완료되어야 합니다.
개별 컴포넌트의 지연 시간 분포에 있는 변동성은 서비스 수준에서 증폭됩니다. 예를 들어, 각 서버가 일반적으로 10ms 에 응답하지만 99 백분위수 지연 시간이 1 초인 시스템을 고려해 봅시다. 사용자 요청이 이러한 서버 중 하나에서만 처리된다면, 100 건의 사용자 요청 중 1 건이 느리겠지요(1 초). 여기의 도표는 이 가상의 시나리오에서 서비스 수준의 지연 시간이 지연 시간의 극단적인 값(outliers)의 아주 작은 비율에 의해 어떻게 영향을 받는지 설명합니다. 사용자 요청이 100 개의 이러한 서버에서 응답을 병렬로 수집해야 한다면, 사용자 요청의 63% 가 1 초 이상 걸리게 됩니다(도표에서 "x"로 표시됨). 단일 서버 수준에서 10,000 건의 요청 중 1 건만이 1 초 이상의 지연 시간을 경험하는 서비스라 하더라도, 2,000 개의 이러한 서버를 가진 서비스에서는 […]"