次の方法で共有


アンバサダー パターン

Azure

コンシューマー サービスまたはアプリケーションに代わってネットワーク要求を送信するヘルパー サービスを作成します。 アンバサダー サービスは、クライアントと併配置されたアウトプロセス プロキシと考えることができます。

このパターンは、監視、ログ記録、ルーティング、セキュリティ (TLS など)、 回復性パターン などの一般的なクライアント接続タスクを言語に依存しない方法でオフロードする場合に役立ちます。 ネットワーク機能を拡張するために、レガシ アプリケーションや変更が困難な他のアプリケーションでよく使用されます。 また、特殊なチームがこれらの機能を実装できるようにすることもできます。

コンテキストと問題

回復性のあるクラウドベースのアプリケーションには、 回線切断、ルーティング、測定と監視、ネットワーク関連の構成更新を行う機能などの機能が必要です。 レガシ アプリケーションや既存のコード ライブラリを更新してこれらの機能を追加することは困難または不可能な場合があります。これは、コードが保守されなくなったり、開発チームによって簡単に変更できないからです。

また、ネットワーク呼び出しでは、接続、認証、および承認のための大幅な構成が必要になる場合があります。 複数の言語とフレームワークを使用してビルドされた複数のアプリケーションでこれらの呼び出しを使用する場合は、これらのインスタンスごとに呼び出しを構成する必要があります。 さらに、ネットワークとセキュリティの機能は、組織内の中央チームによって管理する必要がある場合があります。 大規模なコード ベースでは、そのチームが使い慣れていないアプリケーション コードを更新するのは危険です。

解決策

クライアント フレームワークとライブラリを、アプリケーションと外部サービスの間のプロキシとして機能する外部プロセスに配置します。 プロキシをアプリケーションと同じホスト環境にデプロイして、ルーティング、回復性、セキュリティ機能を制御し、ホスト関連のアクセス制限を回避します。 アンバサダー パターンを使用して、インストルメンテーションを標準化および拡張することもできます。 プロキシは待機時間やリソースの使用状況などのパフォーマンス メトリックを監視でき、この監視はアプリケーションと同じホスト環境で行われます。

アンバサダー パターンの図

アンバサダーにオフロードされる機能は、アプリケーションとは別に管理できます。 アプリケーションの従来の機能を妨げることなく、アンバサダーを更新および変更できます。 また、アンバサダーに移動されたセキュリティ、ネットワーク、または認証機能を個別の専門チームが実装して維持することもできます。

アンバサダー サービスは、使用しているアプリケーションまたはサービスのライフサイクルに付随する サイドカー としてデプロイできます。 または、アンバサダーが共通ホスト上の複数の異なるプロセスによって共有されている場合は、デーモンまたは Windows サービスとしてデプロイできます。 使用しているサービスがコンテナー化されている場合、アンバサダーは、通信用に構成された適切なリンクを使用して、同じホスト上に別のコンテナーとして作成する必要があります。

問題と考慮事項

  • プロキシにより、待機時間のオーバーヘッドが発生します。 アプリケーションによって直接呼び出されるクライアント ライブラリが、より優れたアプローチであるかどうかを検討します。
  • プロキシに一般化された機能を含めると考えられる影響を考慮してください。 たとえば、アンバサダーは再試行を処理できますが、すべての操作がべき等でない限り安全ではない可能性があります。
  • クライアントが何らかのコンテキストをプロキシに渡してクライアントに戻せるようにするメカニズムを検討してください。 たとえば、再試行をオプトアウトする HTTP 要求ヘッダーを含めたり、再試行する最大回数を指定したりします。
  • プロキシをパッケージ化してデプロイする方法を検討します。
  • すべてのクライアントに 1 つの共有インスタンスを使用するか、各クライアントのインスタンスを使用するかを検討します。

このパターンを使用する場合

このパターンは、次の場合に使用します。

  • 複数の言語またはフレームワークに共通のクライアント接続機能のセットを構築する必要があります。
  • クロスカット クライアント接続の問題をインフラストラクチャ開発者や他のより特殊なチームにオフロードする必要があります。
  • レガシ アプリケーションまたは変更が困難なアプリケーションで、クラウドまたはクラスターの接続要件をサポートする必要があります。

このパターンは、次の場合には適切でない可能性があります。

  • ネットワーク要求の待機時間が重要な場合。 プロキシではオーバーヘッドが少なくなっていますが、場合によってはアプリケーションに影響を与える可能性があります。
  • クライアント接続機能が 1 つの言語で使用される場合。 その場合は、パッケージとして開発チームに配布されるクライアント ライブラリを使用することをお勧めします。
  • 接続機能を一般化できないため、クライアント アプリケーションとのより深い統合が必要な場合。

ワークロード設計

アーキテクトは、ワークロードの設計でアンバサダー パターンを使用して、 Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価する必要があります。 例えば次が挙げられます。

このパターンが柱の目標をサポートする方法
信頼性設計の決定により、ワークロードが誤動作に対して復元力を持ち、障害発生後も完全に機能する状態に回復することができます。 このパターンによって促進されるネットワーク通信仲介ポイントは、再試行やバッファリングなどの信頼性パターンをネットワーク通信に追加する機会を提供します。

- RE:07 自己保護
セキュリティ設計の決定により、ワークロードのデータとシステムの機密性整合性、および可用性が確保されます。 このパターンは、クライアントが直接処理できなかったネットワーク通信のセキュリティを強化する機会を提供します。

- SE:06 ネットワーク制御
- SE:07 暗号化

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

次の図は、アンバサダー プロキシを介してリモート サービスに要求を行うアプリケーションを示しています。 アンバサダーは、ルーティング、回線切断、およびログ記録を提供します。 リモート サービスを呼び出し、クライアント アプリケーションに応答を返します。

アンバサダー パターンの例