マイクロサービスを使用するようにアプリケーションを書き換えると、1 つのユーザー トランザクションに関与するコンポーネントとエンドポイントの数が増加します。このため、ユーザー サービスを確実に動作させるにはオブザーバビリティが重要となります。このリファレンス アーキテクチャでは、OpenTelemetry と Cloud Trace を使用して、マイクロサービス アプリケーションのトレース情報をキャプチャする方法を示します。
このドキュメントは、分散トレースの基礎を理解し、その原則をサービスに適用してサービスのオブザーバビリティを改善したいと考えているデベロッパー、SRE、DevOps エンジニアを対象としています。
アーキテクチャ
次の図は、このアーキテクチャを実装するアプリの構造を示しています。
上の図に示すように、このアーキテクチャは 2 つの GKE クラスタから構成されています。各クラスタにアプリケーションをデプロイします。ユーザー トラフィックはフロントエンド クラスタのフロントエンド アプリに送信されます。フロントエンド クラスタのフロントエンド Pod が、バックエンド クラスタのバックエンド Pod と通信します。バックエンド Pod が外部 API エンドポイントを呼び出します。
オブザーバビリティ データが Cloud Trace にエクスポートされ、アプリケーション経由で伝播されるリクエストが追跡されます。
設計上の考慮事項
Kubernetes 上で実行されるサービスの場合、Istio などのサービス メッシュを使用すると、サービス間のトラフィックの分散トレースが可能になります。専用の計測ツールは必要ありません。ただし、次のような要件がある場合があります。
- Istio が提供するトレースよりも詳細にトレースを制御したい。
- トレース情報でアプリケーション内部のキャプチャが必要になる場合がある。
- Kubernetes で実行されていないコードのトレースが必要になる場合がある。
このような場合は OpenTelemetry を使用できます。これは、分散マイクロサービス アプリケーションに計測機能を追加し、さまざまな言語、プラットフォーム、環境にわたってトレース、指標、ログを収集できるオープンソース ライブラリです。
トレース、スパン、コンテキストについて
分散トレースのコンセプトは、Google が発表した Dapper の研究論文で解説されています。次の図では、1 つのトレースに 5 つのスパンがあります。
トレースは、分散システムがユーザー リクエストにどのように応答したかを記述した情報全体を指します。トレースはスパンで構成されています。各スパンは、ユーザー リクエストの処理に関係する特定のリクエストとレスポンスのペアを表します。親スパンは、エンドユーザーが観測したレイテンシを記述します。子スパンは、分散システムの特定のサービスがどのように呼び出され、どのように応答されたかと、キャプチャされたレイテンシ情報を記述します。
この図は、2 つのバックエンド リクエストを作成する 1 つのフロントエンド リクエストを示しています。2 番目のバックエンド呼び出しでは、実行を完了するために 2 つのヘルパー呼び出しが必要です。各呼び出しには、そのスパン ID と親スパンの ID のラベルが付けられます。
分散システムでのトレースにおける課題は、さまざまなバックエンド サービスに対して後続のリクエストが実行されたときに、元のフロントエンド リクエストに関する情報が自動的または本質的に維持されないことです。
一部のツール（Go 言語など）では、クラスタの IP アドレスと認証情報などのコンテキストを含むリクエストを作成できます。OpenTelemetry では、このコンセプトが拡大され、スパン コンテキストが含まれています。つまり、HTTP ヘッダーに追加情報が読み込まれます。親スパンに関する情報は、その後の各リクエストに含めることができます。さらに、子スパンを追加してトレース全体を構成でき、これにより、ユーザー リクエストがシステムを通過して最終的にユーザーに返されるまでの過程を確認できます。
デプロイ
このアーキテクチャをデプロイするには、分散トレースをデプロイしてマイクロサービスのレイテンシをモニタリングするをご覧ください。
次のステップ
- OpenTelemetry について学習する。
- このアーキテクチャに関連する DevOps 機能の詳細については、以下をご覧ください。
- DevOps のクイック チェックで、業界における立ち位置を把握する。
- リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。