Jaeger統合実装パターン - all-in-oneから本番構成まで ​

Jaegerはオープンソースの分散トレーシングシステムで、OpenTelemetryの標準的なバックエンドとして広く採用されています。このセクションでは、OpenTelemetryから収集したトレースデータをJaegerに送信する複数の実装パターンを、小規模な開発環境から本番運用まで段階的に解説します。

Jaegerのアーキテクチャ概要 ​

Jaegerは複数のコンポーネントで構成されています。実装パターンにより、これらのコンポーネントの配置が異なります。

┌──────────────────────────────┐
│   アプリケーション             │
│   (OpenTelemetry SDK)        │
└──────────────┬───────────────┘
               │
               ├─→ [パターン1] Jaeger Collector (直接送信)
               │
               ├─→ [パターン2] Jaeger Agent → Collector
               │
               └─→ [パターン3] OpenTelemetry Collector → Jaeger
                    (フィルタリング・サンプリング)
                         ↓
                  ┌──────────────────┐
                  │ Jaeger Collector │
                  │  + Storage       │
                  │  + Query (UI)    │
                  └──────────────────┘

パターン1：All-in-One構成（開発環境） ​

最もシンプルな構成です。Jaegerの全機能（Collector、Storage、Query）が単一プロセスで動作します。

用途: 開発環境、動作確認、トレーシング技術の学習

Dockerで起動:

bash
docker run -d \
  --name jaeger \
  -p 16686:16686 \
  -p 4317:4317/tcp \
  jaegertracing/all-in-one:latest

このコマンドでJaegerが起動します：

  • ポート16686: Web UI（トレース検索・可視化）
  • ポート4317: OpenTelemetry Protocol (OTLP) gRPC エンドポイント

アプリケーション設定:

OpenTelemetryで収集したトレースを、環境変数でJaegerに送信するよう設定します。

bash
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

アプリケーション側では、OpenTelemetry SDKを初期化する際にこの設定が自動的に使用されます。実際の設定方法は使用言語によって異なりますが、基本的にはこれだけで十分です。

メリット・デメリット:

  • ✅ セットアップが極めてシンプル
  • ✅ 追加インフラ不要
  • ❌ ストレージはメモリのみ（再起動で消失）
  • ❌ スケーラビリティなし（本番環境には不適切）

パターン2：Collector構成（小〜中規模本番環境） ​

OpenTelemetry CollectorをJaegerの前段に配置し、フィルタリング・サンプリング・バッチ処理を行う構成です。

┌──────────────────────────┐
│  アプリケーション群       │
│ (OpenTelemetry計装)     │
└──────────────┬───────────┘
               │ OTLP gRPC
         ┌─────▼─────┐
         │ OTel      │
         │ Collector │  (サンプリング、フィルタリング)
         └─────┬─────┘
               │ Jaeger Protocol
         ┌─────▼──────────────────┐
         │ Jaeger Collector       │
         │ + Elasticsearch/       │
         │   Cassandra            │
         └────┬───────────────────┘
              │
         ┌────▼────────┐
         │ Jaeger UI   │
         │ (Query)     │
         └─────────────┘

YAML設定例（OpenTelemetry Collector）:

yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 10s
    send_batch_size: 1024
  sampling:
    sampling_percentage: 10

exporters:
  jaeger:
    endpoint: jaeger-collector:14250
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, sampling]
      exporters: [jaeger]

重要なプロセッサー:

  • Batch: トレースをバッチで送信。ネットワークオーバーヘッド削減
  • Sampling: 全トレースの10%のみを保存。大規模環境でストレージ削減

メリット・デメリット:

  • ✅ データ処理をCollectorで一元化
  • ✅ サンプリングでストレージコスト削減
  • ✅ Collectorが複数インスタンスで水平スケール可能
  • ❌ セットアップが複雑化
  • ❌ Collectorの運用が追加負担

パターン3：分散構成（大規模本番環境） ​

複数のJaeger Agentをホスト上にデプロイし、Collectorに集約する構成です。スケーラビリティと耐障害性に優れています。

┌────────────────────────────────────────┐
│ 複数ホスト / コンテナ                  │
├────────────────┬─────────────────────┤
│ Host A         │ Host B / Host C...  │
│  ┌─────────┐   │  ┌─────────┐       │
│  │アプリ   │   │  │アプリ   │       │
│  └────┬────┘   │  └────┬────┘       │
│       │        │       │            │
│  ┌────▼─────┐  │  ┌────▼─────┐    │
│  │Jaeger    │  │  │Jaeger    │    │
│  │Agent     │  │  │Agent     │    │
│  └────┬─────┘  │  └────┬─────┘    │
│       │        │       │            │
└───────┼────────┼───────┼────────────┘
        │        │       │
        │        └─→ [OpenTelemetry Collector]
        │
        └─────────────┬──────────────┐
                      │ (バッチ化)    │
                 ┌────▼────────────┐
                 │Jaeger Collector │
                 │+ Elasticsearch/ │
                 │  Cassandra      │
                 └────┬────────────┘
                      │
                 ┌────▼──────┐
                 │Jaeger UI  │
                 │(Query)    │
                 └───────────┘

