요청과 장애를 개수로 측정할 때와, 사용자가 실제로 시간으로 체감할 때 왜 평균이 다르게 보이는지 inspection paradox를 통해 설명합니다.
제 이름은 Marc Brooker입니다. 저는 제대로 작동하는 것을 만들고, 멋진 일을 하는 것을 좋아합니다. 큰 것을 만드는 것도 좋아합니다. 또한 기계가공, 용접, 요리, 스키도 조금 합니다.
저는 시애틀의 Amazon Web Services (AWS)에서 엔지니어로 일하고 있으며, agentic AI, 특히 agentic AI의 안전과 정책을 다룹니다. 그전에는 EC2, EBS, 데이터베이스, serverless, 그리고 serverless 데이터베이스에서 일했습니다.
모든 의견은 개인적인 것입니다.
@marcbrooker on Mastodon@MarcJBrooker on Twitter
무슨 뜻이냐고요?
앨리스를 만나보세요. 앨리스는 여러분의 웹 서비스를 사용합니다. 앨리스는 대부분의 사람들처럼 자신의 시간을 초와 분으로 잽니다. 앨리스는 여러분의 서비스가 느리다고 말합니다. 여러분은 서비스에 대한 평균 요청이 100ms 안에 완료된다고 말하지만, 앨리스는 자신의 평균 대기 시간이 1s라고 말합니다.
두 사람 모두 맞습니다.
알렉스를 만나보세요. 알렉스는 여러분의 웹 서비스를 사용합니다. 알렉스는 대부분의 사람들처럼 자신의 시간을 초와 분으로 잽니다. 알렉스는 장애가 발생하면 그것이 오래 지속되어 정말 짜증 난다고 말합니다. 여러분은 MTTR이 1분 미만이라고 말합니다. 알렉스는 자신이 보는 평균 장애 지속 시간이 1시간이라고 말합니다.
다시 말해, 두 사람 모두 맞습니다.
무슨 일이 벌어지고 있을까요? 여기서 벌어지는 일은, 여러분은 시간을 요청 수나 장애 건수로 측정하고 있고, 알렉스와 앨리스는 시간을 초와 분으로 측정하고 있다는 것입니다. 긴 요청이나 긴 장애가 발생하면, 알렉스와 앨리스는 그것을 긴 시간으로, 큰 가중치를 두고 셉니다. 하지만 여러분은 그것을 단지 한 건으로만 셉니다.
좀 더 기술적으로 말하면, 여기서 벌어지는 일은 _inspection paradox_입니다. 알렉스와 앨리스가 경험하는 것은 여러분의 지연 시간 분포가 아니라, 그 분포의 t-가중 버전입니다. 여러분의 MTTR 또는 평균 요청 시간이 이라면, 알렉스와 앨리스가 경험하는 값은 입니다.
그들이 기다리는 시간의 대부분에서, 그들은 오래 걸리는 것들을 기다리고 있습니다. 이것이 인간이 시간을 체감하는 방식과 대략 비슷합니다.
작은 시뮬레이션으로 이것을 살펴봅시다. 중앙값 지연 시간(또는 복구 시간)과 99백분위 지연 시간(또는 복구 시간)을 넣으면, 거기에 맞는 로그정규 분포를 맞춘 뒤 서비스 메트릭이 보는 것과 고객이 보는 것을 모두 그려 보겠습니다.
중앙값: ms p99: ms
서비스가 보는 것(평균): 254 ms. 고객이 경험하는 것(평균): 410 ms.
예를 들어 중앙값으로 30을 넣어 봅시다(일단 밀리초는 무시하고 이것들을 분이라고 가정합시다). 그러면 Median TTR이 30분이라는 뜻입니다(즉 사후 분석의 절반에서 복구 시간이 분으로 보인다는 뜻입니다). 그리고 p99로 600을 넣습니다(100번의 사건 중 한 번은 복구에 10시간이 걸립니다). 그러면 여러분의 MTTR은 1시간을 조금 넘습니다. 하지만 고객이 경험하는 평균 복구 시간은 약 6시간입니다!
꼬리 지연 시간(그리고 긴 복구 시간)을 이해하는 것이 왜 중요한지에 대해서는 많은 논거가 있습니다(예: 여러 사례). 하지만 제가 보기에 이것은 가장 널리 이해되지 않은 이유입니다. 서비스 시간의 경우 timeout-and-retry가 이런 지연을 때때로 가릴 수 있습니다(실행 중인 요청이 락이나 다른 배타적 자원을 잡고 있지 않다면). 하지만 복구 시간의 경우에는 이렇게 가릴 방법이 없습니다. 꼬리의 두꺼움은 매우 중요합니다. 이것은 또한 제가 서비스 지연 시간이나 복구 시간을 생각하는 방식으로 trimmed measurement(예: trimmed mean)를 좋아하지 않는 이유 중 하나이기도 합니다. 그것들은 고객 경험을 지배하는 오른쪽 꼬리의 형태에 대한 정말 중요한 맥락 일부를 버려 버립니다(또 다른 이유는 Little’s Law와 용량 사용률과 관련이 있으며, 이전에 글로 쓴 적이 있습니다).
로그정규에 대한 메모: 여기서는 수치적 편의를 위해 로그정규를 선택했습니다. 이것은 가 된다는 좋은 성질이 있습니다. 또한 0 근처에서 거동이 안정적입니다. 저는 로그정규가 지연 시간이나 복구 시간 메트릭의 분포로 특별히 좋은 선택이라고는 생각하지 않으며, 일반적으로는 이런 문제에 완전히 비모수적으로 접근할 것입니다.
