평균은 아무것도 말해주지 않는다 — 히스토그램과 히트맵으로 레이턴시 장애의 범인을 찾은 과정

새벽에 장애 호출을 받았는데 대시보드가 이상한 이야기를 하고 있었어요. 평균 레이턴시(응답 시간)는 36ms에서 38ms로 겨우 4% 올랐을 뿐인데, p99는 두 배 넘게 튀어서 250ms SLO를 뚫었고 고객들은 타임아웃을 호소하고 있었거든요. 엔지니어 Farid Zakaria가 이 상황을 어떻게 파고들었는지 블로그에 공유했는데, "평균이라는 숫자가 얼마나 쓸모없는지"를 보여주는 아주 좋은 실전 사례라서 소개해요.

잠깐 용어부터 짚고 갈게요. p99가 뭐냐면, 전체 요청을 빠른 순서로 줄 세웠을 때 상위 99% 지점의 응답 시간이에요. 즉 "100명 중 제일 느린 1명이 겪는 경험"인 거죠. 평균은 모든 요청을 뭉뚱그린 값이라서, 소수의 요청이 아주 느려져도 티가 잘 안 나요.

선 두 개로는 '분포의 모양'이 안 보여요

문제의 서비스는 샤딩된 키-값 저장소 앞단의 gRPC 서비스였고, 피크 기준 초당 4만 건의 요청을 처리하고 있었어요. 기본 대시보드는 평균과 p99를 시계열 그래프의 선 두 개로 그려주는데, 저자는 이게 첫 번째 함정이었다고 말해요. 1분마다 수만 건의 요청 분포를 숫자 두 개로 압축해 버리니까, 분포의 '모양'이 완전히 사라지거든요.

그래서 저자는 OpenTelemetry로 1% 샘플링해 둔 원본 레이턴시 데이터를 DuckDB(노트북에서도 돌아가는 가벼운 분석용 데이터베이스)로 불러와서 히스토그램부터 그렸어요. 그랬더니 분포가 쌍봉(bimodal)이었던 거예요. 대부분의 요청은 30ms 근처에 몰려 있는데, 450ms 근처에 작은 봉우리가 하나 더 있었죠. 그리고 평균 38ms는 그 두 봉우리 사이, 실제 요청이 거의 존재하지 않는 지점에 있었어요. 글 제목 그대로, 평균은 사실상 아무 요청도 경험하지 않은 레이턴시를 설명하고 있었던 거죠.

히트맵이 범인의 '리듬'을 보여줬어요

그런데 히스토그램만으로는 시간 정보가 없어요. 결정적인 시각화는 레이턴시 히트맵이었는데요. 가로축은 시간, 세로축은 레이턴시 구간, 색깔은 해당 구간에 속한 요청 수로 그리는 방식이에요. 성능 분석의 대가 Brendan Gregg가 오랫동안 강조해 온 기법이기도 하죠. 히트맵을 그리자 450ms 대역이 약 30초 주기로 규칙적으로 깜빡이는 게 보였어요. 부하 때문에 느려지는 거라면 이런 규칙적인 리듬이 나올 리가 없거든요. 주기적인 패턴은 "뭔가 스케줄된 작업이 있다"는 강력한 냄새예요.

다음 단계는 히트맵을 백엔드 샤드별로 쪼개서 나란히 놓고 비교하는 것(small multiples)이었어요. 그랬더니 64개 샤드 중 딱 3개에서만 느린 대역이 나타났고, 그 3개는 같은 물리 호스트를 쓰고 있었죠. 여기까지 오니 범인은 금방 나왔어요. 전체 장비에 설정을 배포하는 과정에서 그 호스트의 RocksDB 컴팩션 설정이 잘못됐고, 컴팩션(저장소가 데이터 파일을 정리하는 백그라운드 작업)이 30초마다 돌면서 디스크 I/O를 독차지해 정작 사용자 읽기 요청을 굶기고 있었던 거예요.

우리가 가져갈 교훈

• 평균은 치우친 분포, 봉우리가 여러 개인 분포에서는 거의 무의미해요. 퍼센타일 시계열이 낫긴 하지만 여전히 모양을 뭉개요.
• 히스토그램은 봉우리의 존재를, 히트맵은 봉우리의 시간 변화를, 샤드별 분할은 위치를 보여줘요. 시각화마다 답할 수 있는 질문이 달라요.
• 미리 집계된 퍼센타일은 나중에 새로운 기준(샤드, 호스트 등)으로 다시 쪼갤 수 없어요. 원본 샘플 데이터를 쿼리 가능한 형태로 남겨두는 게 핵심이에요. 저자는 Parquet 파일 위에 DuckDB를 얹어서 이 분석을 몇 분 만에 끝냈다고 해요.

한국에서도 Grafana 대시보드에 평균과 p99 선 두 개만 띄워놓고 운영하는 팀이 많은데요. 이 사례의 OpenTelemetry 샘플링 + 오브젝트 스토리지 + DuckDB 조합은 큰 비용 없이 지금 바로 도입해볼 수 있는 구성이에요. 장애가 났을 때 "새 기준으로 다시 쪼개볼 수 있는 원본"이 있느냐 없느냐가 디버깅 시간을 시간 단위에서 분 단위로 바꿔주거든요.

한 줄 정리: 평균은 "모든 요청이 똑같다면?"이라는, 아무도 묻지 않은 질문에 대한 답이에요. 여러분 팀의 대시보드는 분포의 모양을 보여주고 있나요, 아니면 선 두 개로 뭉개고 있나요? 원본 데이터 덕분에 장애 원인을 빨리 찾았던 경험이 있다면 공유해 주세요.

---

🔗 출처: Hacker News