こんにちは！今日は、分散システム環境での開発とデバッグをさらに一歩進化させるOpenTelemetryの強力な機能、Baggageについてご紹介します。
🤔 分散トレーシング、でも情報はどのように伝達するの？
マイクロサービスアーキテクチャ（MSA）では、一つのリクエストが複数のサービスを経由して処理されることがよくあります。このとき、リクエスト全体の流れを追跡するためにOpenTelemetryのような分散トレーシングシステムが使われます。
しかし、こんな悩み、一度は経験したことがあるのではないでしょうか。「最初のサービスで分かったユーザーIDを最後のサービスまで伝える方法はないだろうか？」「各サービスでDBを照会してテナント情報を確認する必要があるのだろうか？」
これらの悩みを解決してくれる魔法のような機能が、まさにBaggageです！✨
🎒 Baggageとは何でしょうか？
Baggageは、その名の通り「手荷物」のように、私たちが望むデータを詰めて旅（Trace）の間ずっと持ち歩くカバンだと考えると分かりやすいです。
もう少し技術的に説明すると、トレース（Trace）内で特定のデータをキーと値（Key-Value）のペアで保存し、一つのスパン（Span）から別のスパンへ、さらにはサービス境界を越えてまで伝達（伝播）するメカニズムです。
- 出発点 🛫: アップストリームサービス（最初にリクエストを受け取るサービス）でBaggageに情報を格納します。
- 旅行中 ➡️: リクエストが他のサービスに転送される際、このBaggage情報も一緒に旅をします。
- 到着点 🛬: ダウンストリームサービス（後でリクエストを受け取るサービス）では、いつでもBaggageを開いて情報を取り出して利用できます。
💡 Baggage、こんな時に本当に便利です！
Baggageの真価は、コンテキスト情報を伝達する際に発揮されます。
例えば、ユーザーAが「プレミアム」プランを利用していると仮定してみましょう。
- 認証サービス (Service A) 🔐
- ユーザーAのログインリクエストを受け取り、このユーザーが「プレミアム」プランであることを確認します。
- Baggageに plan: premium という情報を格納します。
- 注文サービス (Service B) 🛒
- 認証サービスからリクエストを受け取ります。
- Baggageを開いてみると、plan: premium 情報が入っていますね！
- 「ああ、このユーザーはプレミアム会員だ！」と即座に認識し、プレミアム会員専用の割引クーポンを適用してくれます。🎟️
- 通知サービス (Service C) 🔔
- 注文サービスからリクエストを受け取ります。
- 同様に、Baggageを通じてこのユーザーがプレミアム会員であることを知り、「プレミアム会員専用の特別配送が開始されました。」のようなパーソナライズされた通知を送ることができます。
もしBaggageがなかったら、注文サービスと通知サービスはユーザーの料金プランを確認するためにそれぞれデータベースを照会しなければならなかったでしょう。😱 Baggageのおかげで、不要なDB照会を減らし、サービス間の依存性を低減し、システム全体の効率を高めることができたのです！
🔖 スパン属性(Attribute)とは何が違うのですか？
「あれ？それは単にスパンの属性として保存すればいいんじゃないですか？」と思われるかもしれません。しかし、重要な違いがあります。
- スパン属性 (Span Attribute) 🏷️: その「一つの」スパンにのみ依存する情報です。タグを貼るようなもので、そのスパンが終わると情報も一緒に終わります。
- Baggage 🎒: トレースコンテキスト自体に乗って「旅全体」の間ずっとついて回る情報です。旅行カバンのようにサービス境界を越えて移動します。
✨ まとめ
OpenTelemetryのBaggageは、分散環境でコンテキスト情報を簡単かつ効率的に伝播できる非常に強力なツールです。ユーザー情報、テナントID、実験グループ情報など、さまざまなデータをBaggageに格納して活用することで、よりスマートで高性能な分散システムを構築できるでしょう。
さあ、あなたのシステムにもBaggageという素敵な旅行カバンを持たせてみてはいかがでしょうか？
コメントを残す