OpenTelemetry 기반 분산 추적 구축: 로그·메트릭·트레이스 통합 분석 가이드

마이크로서비스 환경에서는 하나의 사용자 요청이 API 게이트웨이, 인증 서비스, 주문 서비스, 데이터베이스, 메시지 브로커처럼 여러 구성 요소를 거쳐 처리된다. 이때 응답 지연이나 오류가 발생하면 개별 서버의 로그만 확인해서는 정확한 원인을 찾기 어렵다. 각 서비스의 시간 기준이 다를 수 있고, 동일한 요청을 구분할 공통 식별자가 없으며, 정상 로그와 장애 로그가 여러 저장소에 흩어지기 때문이다.

OpenTelemetry는 특정 모니터링 제품에 종속되지 않는 관측성 프레임워크다. 애플리케이션에서 트레이스, 메트릭, 로그를 수집하고 OTLP 프로토콜을 통해 원하는 분석 시스템으로 전달할 수 있다. 특히 Trace ID와 Span ID를 중심으로 세 가지 신호를 연결하면 “어느 서비스가 느린가”를 넘어 “어떤 요청이 어느 구간에서 왜 느려졌는가”까지 추적할 수 있다.

OpenTelemetry의 로그·메트릭·트레이스 이해하기

트레이스는 하나의 요청이 여러 서비스를 통과한 전체 경로를 보여준다. 전체 요청 단위를 Trace라고 하며, 서비스 내부의 개별 처리 구간은 Span으로 표현한다. 예를 들어 상품 주문 요청이 API 게이트웨이, 주문 서비스, 결제 서비스, 데이터베이스를 순서대로 거쳤다면 각각의 호출이 Span으로 기록된다. Span에는 시작 시각, 소요 시간, 상태, 오류 정보와 같은 속성이 포함된다.

메트릭은 일정 시간 동안 집계된 시스템 상태를 나타낸다. CPU 사용률, 메모리 사용량, 초당 요청 수, 오류율, 응답 시간 백분위수, 데이터베이스 커넥션 풀 사용량 등이 대표적이다. 메트릭은 장애 범위를 빠르게 파악하는 데 유용하지만 특정 요청이 느려진 이유까지 단독으로 설명하기는 어렵다.

로그는 애플리케이션에서 발생한 개별 이벤트의 상세 기록이다. 오류 메시지와 스택 트레이스, 처리 결과, 업무 식별자 등을 남길 수 있다. 기존 로그에 Trace ID와 Span ID를 함께 기록하면 특정 트레이스에서 발생한 로그만 즉시 조회할 수 있다. OpenTelemetry의 컨텍스트 전파는 프로세스와 네트워크 경계를 넘어 신호를 연결하는 핵심 원리다. 일반적인 HTTP 통신에서는 traceparent 헤더를 이용해 상위 요청의 추적 문맥을 하위 서비스로 전달한다. OpenTelemetry 공식 문서에서도 컨텍스트 전파를 분산 추적과 신호 상관분석의 기반으로 설명한다.

분산 추적 수집 구조 설계하기

일반적인 구성은 애플리케이션 계측, OpenTelemetry Collector, 관측성 백엔드의 세 영역으로 나뉜다. 애플리케이션은 SDK 또는 자동 계측 에이전트를 사용해 텔레메트리 데이터를 생성한다. Collector는 데이터를 수신하고 가공한 다음 트레이스, 메트릭, 로그 저장소로 전달한다. 백엔드에서는 Grafana, Jaeger, Tempo, Prometheus, Loki, Elasticsearch 또는 상용 APM 서비스를 조합할 수 있다.

Collector의 처리 흐름은 Receiver, Processor, Exporter, Pipeline으로 구성한다. Receiver는 OTLP 등의 방식으로 데이터를 받고, Processor는 배치 처리, 메모리 제한, 속성 추가, 필터링, 샘플링을 수행한다. Exporter는 가공된 데이터를 최종 저장소로 내보낸다. Pipeline은 이러한 구성 요소를 트레이스, 메트릭, 로그 신호별로 연결한다.

소규모 환경에서는 각 노드나 애플리케이션 가까이에 Collector를 배치하는 Agent 방식으로 시작할 수 있다. 서비스 수가 많거나 전송 정책을 중앙에서 관리해야 한다면 Agent와 Gateway를 함께 사용하는 구조가 안정적이다. Agent는 로컬 데이터를 수집하고 Gateway는 샘플링, 필터링, 외부 전송을 담당한다. Kubernetes에서는 DaemonSet 형태의 노드 단위 Collector와 Deployment 형태의 중앙 Collector를 조합할 수 있다.

처음부터 모든 요청을 장기간 저장하는 방식은 권장하기 어렵다. 트래픽이 증가하면 네트워크 전송량과 저장 비용이 빠르게 커지기 때문이다. 정상 요청은 일정 비율만 보존하고, 오류 요청이나 지연 시간이 긴 요청은 우선 보존하는 샘플링 정책이 필요하다. 다만 요청이 완료되기 전에 결정하는 헤드 샘플링만 사용하면 중요한 느린 요청을 놓칠 수 있다. 장애 분석이 중요하다면 Collector Gateway에서 전체 트레이스 결과를 확인한 후 결정하는 테일 샘플링을 검토하는 것이 좋다.

