OpenTelemetryをざっくり理解する
なぜOpenTelemetryが必要なのか
ざっくり図にまとめるとこんな感じです。
一昔前、システムは一枚岩で動作するのが基本でした。さらに、ログ、メトリクス、トレース（いわゆるオブザーバビリティの3本柱）もそれぞれ監視ツールとして独立していました。
この場合、システム全体で問題が発生すると原因の特定が困難です。それぞれの監視ツールを一つずつチェックしてボトルネックを探すしかなく、膨大な時間がかかります。
さらに現在は分散システムの時代です。単一システム内の問題だけでなく、システム間の連携も考慮する必要があり、原因特定はより難しくなっています。
そこで誕生したのがOpenTelemetryです。
OpenTelemetryを使うと、整理された相関データが得られます。相関データにより「横串」でデータを眺めることができ、ボトルネックの発見が容易になります。
また、OpenTelemetryはユニバーサルスタンダードとして広く採用されています。主要クラウドプロバイダー（AWS、Google Cloud、Azure）やDatadogなどのSaaSもOpenTelemetryに対応しています。
これによりベンダーロックインを回避でき、テレメトリーの送信先を自由に選択できます。
OpenTelemetryに関連する用語
OpenTelemetryには特有の用語が存在します。まずはそれらの概要を掴んでおきましょう。
-
テレメトリー
- システムが何をしているかを示すデータ
-
SpanContext
- スパンを識別するための情報
- テレメトリーを横断的に相関させるために必須の要素
- TraceID、SpanID など
-
トレース
- 1つのトランザクションに関連するスパンの集まり
- SpanContext（TraceID）によって相関づけられる
-
スパン
- トレースを構成する個々の処理単位
-
計装（インストゥルメンテーション）
- アプリケーションにテレメトリーデータを出力するコードを追加すること
-
OTLP
- OpenTelemetryプロトコル
- テレメトリーデータをCollectorやバックエンドに送信するための標準フォーマット
OpenTelemetryのアーキテクチャ
以下は、一般的なOpenTelemetryを採用しているシステムのアーキテクチャです。
OpenTelemetryが担うのは、ApplicationとOpenTelemetry Collectorの部分です。
バックエンドシステム（e.g. Cloud Trace）に送信したあと、どのようにテレメトリーデータを可視化するかは、各ベンダーの裁量に委ねられています。
計装によってアプリケーションから直接バックエンドに送信することも可能ですが、Collectorを挟むことが推奨されています。
アプリケーションは「データをCollectorに渡すだけ」で済み、以下の処理をCollectorに任せられます。
- 送信失敗時の再試行
- バッチ処理
- 暗号化
- 機密データの除去
これにより、アプリケーションはビジネスロジックに集中でき、テレメトリー送信の複雑さから解放されます。
計装の方法
計装には大きく分けて2つのアプローチがあります。
-
ホワイトボックスアプローチ（手動計装 / Manual Instrumentation）
- サービスやライブラリに直接テレメトリーコードを追加する
- アプリケーション固有の詳細なデータが取得できる
-
ブラックボックスアプローチ（自動計装 / Automatic Instrumentation）
- 外部エージェントやライブラリを利用してテレメトリーを生成する
- 既存のコードを変更せずに済む
どちらも一長一短があり、要件に応じて使い分けます。
まとめ
OpenTelemetryは、分散システム時代のオブザーバビリティを実現するための標準ツールです。ログ、メトリクス、トレースを統合し、相関データとして扱うことで、複雑なシステムのボトルネック特定を容易にします。
基本的な流れは以下の通りです。
- アプリケーションに計装を追加してテレメトリーデータを生成
- OpenTelemetry Collectorでデータを処理・変換
- 各種バックエンド（Cloud Trace、Datadogなど）に送信
Discussion