메트릭

서비스가 이상하다는 사실을 고객이 먼저 알려 주던 시절이 있었습니다. 문의가 열 건쯤 쌓이면 그제야 개발자가 서버에 접속해 로깅으로 남겨 둔 기록을 열었습니다. 로깅은 프로그램이 돌면서 벌어진 일을 한 줄씩 글로 적어 두는 방식입니다. 거기 어딘가에 답이 있기는 했지만, 하루에 수백만 줄이 쌓인 파일에서 무엇을 찾아야 할지 모른 채 화면을 내리는 일이었습니다.

더 곤란한 것은 견줄 대상이 없다는 점이었습니다. 문서 저장 요청이 세 건 실패한 줄을 찾아냈다고 해도, 그게 원래 그 정도 나던 것인지 오늘만 그런 것인지 알 방법이 없었습니다. 견주려면 어제 파일을 다시 열어 같은 줄을 손으로 세는 수밖에 없었습니다.

메트릭은 이 두 가지를 한꺼번에 덜어 내려고 만든 형태입니다. 사건마다 사연을 적는 대신 같은 종류의 값만 세어 시각표에 얹습니다. 실패한 저장 요청이 몇 건인지를 1분 간격으로 계속 적어 두면, 오늘 오후 두 시의 값과 지난주 같은 시각의 값을 나란히 놓는 일이 그래프 한 장으로 끝납니다. 무슨 일이 왜 벌어졌는지에 답하기를 포기하는 대신, 언제부터 얼마나 달라졌는지 하나에만 답하도록 좁힌 것입니다.

값을 하나 남길 때마다 이름과 숫자와 시각을 함께 적고, 나중에 같은 이름의 값을 시간 순으로 이어 그래프로 읽습니다.

점 하나는 네 조각으로 이뤄집니다.

1. 이름 — 무엇을 세는 값인지 가리킵니다. 저장 요청 수라면 document_save_total 처럼 씁니다.
2. 값 — 그 순간의 숫자입니다.
3. 시각 — 언제의 값인지입니다. 이 조각이 있어야 시간축에 얹힙니다.
4. 라벨 — 같은 이름의 값을 갈라 보는 꼬리표입니다. 요청이 성공했는지 실패했는지를 붙여 두면 나중에 실패한 것만 골라 볼 수 있습니다.

세는 방식은 셋입니다.

1. 카운터 — 한 방향으로만 늘어나는 값입니다. 누적 요청 수처럼 줄어들 일이 없습니다. 자동차의 주행거리계와 같아서, 읽을 때도 현재 값이 아니라 1분 전과의 차이를 봅니다.
2. 게이지 — 올라가고 내려가는 값입니다. 메모리 사용량이나 접속자 수처럼 지금 얼마인지가 곧 답입니다. 같은 비유를 이어 가면 이쪽은 속도계입니다.
3. 히스토그램 — 값이 어느 구간에 몇 건씩 떨어졌는지를 세어 둡니다. 응답 시간처럼 값 하나보다 분포가 궁금한 것에 씁니다.

히스토그램이 따로 필요한 이유는 평균이 자주 거짓말을 하기 때문입니다. 요청 100건 가운데 95건이 0.1초에 끝나고 5건이 8초 걸렸다면 평균은 0.5초로 나와 아무 문제 없어 보입니다. 하지만 스무 명 중 한 명은 8초를 기다렸고, 그 한 명이 문의를 넣습니다. 그래서 응답 시간은 평균 대신 백분위수로 봅니다. p95 가 8초라는 말은 느린 쪽 5퍼센트를 잘라 냈을 때 남는 경계가 8초라는 뜻입니다.

초당 수천 건씩 들어오는 값을 그대로 전부 보관하지는 않습니다. 보통 1분 단위로 묶어 한 점으로 만들고 오래된 구간일수록 더 굵게 묶습니다. 어제 오후의 1초 단위 값을 다시 볼 일은 없지만 지난 분기의 추세는 봐야 하기 때문입니다.

모아 둔 값이 실제로 일을 하는 자리는 넷입니다.

