10장: 관측 가능성 — 로깅, 메트릭, 알림, 트레이싱

8장의 후반부는 시스템을 만든 다음의 이야기다. 분산 시스템은 하나의 프로세스를 디버거로 따라갈 수 없으므로, 시스템의 내부 상태를 밖에서 관측할 수 있게 만드는 장치를 처음부터 설계에 포함해야 한다.

분산 시스템 로깅

로깅은 시스템 상태를 파악하고 문제를 해결하는 가장 기본적인 수단이다. 분산 환경에서 핵심이 되는 것은 중앙 집중형 로깅(Centralized Logging), 즉 여러 기기에서 생성된 로그를 한곳에 모아 저장하는 방식이다.

두 번째가 중앙 집중형 로깅의 진짜 이유다. 하나의 요청이 여러 서비스를 거치는 구조에서, 각 서비스의 로그가 각자의 디스크에만 남아 있으면 그 요청이 어디서 실패했는지 재구성할 수 없다.

주요 오픈 소스 도구는 세 가지가 소개된다.

모범 사례

• 일관된 로그 형식 사용하기 — 파싱과 검색이 가능해진다
• 로그에 컨텍스트 정보 포함하기 — 요청 ID, 사용자 ID, 트레이스 ID 등
• 예외를 적절히 처리하기 — 스택 트레이스를 삼키지 않는다
• 적절한 로그 레벨 설정하기
• 로그 순환 및 아카이빙하기

메트릭

메트릭은 특정 시간 간격 동안 측정된 데이터를 수치로 표현한 것이다. 로그가 "무슨 일이 있었는가"를 기록한다면, 메트릭은 "지금 어떤 상태인가"를 숫자로 요약한다.

책은 메트릭을 세 종류로 나눈다.

이 분류가 유용한 이유는 누가 그 숫자를 보는가가 다르기 때문이다. 시스템 메트릭은 인프라 담당자가, 애플리케이션 메트릭은 서비스 개발자가, 비즈니스 메트릭은 제품 담당자가 본다. 대시보드를 하나에 다 몰아넣으면 아무도 자기 숫자를 찾지 못한다.

도구

모범 사례

• 핵심 메트릭 선정하기
• 일관된 이름 규칙 사용하기
• 오류율과 지연 시간 모니터링하기
• 메트릭 시각화하기

알림

알림 설계의 핵심은 민감도와 정확성 사이의 균형이다. 너무 민감하면 거짓 경보가 쏟아지고, 너무 둔감하면 실제 장애를 놓친다.

책이 제시하는 판단 기준은 세 가지다.

• 중요도 — 이것이 정말 사람을 깨울 만한 일인가
• 실행 가능성 — 알림을 받은 사람이 할 수 있는 조치가 있는가
• 문제를 파악할 수 있는 정보 — 알림 자체에 원인 파악에 필요한 정보가 담겨 있는가

두 번째 기준이 가장 실용적이다. 받아도 할 수 있는 일이 없는 알림은 알림이 아니라 소음이다. 조치할 방법이 없다면 그것은 대시보드에 있어야 할 지표이고, 알림으로 만들 이유가 없다.

도구로는 프로메테우스의 구성 요소인 알림 매니저(Alertmanager), 데이터 기반 조건으로 알림을 만들 수 있는 그라파나(Grafana), 그리고 모니터링 도구와 연동해 알림을 중앙에서 관리하는 페이저듀티(PagerDuty)를 든다. 페이저듀티는 오픈 소스가 아니지만 프로메테우스나 그라파나와 쉽게 연동된다.

모범 사례는 짧고 명확하다.

• 알림을 너무 많이 발생시키지 말 것
• 알림을 테스트할 것
• 알림 프로세스를 문서화할 것

분산 트레이싱

분산 트레이싱은 하나의 요청이 여러 서비스와 서버를 거치는 과정을 추적하는 기법이다. 요청이 처리되는 각 단계를 스팬(Span) 으로 기록하고, 스팬이 모여 요청 전체의 흐름을 보여주는 트레이스(Trace) 를 구성한다.

하나의 트레이스는 스팬들이 시간축 위에 겹쳐 쌓인 형태로 보인다.

