한양과기고 에듀테크 수업도구 대시보드

🧩 왜 필요한가 MSA의 문제

브라우저

→

Nginx

→

앱 서버

→

DB / 외부 API

요청 하나가 여러 프로세스를 거치는 순간, 각자 자기 로그만 남긴다. 느려진 요청 하나를 추적하려면 Nginx 로그, 앱 로그, DB 로그를 시간으로 짜맞춰야 한다 — 서비스가 늘어날수록 이 방식은 무너진다.

🔗 Trace와 Span 개념

🟢 Trace (trace_id 하나, 요청 전체 여정) ├─ Span: nginx proxy_pass (8ms) └─ Span: /weather 핸들러 (root span, 150ms) ├─ Span: DB INSERT (6ms) └─ Span: 외부 날씨 API (120ms)

Trace = 요청 하나의 전체 여정(같은 trace_id).
Span = 그 안의 한 구간. 자신의 span_id와 parent_span_id를 가져 트리 구조를 이룬다.

🧪 인터랙티브 데모 — offset0xf.com 요청 하나의 트레이스 재현 막대 클릭 시 상세 정보

브라우저가 GET /weather 를 요청하면, 그 안에서 DB 기록과 외부 날씨 API 호출이 함께 일어난다. 아래 버튼으로 이 요청을 시뮬레이션하고, 막대를 클릭해 각 span의 상세 정보를 확인해보자.

0ms40ms80ms120ms160ms

실시간 로그

// 버튼을 눌러 요청을 시작하세요

선택한 Span 상세

막대를 클릭하면
trace_id / span_id / duration 등이
여기에 표시됩니다.

📡 Trace Context 전파 W3C traceparent

서비스 간 호출 시 이 헤더 하나로 trace_id를 이어받는다.

# 요청 헤더 traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 │ └─ trace_id (32자) └─ span_id (16자) # 다음 서비스로 넘어갈 때 # trace_id는 그대로, span_id만 새로 발급 new_span = tracer.start_span( "weather-api-call", parent=incoming_span_id )

🏛️ 관측 가능성의 세 기둥

Logs — "무슨 일이 있었나" 이산적 이벤트 기록

Metrics — "지금 상태가 어떤가" 집계된 수치(CPU, QPS)

Traces — "요청 하나가 어디를 거쳤나" 인과관계 있는 span 트리

셋은 서로를 대체하지 않는다. 메트릭으로 이상 징후를 감지하고, 트레이스로 어느 span이 느린지 좁힌 뒤, 로그로 원인을 확인하는 식으로 함께 쓴다.

🛠️ 실제 도구와 샘플링

계측 표준
OpenTelemetry SDK가 span을 만들고, Jaeger/Zipkin/Tempo 같은 백엔드가 수집·시각화.

샘플링이 필요한 이유
트래픽이 많으면 100% 수집은 저장 비용·오버헤드가 큼.

Head-based vs Tail-based
시작 시점에 미리 확률로 결정 vs 끝까지 본 뒤 에러/느린 요청만 보존.