관측(observability), 나중에 물어볼 수 있게 남겨 두는 일

가게에 도둑이 든 다음 날에야 사람들은 CCTV를 확인해요. 그리고 그때 세 가지를 알게 돼요. 카메라가 그 각도를 찍고 있었는지, 화질이 얼굴을 알아볼 만했는지, 그리고 녹화분이 아직 지워지지 않았는지. 사건이 난 뒤에는 이 셋 가운데 무엇도 바꿀 수 없어요.

앞 시리즈를 닫으면서 문장 하나를 남겨 두었어요. 대체 경로가 조용히 잘 동작하면 1차 경로가 며칠째 죽어 있어도 아무도 모른다는 것이었어요. 관측(observability)은 그 문장을 뒤집는 일이에요. 지금 잘 돌아가는지를 보는 것이 아니라, 나중에 무언가를 물어보고 싶을 때 답할 재료가 남아 있게 하는 쪽에 가까워요.

세 신호는 서로 다른 질문에 답한다

관측에서 다루는 재료는 보통 셋으로 나뉘어요. 로그는 그때 무슨 일이 있었는지를 사건 단위로 적은 기록이에요. 지표는 요청 수나 응답 시간처럼 수치를 일정 간격으로 모은 시계열이에요. 추적은 요청 하나가 여러 구성 요소를 지나며 어디서 얼마나 시간을 썼는지 이어 붙인 기록이에요.

이 구분이 실무에서 중요해지는 순간은 대개 하나로 다른 하나를 대신하려 할 때예요. 흔한 실패가 로그로 비율을 구하려는 시도예요. 오류가 났을 때만 줄이 남는 구조에서는 로그를 아무리 세어도 오류 건수만 나오고 전체 요청 수가 없으니 오류율이 나오지 않아요. 성공한 요청은 애초에 기록되지 않았기 때문이에요. 반대로 지표만 있으면 오류율이 3퍼센트라는 사실은 알아도 그 3퍼센트가 왜 실패했는지는 알 수 없어요.

셋 중 무엇을 남길지는 저장 비용의 문제처럼 보이지만 실제로는 나중에 던질 수 있는 질문의 목록을 미리 정하는 일이에요.

아무도 설계하지 않았는데 표준이 된 로그

로그의 역사는 이 분야가 얼마나 뒤늦게 정리됐는지를 보여 줘요. syslog는 Eric Allman이 sendmail을 만들며 함께 만든 것이었어요. 특정 프로그램의 부속으로 출발한 물건이 유닉스 계열 전반으로 퍼졌고, 그 뒤 오랫동안 아무도 형식을 정하지 않은 채로 모두가 썼어요.

IETF가 2001년 8월 RFC 3164를 냈을 때조차 그것은 표준이 아니었어요. 문서 스스로 이것은 현장에서 관찰된 구현들의 동작을 적은 정보성 기록이라고 밝히고 있어요. 정하는 문서가 아니라 이미 벌어진 일을 받아 적은 문서였던 셈이에요. 실제 표준은 2009년 3월 RFC 5424가 나오면서야 생겼어요.

로그를 다루는 일이 늘 지저분한 데에는 이런 내력이 있어요. 형식이 먼저 있고 프로그램이 따라간 것이 아니라 프로그램들이 각자 남기던 것을 나중에 묶었기 때문이에요. 지금도 로그 수집의 상당 부분이 남의 형식을 알아보는 작업에 쓰여요. 그래서 새로 만드는 쪽에서는 사람이 읽기 좋은 문장 대신 기계가 파싱하지 않아도 되는 구조를 처음부터 정해 두는 편이 나아요.

지표는 라벨에서 무너진다

지표 쪽의 흐름을 바꾼 것은 2012년 SoundCloud에서 시작해 2016년 5월 클라우드 네이티브 컴퓨팅 재단의 두 번째 프로젝트로 받아들여진 Prometheus였어요. Kubernetes 다음이 이 프로젝트였다는 사실이 당시 필요의 크기를 말해 줘요.

이 방식의 핵심은 수치에 라벨을 붙여 나중에 원하는 기준으로 잘라 볼 수 있게 하는 것이에요. 응답 시간에 어떤 화면인지, 어떤 상태 코드였는지를 붙여 두면 화면별로도 상태별로도 볼 수 있어요. 편리한 만큼 함정도 여기 있어요.

