コンシューマー サービスまたはアプリケーションの代わりにネットワーク要求を送信するヘルパー サービスを作成します。 アンバサダー サービスは、クライアントと併置されるアウトプロセス プロキシと考えてください。
アンバサダー パターンを使用して、監視、ログ記録、ルーティング、トランスポート層セキュリティ (TLS) などのセキュリティ、 回復性パターン などの一般的なクライアント接続タスクを言語に依存しない方法でオフロードします。 アンバサダー パターンを使用して、レガシ アプリケーションや変更が困難な他のアプリケーションのネットワーク機能を拡張します。 専門チームは、アンバサダー パターンを使用してこれらの機能を実装することもできます。
コンテキストと問題
回復性に優れたクラウドベースのアプリケーションには、 回線切断、ルーティング、測定と監視、ネットワーク関連の構成更新などの機能が必要です。 開発チームがコードを維持しない場合、またはコードを簡単に変更できない場合は、レガシ アプリケーションや既存のコード ライブラリを更新してこれらの機能を追加することが困難または不可能になる可能性があります。
また、ネットワーク呼び出しでは、接続、認証、および承認のための大幅な構成が必要になる場合があります。 複数のアプリケーションが異なる言語とフレームワーク間でこれらの呼び出しを使用する場合は、インスタンスごとに呼び出しを個別に構成する必要があります。 組織内の中央チームは、ネットワークとセキュリティの機能を管理する必要がある場合があります。 大規模なコード ベースでは、そのチームが未知のアプリケーション コードを更新するのは危険な場合があります。
ソリューション
クライアント フレームワークとライブラリを、アプリケーションと外部サービスの間のプロキシとして機能する外部プロセスに配置します。 ルーティング、回復性、およびセキュリティ機能を制御し、ホスト関連のアクセス制限を回避するには、アプリケーションと同じホスト環境にプロキシをデプロイします。 アンバサダー パターンを使用して、インストルメンテーションを標準化および拡張します。 プロキシは、アプリケーションと同じホスト環境で、待機時間やリソースの使用状況などのパフォーマンス メトリックを監視できます。
アンバサダーにオフロードされる機能は、アプリケーションとは別に管理できます。 アプリケーションの従来の機能を妨げることなく、アンバサダーを更新および変更できます。 また、独立した専門チームは、アンバサダーに移動されたセキュリティ、ネットワーク、または認証機能を実装して維持することもできます。
アンバサダー サービスを サイドカー としてデプロイして、消費するアプリケーションまたはサービスのライフ サイクルに付随させることができます。 または、共通ホスト上の複数の個別のプロセスがアンバサダーを共有している場合は、デーモンまたは Windows サービスとしてデプロイできます。 使用しているサービスがコンテナー化されている場合は、同じホスト上に別のコンテナーとしてアンバサダーを作成し、通信に適したリンクを設定します。
問題と考慮事項
このパターンの実装方法を決めるときには、以下の点に注意してください。
プロキシにより、待機時間のオーバーヘッドが発生します。 アプリケーションが直接呼び出すクライアント ライブラリの方が良い方法かどうかを検討します。
プロキシに一般化された機能を含めると考えられる影響を考慮してください。 たとえば、アンバサダーが再試行を処理することも可能ですが、すべての操作がべき等でない限り、そのアプローチは安全ではない可能性があります。
クライアントが何らかのコンテキストをプロキシに渡してクライアントに戻すために使用できるメカニズムを考えてみましょう。 たとえば、再試行をオプトアウトする HTTP 要求ヘッダーを含めたり、再試行する最大回数を指定したりします。
プロキシをパッケージ化してデプロイする方法を検討します。
すべてのクライアントに 1 つの共有インスタンスを使用するか、各クライアントのインスタンスを使用するかを検討します。
このパターンを使用する場合
このパターンは次の状況で使用します。
複数の言語またはフレームワークに共通のクライアント接続機能のセットを構築する必要があります。
クロスカット クライアント接続に関する問題を、インフラストラクチャ開発者や他のより特殊なチームにオフロードする必要があります。
レガシ アプリケーションまたは変更が困難なアプリケーションでは、クラウドまたはクラスターの接続要件をサポートする必要があります。
API ゲートウェイ、サービス メッシュ、または標準のイングレスおよびエグレス制御が簡単に処理しないプロトコルまたは接続パターンをサポートする必要があります。
このパターンは、次の場合に適さない場合があります。
ネットワーク要求の待機時間は非常に重要です。 プロキシでは最小限のオーバーヘッドが発生し、このオーバーヘッドがアプリケーションに影響する可能性があります。
クライアント接続機能は、1 つの言語で使用されます。 その場合は、パッケージとして開発チームに配布されるクライアント ライブラリを使用することをお勧めします。
接続機能を一般化することはできません。これらの機能には、クライアント アプリケーションとのより深い統合が必要です。
アプリケーション プラットフォームでは、相互 TLS (mTLS)、トラフィック管理、ポリシー機能を処理するための事前構築済みのソリューション (サービス メッシュなど) がサポートされています。 カスタム アンバサダー ソリューションを作成する代わりに、これらのソリューションを使用します。
ワークロード設計
ワークロードの設計でアンバサダー パターンを使用して、 Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。
| 支柱 | このパターンが柱の目標をサポートする方法 |
|---|---|
| 信頼性設計の決定は、故障に対するワークロードの回復性を高め、障害の発生後にワークロードを完全な機能状態に回復させるために役立ちます。 | このパターンでは、ネットワーク通信仲介ポイントが導入されるため、再試行やバッファリングなどの信頼性パターンをネットワーク通信に追加できます。 - RE:07 自己保護 |
| セキュリティ設計の決定により、ワークロードのデータとシステムの機密性、整合性、および可用性が確保されます。 | このパターンでは、クライアントが直接処理できないネットワーク通信にセキュリティを実装できます。 - SE:06 ネットワーク制御 - SE:07 暗号化 |
このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。
例
次の図は、アンバサダー プロキシを介してリモート サービスに要求を行うアプリケーションを示しています。 アンバサダーは、ルーティング、回線切断、およびログ記録を提供します。 リモート サービスを呼び出し、クライアント アプリケーションに応答を返します。
コンテナー化された環境では、このアンバサダーはアプリケーション コンテナーの横にあるサイドカー コンテナーとして実行されます。 非コンテナー化環境では、ローカル プロセスまたは同じホスト上の Windows サービスとして実装します。