デプロイ方法（Docker Compose例）:

各ホスト上でJaeger Agentをサイドカーコンテナとして実行：

yaml
agent:
  image: jaegertracing/jaeger-agent:latest
  ports:
    - "6831:6831/udp"
    - "16686:16686"
  command: ["--reporter.logLevel=debug"]
  environment:
    - COLLECTOR_ZIPKIN_HOST_PORT=collector:9411

メリット・デメリット:

  • ✅ ホスト単位でのローカルエージェントによる低レイテンシ
  • ✅ ネットワーク分断時のローカルバッファリング
  • ✅ スケーラビリティに優れた構成
  • ❌ 全ホストへのAgentデプロイが必要
  • ❌ インフラ管理の複雑さ増加

Kubernetes環境でのデプロイ ​

Kubernetesでは、Helm ChartやKubernetesマニフェストを使用してJaegerをデプロイできます。

Helm Chartを使用した導入（推奨）:

bash
helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
helm install jaeger jaegertracing/jaeger \
  --namespace observability \
  --create-namespace

アプリケーションポッドでのOTLP設定:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-app
spec:
  containers:
  - name: app
    image: myapp:latest
    env:
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: http://jaeger-collector:4317
    - name: OTEL_SERVICE_NAME
      value: sample-service

メリット・デメリット:

  • ✅ Kubernetes OperatorやHelm Chartで簡潔にデプロイ
  • ✅ スケーラビリティはクラスタで自動管理
  • ✅ セルフヒーリング機能あり
  • ❌ Kubernetesクラスタが前提
  • ❌ Namespace管理など追加設定が必要

トレース送信方式の比較 ​

実装パターン間でのトレース送信方式に違いがあります。

┌────────────────────────────────────────┐
│       アプリケーション                  │
│     (OpenTelemetry SDK)               │
└────────────────┬───────────────────────┘
                 │
     ┌───────────┼────────────┐
     │           │            │
     │ [方式A]   │ [方式B]    │ [方式C]
     │ 直接送信  │ Agent経由  │ Collector経由
     │           │            │
     ▼           ▼            ▼
  Jaeger     Jaeger      OpenTelemetry
  Collector  Agent       Collector
     │          │            │
     ├──────────┼────────────┤
     │          │            │
     └──────────┼────────────┘
                ▼
          Jaeger Collector
          + Storage
  • 方式A（直接送信）: レイテンシが低いが、Collectorは単一障害点
  • 方式B（Agent経由）: Agentがローカルバッファリング。ネットワーク耐性向上
  • 方式C（Collector経由）: サンプリング等の処理が可能。高度なデータ制御に向く

実装上の注意点 ​

サンプリング戦略 ​

本番環境ではサンプリング率を調整してストレージコストを削減します。

  • 開発環境: 100%（全トレース記録）
  • ステージング環境: 10-50%
  • 本番環境: 1-10%（高トラフィック環境では0.1%未満も検討）

リテンション管理 ​

Jaeger UIで確認できる保持期間を設定します。

  • 開発環境: 1-7日
  • 本番環境: 7-30日

古いトレースデータはストレージから自動削除します。

認証・セキュリティ ​

本番環境では認証とTLS暗号化は必須です：

yaml
exporters:
  jaeger:
    endpoint: https://jaeger-collector.example.com:14250
    tls:
      insecure: false
      cert_file: /path/to/cert.pem
      key_file: /path/to/key.pem

まとめ：パターン選択ガイド ​

実装パターンの選択は環境規模と要件で判断します：

パターン環境スケールセットアップ複雑性
All-in-One開発小最小
Collector本番(小〜中)中中
分散構成本番(大規模)大高
Kubernetesクラウド中〜大中

実装のポイント:

  1. 最初はAll-in-Oneで動作確認
  2. 本番環境ではCollectorまたはKubernetesパターンを採用
  3. サンプリング率は環境に応じて細かく調整
  4. セキュリティ対策を早期から組み込む

次の記事: トレース検索・分析ワークフロー では、収集したトレースデータから効率的に問題を特定し、パフォーマンス分析を行う実務的なワークフローを解説します。