Prometheus 문서는 고유한 라벨 조합마다 별도의 시계열이 생긴다고 설명해요. 시계열은 같은 대상을 시간에 따라 잇는 수치의 줄이에요. 예를 들어 화면 20종과 상태 코드 5종이 모두 조합되면 한 지표에 100개의 줄이 생길 수 있어요. 실제 개수는 관측된 조합에 달려 있어요. 사용자 식별자처럼 계속 늘어나는 값을 더하면 그 줄도 크게 늘 수 있죠.

이것이 관측에서 가장 흔한 자해예요. 그리고 대개 문제가 생긴 다음에 발견되는데, 그때는 이미 저장소가 가득 차서 정작 필요한 지표까지 함께 잃어요.

화면 3종·상태 2종에 예시 사용자 구분을 더해 보세요.

라벨 조합

3 × 2

서로 다른 시계열

6개

같은 지표라도 서로 다른 라벨 조합마다 시계열이 생겨요. 3 × 2의 여섯 조합에 사용자 네 명이 모두 들어가면 24개예요.

여섯 조합을 모두 기록하면 시계열도 여섯 개예요.

각 조합에 네 사용자의 기록이 모두 있으면 24개가 돼요. 실제로 기록된 조합마다 한 줄이에요.

모든 조합이 실제로 기록되는 가정이에요. 실제 시계열 수는 관측한 조합에 달려 있고, 저장소 메모리를 계산한 값은 아니에요.

무엇을 물어볼 수 있게 남길 것인가

Google의 신뢰성 엔지니어링 문헌은 사용자를 향한 시스템에서 네 가지만 고를 수 있다면 지연, 트래픽, 오류, 포화를 보라고 정리해요. 무엇을 볼지 정하기 어려울 때 출발점으로 삼을 만한 목록이에요.

신호	잘 답하는 질문	필요한 조건
로그	그 요청에 무슨 일이 있었나	필요한 사건과 맥락이 기록돼 있어야 함
지표	얼마나 자주, 얼마나 오래 걸리나	분모와 라벨 범위를 올바르게 정해야 함
추적	여러 서비스를 거치며 어디서 기다렸나	요청 연결 정보와 표본 수집 범위가 필요

여기에 한 줄이 더 필요해요. 신호가 오지 않는 상태를 어떻게 다룰지예요. 알람이 울리지 않았다는 사실은 정상이라는 뜻일 수도 있고, 수집이 끊겼다는 뜻일 수도 있어요. 두 상태를 구분해 두지 않으면 가장 조용한 순간이 가장 위험한 순간이 돼요.

저는 무엇을 남기지 않았나

제가 만드는 앱에서 AI 응답 경로에 대체 길을 둔 이야기를 앞 글에서 했어요. 그 구조를 만들고 나서 곧바로 한 일이 폴백이 언제 왜 동작했는지를 따로 세는 것이었어요. 이유가 시간 초과인지, 상대가 오류를 돌려준 것인지, 아니면 제가 일부러 꺼 둔 상태인지를 나눠 두지 않으면 세 가지가 같은 숫자로 합쳐져요. 정상적인 전환과 경보가 필요한 전환이 구분되지 않으면 그 지표는 며칠 만에 아무도 보지 않게 돼요.

남기지 않기로 한 것도 있어요. 이 서비스는 무료 등급 안에서 도는 작은 기계 위에 있어서 전부 오래 보관할 수 없어요. 그래서 상세한 기록은 짧게, 요약된 수치는 길게 두는 쪽으로 나눴어요. 이 선택이 실제로 정하는 것은 저장 비용이 아니라 몇 달 뒤에 물어볼 수 없게 되는 질문의 목록이에요. 반년 전 그날 왜 느렸는지를 묻고 싶어졌을 때, 그 답은 이미 반년 전에 정해져 있어요.

관측을 붙이면서 바뀐 것은 무엇을 볼 수 있게 되었는가보다 무엇을 못 보고 있었는지를 알게 되었다는 쪽이었어요. 잘 돌아간다고 믿었던 구간이 사실은 아무 기록도 남기지 않는 구간이었다는 것을 확인하는 일이 대부분이었어요.