- Authors
- Name
- 들어가며
- 분산 트레이싱 핵심 개념
- OpenTelemetry SDK 계측 (Python/Go)
- OpenTelemetry Collector 구성
- Jaeger 백엔드 구축과 운영
- Grafana Tempo: 대규모 트레이스 스토리지
- 트레이싱 백엔드 비교 (Jaeger vs Tempo vs Zipkin)
- 샘플링 전략과 비용 최적화
- 운영 시 주의사항과 트러블슈팅
- 실패 사례와 복구 절차
- 마치며
- 참고자료

들어가며
마이크로서비스 아키텍처에서 하나의 사용자 요청은 여러 서비스를 거쳐 처리된다. API Gateway에서 시작된 요청이 인증 서비스, 주문 서비스, 결제 서비스, 알림 서비스를 순차적/병렬적으로 호출하는 구조에서, 특정 요청이 느린 이유를 파악하려면 전체 호출 체인을 추적해야 한다. 단일 서비스의 로그나 메트릭만으로는 서비스 간 인과 관계를 파악하기 어렵다.
분산 트레이싱(Distributed Tracing)은 이 문제를 해결한다. 요청이 서비스 경계를 넘을 때마다 고유한 Trace ID를 전파하고, 각 서비스에서 수행한 작업을 Span으로 기록하여 전체 요청 흐름을 하나의 트레이스로 재구성한다. Google의 Dapper 논문(2010)에서 시작된 이 개념은 이제 OpenTelemetry라는 CNCF 프로젝트로 표준화되었고, Jaeger와 Grafana Tempo 같은 백엔드를 통해 저장하고 분석할 수 있다.
이 글에서는 분산 트레이싱의 핵심 개념부터 시작하여 OpenTelemetry SDK를 활용한 Python/Go 계측, OpenTelemetry Collector 구성, Jaeger와 Grafana Tempo 백엔드 구축, 샘플링 전략, 비용 최적화, 운영 시 주의사항까지 프로덕션 환경에서 필요한 전체 파이프라인을 실전 코드와 함께 다룬다.
분산 트레이싱 핵심 개념
Trace, Span, Context Propagation
분산 트레이싱의 세 가지 핵심 개념을 정리한다.
Trace는 하나의 사용자 요청이 시스템을 통과하는 전체 경로를 나타낸다. 고유한 Trace ID로 식별되며, 여러 Span의 집합으로 구성된다.
Span은 트레이스 내에서 하나의 작업 단위를 나타낸다. 각 Span은 고유한 Span ID, 부모 Span ID, 시작/종료 시간, 속성(Attributes), 이벤트(Events), 상태(Status)를 가진다. Span의 종류(SpanKind)는 SERVER, CLIENT, PRODUCER, CONSUMER, INTERNAL 다섯 가지가 있다.
Context Propagation은 Trace ID와 Span ID를 서비스 경계를 넘어 전달하는 메커니즘이다. HTTP 헤더(W3C Trace Context의 traceparent, tracestate), gRPC 메타데이터, 메시지 큐 헤더 등을 통해 컨텍스트가 전파된다.
W3C Trace Context 표준
W3C Trace Context는 분산 트레이싱의 컨텍스트 전파 표준이다. traceparent 헤더의 형식은 다음과 같다.
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
| | | |
버전 Trace ID (32자) Parent Span ID Flags
OpenTelemetry는 기본적으로 W3C Trace Context를 사용하며, B3(Zipkin), Jaeger 형식의 전파도 지원한다.
OpenTelemetry 아키텍처 개요
OpenTelemetry는 텔레메트리 데이터(트레이스, 메트릭, 로그)를 생성, 수집, 전송하기 위한 벤더 중립적 프레임워크다. 주요 구성 요소는 다음과 같다.
- API: 계측을 위한 인터페이스 정의 (벤더 독립적)
- SDK: API의 구현체 (샘플링, 배치, 내보내기 등)
- Collector: 텔레메트리 데이터를 수신, 처리, 내보내는 독립 프로세스
- Instrumentation Libraries: 라이브러리/프레임워크 자동 계측
OpenTelemetry SDK 계측 (Python/Go)
Python 계측
Python 애플리케이션에 OpenTelemetry를 적용하는 방법을 살펴본다. 먼저 필요한 패키지를 설치한다.
pip install opentelemetry-api \
opentelemetry-sdk \
opentelemetry-exporter-otlp \
opentelemetry-instrumentation-flask \
opentelemetry-instrumentation-requests \
opentelemetry-instrumentation-sqlalchemy
다음은 Flask 애플리케이션에 OpenTelemetry를 적용하는 전체 코드다.
# tracing.py - OpenTelemetry 초기화 모듈
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource, SERVICE_NAME, SERVICE_VERSION
from opentelemetry.propagate import set_global_textmap
from opentelemetry.propagators.composite import CompositePropagator
from opentelemetry.trace.propagation import TraceContextTextMapPropagator
from opentelemetry.baggage.propagation import W3CBaggagePropagator
def init_tracer(service_name: str, otlp_endpoint: str = "localhost:4317"):
"""OpenTelemetry TracerProvider를 초기화하고 글로벌 설정을 적용한다."""
resource = Resource.create({
SERVICE_NAME: service_name,
SERVICE_VERSION: "1.0.0",
"deployment.environment": "production",
})
provider = TracerProvider(resource=resource)
# OTLP gRPC Exporter 설정
otlp_exporter = OTLPSpanExporter(endpoint=otlp_endpoint, insecure=True)
span_processor = BatchSpanProcessor(
otlp_exporter,
max_queue_size=2048,
max_export_batch_size=512,
schedule_delay_millis=5000,
)
provider.add_span_processor(span_processor)
# 글로벌 TracerProvider 등록
trace.set_tracer_provider(provider)
# W3C Trace Context + Baggage 전파 설정
set_global_textmap(CompositePropagator([
TraceContextTextMapPropagator(),
W3CBaggagePropagator(),
]))
return provider
# app.py - Flask 애플리케이션에 트레이싱 적용
from flask import Flask, request, jsonify
from opentelemetry import trace
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor
from tracing import init_tracer
import requests
# 트레이서 초기화
provider = init_tracer("order-service", "otel-collector:4317")
app = Flask(__name__)
# 자동 계측: Flask와 requests 라이브러리
FlaskInstrumentor().instrument_app(app)
RequestsInstrumentor().instrument()
# 수동 계측을 위한 트레이서 획득
tracer = trace.get_tracer("order-service", "1.0.0")
@app.route("/orders", methods=["POST"])
def create_order():
"""주문 생성 API - 수동 Span을 추가하여 세밀한 추적 수행"""
with tracer.start_as_current_span(
"validate_order",
attributes={"order.type": "standard"}
) as span:
order_data = request.get_json()
span.set_attribute("order.item_count", len(order_data.get("items", [])))
# 재고 확인 - 외부 서비스 호출 (자동 계측됨)
inventory_resp = requests.post(
"http://inventory-service:8080/check",
json=order_data["items"]
)
if inventory_resp.status_code != 200:
span.set_status(trace.StatusCode.ERROR, "Inventory check failed")
span.record_exception(Exception("재고 부족"))
return jsonify({"error": "insufficient_inventory"}), 400
with tracer.start_as_current_span("process_payment") as span:
payment_resp = requests.post(
"http://payment-service:8080/charge",
json={"amount": order_data["total"]}
)
span.set_attribute("payment.method", order_data.get("payment_method", "card"))
return jsonify({"order_id": "ORD-12345", "status": "confirmed"}), 201
if __name__ == "__main__":
app.run(host="0.0.0.0", port=8080)
Go 계측
Go 애플리케이션에서는 go.opentelemetry.io/otel 패키지를 사용한다. HTTP 서버와 gRPC 클라이언트에 트레이싱을 적용하는 예제를 살펴본다.
// tracing.go - OpenTelemetry 초기화
package main
import (
"context"
"log"
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
"go.opentelemetry.io/otel/propagation"
"go.opentelemetry.io/otel/sdk/resource"
sdktrace "go.opentelemetry.io/otel/sdk/trace"
semconv "go.opentelemetry.io/otel/semconv/v1.24.0"
"go.opentelemetry.io/otel/trace"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
)
func initTracer(ctx context.Context, serviceName, endpoint string) (*sdktrace.TracerProvider, error) {
// gRPC 연결로 OTLP Exporter 생성
conn, err := grpc.NewClient(endpoint,
grpc.WithTransportCredentials(insecure.NewCredentials()),
)
if err != nil {
return nil, err
}
exporter, err := otlptracegrpc.New(ctx, otlptracegrpc.WithGRPCConn(conn))
if err != nil {
return nil, err
}
// Resource 정의 - 서비스 메타데이터
res, err := resource.New(ctx,
resource.WithAttributes(
semconv.ServiceName(serviceName),
semconv.ServiceVersion("1.0.0"),
semconv.DeploymentEnvironment("production"),
),
)
if err != nil {
return nil, err
}
// TracerProvider 생성
tp := sdktrace.NewTracerProvider(
sdktrace.WithBatcher(exporter,
sdktrace.WithMaxQueueSize(2048),
sdktrace.WithMaxExportBatchSize(512),
),
sdktrace.WithResource(res),
sdktrace.WithSampler(sdktrace.ParentBased(
sdktrace.TraceIDRatioBased(0.1), // 10% 샘플링
)),
)
// 글로벌 설정
otel.SetTracerProvider(tp)
otel.SetTextMapPropagator(propagation.NewCompositeTextMapPropagator(
propagation.TraceContext{},
propagation.Baggage{},
))
return tp, nil
}
// handleOrder - HTTP 핸들러에서 수동 Span 생성
func handleOrder(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
tracer := otel.Tracer("order-handler")
ctx, span := tracer.Start(ctx, "process-order",
trace.WithSpanKind(trace.SpanKindServer),
)
defer span.End()
// 비즈니스 로직에 컨텍스트 전달
orderID, err := processOrder(ctx)
if err != nil {
span.RecordError(err)
span.SetStatus(codes.Error, err.Error())
http.Error(w, "order failed", http.StatusInternalServerError)
return
}
span.SetAttributes(attribute.String("order.id", orderID))
w.WriteHeader(http.StatusCreated)
}
자동 계측 vs 수동 계측
| 구분 | 자동 계측 | 수동 계측 |
|---|---|---|
| 적용 방식 | 라이브러리/에이전트 사용 | 코드에 직접 Span 생성 |
| 코드 변경 | 최소 (초기화만) | 비즈니스 로직 곳곳에 삽입 |
| 커버리지 | HTTP, DB, gRPC 등 프레임워크 레벨 | 커스텀 비즈니스 로직까지 가능 |
| 세밀한 제어 | 제한적 | 속성, 이벤트, 링크 자유롭게 추가 |
| 권장 전략 | 기본 골격으로 사용 | 핵심 비즈니스 로직에 보완적으로 추가 |
실전에서는 자동 계측으로 HTTP/gRPC/DB 호출의 기본 Span을 생성하고, 수동 계측으로 비즈니스 로직의 핵심 구간을 추가로 계측하는 하이브리드 전략을 권장한다.
OpenTelemetry Collector 구성
OpenTelemetry Collector는 텔레메트리 데이터를 수신(Receivers), 처리(Processors), 내보내기(Exporters)하는 파이프라인 역할을 한다. 애플리케이션에서 직접 백엔드로 데이터를 보내는 대신 Collector를 중간에 두면 재시도, 배치, 샘플링, 라우팅 등을 중앙에서 관리할 수 있다.
Collector 구성 파일
# otel-collector-config.yaml
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
timeout: 5s
send_batch_size: 1024
send_batch_max_size: 2048
memory_limiter:
check_interval: 1s
limit_mib: 1024
spike_limit_mib: 256
resource:
attributes:
- key: environment
value: production
action: upsert
- key: cluster
value: k8s-prod-01
action: upsert
# Tail-based 샘플링: 에러와 느린 요청은 100% 수집
tail_sampling:
decision_wait: 10s
num_traces: 100000
expected_new_traces_per_sec: 1000
policies:
- name: error-policy
type: status_code
status_code:
status_codes:
- ERROR
- name: latency-policy
type: latency
latency:
threshold_ms: 1000
- name: probabilistic-policy
type: probabilistic
probabilistic:
sampling_percentage: 10
exporters:
otlp/jaeger:
endpoint: jaeger-collector:4317
tls:
insecure: true
otlp/tempo:
endpoint: tempo:4317
tls:
insecure: true
debug:
verbosity: basic
extensions:
health_check:
endpoint: 0.0.0.0:13133
zpages:
endpoint: 0.0.0.0:55679
service:
extensions: [health_check, zpages]
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, resource, tail_sampling, batch]
exporters: [otlp/jaeger, otlp/tempo, debug]
telemetry:
logs:
level: info
metrics:
address: 0.0.0.0:8888
Collector Docker Compose 배포
# docker-compose.yaml (Collector 부분)
services:
otel-collector:
image: otel/opentelemetry-collector-contrib:0.116.0
command: ['--config=/etc/otel-collector-config.yaml']
volumes:
- ./otel-collector-config.yaml:/etc/otel-collector-config.yaml:ro
ports:
- '4317:4317' # OTLP gRPC
- '4318:4318' # OTLP HTTP
- '8888:8888' # Collector 메트릭
- '13133:13133' # Health check
- '55679:55679' # zPages
restart: unless-stopped
deploy:
resources:
limits:
memory: 2g
cpus: '1.0'
healthcheck:
test: ['CMD', 'wget', '--spider', '-q', 'http://localhost:13133']
interval: 10s
timeout: 5s
retries: 3
Collector 구성에서 주의할 점은 processors 순서다. memory_limiter는 반드시 첫 번째로 배치하여 OOM을 방지해야 하며, batch는 마지막에 위치시켜 네트워크 효율을 높인다.
Jaeger 백엔드 구축과 운영
Jaeger는 Uber에서 개발한 오픈소스 분산 트레이싱 시스템으로, CNCF Graduated 프로젝트다. Jaeger v2는 OpenTelemetry Collector를 기반으로 재구축되어 네이티브 OTLP 지원을 제공한다.
Jaeger 프로덕션 배포
프로덕션 환경에서는 Jaeger all-in-one이 아닌 분리된 컴포넌트 배포를 권장한다. Elasticsearch를 스토리지 백엔드로 사용하는 구성을 살펴본다.
# docker-compose-jaeger.yaml
services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.17.0
environment:
- discovery.type=single-node
- xpack.security.enabled=false
- 'ES_JAVA_OPTS=-Xms1g -Xmx1g'
ports:
- '9200:9200'
volumes:
- es_data:/usr/share/elasticsearch/data
healthcheck:
test: ['CMD-SHELL', 'curl -f http://localhost:9200/_cluster/health || exit 1']
interval: 10s
timeout: 5s
retries: 10
jaeger:
image: jaegertracing/jaeger:2.4.0
environment:
- SPAN_STORAGE_TYPE=elasticsearch
- ES_SERVER_URLS=http://elasticsearch:9200
- ES_NUM_SHARDS=3
- ES_NUM_REPLICAS=1
- ES_INDEX_PREFIX=jaeger
- ES_TAGS_AS_FIELDS_ALL=true
- COLLECTOR_OTLP_ENABLED=true
ports:
- '16686:16686' # Jaeger UI
- '4317:4317' # OTLP gRPC
- '4318:4318' # OTLP HTTP
- '14250:14250' # gRPC Collector
depends_on:
elasticsearch:
condition: service_healthy
restart: unless-stopped
volumes:
es_data:
driver: local
Jaeger 인덱스 관리
Elasticsearch 기반 Jaeger 운영에서 인덱스 관리는 필수다. 오래된 트레이스를 자동 삭제하는 크론잡을 설정한다.
#!/bin/bash
# jaeger-index-cleaner.sh - 14일 이상 된 Jaeger 인덱스 삭제
ES_URL="http://elasticsearch:9200"
RETENTION_DAYS=14
# 삭제 대상 날짜 계산
CUTOFF_DATE=$(date -d "-${RETENTION_DAYS} days" +%Y-%m-%d)
echo "Deleting Jaeger indices older than ${CUTOFF_DATE}..."
# jaeger-span-* 및 jaeger-service-* 인덱스 조회 및 삭제
for INDEX_TYPE in "jaeger-span" "jaeger-service"; do
INDICES=$(curl -s "${ES_URL}/_cat/indices/${INDEX_TYPE}-*" \
| awk '{print $3}' \
| sort)
for INDEX in ${INDICES}; do
# 인덱스명에서 날짜 추출 (jaeger-span-2026-03-01 형식)
INDEX_DATE=$(echo "${INDEX}" | grep -oP '\d{4}-\d{2}-\d{2}')
if [[ "${INDEX_DATE}" < "${CUTOFF_DATE}" ]]; then
echo "Deleting index: ${INDEX}"
curl -s -X DELETE "${ES_URL}/${INDEX}"
fi
done
done
echo "Cleanup completed."
Jaeger 핵심 기능
- 트레이스 검색: 서비스명, 작업명, 태그, 시간 범위로 트레이스 검색
- 트레이스 비교: 두 트레이스를 나란히 비교하여 성능 차이 분석
- 의존성 그래프: 서비스 간 호출 관계를 DAG로 시각화
- SPM (Service Performance Monitoring): RED 메트릭(Rate, Error, Duration) 자동 생성
Grafana Tempo: 대규모 트레이스 스토리지
Grafana Tempo는 대규모 분산 트레이싱을 위해 설계된 백엔드다. Jaeger와 달리 인덱스를 생성하지 않고 오브젝트 스토리지(S3, GCS, Azure Blob)에 트레이스를 직접 저장하여 비용을 획기적으로 줄인다.
Tempo 구성
# tempo-config.yaml
server:
http_listen_port: 3200
distributor:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
ingester:
max_block_duration: 5m
max_block_bytes: 1073741824 # 1GB
flush_check_period: 10s
compactor:
compaction:
block_retention: 336h # 14일
ring:
kvstore:
store: memberlist
storage:
trace:
backend: s3
s3:
bucket: tempo-traces-prod
endpoint: s3.ap-northeast-2.amazonaws.com
region: ap-northeast-2
# IAM Role 기반 인증 권장 (access_key 직접 입력 지양)
wal:
path: /var/tempo/wal
local:
path: /var/tempo/blocks
pool:
max_workers: 100
queue_depth: 10000
querier:
search:
query_timeout: 30s
frontend_worker:
frontend_address: tempo-query-frontend:9095
metrics_generator:
registry:
external_labels:
source: tempo
cluster: k8s-prod
storage:
path: /var/tempo/generator/wal
remote_write:
- url: http://prometheus:9090/api/v1/write
send_exemplars: true
traces_storage:
path: /var/tempo/generator/traces
processor:
service_graphs:
dimensions:
- service.namespace
- deployment.environment
span_metrics:
dimensions:
- http.method
- http.status_code
- http.route
overrides:
defaults:
metrics_generator:
processors: [service-graphs, span-metrics]
Tempo + Grafana 통합
Tempo의 진정한 힘은 Grafana와의 통합에서 나온다. TraceQL을 사용하여 트레이스를 쿼리하고, 로그(Loki)와 메트릭(Prometheus/Mimir)을 트레이스와 상호 연결할 수 있다.
Grafana 데이터소스 설정에서 Tempo를 추가하고, Trace to Logs, Trace to Metrics 기능을 활성화하면 트레이스의 특정 Span에서 관련 로그와 메트릭으로 바로 점프할 수 있다. 이것이 Grafana 스택의 핵심 차별점인 "상관관계 분석(Correlation)"이다.
TraceQL 쿼리 예제
Tempo 2.0부터 도입된 TraceQL은 트레이스 전용 쿼리 언어다.
// 에러 상태인 Span을 가진 트레이스 검색
{ status = error }
// 특정 서비스에서 1초 이상 걸린 Span 검색
{ resource.service.name = "order-service" && duration > 1s }
// HTTP 500 에러를 반환한 Span 검색
{ span.http.status_code = 500 }
// 두 서비스 간의 호출 관계 검색
{ resource.service.name = "api-gateway" } >> { resource.service.name = "payment-service" }
트레이싱 백엔드 비교 (Jaeger vs Tempo vs Zipkin)
트레이싱 백엔드를 선택할 때 환경과 요구사항에 맞는 도구를 선택하는 것이 중요하다. 주요 트레이싱 백엔드를 비교한다.
| 항목 | Jaeger | Grafana Tempo | Zipkin | AWS X-Ray |
|---|---|---|---|---|
| 개발 주체 | Uber (CNCF Graduated) | Grafana Labs | Twitter (현 X) | AWS |
| 스토리지 | Elasticsearch, Cassandra, Kafka | S3, GCS, Azure Blob | Elasticsearch, MySQL, Cassandra | AWS 자체 스토리지 |
| 인덱싱 | 전체 인덱싱 | 인덱스 없음 (Trace ID 기반) | 전체 인덱싱 | 자체 인덱싱 |
| 쿼리 | 서비스, 태그, 시간 기반 검색 | TraceQL, Trace ID 검색 | 서비스, 태그, 시간 기반 검색 | Filter Expressions |
| GB당 스토리지 비용 | 높음 (ES 인덱싱) | 매우 낮음 (오브젝트 스토리지) | 높음 (ES 인덱싱) | 중간 (관리형) |
| OTLP 지원 | 네이티브 (v2) | 네이티브 | 별도 Collector 필요 | 별도 SDK/Collector |
| 스케일링 | 수평 확장 가능 | 수평 확장 우수 | 제한적 | 자동 (관리형) |
| UI | 자체 UI (우수) | Grafana (탁월) | 자체 UI (기본) | AWS 콘솔 |
| 메트릭 생성 | SPM (v2) | Metrics Generator | 없음 | 자체 메트릭 |
| 로그 연동 | 제한적 | Loki 네이티브 연동 | 없음 | CloudWatch 연동 |
| 적합한 환경 | 독립 트레이싱 시스템 | Grafana 스택 사용 환경 | 소규모/학습 | AWS 네이티브 |
선택 가이드
- Jaeger: 독립적인 트레이싱 시스템이 필요하고, 풍부한 검색 기능이 중요하며, Elasticsearch/Cassandra 운영 역량이 있는 팀
- Grafana Tempo: 이미 Grafana, Loki, Prometheus/Mimir를 사용하고 있으며, 비용 효율이 중요하고, 대규모 트레이스를 처리해야 하는 환경
- Zipkin: 빠른 프로토타이핑이나 학습 목적, 또는 레거시 Zipkin 형식과의 호환이 필요한 경우
- AWS X-Ray: AWS 서비스(Lambda, ECS, EKS)를 주로 사용하고, 관리형 서비스를 선호하는 환경
샘플링 전략과 비용 최적화
프로덕션 환경에서 모든 트레이스를 수집하면 스토리지 비용과 네트워크 부하가 급증한다. 효과적인 샘플링 전략은 비용과 가시성 사이의 균형을 맞추는 핵심이다.
Head-based 샘플링
요청이 시작될 때 샘플링 여부를 결정한다. 구현이 단순하지만, 에러 트레이스를 놓칠 수 있다.
# Python에서 Head-based 확률적 샘플링 설정
from opentelemetry.sdk.trace.sampling import TraceIdRatioBased, ParentBased
# ParentBased: 부모 Span이 샘플링되었으면 자식도 샘플링
# 부모가 없는 루트 Span은 10% 확률로 샘플링
sampler = ParentBased(root=TraceIdRatioBased(0.1))
provider = TracerProvider(
resource=resource,
sampler=sampler,
)
Tail-based 샘플링
트레이스가 완성된 후 전체 Span을 보고 샘플링 여부를 결정한다. OpenTelemetry Collector의 tail_sampling 프로세서를 사용하며, 에러 트레이스나 지연이 큰 트레이스를 100% 수집할 수 있다. 단, Collector에 메모리 부하가 발생하므로 decision_wait 시간과 num_traces 설정을 환경에 맞게 조정해야 한다.
비용 최적화 전략
- 계층별 샘플링: 정상 트래픽은 5~10%, 에러/느린 요청은 100% 수집
- 서비스별 차등 샘플링: 핵심 서비스는 높은 비율, 내부 헬스체크는 0%
- 스토리지 티어링: 최근 데이터는 빠른 스토리지, 오래된 데이터는 저비용 스토리지
- TTL 설정: 트레이스 보존 기간을 7~14일로 제한 (대부분의 디버깅은 48시간 내 발생)
- Attribute 필터링: 불필요한 Span Attribute를 Collector에서 제거하여 데이터 크기 축소
운영 시 주의사항과 트러블슈팅
Context Propagation 누락
분산 트레이싱에서 가장 흔한 문제는 컨텍스트 전파 누락이다. 서비스 간 호출에서 traceparent 헤더가 전달되지 않으면 트레이스가 끊어진다.
증상: Jaeger/Tempo에서 트레이스를 보면 Span이 하나밖에 없거나, 서로 다른 Trace ID로 분리되어 있다.
원인과 해결:
- HTTP 클라이언트 라이브러리의 자동 계측이 누락된 경우:
RequestsInstrumentor().instrument()또는otelhttp.NewTransport()적용 - 메시지 큐(Kafka, RabbitMQ)를 통한 호출에서 컨텍스트가 전파되지 않는 경우: 메시지 헤더에 traceparent를 수동으로 주입/추출
- gRPC 인터셉터가 적용되지 않은 경우:
otelgrpc.UnaryClientInterceptor()추가
Collector 병목과 백프레셔
트래픽이 급증하면 Collector가 처리량을 감당하지 못해 Span이 누락될 수 있다.
모니터링 지표:
otelcol_exporter_send_failed_spans: 내보내기 실패한 Span 수otelcol_processor_batch_timeout_trigger_send: 타임아웃으로 인한 강제 전송otelcol_receiver_refused_spans: 수신 거부된 Span 수
해결:
memory_limiter프로세서를 반드시 설정하여 OOM 방지- Collector를 수평 확장하고 로드밸런서 뒤에 배치
batch프로세서의send_batch_size와timeout을 조정
높은 카디널리티 Attribute
Span Attribute에 사용자 ID, 세션 ID, 요청 본문 등 카디널리티가 높은 값을 넣으면 인덱싱 비용이 폭증한다 (특히 Jaeger + Elasticsearch 환경).
가이드라인:
- Attribute 값의 카디널리티는 수천 이하로 유지
- 고유 식별자는 Span Attribute 대신 Span Event나 로그에 기록
- Jaeger의
ES_TAGS_AS_FIELDS_ALL=false로 설정하고 필요한 태그만 인덱싱
실패 사례와 복구 절차
사례 1: Collector OOM으로 인한 트레이스 유실
상황: Tail-based 샘플링을 사용하는 Collector에서 트래픽 급증으로 메모리 사용량이 한계를 초과하여 프로세스가 종료되었다. 약 5분간 모든 트레이스가 유실되었다.
근본 원인: tail_sampling 프로세서의 num_traces가 50,000으로 설정되어 있었으나, 피크 시간에는 초당 10,000건의 새 트레이스가 유입되었다. decision_wait이 30초로 설정되어 최대 300,000개의 트레이스를 메모리에 보관해야 했다.
복구 절차:
- Collector Pod 자동 재시작 확인 (Kubernetes liveness probe)
num_traces를 200,000으로 증가,decision_wait을 10초로 축소memory_limiter의limit_mib를 실제 Pod 메모리 한계의 80%로 설정- Collector 인스턴스를 3개로 수평 확장
예방 조치: Collector의 메모리 사용량에 대한 알림 규칙을 설정하고, 자동 스케일링(HPA)을 적용한다.
사례 2: Elasticsearch 인덱스 폭증으로 인한 Jaeger 장애
상황: 새로운 서비스를 배포한 후 Span Attribute에 요청 바디 전체를 포함하는 계측이 추가되었다. 24시간 만에 Elasticsearch 디스크 사용량이 95%를 초과하여 인덱스 쓰기가 차단되었다.
근본 원인: 개발자가 디버깅 목적으로 span.set_attribute("request.body", json.dumps(request_body))를 추가했으나, 이 Attribute의 평균 크기가 10KB였고 초당 1,000건의 요청이 발생하여 일일 약 800GB의 추가 데이터가 생성되었다.
복구 절차:
- 문제가 된 서비스의 Span Attribute를 제거하는 핫픽스 배포
- Elasticsearch의 디스크 워터마크를 일시적으로 조정하여 쓰기 재개
- 문제 기간의 인덱스를 수동 삭제하여 디스크 확보
- Collector에 Attribute 크기 제한 프로세서 추가
예방 조치: Collector 레벨에서 attributes 프로세서를 사용하여 Attribute 값 크기를 제한하고, CI/CD 파이프라인에서 계측 코드 리뷰를 의무화한다.
사례 3: 클럭 스큐로 인한 비정상적인 Span 순서
상황: Jaeger UI에서 트레이스를 볼 때 자식 Span이 부모 Span보다 먼저 시작되거나, Span 시간이 음수로 표시되었다.
근본 원인: 컨테이너 호스트 노드 간 시간 동기화(NTP)가 정상 작동하지 않아 최대 500ms의 클럭 스큐가 발생했다.
복구 절차:
- 모든 노드에서 NTP 동기화 상태 확인:
chronyc tracking - NTP 서버 설정 수정 및 강제 동기화
- 클럭 스큐가 큰 기간의 트레이스 데이터는 무시
예방 조치: Kubernetes 노드에 chrony 또는 systemd-timesyncd를 설정하고, NTP 오프셋에 대한 모니터링 알림을 구성한다.
마치며
분산 트레이싱은 마이크로서비스 아키텍처에서 필수적인 관측 가능성 도구다. OpenTelemetry를 통해 벤더 중립적으로 계측하고, Jaeger 또는 Grafana Tempo를 백엔드로 사용하면 프로덕션 환경에서 요청 흐름을 투명하게 추적할 수 있다.
핵심 정리:
- OpenTelemetry로 계측을 표준화한다. 자동 계측으로 기본 골격을 만들고, 수동 계측으로 비즈니스 로직을 보완한다.
- OpenTelemetry Collector를 중간에 배치한다. 재시도, 샘플링, 라우팅을 중앙에서 관리한다.
- 백엔드는 환경에 맞게 선택한다. Grafana 스택이라면 Tempo, 독립 시스템이라면 Jaeger가 적합하다.
- Tail-based 샘플링으로 비용을 최적화한다. 에러와 지연이 큰 요청은 반드시 수집하고, 정상 요청은 낮은 비율로 샘플링한다.
- 운영 파이프라인을 모니터링한다. Collector와 백엔드 자체의 메트릭을 수집하고 알림을 설정한다.
분산 트레이싱을 도입할 때 가장 중요한 것은 "모든 것을 계측하려 하지 않는 것"이다. 핵심 사용자 여정(Critical User Journey)을 먼저 정의하고, 해당 경로의 서비스를 우선 계측한 후 점진적으로 확대하는 것이 현실적인 접근이다.