SpeedData

システムトレース

AWS Kinesis 上で OpenTelemetry トレースヘッダを伝搬する方法: パート1

IPM ― 顧客体験と従業員体験向上のためのソリューション

2024年6月14日
翻訳: 逆井 晶子

この記事は米Catchpoint Systems社のブログ記事「How to propagate OpenTelemetry trace headers over AWS Kinesis: Part 1」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

AWS Kinesis における OpenTelemetry トレースヘッダの伝搬の複雑さを解説するシリーズへようこそ。
この3部構成の探索では、分散システムにおけるトレースヘッダの重要な役割を掘り下げ、AWS Kinesis に特有の課題を議論し、データ追跡を堅牢かつ一貫して維持するための革新的なソリューションを探ります。

トレースヘッダの伝搬を理解する

「トレースヘッダ」伝搬とは、OpenTelemetry の世界において、特定のリクエストに関連する識別子やその他のメタデータを分散システムのサービス間で運ぶメカニズムを指します。
この伝搬は、異なるシステムコンポーネント間で一貫したトレースコンテキストを維持するために重要です。

トレースヘッダとは何か？
トレースヘッダは、トレース ID、スパン ID、トレースフラグなどの情報で、HTTP リクエストやメッセージングプロトコルのヘッダに埋め込まれます。
トレース ID はシステム全体を通じたリクエストの旅を表し、スパン ID はその旅の中での特定の操作やサービスコールを指します。
トレースヘッダはどのように伝搬されるのか？
OpenTelemetry は、これらのトレースヘッダを一つのサービスから別のサービスにどのように転送するかを規定しています。
サービスがリクエストを受信すると、これらのヘッダを抽出し、トレース情報を記録し、ダウンストリームサービスへのアウトゴーイングリクエストにそれらを含めます。
これにより、リクエストのパスにある各サービスが統一されたトレースに寄与します。
クロスサービストレーシングの役割
トレースヘッダを伝搬することで、OpenTelemetry はクロスサービストレーシングを可能にします。
これは、リクエストの発生元からそれが通過するすべてのサービスまで、リクエストを追跡できることを意味し、分散システムにおけるリクエストの経路を一貫した視点で提供します。
トレース伝搬における相互運用性と標準化
OpenTelemetry は、W3C トレースコンテキストのような標準化されたトレースコンテキスト伝搬フォーマットに従います。
この標準化により、異なるトレーシングツールやプラットフォーム間の互換性と相互運用性が保証され、異なる可観測性ソリューションの統合や切り替えが容易になります。
分散システムにおけるトレース伝搬の重要性
マイクロサービスや分散アーキテクチャでは、単一のユーザリクエストが複数のサービスを含む可能性があります。
トレースヘッダの伝搬により、開発者やオペレーターはリクエストの全体のパスを視覚化でき、問題の診断、サービスの依存関係の理解、性能の最適化が容易になります。

AWS Kinesis におけるトレースヘッダ伝搬の課題を理解する

今日の急速に進化するデジタル環境では、分散アプリケーションを追跡および監視することが、性能と信頼性を確保するために重要です。
トレースヘッダ伝搬は、このプロセスの重要な部分であり、さまざまなサービス間でのリクエストの流れを追跡し、最適化するのに役立ちます。
HTTP ベースの通信では、ヘッダを通じたトレースの伝搬が簡単に行えるのに対し、AWS Kinesis のようなサービスでは、メタデータのレイヤーが存在しないため、異なる課題が発生します。

HTTP 通信では、通常、トレースヘッダはリクエストのボディとは別に HTTP ヘッダに追加されます。
これにより、トレース情報はメッセージの実際の内容を変更することなく伝搬されます。
OpenTelemetry などのツールは、標準的な HTTP リクエストとレスポンスサイクルの一環として、これらのヘッダを自動的に挿入および抽出するメカニズムを提供します。
このアプローチは非侵襲的（※）で、メッセージボディの完全性や形式に影響を与えません。

※訳注
非侵襲的とは、既存の状態や構造に物理的またはデータ的な影響を与えずに、付加的な操作や情報のやり取りを行うことです。

しかし、HTTP とは異なり、AWS Kinesis のような特定のサービスでは、各レコードにトレースコンテキストをシームレスに追加できる別個のメタデータまたはヘッダセクションをサポートしていません。
たとえば、AWS Kinesis では、各レコードはデータのブロブであり、ヘッダやメタデータを個別のレコードに直接添付するための組み込みのメカニズムはありません。
その結果、トレース情報を伝搬するには、実際のレコードを変更してこの情報を含める必要があります。