trace_id = a1b2c3
0ms                                                        320ms
|-----------------------------------------------------------|
[API 게이트웨이: 요청 처리                                    ]  320ms
  [사용자 서비스: 인증 확인   ]                                  70ms
        [주문 서비스: 주문 조회                     ]           160ms
           [데이터베이스: SELECT 쿼리          ]                100ms

각 막대가 하나의 스팬이고, 스팬은 부모 스팬의 ID를 들고 있어 호출 관계가 트리로 복원된다. 위 예시에서는 전체 320ms 중 100ms가 데이터베이스 쿼리에서 소모됐다는 사실이 한눈에 드러난다.

이 구조가 주는 이점은 세 가지다.

• 성능 최적화 — 어느 단계가 시간을 잡아먹는지 눈으로 볼 수 있다
• 오류 진단 — 실패가 발생한 정확한 지점을 찾을 수 있다
• 시스템 동작 파악 — 요청이 실제로 어떤 서비스를 거치는지 확인할 수 있다

메트릭과의 차이가 여기서 갈린다. 메트릭은 "주문 API의 p99 지연 시간이 2초"라고 알려주지만, 그 2초가 어디서 발생하는지는 알려주지 않는다. 트레이싱은 그 2초를 서비스별로 쪼개 보여준다.

도구

오픈텔레메트리가 앞의 둘과 성격이 다르다는 점을 짚어 둘 만하다. 예거와 집킨은 트레이스를 저장하고 보여주는 백엔드이고, 오픈텔레메트리는 애플리케이션에서 데이터를 뽑아내는 계측 표준이다. 오픈텔레메트리로 계측해 두면 백엔드를 예거에서 다른 것으로 바꿀 때 애플리케이션 코드를 건드리지 않아도 된다.

모범 사례

• 코드에 트레이싱 추가하기 — 계측 없이는 아무 데이터도 나오지 않는다
• 컨텍스트 전파하기 — 트레이스를 여러 서비스에 걸쳐 추적하려면 트레이스 컨텍스트를 서비스 간에 전달해야 한다
• 스팬 이름을 명확하게 작성하기
• 스팬에 주석 추가하기

두 번째가 분산 트레이싱 도입에서 실제로 가장 까다로운 부분이다. HTTP 헤더로 트레이스 ID를 넘기는 것은 쉽지만, 메시지 큐를 거치는 비동기 경로나 배치 작업에서 컨텍스트를 이어 붙이는 일은 별도 작업이 필요하다.

세 가지 신호를 함께 보기

로그, 메트릭, 트레이스는 흔히 관측 가능성의 세 기둥으로 불린다. 각자 답하는 질문이 다르다.

세 신호를 이 순서로 쓸 수 있게 만드는 것이 실무의 목표다. 메트릭 알림에서 트레이스로, 트레이스에서 해당 스팬의 로그로 클릭 한 번에 이동할 수 있으려면, 세 신호가 공통 ID로 연결되어 있어야 한다. 로깅 절에서 나온 "로그에 컨텍스트 정보 포함하기"가 결국 여기로 이어진다.

정리

8장은 API 설계에서 관측 가능성까지 폭넓게 다루고, 책이 스스로 요약한 여섯 가지 실천 항목으로 마무리한다. 적절한 API 설계 선택, API 보안 최우선 고려, 중앙 집중형 로깅 구현, 핵심 메트릭 모니터링, 구체적이고 실용성 있는 알림 설계, 분산 트레이싱 활용.

관측 가능성 부분은 도구 목록과 모범 사례 나열 중심이라 깊이는 얕지만, 각 신호가 무엇을 위해 존재하는지는 명확하게 구분해 준다. 특히 알림 설계에서 "실행 가능성"을 기준으로 제시한 것과, 트레이싱에서 컨텍스트 전파를 별도로 강조한 것은 실제 운영 경험이 반영된 대목으로 읽힌다.

건축과 운영을 같은 장에 묶어 놓은 구성도 의미가 있다. 관측 가능성은 시스템을 다 만든 다음에 얹는 부가 기능이 아니라, API를 설계하는 시점에 요청 ID를 어떻게 흘릴지 함께 결정해야 하는 문제라는 점이 드러난다.