AWS Distro for OpenTelemetry (ADOT) にわかによるキャッチアップ 個人メモ
hassaku63Space で喋ることになったので、多少なり調べておくことにした。
これ。
とりあえずハッシュタグは #adot_chatting としておく。
免責
ADOT と OTel はよくわからんので、違ったこと書くかもしれない。よってここに書いてあるすべての情報は、その正しさについて一切保証しません
hassaku63OpenTelemetry 自体は分散トレースの仕組みと、それをサポートするパッケージを指す用語、という認識。
んで、似たような立ち位置の X-Ray については以前に調べたことがあるし、多少なり使っているのでなんとなく感覚はわかる。
X-Ray と X-Ray SDK については、大昔覚えたてのころに軽くプレゼンしてた話があるので貼っておくことにする
概念的には「1つのユーザー要求を満たすために動作するあらゆるコンポーネント間での流れをキャプチャしたい」が根源的なモチベであり、本質的にはサービスの構成要素に対して横断的に適用できるログ的な性格をした何か、と理解している。
ユーザー要求があったとき、それを満たすために upstream -> downstream へと制御が渡されていく（例えば SQS とか EventBridge を介したり、コンテナ間で通信したり）わけだが、それらのサービスコンポーネント間でやり取りされる HTTP Request/Response にトレース用の特別なヘッダを ID 等の情報を付与して埋め込む仕組みを入れておいて、downstream にリクエストが発生する場合にはそのヘッダ値を部分的に引き継ぐことで要求に対応する ID の一意性を保てるようにしよう、というのがトレースの基本的な考え方。（これは SDK の使用やサービス統合の機能で満たすことになる）
この原理によって、1件の要求を処理のために複数サービスコンポーネントをまたいでも、トレースヘッダが持つ ID が一意ならその一連のデータはある特定のユーザー要求に紐づくものとして認識できるようになる。マイクロサービス的なアーキテクチャが一般的になったことでサービスコンポーネントも分散することが多くなったので、そこで横断的に1ユーザー要求に対する「トレース」が取れるなら、何かが起こってユーザーに不利益が出たとしてもそれを後追いできるようになるから嬉しいでしょう？・・・と、言っているのが分散トレースの意義（と私なりには解釈している）
で、ここからは主要な用語の話。
X-Ray における「トレース」は上記の概念で言うところの「1件のユーザー要求（に紐づく全部のイベント）」ということになる。トレースの構成要素には「セグメント」という概念があって、これは親子関係を持つことができる。upstream 側でキャプチャされたセグメントが親で、そこから派生してリクエストが流れた downstrem の側でキャプチャされるセグメントが子になる...ように作られている。
※厳密には downstream 側のやつは「サブセグメント」と用語が区別されている
こんな感じのノリで、それぞれのサービスコンポーネントでトレース用ヘッダを部分的に引き回していくわけだが、実態としてはそのトレース情報はどこかしらに送信しないと閲覧ができない。私たちが直接意識することは少ないと思うが、そこらへんは各サービスコンポーネントに（暗黙的 or 明示的な）サイドカー的な agent がいて、そいつが中央のトレース収集用のサーバー (AWS managed) に対していい感じに送りつけているような動きになる。SDK 使って明示的に "Instrument" した場合は、それも agent を通して送信される。
このへんの概念が OTel ではどうなるかというと、だいたい以下のような対応関係で説明できる。
| X-Ray | OTel |
|---|---|
| トレース | Trace |
| セグメント | Span (root span) |
| サブセグメント | Span (not root) |
多分 OTel のがシンプル。ネスト可能な親子関係が全部 Span という用語で統一されている。