オープンソース分散トレーシング比較：Jaeger vs Zipkin vs Grafana Tempo でマイクロサービスを可視化する

マイクロサービスアーキテクチャでは、1つのユーザーリクエストが複数のサービスをまたいで処理されます。分散トレーシングはこのリクエストの経路・レイテンシ・エラーを可視化するObservabilityの重要な柱です。Jaeger・Zipkin・Grafana TempoはオープンソースとしてOpenTelemetryと連携して使えます。

分散トレーシングが解決する問題

マイクロサービスのデバッグで起きること:

• API GatewayのレイテンシがP99で1秒を超えているが、どのサービスが遅いかわからない
• ユーザーからエラーの報告があるが、どのマイクロサービスで発生したか特定できない
• あるサービスが別のサービスを数十回呼び出しているN+1問題に気づかない

分散トレーシングはリクエストを「スパン（Span）」の木構造として記録し、これらを一目で可視化します。

OpenTelemetry: 標準化されたトレーシングAPI

現代の分散トレーシングはOpenTelemetry（OTel）を使って実装します。アプリケーションはOTel SDKでトレースを生成し、コレクターを経由してJaeger/Zipkin/Tempoに転送します。

# OpenTelemetryでPythonアプリを計装
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.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor

# トレーサープロバイダーの設定
provider = TracerProvider()
otlp_exporter = OTLPSpanExporter(endpoint="http://otel-collector:4317", insecure=True)
provider.add_span_processor(BatchSpanProcessor(otlp_exporter))
trace.set_tracer_provider(provider)

# FastAPIを自動計装（全エンドポイントのトレースを自動生成）
FastAPIInstrumentor.instrument_app(app)
RequestsInstrumentor().instrument()  # requestsライブラリの外部呼び出しも追跡

# カスタムスパンの作成
tracer = trace.get_tracer(__name__)

async def process_order(order_id: str):
    with tracer.start_as_current_span("process_order") as span:
        span.set_attribute("order.id", order_id)
        span.set_attribute("order.source", "web")

        with tracer.start_as_current_span("validate_inventory"):
            result = await check_inventory(order_id)
            span.set_attribute("inventory.available", result.available)

        with tracer.start_as_current_span("charge_payment"):
            await charge_card(order_id)

Jaeger

Uberが開発しCNCFに寄贈した分散トレーシングシステムです。サービストポロジーグラフ・スパン検索・パフォーマンス比較を提供します。

# Jaeger All-in-One（開発用）
docker run -d --name jaeger   -e COLLECTOR_OTLP_ENABLED=true   -p 6831:6831/udp   -p 6832:6832/udp   -p 5778:5778   -p 16686:16686   -p 4317:4317   -p 4318:4318   jaegertracing/all-in-one:latest

# UIは http://localhost:16686 でアクセス

# Kubernetes向けJaeger Operator
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      serverUrls: https://elasticsearch:9200
  ingress:
    enabled: true

Grafana Tempo

Grafanaエコシステムに統合された軽量・低コストのトレースバックエンドです。オブジェクトストレージ（S3・GCS）をバックエンドに使い、大量のトレースを安価に保存できます。Grafanaのダッシュボードで他のメトリクス・ログと横断的に確認できます。

# Grafana Tempoのdocker-compose設定
services:
  tempo:
    image: grafana/tempo:latest
    command: [ "-config.file=/etc/tempo.yaml" ]
    volumes:
      - ./tempo.yaml:/etc/tempo.yaml
      - tempo-data:/var/tempo
    ports:
      - "4317:4317"  # OTLPgRPC
      - "4318:4318"  # OTLPHTTP
      - "3200:3200"  # Tempo API

  grafana:
    image: grafana/grafana:latest
    volumes:
      - grafana-data:/var/lib/grafana
    environment:
      - GF_FEATURE_TOGGLES_ENABLE=traceqlEditor
    ports:
      - "3000:3000"