첫째는 대시보드입니다. 요청 수, 실패율, 응답 시간 같은 값을 한 화면에 모아 두고 아침에 한 번 훑습니다. 평소 모양을 눈에 익혀 두려는 것이라, 이상한 날에는 숫자를 읽기 전에 모양만 봐도 티가 납니다.

둘째는 알림입니다. 알림은 정해 둔 조건을 넘으면 담당자에게 연락이 가도록 걸어 두는 장치인데, 그 조건을 문장으로 적으려면 셀 수 있는 값이 있어야 합니다. "실패율이 5분 동안 1퍼센트를 넘으면" 같은 조건은 메트릭 없이는 쓸 수 없습니다. 새벽 세 시에 대시보드를 보는 사람은 없으니 실무에서는 이쪽이 더 자주 쓰입니다.

셋째는 배포 직후 확인입니다. 새 버전을 올린 뒤 실패율과 응답 시간이 올라가는지 10분쯤 지켜보다가, 올라가면 이전 버전으로 되돌립니다. 되돌릴지 말지를 그래프 한 장으로 정할 수 있다는 점이 크게 쓰입니다.

넷째는 목표를 세우고 판정하는 자리입니다. SLI는 서비스 품질을 실제로 재는 값이고 SLO는 그 값을 어디까지 지키겠다고 팀이 정해 둔 선인데, 둘 다 메트릭 위에 얹힙니다. 저장 성공률 99.9퍼센트라는 목표는 성공 건수와 전체 건수를 이미 세고 있어야 성립하고, 그 선을 지켰는지도 같은 값으로 판정합니다.

"이거 메트릭에 잡히나요? 대시보드에 없으면 없는 일이 됩니다."

기능을 내기 전에 계측을 먼저 심자는 요청입니다. 재고 있지 않으면 문제가 생겨도 아무도 모른다는 뜻입니다.

"평균 응답 시간 말고 p95 로 보여 주세요."

평균이 느린 소수를 가려 버리니 분포의 끝을 보자는 말입니다.

"라벨에 사용자 ID 넣지 마세요. 시계열 터집니다."

갈라 보는 꼬리표에 값의 종류가 너무 많은 것을 넣으면 저장해야 할 선 개수가 사용자 수만큼 늘어난다는 경고입니다.

페이지덱에서는 새 기능을 내보내는 날마다 같은 장면이 반복됩니다. 태오가 배포를 걸어 놓고 실패율 그래프를 띄워 둔 채 다른 일을 하다가, 선이 평소 자리인 0.2퍼센트에서 3퍼센트로 올라가면 바로 되돌립니다. 되돌린 뒤에야 로그를 열어 무엇이 터졌는지 찾습니다. 원인을 먼저 찾으려 들면 그동안 고객은 계속 실패를 겪습니다.

메트릭을 심어 두면 장애의 원인까지 알 수 있다고 생각하기 쉽습니다. 그래프가 14시 01분에 꺾이는 모습을 보면 답이 거기 있는 것처럼 보이니 자연스러운 착각입니다. 하지만 메트릭이 답하는 것은 언제부터 얼마나까지입니다. 어느 조각이 느렸는지는 분산 추적이, 그 조각에서 무엇이 터졌는지는 로깅이 답합니다. 셋 중 메트릭만 심어 두면 매번 14시 01분까지 알아낸 뒤 서버에 직접 들어가 뒤지게 됩니다.

값을 많이 남길수록 좋다고 보는 것도 흔한 오해입니다. 재는 것이 늘면 아는 것도 는다는 셈이지만, 메트릭의 비용은 점의 개수가 아니라 라벨 조합의 개수를 따라 오릅니다. 응답 시간에 사용자 ID 라벨을 붙이면 사용자 4만 명짜리 서비스에서 관리해야 할 선이 4만 개가 됩니다. 저장 비용이 수십 배로 뛰고 그래프는 느려서 열리지 않습니다. 라벨에는 값의 종류가 손에 꼽을 만큼 적은 것만 넣고, 사용자별로 봐야 하는 내용은 로깅 쪽에 맡깁니다.