어느 날 지표 저장소가 메모리 부족으로 죽습니다. SaaS를 쓰는 팀이라면 서버 대신 이번 달 청구서가 뛰어오르고요. 트래픽이 늘지도 않았고 새 서비스를 붙이지도 않았어요. 범인을 찾아보니 지난주 배포에 들어간 지표 한 줄입니다. 요청 경로를 레이블(label)로 붙였을 뿐인데요. 😅 관측성 정리와 OpenTelemetry 지표 정리에서 지표에 사용자 ID 같은 값을 넣지 말라고 했는데요. 실제 사고는 그렇게 대놓고 나지 않습니다. 대부분은 "이건 값이 몇 개 안 되겠지" 하고 붙인 레이블이 생각보다 많은 값을 가지면서 터지죠.
지금까지 이 시리즈에서 속성 이름을 꽤 여러 개 지었습니다. order.id, db.system, http.request.method 같은 것들이요. 별생각 없이 지은 이름도 있고 어디서 본 듯한 이름도 있었죠. 그런데 이름은 정말 아무래도 괜찮을까요? 🤔 스팬 하나만 놓고 보면 그렇습니다. http.method라고 적든 request_method라고 적든 내가 읽으면 되니까요. 문제는 그 스팬이 나 혼자 만든 게 아닐 때 시작됩니다. 이름이 갈리면 잃는 것 상황을 그려 보겠습니다. 주문 서비스는 직접 계측해서 http.metho
남은 신호는 로그 하나입니다. 그런데 지표 정리까지 왔다면 좀 이상하게 느껴질 거예요. 로그는 이미 다들 쓰고 있잖아요. 😅 파이썬이면 logging, Node라면 Pino나 Winston을 붙여 두고 잘 돌아가는데 여기에 또 새로운 걸 얹어야 하나 싶죠. OpenTelemetry도 같은 생각을 했습니다. 그래서 로그만 다른 길을 갔어요. 이 글에서는 그 선택이 무엇이었는지, 그리고 기존 로그를 추적과 이어 붙이는 방법을 다루겠습니다. 로그만 접근이 달랐던 이유 추적과 지표는 OpenTelemetry가 새로 표준을 만들었습니다.
수집기 정리까지 오면서 흘려보낸 건 추적뿐이었습니다. 추적은 요청 하나를 아주 자세히 보여 주지만 "지난 한 시간 동안 오류율이 몇 퍼센트였나"에는 답하지 못해요. 요청 하나하나를 다 뒤져 세야 하니까요. 지표, 로그, 추적 정리에서 정리했듯 그건 지표(metric)의 몫입니다. 이 글에서는 지표를 만드는 계측기(instrument) 종류를 고르는 법, 속성을 붙일 때 조심할 것, 그리고 Prometheus까지 연결하는 과정을 다루겠습니다. 계측기는 네 가지 지표를 만들려면 먼저 미터(meter)를 얻고 거기서 계측기를 만듭니다.
지금까지 만든 구조에는 선이 하나뿐이었습니다. 애플리케이션이 백엔드로 직접 보내는 선이요. 서비스가 둘일 때는 아무 문제가 없죠. 그런데 스무 개가 되면 어떨까요? 백엔드 주소를 바꾸려면 스무 곳을 고쳐 배포해야 합니다. 어떤 속성을 모든 서비스에 붙이기로 했다면 역시 스무 곳이고요. 백엔드가 잠깐 죽으면 스무 개의 애플리케이션이 각자 재시도하다 메모리에 데이터를 쌓습니다. 😰 관측을 위해 넣은 코드가 서비스를 위협하는 셈이죠. 이 글에서는 그 사이에 두는 수집기(Collector)를 다루겠습니다. 파이프라인 세 조각 수집기는 텔
OpenTelemetry 추적 정리에서 만든 트리는 깔끔했지만 한계가 있었습니다. 프로세스 하나 안에서만 이어진다는 것이요. 주문 서비스가 결제 서비스를 HTTP로 부르면 어떻게 될까요? 결제 서비스 입장에서는 그냥 요청 하나가 들어온 겁니다. 자기가 누구의 자식인지 알 도리가 없으니 새 추적을 시작하죠. 결과적으로 사용자 눈에는 한 번의 주문인데 추적은 두 개로 쪼개집니다. 😅 서비스가 늘어날수록 이 조각은 많아지고, 정작 알고 싶은 "이 주문 요청이 어디서 시간을 썼나"는 답할 수 없게 돼요. 이 글에서는 경계를 넘어 추적을
OpenTelemetry 정리에서 계측 코드가 API에만 의존하면 백엔드를 갈아 끼울 수 있다는 이야기를 했는데요. 그때 만든 스팬은 greet 하나뿐이었습니다. 이름을 붙이고 끝낸 게 전부였죠. 실제로는 여기서부터가 어렵습니다. 요청 하나를 처리하는 동안 스팬을 하나만 만들면 "이 요청이 200밀리초 걸렸다"까지만 알 수 있고, 반대로 함수마다 만들면 화면이 스팬으로 뒤덮여 오히려 안 보이거든요. 😅 이 글에서는 스팬에 무엇을 담는지, 어느 단위로 나누는 게 쓸모 있는지, 그리고 만든 추적을 Jaeger에서 어떻게 확인하는지를
추적(trace)을 처음 붙일 때 Jaeger를 골랐다고 해 볼게요. Jaeger가 주는 라이브러리를 받아 서비스 곳곳에 스팬을 만드는 코드를 심었고, 잘 돌아갑니다. 그런데 반년 뒤 팀이 다른 백엔드로 옮기기로 합니다. 무엇을 다시 해야 할까요? 심어 둔 계측 코드 전부입니다. 😅 몇 년 전까지는 이게 기본값이었습니다. 관측 도구를 고르는 일이 곧 그 도구를 코드에 새겨 넣는 일이었고, 한번 새기면 되돌리기 어려웠죠. 지금은 다릅니다. 계측 코드는 그대로 두고 환경 변수 하나만 바꾸면 텔레메트리(telemetry)가 다른 곳으로
관측성 정리에서 미리 정하지 않은 질문에 답하려면 원시 이벤트를 남겨야 한다고 했는데요. 그러면 다음 질문이 따라옵니다. 어떤 형태로 남길까? 앞 글에서 던진 자가 진단 세 질문을 다시 꺼내 보면 답이 셋으로 갈립니다. "지금 오류율이 얼마인가"는 숫자 하나로 답하고, "그 사용자의 요청에 무슨 일이 있었나"는 사건 기록으로 답하고, "요청이 어느 서비스에서 시간을 썼나"는 요청의 여정으로 답해야 하거든요. 이 세 형태가 지표(metric), 로그(log), 추적(trace)입니다. 2017년쯤부터 "관측성의 세 기둥"이라는 말로
에러 예산 정리까지 네 편에서 다룬 도구는 전부 잘 작동합니다. 알림이 울리면 온콜이 확인하고 대시보드를 열죠. 그런데 대시보드를 열어 놓고 막히는 순간이 있습니다. "왜 특정 지역 사용자만 느리지?"라는 질문에 답할 그래프가 없는 거예요. 지역별 응답 시간 그래프를 미리 만들어 둔 적이 없으니까요. 🤔 미리 만든 그래프는 미리 정한 질문에만 답합니다. 장애 중에 나오는 질문은 대개 미리 정하지 않은 질문이고요. 이 간극에 이름을 붙인 게 관측성(observability)입니다. 이 글에서는 모니터링과 관측성이 어떻게 다른지, 왜
SLI, SLO, SLA 정리에서 가용성 SLO를 30일 동안 99.9%로 잡으면 "0.1%까지는 실패해도 된다"는 허용량이 생긴다고 했는데요. 이 허용량을 어떻게 부르느냐가 생각보다 중요합니다. "허용 오차"라고 부르면 넘지 말아야 할 선처럼 들리지만 "예산"이라고 부르는 순간 질문이 바뀌거든요. 남은 예산을 어디에 쓸까? 🤔 이게 에러 예산(error budget)이라는 개념의 전부입니다. 실패해도 되는 양을 쓸 수 있는 자원으로 보는 거예요. 이 글에서는 에러 예산이 무엇인지, 예산이 남았을 때와 바닥났을 때 무엇을 하기로
온콜 정리의 끝에서 남겨 둔 질문이 있었죠. 오류율 알림의 임계값을 5%로 할지 1%로 할지를 놓고 팀 안에서 의견이 갈리는 상황이요. 개발 쪽은 "1%는 너무 빡빡해서 배포할 때마다 울린다"고 하고, 운영 쪽은 "5%면 사용자 스무 명 중 한 명이 실패하는 건데 그걸 그냥 둘 거냐"고 합니다. 둘 다 틀린 말은 아닌데 대화가 끝나지 않아요. 🤔 이 논쟁이 안 끝나는 이유는 "우리 서비스가 얼마나 실패해도 괜찮은가"를 먼저 정하지 않았기 때문입니다. 그 기준을 세우는 도구가 SLI, SLO, SLA인데요. 비슷하게 생긴 세 약어가
알림 규칙을 공들여 만들어 놨다고 해 볼게요. 그런데 알림이 채팅 채널 하나에 전부 쏟아지고 있습니다. 낮에는 누군가 보고 반응하지만 새벽에는 아무도 안 봐요. 반대로 팀 전원에게 전화가 가도록 해 둔 팀도 있는데 다들 "누가 보겠지" 하고 다시 잠듭니다. 😅 규칙은 제대로 발동했는데 사람에게 닿지 않은 거죠. 알림이 발동한 순간부터 누군가 대응을 시작하는 순간까지, 그 사이의 경로를 설계하는 게 이 글의 주제입니다. 알림을 어디로 보낼지, 누가 받을지, 못 받으면 어떻게 할지, 그리고 알림이 너무 많아지면 무슨 일이 생기는지를
새벽 3시에 결제 API가 죽었는데 아침 9시에 출근해서 대시보드를 열어 보고서야 알았던 경험, 혹시 있으신가요? 😅 대시보드는 있었습니다. 그래프도 정확했고요. 오류율이 치솟은 시각까지 그대로 그려져 있었죠. 문제는 그 여섯 시간 동안 아무도 그 화면을 보고 있지 않았다는 겁니다. 이런 일을 겪고 나면 "대시보드를 더 잘 만들어야겠다"는 결론으로 가기 쉬운데요. 사실 대시보드가 아무리 좋아져도 문제는 해결되지 않습니다. 대시보드와 알림은 하는 일이 다르기 때문입니다. 이 글에서는 둘의 역할이 어떻게 나뉘는지, 알림 규칙이 무엇으