【CNDW2024】大規模環境でのOpenTelemetry Collector運用とOpAMPの活用

CloudNative Days Winter 2024で「大規模システムへのOpenTelemetry Collector導入の勘所とOpAMPに見る未来」と題したセッションが公開された。担当したのは、Datadog Japanの逆井啓佑氏。大規模なシステム環境においてOpenTelemetry Collectorをどのように導入・運用するか、そしてその管理を効率化するためのOpAMPについて解説した。

オブザーバビリティの基本とOpenTelemetryの役割

セッションは、まず「オブザーバビリティとは何か」という基本的な部分から始まり、システムの内部状態を推論するために必要なテレメトリーシグナルの重要性についても紹介された。

逆井氏は、「オブザーバビリティとは、外部シグナルからシステムの内部状態を推論する能力です」と語り、オブザーバビリティの本質的な目的を明確にした。システムの健全性を維持し、異常を迅速に検知するためには、ログ、トレース、メトリクス、プロファイルなど主要なテレメトリーシグナルが不可欠であり、それらを統合的に管理することが求められると強調した。

その後、OpenTelemetry（略称はOTel）の役割について紹介。「OpenTelemetryはCNCFのプロジェクトで、テレメトリーの標準仕様を策定し、多言語対応の計装ライブラリを提供しています」と語り、Goをはじめとする複数のプログラミング言語向けに計装ライブラリが提供されていることも紹介した。

イントロダクション（OpenTelemetry）

さらにOpenTelemetryの重要な特徴であるコード改変不要の「ゼロコード計装」が提供されていることに触れ、これによって開発者の負担を軽減しつつ、監視データの収集を容易にできると説明した。

OTel Collectorの構成と基本機能

次にOpenTelemetry Collectorについて、逆井氏はその役割と基本構成を解説した。OTel Collectorは、システムから収集したテレメトリーシグナルを処理し、適切なバックエンドに送信するゲートウェイのような役割を果たす。システム監視において重要な存在で、大規模環境ではとくに必要不可欠なコンポーネントである。

「OTel Collectorは、受信、処理、送信を行うエージェントであり、レシーバー、プロセッサー、エクスポーター、コネクターの四つのコンポーネントで構成されます」と逆井氏は説明し、それぞれのコンポーネントについて詳しく紹介した。レシーバーはデータを受信し、プロセッサーは必要に応じてデータを加工し、エクスポーターが最終的にバックエンドへ送信する。さらに異なるテレメトリーパイプラインを繋ぐ役割を担うコネクターも存在し、柔軟なデータ処理を可能にする。

続いてOTel Collectorの公式ディストリビューションについても解説。公式に四つのディストリビューションが提供されており、それぞれの特徴や用途が異なる。最小限のコンポーネントを含むコアディストリビューション、すべてのコンポーネントを含むコントリビューションディストリビューション、Kubernetes環境向けのKubernetesディストリビューション、そしてOTLPコンポーネントのみを含むOTLPディストリビューションがある。「OTelでは、OTel Collector Builderを使用して、必要なコンポーネントだけを含むカスタムビルドを作成できます」と逆井氏は語るとともに、大規模運用ではカスタムビルドが推奨されることを強調した。

OpenTelemetry Collector について

システム規模に応じたCollectorの配置戦略

OTel Collectorの導入方法について、逆井氏は三つの主な構成パターンを紹介した。まず最もシンプルな構成として、そもそもOTel Collectorを使用していない方法が挙げられた。この構成では、各アプリケーションがOTel SDKを用いて直接監視バックエンドへデータを送信する。しかしこの方法ではホストメトリクスの収集ができず、監視ツールを変更する際にはアプリケーション側の設定を変更する必要があるといった欠点がある。

次に各ノードにOTel Collectorを配置する方法だ。この構成では、ノードごとにOTel Collectorを設置し、各アプリケーションのデータを収集・集約することで、環境情報のタグ付けが可能となり、アプリケーション側の負荷を軽減できる。「この構成であれば、ノードごとのテレメトリー情報を効率的に収集できます」と逆井氏は語り、とくにKubernetes環境ではDaemonSetなどを利用して実装するのが一般的であると説明した。