このブログシリーズでは、AWS Kinesis を通じたトレースヘッダ伝搬で直面する基本的な障害を探り、これらの課題を克服するための革新的で実践的なソリューションを検討します。
これらのソリューションは、トレースデータの伝送効率を向上させ、分散システムでの監視プロセスの効果を高めることを目指しています。

AWS Kinesis サービス上でトレースヘッダを伝搬するための現在のソリューションは何か？

AWS Kinesis では、プロデューサーとコンシューマー間でトレースヘッダを伝搬するために、プロデューサーが送信するレコード内にトレース情報を埋め込み、コンシューマー側でこれを抽出する方法が用いられます。
このプロセスにより、Kinesis ストリームを通じたデータの旅をトレースすることができ、分散システムでの監視やトラブルシューティングに不可欠です。

1. Kinesis レコードへのトレースヘッダの埋め込み（プロデューサー側）
  • プロデューサーアプリケーションが Kinesis ストリームにレコードを送信する際、レコード内にトレースコンテキスト情報を含める必要があります。 これは、トレース ID やスパン ID などのトレースヘッダをレコードのデータに追加することで実現できます。
  • トレースコンテキストは、OpenTelemetry SDK などのプロデューサーアプリケーションに統合されたトレーシングツールから取得できます。
  • このトレースコンテキストは、互換性と使いやすさを確保するために、W3C トレースコンテキストなどの標準形式に準拠している必要があります。
2. AWS Kinesis へのレコードの送信
  • AWS SDK を使用して、レコードを Kinesis ストリームに送信します。 各レコードのペイロードにトレースコンテキスト情報が含まれていることを確認してください。
  • トレースコンテキストの完全性と可読性を維持し、コンシューマーが正しく解釈できるようにすることが重要です。
3. Kinesis レコードからのトレースヘッダの抽出（コンシューマー側）
  • コンシューマー側では、Kinesis ストリームから読み取るアプリケーションやサービスは、各レコードからトレースコンテキスト情報を抽出する必要があります。
  • これには、レコードデータを解析してトレースヘッダを取得することが含まれます。
  • 抽出されたトレースコンテキストを使用して、プロデューサーが開始したトレースとコンシューマーの処理アクティビティをリンクさせる必要があります。
4. トレースの継続
  • トレースコンテキストを抽出した後、コンシューマーアプリケーションはそれを使用して独自の処理アクティビティに注釈を付け、プロデューサーが作成したスパンと論理的に接続されたスパンを作成する必要があります。
  • この継続的なトレーシングにより、データがプロデューサーから Kinesis を経由してコンシューマーに移動する全ライフサイクルを視覚化できます。

AWS Kinesis 上でトレースヘッダを伝搬するためにレコードを変更する際の課題は何か？

AWS Kinesis では、トレースヘッダを伝搬するためにレコードの元の内容を変更することは、いくつかの課題や潜在的な問題を引き起こす可能性があります。
元のメッセージにトレースヘッダを追加する必要があることは、データの完全性を維持し、メッセージサイズの増加を管理し、特定のデータフォーマットを期待する下流システムとの互換性を確保するなどの問題を引き起こします。
さらに、プロデューサーがデータにトレースコンテキストを埋め込み、コンシューマーがそれを抽出して解釈するため、データ処理ロジックに複雑さが加わります。

ここに発生する可能性のある問題をいくつか挙げます。

データの完全性の懸念
トレースヘッダを含めるために元のレコードを変更することは、データの完全性を損なう可能性があります。
特に、データがセンシティブまたは規制に準拠したプロセスに使用される場合、改変や変更が重大な影響を及ぼす可能性があります。
スキーマとフォーマットの互換性
データスキーマが厳格または事前定義されている場合（例えば、特定のフォーマットを期待するデータパイプラインなど）、追加のトレースヘッダが下流システムとの互換性の問題を引き起こす可能性があります。
レコード処理の複雑さ
レコード内にトレースヘッダを含めることは、プロデューサーとコンシューマーの両側で処理ロジックに複雑さを追加します。
プロデューサーは正しくトレース情報を埋め込み、コンシューマーはこれを解析して抽出する必要があり、追加の処理ステップが必要です。

パート1の結論

見てきたように、トレースヘッダをレコードに直接組み込むことは、AWS Kinesis の運用に複雑さをもたらし、システム内のプロデューサーとコンシューマーの両方に課題をもたらします。
これらの複雑さを解決するためには、データトレースの細かさを犠牲にすることなく、このプロセスを簡素化する効果的なソリューションが必要です。

シリーズの次回では、これらの課題に対処する革新的なアプローチを探り、トレースヘッダ伝搬のためのより簡便な方法を提供します。