자동 계측과 수동 계측 적용 방법

Java, .NET, Python, JavaScript 등 주요 언어에서는 자동 계측을 활용할 수 있다. Java 환경이라면 애플리케이션 코드를 대폭 수정하지 않고 Java Agent를 JVM 옵션으로 추가해 HTTP 요청, JDBC 호출, 메시징 통신 등을 수집할 수 있다. Kubernetes에서는 OpenTelemetry Operator를 통해 지원 언어의 자동 계측을 주입하는 구성도 가능하다.

자동 계측은 도입 속도가 빠르지만 업무 로직의 의미까지 자동으로 이해하지는 못한다. 예를 들어 결제 승인 단계, 재고 예약 처리, 회원 등급 산정처럼 비즈니스상 중요한 작업은 수동 Span으로 추가하는 편이 좋다. Span에는 service.name, 배포 환경, 서비스 버전과 같은 Resource 속성을 일관되게 설정해야 한다. HTTP, 데이터베이스, 메시징 속성은 OpenTelemetry의 시맨틱 컨벤션을 따르는 것이 좋다. 서비스마다 임의의 속성명을 사용하면 통합 검색과 대시보드 재사용이 어려워진다.

민감정보 관리도 중요하다. 사용자 비밀번호, 인증 토큰, 주민등록번호, 카드번호, SQL 바인드 값 등을 Span이나 Baggage에 그대로 기록해서는 안 된다. Baggage는 여러 서비스로 전달될 수 있으므로 고객 식별 정보 대신 내부 요청 등급이나 비식별화된 값만 사용하는 것이 안전하다. 속성 수가 지나치게 많거나 값의 종류가 계속 증가하는 고카디널리티 데이터는 저장 비용과 검색 성능을 악화시킬 수 있다.

장애 상황에서 통합 분석하는 실전 방법

실무에서는 먼저 메트릭으로 이상 구간을 좁히고, 트레이스로 느린 호출 경로를 찾은 다음, 관련 로그에서 상세 오류를 확인하는 순서가 효율적이었다. 예를 들어 API 응답 시간이 갑자기 증가했다면 서비스별 지연 시간과 오류율을 확인한다. 이후 해당 시간대의 느린 트레이스를 조회해 데이터베이스 Span, 외부 API Span, 메시지 처리 Span 중 어디에서 시간이 소요됐는지 비교한다. 마지막으로 동일한 Trace ID가 포함된 로그를 조회하면 예외 메시지나 재시도 내역을 확인할 수 있다.

개인적으로 가장 자주 확인하게 되는 부분은 컨텍스트 전파 단절이다. 앞단 서비스에서는 Trace ID가 생성되지만 중간 서비스부터 새로운 Trace가 만들어지는 경우가 있다. HTTP 프록시가 traceparent 헤더를 제거하거나, 비동기 스레드로 전환하는 과정에서 Context가 전달되지 않거나, 메시지 생산자가 추적 정보를 메시지 헤더에 넣지 않은 것이 주요 원인이다. 이 경우 서비스별 Trace가 따로 보이므로 장애 지점이 정상처럼 보일 수 있다.

Collector에서 데이터가 누락된다면 애플리케이션만 점검하지 말고 Collector 자체 메트릭과 로그를 함께 확인해야 한다. 메모리 제한 초과, Exporter 전송 실패, 백엔드 인증 오류, 전송 큐 포화가 발생하면 애플리케이션은 정상적으로 데이터를 생성해도 최종 저장소에는 나타나지 않는다. memory_limiter와 batch Processor를 적용하고, Collector의 거부 데이터 수와 Exporter 실패 건수를 모니터링하는 것이 좋다.

트레이스가 지나치게 많다면 모든 Span을 무조건 제거하기보다 헬스 체크, 정적 파일, 반복적인 내부 호출처럼 분석 가치가 낮은 대상을 필터링해야 한다. 반대로 오류 상태, 높은 지연 시간, 특정 핵심 API는 우선 보존해야 한다. 샘플링 비율을 조정할 때는 단순히 저장 비용만 비교하지 말고 실제 장애 트레이스가 남는지 정기적으로 검증해야 한다.

마치며

OpenTelemetry 기반 분산 추적의 핵심은 데이터를 많이 모으는 것이 아니라 로그, 메트릭, 트레이스를 동일한 요청 문맥으로 연결하는 데 있다. 메트릭은 이상 징후를 빠르게 발견하게 해주고, 트레이스는 병목이 발생한 호출 경로를 보여주며, 로그는 해당 구간의 구체적인 오류 원인을 제공한다.

초기에는 핵심 서비스 몇 개를 대상으로 자동 계측과 Collector를 적용하고, Trace ID가 서비스 끝까지 정상적으로 전달되는지 검증하는 것이 좋다. 이후 업무상 중요한 구간에 수동 Span을 추가하고 샘플링과 민감정보 제거 정책을 정교하게 조정하면 된다. Collector 자체의 처리량과 전송 실패까지 모니터링해야 관측 시스템이 장애 순간에도 신뢰할 수 있는 데이터를 제공한다. 이러한 구조를 갖추면 복잡한 마이크로서비스 환경에서도 추측에 의존하지 않고 요청 단위의 근거를 따라 장애 원인을 찾을 수 있다.