CLOUD SECURITY LAB

OpenTelemetry Collector: 複数のバックエンドにデータを賢く分散する方法 ⚖️

—

by

cslab
in

こんにちは！Observability（可観測性）環境を構築する際、増加するトラフィックに対応するために複数のバックエンドインスタンスを運用することがよくあります。OpenTelemetry Collectorを通じて収集された膨大なトレース、メトリック、ログデータを、これらのバックエンドインスタンスにどのように公平かつ効率的に分配できるでしょうか？🤔

本日は、複数のバックエンドにデータを安定して分散させる最適な方法について見ていきましょう。

🧐 もしかして、OTLP Exporterに複数のエンドポイントを設定すればいいのでは？

これは最初に思いつく簡単な方法です。OTLP（OpenTelemetry Protocol）エクスポーターの設定にエンドポイントのリストを追加する、というものです。

exporters:
  otlp:
    endpoint: backend-1:4317, backend-2:4317

しかし、この方法は私たちが望むロードバランシングとは少し異なります。OTLPエクスポーターに複数のエンドポイントを設定するのは、主にフェイルオーバーのために使用されます。🔄つまり、最初のエンドポイントに問題が発生した場合に次のエンドポイントに送信する方式なので、データが一方に偏る可能性があります。精巧に負荷を分散する機能とは言えません。

🚀 答えはこれ！Load Balancing Exporter です。

名前からもわかるように、このエクスポーターは複数のバックエンドインスタンスにデータを分散（ロードバランシング）する目的のために特別に設計されています。

Load Balancing Exporter (loadbalancing) は内部的にOTLPエクスポーターを使用し、受信したデータを複数のバックエンドに効果的に分配する役割を果たします。

主な特徴:

  • 多様な分散モードをサポート:
  • ラウンドロビン (Round Robin): 受信したリクエストを順番に各バックエンドに公平に分配します。⚖️
  • 一貫性ハッシュ (Consistent Hashing): トレースIDに基づいてハッシュを行い、常に同じトレースIDを持つスパンが同じバックエンドに送られることを保証します。これは、特定のトレース全体を1箇所で分析する際に非常に有用です。🔗
  • バックエンドの状態確認: 定期的にバックエンドの状態を確認し、問題のあるバックエンドは分配対象から除外して安定性を高めます。

このように、loadbalancingエクスポーターは、データを複数のバックエンドに均等に、そして意図した方法で分配するのに最も最適化された選択肢です。

⚠️ ちょっと待って、これらのコンポーネントと混同しないでください！

OpenTelemetry Collectorには様々なコンポーネントがあり、その役割が混同されがちです。データ分散に関連してよく混同される2つのプロセッサーについて見ていきましょう。（これらはエクスポーターではありません！）

1. Queued Retry Processor

このコンポーネントは、その名前の通り、再試行（Retry）とキュー（Queue）を管理する役割を担います。💪

  • 役割: エクスポーターがデータをバックエンドに送信するのに失敗した場合、すぐに破棄するのではなく、一時的にキューに保存してから再送信する役割を果たします。
  • 目的: 一時的なネットワーク問題などによるデータ損失を防ぎ、送信の信頼性を高めることが主な目的です。データ分散とは直接的な関連はありません。

2. Routing Processor (routing)

このコンポーネントは、受信したデータの属性を見てどこに送るかを決定する交通警察 🚦 の役割を果たします。

  • 役割: データに含まれる特定の属性（例：サービス名、環境情報など）を基準に、「このデータはAパイプラインに送る」、「あのデータはBパイプラインに送る」といった条件付きルーティングを実行します。
  • 目的: すべてのデータを均等に分割するのではなく、データの内容に応じて意図的に異なる宛先に送ることが主な目的です。

🏗️ アーキテクチャ構成図

OpenTelemetry (Otel) 環境でLoad Balancing Exporterを適用する例をご紹介します。

正確に言うと、「Load Balancing Exporter」という名前の単一コンポーネントがあるわけではありません。一般的なアーキテクチャは、複数のOTel Collector（コレクター）インスタンスを実行し、その前にロードバランサーを配置する方式です。アプリケーションのOtel Exporterは、このロードバランサーのアドレスのみを参照するように設定します。

この構造には、次のような大きな利点があります。

  • 高可用性 (High Availability): 複数のCollectorのうち1つに障害が発生しても、中断することなくテレメトリーデータを収集できます。
  • 拡張性 (Scalability): データ量が増加しても、Collectorインスタンスを追加するだけで簡単に拡張できます。

まず概念を理解すると、コードを把握しやすくなります。

