MTTR 단축을 위한 관측 가능성 시스템 개선 여정

최근 관측 가능성(Observability) 관련 서적을 읽으면서, 회사의 알람 시스템을 전면 개선하기로 결심했습니다.
관측 가능성의 핵심은 로그, 메트릭, 트레이스를 상관관계로 연결하여 근본 원인을 빠르게 파악할 수 있는 시스템을 구축하는 것입니다.

문제 상황

입사 당시 회사에는 중앙집중형 로그 시스템만 존재했고, 그 외의 모니터링·알람 체계는 사실상 없었습니다. 

그 결과 장애 발생 시, 개발자가 먼저 감지하는 것이 아니라 고객 문의 -> 실무자가 문제임을 인지  -> 개발자에게 보고하는 형식으로 되어 있었습니다.

이 구조에서는 실무자의 인지 시간 + 개발자의 문제 해결 시간이 그대로 MTTR(Mean Time To Recovery)에 반영됩니다.
실제로는 한 달 이상 지속된 버그가 뒤늦게 발견되는 사례도 있었습니다.

목표 설정

이 문제를 해결하기 위해 다음 두 가지 목표를 세웠습니다.

1. 에러 발생 후 즉시(수 분 이내) 감지 가능한 알람 시스템 구축
2. 에러 발생 위치와 원인을 한눈에 파악할 수 있는 가시성 확보
   

솔루션 선정

여러 APM 및 관측 가능성(Observability) 툴을 검토한 결과 Elasticsearch, Jaeger, Grafana, Mimir를 조합해 사용하기로 결정했습니다.
일반적으로 많이 쓰이는 LGTM(Loki, Grafana, Tempo, Mimir) 스택 대신, EJGM(Elasticsearch, Jaeger, Grafana, Mimir)을 선택한 이유는 다음과 같습니다.

1. 기존 인프라 유지 필요성
   사내에서 이미 Elasticsearch를 사용 중이었으며, 이를 완전히 제거하는 것은 현실적으로 어려웠습니다.
2. 근본 원인 분석의 효율성
   Tempo보다 Jaeger가 복잡한 트레이스 분석과 근본 원인 파악에서 더 강점을 가지고 있다고 판단했습니다.
   특히 Jaeger는 검색 기능과 시각화 측면에서 세밀하며, OpenTelemetry 표준을 지원해 추후 확장성도 확보할 수 있습니.
   또한 저장소 역시 기존의 엘라스틱 서치와 연계할 수 있으니 jaeger가 이점이 높다고 생각했고, jaeger 역시 오픈텔레메트리를 공식적으로 지원했기 때문에 tempo보단 jaeger를 선택하게 됐습니다.

TraceId와 Log의 상관관계 구축

아래는 최종 구축한 사내 Jaeger 구조입니다. 여기서 핵심은 트레이스와 로그의 상관관계 구축입니다. 이를 위해 Fluent Bit Elasticsearch로 로그를 적재하기 전에 중간 처리 단계를 두었고, 이 과정에서 traceID를 추출해 별도의 인덱스를 생성하도록 구현했습니다.

jaeger 구조

또한 저는 jaeger UI를 사용하지 않고 그라파나를 사용했는데, 이는 추후 상관관계 시각화를 위한 선택이었습니다. 아래의 사진이 Jaeger와 로그간의 상관관계를 보여주는 그라파나 화면입니다.

상관관계 화면

알람 시스템 개선

상관관계 조회 기능은 구축했지만, Grafana는 Jaeger 기반 알람 기능을 기본 제공하지 않습니다.
이를 해결하기 위해 두 가지 방안을 검토했습니다.

• Fluent-bit → Slack 전송
  (장점) 무료, 간단한 구현 가능
  (단점) 알람 세부 조정 불가
• Elasticsearch 알람
  (장점) 세밀한 알람 구성 가능
  (단점) 유료 버전에서만 Slack 웹훅 지원

최종적으로 전용 알람 서버를 두고, Elasticsearch를 10분 간격으로 폴링하는 방식을 선택했습니다. 유지보수 부담이라는 단점이 있더라도, 아래와 같은 이점이 이를 충분히 상쇄한다고 판단했습니다.

• LLM 기반 자동 분석(예: false positive 필터링, Snooze 기능) 적용 가능
• Elasticsearch 유료 라이선스 비용 절감
• span 메타데이터 포함 알람 전송으로 대응 속도 향상

 

메트릭·로그·트레이스 상관관계 강화

기존 메트릭 알람은 다음과 같은 한계가 있었습니다. 

• 알람 정보가 제한적
• 수집 주기에 따라 잘못된 알람 발생 가능

아래의 사진이 대표적으로 잘못된 알람이라고 생각하는 그 이유는 알람의 발생여부 정보만 알려주고, 추가적인 맥락이 부족해서 개발자가 직접 디버깅을 해야 한다는 점이었습니다. 

 

그러나, 아래와 같이 서버 구조를 개선하면 상황이 달라집니다. LLM이 사용자의 대응 방안을 인지하고 이를 자동으로 수행하면서, 더 풍부한 정보를 제공할 수 있습니다. 예를 들어 메트릭 정보에 로그를 결합하여 맥락을 보강하고, 최종적으로 해당 알람이 잘못된 것인지 여부까지 판단할 수 있습니다. 이를 통해 개발자의 피로도를 줄이고, 알람의 심각성 판단 정확도를 높일 수 있습니다.

메트릭 상관관계 구축

왼쪽은 기존의 알람이고, 오른쪽은 LLM이 컨텍스트 정보까지 제공해준 알람입니다.

마무리
관측 가능성은 단순히 데이터를 수집하는 것이 아니라,
로그·메트릭·트레이스를 연결하여 문제의 맥락(Context)을 제공하는 것입니다.