메트릭과 알림

녹화본과 계기판

앞 강의에서 로그를 배웠습니다. 로그는 사건 하나하나의 기록입니다. "3시 14분 22초, 사용자 A의 결제가 실패했다."

로그로 답할 수 없는 질문이 있습니다.

"지금 서비스 괜찮아요?"

이 질문에 답하려면 로그 수백만 줄을 다 읽어야 합니다. 새벽 3시에 그럴 수는 없습니다. 필요한 건 요약된 숫자 하나입니다.

"지금 초당 1,200건 들어오고, 오류율 0.3%, 응답 95%가 180밀리초 이내입니다."

이 숫자들이 메트릭입니다. 자동차로 치면 로그는 블랙박스 영상이고, 메트릭은 속도계·연료계·수온계입니다. 사고 원인을 밝힐 때는 영상을 보지만, 운전 중에 보는 것은 계기판입니다.

차이는 크기에도 있습니다. 로그는 요청 하나당 한 줄이라 어마어마하게 쌓입니다. 메트릭은 몇 초에 숫자 몇 개뿐입니다. 그래서 메트릭은 몇 년치를 싸게 보관하며 "작년 이맘때보다 느려졌나?"를 물어볼 수 있습니다. 로그로는 그런 질문을 하기 어렵습니다.

그럼 무엇을 재야 하나

잴 수 있는 것은 수천 가지입니다. CPU, 메모리, 디스크, 스레드 수, 커넥션 수… 전부 재면 아무것도 못 봅니다. 계기판에 바늘이 200개 있으면 그건 계기판이 아닙니다.

현장에서 널리 쓰이는 답은 네 가지만 우선 보라는 것입니다.

앞의 셋은 손님이 직접 겪는 것이고, 마지막 하나는 곧 겪게 될 것을 미리 알려줍니다. 포화도가 90%면 아직 아무 문제가 없지만, 손님이 조금만 더 와도 무너진다는 뜻입니다.

평균의 함정

지연을 잴 때 평균은 거의 쓸모가 없습니다.

손님 100명 중 99명이 0.1초, 1명이 30초를 기다렸다면 평균은 0.4초입니다. "평균 0.4초, 아주 좋네요"라고 보고하는 순간, 30초를 기다린 그 사람은 앱을 지우고 있습니다.

그래서 95번째 값을 봅니다. 100명을 기다린 순서대로 줄 세웠을 때 95번째 사람의 대기 시간입니다. 이 숫자가 0.2초라면 "95%의 손님은 0.2초 안에 처리됐다"는 뜻이고, 이건 평균과 달리 가장 억울한 사람 쪽을 보고 있습니다.

계기판을 아무도 안 볼 때

계기판을 만들었습니다. 그런데 새벽 3시에는 아무도 안 봅니다. 그래서 규칙을 걸어둡니다. "이 바늘이 이 선을 넘으면 담당자를 깨워라." 이것이 알림입니다.

여기서 대부분의 조직이 같은 실수를 합니다.

나쁜 알림 — 부품에 건다

"서버 3번의 CPU가 90%를 넘었습니다."

새벽 3시에 이 알림을 받고 일어나서 확인해 보니 사용자는 아무 불편이 없습니다. 그냥 잠깐 바빴을 뿐입니다. 이런 일이 몇 번 반복되면 어떻게 될까요?

사람들이 알림을 끕니다. 그리고 진짜 사고가 났을 때 아무도 안 일어납니다. 이것을 알림 피로라고 하고, 실제 장애의 상당수가 여기서 시작됩니다.

좋은 알림 — 증상에 건다

"결제 실패율이 5분째 5%를 넘고 있습니다."

이건 다릅니다. 지금 이 순간 실제로 사람들이 결제를 못 하고 있습니다. 원인이 CPU든, 데이터베이스든, 외부 결제사든 상관없이 반드시 나가서 고쳐야 합니다.

기준은 이 한 문장으로 요약됩니다.

"이 알림이 울렸는데 아무것도 안 하고 다시 자도 되는가?" 그렇다면 그건 알림이 아니라 그래프여야 합니다.

CPU 90%도 볼 가치는 있습니다. 다만 그건 대시보드에 그려둘 것이지 사람을 깨울 것이 아닙니다. 알림은 비싼 자원입니다. 사람의 잠을 쓰기 때문입니다.

계기판이 고장 나면

마지막으로, 이 강의가 실제로 보여주려는 것입니다.

메트릭도 공짜로 생기지 않습니다. 앱 서버가 숫자를 뱉으면, 그것이 큐를 거쳐, 집계 워커를 거쳐, 저장소에 도착해야 비로소 그래프가 되고 알림이 됩니다. 로그와 똑같이 파이프라인입니다.

그리고 이 파이프라인이 밀리면 무슨 일이 벌어질까요?

집계 워커가 못 따라가면 큐가 찹니다. 큐가 차면 측정값이 버려집니다. 측정값이 없으면 그래프에 선이 안 그려지고, 선이 없으면 알림 규칙이 아무것도 넘지 않습니다.

계기판이 조용한 것과 아무 문제가 없는 것은 완전히 다릅니다.

가장 위험한 순간이 바로 이때입니다. 트래픽이 폭증해서 시스템이 무너지는 바로 그 순간, 측정값도 같이 폭증해서 파이프라인이 막히고, 하필 그때 알림이 침묵합니다. 그래서 실무에서는 "측정값이 안 들어오는 것" 자체를 알림 조건으로 겁니다. 조용함을 정상으로 해석하지 않는 것입니다.

직접 해보세요

아래 과제에서 앱 서버는 초당 50건의 측정값을 뱉는데 집계 워커 한 대는 초당 20건 남짓밖에 처리하지 못합니다. 큐가 차고, 측정값이 버려지기 시작합니다. 워커를 늘려 계기판을 되살려 보세요.