[App 1] ---►                                 ---► [Collector 1]
[App 2] ---► [Load Balancer] (단일 Endpoint) ---► [Collector 2]
[App 3] ---►                                 ---► [Collector 3]

すべてのAppは単一のエンドポイントであるLoadBalancerにデータを送信し、LBが自らCollector1から3まで分散します。

アプリケーション（App）のエクスポーターは、ロードバランサーのアドレス（http://otel-collector-lb:4317）を1つだけ知っていれば十分です。トラフィックを複数のCollectorに分散する役割はロードバランサーが担当します。

🐍 Python適用例

最も一般的なOTLP Exporterを使用して、ロードバランサーの背後にあるCollectorにデータを送信するPythonコードの例です。

1. 必要なライブラリのインストール

pip install opentelemetry-api 
            opentelemetry-sdk 
            opentelemetry-exporter-otlp-proto-grpc

2. Exporter設定とデータ送信コード

アプリケーションコードでは、Exporterのエンドポイントをロードバランサーのアドレスに指定することが重要です。

import time
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.resources import Resource

# gRPCプロトコル用のOTLP Exporterをインポートします。
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# ----------------------------------------------------
# 1. 主要設定: Exporterのエンドポイントをロードバランサーのアドレスに指定
# ----------------------------------------------------
# 実際の環境では、KubernetesサービスアドレスやクラウドロードバランサーのDNSアドレスを使用します。
# gRPCのデフォルトポートは4317、HTTPは4318です。
LOAD_BALANCER_ENDPOINT = "otel-collector-lb:4317"

# サービス名などのリソースを定義します。
resource = Resource(attributes={
    "service.name": "my-python-app"
})

# TracerProviderを設定します。
provider = TracerProvider(resource=resource)

# OTLPSpanExporterインスタンスを作成し、エンドポイントを指定します。
otlp_exporter = OTLPSpanExporter(endpoint=LOAD_BALANCER_ENDPOINT, insecure=True) # insecure=Trueはローカルテスト用

# スパンをバッチ処理するBatchSpanProcessorを設定します。
processor = BatchSpanProcessor(otlp_exporter)
provider.add_span_processor(processor)

# OpenTelemetryのデフォルトTracerProviderとして設定します。
trace.set_tracer_provider(provider)

# アプリケーションのトレーサーを取得します。
tracer = trace.get_tracer(__name__)

# ----------------------------------------------------
# 2. 実際のデータ（Span）の生成と送信
# ----------------------------------------------------
def do_work():
    """예제 작업을 수행하고 스팬을 생성하는 함수"""
    with tracer.start_as_current_span("do_work") as span:
        print("작업을 수행 중입니다...")
        time.sleep(1)
        span.set_attribute("job.status", "completed")
        print("작업 완료!")

if __name__ == "__main__":
    do_work()
    
    # 実際のアプリケーションではこの部分は不要ですが、
    # 例では、スパンが送信される時間を確保するために追加しています。
    time.sleep(2) 
    print("텔레메트리 데이터 전송 완료.")

重要ポイント

>

上記のコードで、OTLPSpanExporter(endpoint=”otel-collector-lb:4317″, …) の部分が最も重要です。

>

アプリケーションはテレメトリーデータをどこに送るか、たった一つのアドレスを知っていればよいため、コードは非常にシンプルになります。バックエンドのCollectorが何台に増えても、アプリケーションコードを修正する必要はありません。

⚙️ OTel Collector 設定例

参考までに、ロードバランサーの背後で実行される各Collectorの設定ファイル（otel-collector-config.yaml）は非常にシンプルで、通常は同じ構成を持ちます。

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        # ロードバランサーからgRPCトラフィックを受信するポート（デフォルト: 4317）
        endpoint: 0.0.0.0:4317
      http:
        # ロードバランサーからHTTPトラフィックを受信するポート（デフォルト: 4318）
        endpoint: 0.0.0.0:4318

exporters:
  # 収集したデータをJaeger、Prometheus、クラウド監視サービスなどに送信します。
  logging: # 単純にコンソールにログを出力するExporter
    loglevel: debug

processors:
  batch:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [logging] # 実際にはJaeger、Tempo、AWS X-Rayなどに設定

このように、Otelでロードバランシングを実装することは、特定のExporterを使用するのではなく、標準的なアーキテクチャパターンを適用することに近いと言えます。

✨ 結論

OpenTelemetry Collectorで収集したデータを複数のバックエンドインスタンスに均等に分散して負荷を分けたい場合は、迷わずLoad Balancing Exporter (loadbalancing) を使用してください！これが、その目的のために生まれた最も確実で強力な方法です。

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です