Skip to main content

MSA를 위한 OpenTelemetry 도입


Intro

1. 왜 OpenTelemetry인가?​

MSA로 전환하면서 서비스가 많아지니 "도대체 어디서 에러가 난 거야?", "어느 구간이 느린 거야?"를 찾는 게 점점 힘들어졌다. 서비스 A 로그, 서비스 B 로그를 따로 열어서 타임스탬프 맞춰가며 연결하다 보면 시간이 다 간다.

로그만으로는 분산 트랜잭션을 추적하기 어렵다고 판단해서 OpenTelemetry(OTel) 를 붙이기로 했다.

2. OpenTelemetry란?​

OpenTelemetry는 클라우드 네이티브 소프트웨어의 성능과 동작을 분석하기 위해 Trace(트레이싱), Metric(메트릭), Log(로그) 데이터를 생성, 수집, 내보내는 오픈소스 표준 프레임워크다.

핵심 구성 요소​

OTel SDK — 애플리케이션 내부에서 Trace / Metric / Log를 생성하고 처리하는 라이브러리다. Gradle / Maven 의존성 추가로 쓸 수 있다.

arch

OTel Collector — 트레이스만 받아서 넘기는 게 아니다. 앱, 에이전트, 기존 시스템 등 여러 소스에서 Trace / Metric / Log를 받아서 가공·필터링·변환한 뒤 Tempo, Jaeger, Prometheus 같은 백엔드로 중계한다.

arch

Exporter — Collector 안에 있는 모듈로, SpanData를 최종 백엔드로 내보낸다. OTLP, Jaeger, Zipkin, Prometheus 포맷을 지원하고 gRPC / HTTP 중에서 선택할 수 있다.

arch

3. 아키텍처 구성​

프로젝트에서는 다음과 같은 파이프라인을 구축했다.

App(Spring Boot) ➡ OTel Collector ➡ Grafana Tempo (Tracing Backend)

  • Application: Java Agent를 사용하여 코드 수정 없이 자동 계측(Auto-Instrumentation) 적용
  • Collector: 중앙에서 데이터를 받아 필터링 후 저장소로 전송
  • Visualization: Grafana와 Tempo를 연동하여 시각화

arch

4. Hands-on​

4-1. Spring Boot 설정​

별도의 코드 수정 없이 opentelemetry-javaagent.jar를 사용하여 실행 시점에 에이전트를 붙였다.

java -javaagent:path/to/opentelemetry-javaagent.jar \
     -Dotel.service.name=my-service \
     -Dotel.exporter.otlp.endpoint=http://otel-collector:4317 \
     -jar my-app.jar
Spring Boot 마이크로서비스 2개
order-service: 주문 요청 처리 및 결제 호출
payment-service: 결제 응답 처리 (응답 지연 시뮬레이션 포함)
PostgreSQL: 재고 및 주문 저장용 DB
OpenTelemetry Collector: 데이터 수집 및 처리
Tempo (Grafana): 트레이스 저장소
Grafana: 트레이스 시각화 도구

arch ▲ 아키텍쳐

4-2. OTel Collector 설정 (otel-collector-config.yaml)​

Collector는 데이터를 받아(Receiver), 처리하고(Processor), 내보내는(Exporter) 파이프라인으로 구성된다.

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  otlp:
    endpoint: "tempo:4317" # Tempo 백엔드 주소
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

5. 결과​

OTel 붙이고 나서 달라진 건 하나다. 장애가 나면 Grafana Tempo에서 TraceID 하나 따라가면 어느 서비스, 어느 구간에서 얼마나 걸렸는지 바로 나온다. 서비스별 로그를 따로 열어서 타임스탬프 맞춰가며 연결하던 시간이 없어졌다.

6. 마치며​

MSA를 처음 구성할 때 로그만 붙여두면 충분하다고 생각했다. 서비스가 두세 개일 때는 그게 맞다. 서비스가 늘어나면서 로그는 각자 따로 쌓이고, 요청 하나가 서비스 5개를 넘나들면 어디서 터진 건지 찾는 것 자체가 일이 된다.

분산 트레이싱은 "있으면 좋은 것"이 아니라 MSA가 어느 규모 이상이 되면 필수다.