OpenTelemetry Collector を運用する際の構成について

最後に、多段構成の導入について詳しく解説した。前段のOTel Collectorで負荷を軽減し、詳細なデータ処理を行うことで、よりスケーラブルなシステムを実現できる。「多段構成を採用することで、リソースの最適化とスケーラビリティの向上を実現できます」と逆井氏は語り、とくにテールベースサンプリングを適用する際に多段構成が有効であることを説明した。

テールベースサンプリング（Tail-Based Sampling）とは、すべてのトレースデータをいったん収集した後、特定の条件に基づいて保存するかどうかを決定する手法だ。従来のヘッドベースサンプリング（Head-Based Sampling）では、トレースが開始される段階でランダムにサンプリングが行われるが、その方法では重要なエラーや異常なトレースを取りこぼしてしまう可能性がある。一方でテールベースサンプリングでは、リクエスト全体を評価したうえで、エラーを含むトレースや処理時間が異常に長いトレースのみを選択的に保存することができる。そのためより重要なデータを効率的に収集し、分析に活用することが可能となる。

とくにOpenTelemetryにおいては、前段のOTel Collectorでトレースデータを収集し、後段のOTel Collectorでテールベースサンプリングを適用することで、システム全体の負荷を抑えながらも、分析に必要なデータを最適な形で保存できる。「この構成を活用することで、大規模環境でも効率的なトレース管理が可能になります」と逆井氏は語り、多段構成の重要性を改めて強調した。

OpAMPによるOTel Collectorのリモート管理

セッションの後半では、OpAMP（Open Agent Management Protocol）について詳しく解説した。OpAMPは、大規模なデータ収集エージェントをリモートで管理するためのネットワークプロトコルであり、エージェントのリモート設定や状態監視を可能にする技術だ。

OpAMP と OpenTelemetry Collector

OpAMPは、OpAMPサーバーとOpAMPクライアントという2つの主要なコンポーネントで構成される。OpAMPサーバーは管理プレーンとして機能し、OpAMPクライアントはエージェント側で動作し、リモートからの指示を受け取る。OpenTelemetry CollectorはこのOpAMPクライアントとして機能し、OpAMPを活用することで、リモートからCollectorの設定を動的に変更したり、エージェントの状態をリアルタイムで監視したりすることが可能になる。

またOpAMPを活用することで、テールベースサンプリングをリモートで適用できる。逆井氏は「後段のOTel Collectorでテールサンプリングのプロセッサーを使い、必要なデータのみを保存することが可能になります」と説明した。これにより、OpAMPを利用した管理の柔軟性がさらに向上する。

この後、実際にOpAMPを用いてOpenTelemetry Collectorをリモート設定するデモンストレーションが行われ、エージェントの構成変更がどのように適用されるのかが示された。デモでは、OpAMPを活用することでリモートからCollectorの設定を変更し、即座に反映できるようすが実演され、その効果が具体的に確認された。

さらに、まとめに入る前のトピックとして、Kubernetes環境におけるOpAMPの活用についても言及した。逆井氏は、「KubernetesでOpenTelemetryを利用する場合、OpenTelemetry OperatorにはOpAMPブリッジという機能があり、Supervisorに対応しています」と付け加えた。このOpAMPブリッジを利用することで、Kubernetes環境内でOTel Collectorのリモート管理が容易になり、ヘルス状態のレポートやリモート設定の適用が可能になることが説明された。

最後に逆井氏は、「OpAMPはまだ事例が少ないものの、今後ステータスが安定してくるとOTel Collectorの管理に欠かせない機能になっていくと考えられます。Collectorを運用している方は、OpAMPのアップデートをウォッチしていくと良いでしょう」と語り、OpAMPの今後の進化と活用の可能性に注目することを推奨して、セッションを締めくくった。