로그만 잔뜩 쌓아뒀는데 정작 장애 원인을 못 찾은 이유

문제 발생

마이크로서비스 여러 개로 이루어진 시스템에서 특정 요청이 느려졌다는 사용자 신고가 들어왔는데, 각 서비스의 로그를 아무리 뒤져봐도 어느 서비스가 병목인지 특정할 수 없었습니다 — 로그는 충분히 많았는데도 정작 필요한 답은 거기 없었습니다.

원인 분석

"관측가능성(observability)"은 흔히 로그, 메트릭, 트레이스라는 세 가지 신호로 이야기됩니다 — 이걸 세 기둥(three pillars)이라고 부릅니다. 문제는 셋이 서로 다른 질문에 답하도록 설계되어 있어서, 로그만 쌓아둔다고 나머지 두 질문에 자동으로 답할 수 있는 게 아니라는 점입니다.

• 로그(Logs): "이 시점에 이 서비스에서 정확히 무슨 일이 있었나?"에 답합니다. 개별 이벤트에 대한 상세한 컨텍스트를 담지만, 여러 서비스에 걸친 하나의 요청을 시간순으로 재구성하기는 원래 목적이 아닙니다.
• 메트릭(Metrics): "지금 시스템 전체 상태가 어떤가?"에 답합니다. 요청 처리량, 에러율, 응답 시간 분포 같은 숫자를 시간에 따라 집계합니다. 추세나 이상 징후를 빠르게 파악하는 데 강하지만, 특정 요청 하나가 왜 느렸는지 같은 개별 사례를 설명하지는 못합니다.
• 트레이스(Traces): "이 하나의 요청이 여러 서비스를 거치는 동안 각 구간에서 얼마나 걸렸나?"에 답합니다. 요청 하나에 고유 ID(trace ID)를 부여해 그 요청이 서비스 A → B → C를 거치는 전체 경로와 각 구간의 소요 시간을 재구성합니다 — 위 사례처럼 "어느 서비스가 병목인가"를 정확히 답할 수 있는 것은 사실상 트레이스뿐입니다.

해결 방안

1. 셋 중 하나만으로는 부족하다는 것을 인식하고, 겪고 있는 문제의 성격에 맞는 신호를 우선 도입합니다 — 지금 사례처럼 "여러 서비스를 거치는 요청의 병목 찾기"라면 트레이스가 정확히 필요한 도구입니다.
2. 분산 트레이싱을 도입하려면 각 서비스가 요청 헤더로 trace ID를 전파하도록 계측(instrumentation)해야 합니다 — OpenTelemetry가 이런 계측을 벤더 중립적인 표준으로 제공합니다.
3. 세 신호를 서로 연결(correlate)할 수 있게 만드는 것도 중요합니다 — 예를 들어 로그에 trace ID를 함께 남기면, 메트릭에서 이상 징후를 발견했을 때 그 시점의 트레이스로, 트레이스에서 특정 구간을 발견했을 때 그 구간의 상세 로그로 자연스럽게 넘어가며 조사할 수 있습니다. 셋을 따로따로 도입해 서로 연결되지 않으면 여전히 수동으로 짜맞춰야 합니다.
4. 처음부터 셋을 완벽하게 갖추려 하기보다, 지금 가장 자주 겪는 조사 어려움이 무엇인지(느린 요청? 전체 장애 감지가 늦음? 특정 에러의 원인 파악?)를 기준으로 우선순위를 정해 하나씩 채워가는 것이 현실적입니다.

공식 문서

• OpenTelemetry Docs: Observability primer