분산 추적

MSA에서 하나의 요청이 여러 서비스를 거칠 때 전체 흐름을 추적해 병목·장애 지점을 파악하는 관찰성(Observability) 기법입니다.

왜 필요한가

[모놀리식]
요청 → 하나의 서버 → 로그 한 곳에서 확인

[MSA — 분산 추적 없을 때]
요청 → 게이트웨이 → 주문서비스 → 재고서비스 → 결제서비스
                                        ↑
                              여기서 500 에러 발생
                     → 어느 서비스에서? 얼마나 걸렸는지?
                     → 4개의 로그를 뒤져야 함

핵심 개념

[하나의 요청 = 하나의 Trace]

Trace ID: abc-123
│
├── Span: 게이트웨이 처리     (0ms ~ 5ms)
├── Span: 주문서비스          (5ms ~ 50ms)
│     └── Span: DB 쿼리       (10ms ~ 40ms)
├── Span: 재고서비스          (50ms ~ 80ms)
└── Span: 결제서비스          (80ms ~ 150ms)
개념설명
Trace하나의 요청 전체 흐름 (Trace ID로 식별)
Span하나의 작업 단위 (시작 시각, 종료 시각, 태그 포함)
Trace ID요청 전체를 관통하는 고유 ID — 서비스 간 헤더로 전파
Parent Span ID호출한 쪽의 Span ID → 계층 구조 형성

전파 흐름

클라이언트
    │
    ▼ HTTP 요청 + 헤더 주입
게이트웨이  [X-B3-TraceId: abc-123, X-B3-SpanId: span-1]
    │
    ▼ 헤더 전달
주문서비스  [TraceId: abc-123, SpanId: span-2, ParentSpanId: span-1]
    │
    ▼
결제서비스  [TraceId: abc-123, SpanId: span-3, ParentSpanId: span-2]

대표 도구

도구특징
JaegerCNCF 프로젝트, Kubernetes 환경 표준
ZipkinTwitter 오픈소스, 경량
TempoGrafana Labs, Grafana & Loki와 자연스러운 통합
AWS X-RayAWS 네이티브

Spring Boot 연동 (Micrometer Tracing)

implementation 'io.micrometer:micrometer-tracing-bridge-brave'
implementation 'io.zipkin.reporter2:zipkin-reporter-brave'

# application.yml
management:
  tracing:
    sampling:
      probability: 1.0   # 1.0 = 100% 샘플링 (운영에서는 0.1 권장)
  zipkin:
    tracing:
      endpoint: http://zipkin:9411/api/v2/spans

// 자동으로 Trace ID가 로그에 포함됨
// [abc-123, span-2] INFO OrderService - 주문 생성: orderId=456

// MDC로 수동 접근
String traceId = MDC.get("traceId");
log.info("주문 생성: orderId={}, traceId={}", orderId, traceId);

로그 · 메트릭 · 추적 — 관찰성 3요소

요소질문도구
로그무슨 일이 있었나?Loki, ELK
메트릭지금 상태가 어떤가?Prometheus, Grafana
분산 추적요청이 어떤 경로로 흘렀나?Jaeger, Zipkin, Tempo

CSLOG에서 보기