# tempo.yaml
server:
  http_listen_port: 3200

distributor:
  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
        http:
          endpoint: 0.0.0.0:4318

storage:
  trace:
    backend: s3
    s3:
      bucket: my-tempo-bucket
      endpoint: s3.amazonaws.com
      region: ap-northeast-1

機能比較表

比較項目	Jaeger	Zipkin	Grafana Tempo
OTel対応	✅	✅	✅
サービストポロジーグラフ	✅	⚠️	✅（Grafana）
トレース検索	✅	✅	✅ TraceQL
スケーラビリティ	✅	⚠️	✅
Grafana統合	✅	✅	✅ ネイティブ
メトリクス連携	✅	❌	✅ 深い統合
ログ連携	✅	❌	✅ Loki連携
ストレージバックエンド	Cassandra/ES	MySQL/ES	S3/GCS
運用コスト	中	低	低（オブジェクトストレージ）
UIの見やすさ	★★★★☆	★★★☆☆	★★★★★
ライセンス	Apache 2.0	Apache 2.0	AGPL 3.0
GitHub Stars	20k+	17k+	4k+

OpenTelemetry 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: 10s
  resource:
    attributes:
      - action: upsert
        key: environment
        value: production

exporters:
  jaeger:
    endpoint: jaeger-collector:14250
    tls:
      insecure: true
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [jaeger, otlp/tempo]

分散トレーシング・観測性ツールはDevOpsカテゴリ（/categories/devops）で一覧でき、セキュリティ監査ログ関連はセキュリティカテゴリ（/categories/security）でも探せます。

FAQ

Q. ログ・メトリクス・トレースの違いを教えてください。

A. Observabilityの三本柱: ログは「何が起きたか」の詳細な記録（エラーメッセージ・イベント）。メトリクスは「どのくらいの量・頻度で起きているか」の数値（CPU・リクエスト数・エラーレート）。トレースは「リクエストがどのサービスを経由してどれだけの時間がかかったか」の経路情報です。三つを組み合わせることで問題の全体像を把握できます。

Q. 小規模マイクロサービスにも分散トレーシングは必要ですか？

A. サービス数が3〜5個程度なら優先度は低く、まずは構造化ログ（JSON形式のログ）を整備することを推奨します。サービス数が10を超え・複数チームが開発・本番の障害対応に時間がかかる段階で導入するのが現実的です。新規サービスではOpenTelemetryで計装だけしておき、後からバックエンドを追加する「先に計装、後でバックエンド」戦略が効果的です。

Q. サンプリングレートはどう設定すべきですか？

A. 全トレースを保存すると大量のストレージが必要になります。一般的なアプローチ: Head-based sampling（最初のサービスでランダムに一定割合を記録・本番は1〜10%）またはTail-based sampling（レイテンシが高い・エラーが発生したリクエストは必ず記録）。Tempo+Grafanaを使うと「99パーセンタイルが2秒を超えたリクエスト」だけを遡って保存するアダプティブサンプリングが設定できます。

Q. Grafana TempoとJaegerを同時に使う構成はありますか？

A. はい。OpenTelemetry Collectorから両方にエクスポートする設定が可能です。Jaegerで詳細なサービストポロジー確認、Grafana TempoでGrafanaダッシュボードとのメトリクス連携、という使い分けをしているチームもあります。長期的にはどちらかに統一するのが管理のしやすさから推奨されます。

まとめ

ユースケース	推奨ツール
CNCFエコシステム・マイクロサービス	Jaeger
Grafana Prometheusと統合	Grafana Tempo
シンプルな分散トレーシング	Zipkin
OTel標準のコレクター	OpenTelemetry Collector

関連外部リソース

• Jaeger GitHubリポジトリ↗
• Grafana Tempo GitHubリポジトリ↗
• OpenTelemetry公式サイト↗
• Zipkin GitHubリポジトリ↗