ゲートウェイ オフロード パターン

共有または専用のサービス機能の負荷をゲートウェイ プロキシにオフロードします。 この方法では、サービス間で重複するのではなく、クライアント側の TLS 証明書の終了などの横断的な懸念事項をゲートウェイに一元化することで、アプリケーション開発を簡略化します。

認証、監視、プロトコル変換などの複数のサービスが責任を共有する場合、これらの懸念事項を 1 つのゲートウェイに統合すると、サービスごとの構成オーバーヘッドとデプロイ リスクが軽減されます。

コンテキストと問題

一部の機能は複数のサービスでよく使用されます。こうした機能には、構成、管理、およびメンテナンスが必要です。 アプリケーションの展開ごとに配布する共有サービスまたは特殊化されたサービスは、管理オーバーヘッドを増やし、デプロイ エラーの可能性を高めます。 その機能を共有するすべてのサービスにわたって、共有機能に更新プログラムを展開する必要があります。

トークンの検証、暗号化、TLS 証明書の管理などのセキュリティの問題では、チーム メンバーに高度に特化したスキルが必要な場合があります。 たとえば、ゲートウェイがない場合は、すべてのアプリケーション インスタンスでクライアント向け証明書を構成してデプロイする必要がある場合があります。 有効期限を追跡し、それらのインスタンス全体で更新、テスト、検証する必要があります。

認証、承認、ログ、監視、調整など、他の一般的なサービスについては、デプロイ数が膨大になると、実装および管理するのが困難です。 この種類の機能を統合すると、オーバーヘッドとエラーの可能性が軽減されます。

ソリューション

一部の機能をゲートウェイにオフロードします。 その後、ゲートウェイは、バックエンド サービスに代わって、クライアント側の証明書管理、認証、TLS 終了、監視、プロトコル変換、調整などの横断的な問題を処理します。

次の図は、受信 TLS 接続を終了し、共有機能を適用するゲートウェイを示しています。 ゲートウェイはバックエンド証明書を検証し、バックエンド サービスへの別の TLS 接続経由でトラフィックを再暗号化します。

TLS 経由でゲートウェイに接続するクライアントの図。

このパターンには次のような利点があります。

  • 各バックエンド サービスに実装するのではなく、認証、調整、要求ログなどの共有構成を一元化することで、サービスの開発を簡略化します。 一元化により、一貫性が向上し、サービスのアップグレードがより簡単になります。

  • 専用チームが、セキュリティなどの専門的知識を必要とする機能を実装できます。 その後、コア チームはアプリケーションの機能に集中でき、これらの特殊な問題を横断的な懸念事項は関連する専門家に任せるようになります。

  • 要求と応答のログ記録および監視に対してある程度の一貫性を提供します。 サービスが正しくインストルメント化されていない場合でも、ゲートウェイは監視とログ記録のベースライン レベルを提供できます。

  • 炭素に対応したトラフィック管理を一元化します。 ゲートウェイは、リアルタイムの炭素強度信号に基づいて、キャッシュ、レート制限、およびログ記録の動作を調整できます。 Azure API Managementは、一部のリージョンとクラシック レベル (Developer、Basic、Standard、Premium) で、これらの機能を限定されたプレビューで提供します。 可用性と構成の詳細については、Azure API Managementの環境に優しい持続可能な API に関するページを参照してください。

問題と考慮事項

このパターンの実装方法を決めるときには、以下の点に注意してください。

  • 高可用性と回復性。 ゲートウェイが高可用性を備え、障害に対する回復性があることを確認します。 ゲートウェイの複数のインスタンスを実行し、単一障害点をなくします。 ゲートウェイはクライアント接続を終端し、リクエスト ボディをバッファリングできるため、インスタンス障害時に処理中のリクエストがどのように扱われるかを検討してください。 ゲートウェイ インスタンスを削除または再起動してもアクティブなセッションが削除されないように、接続ドレインまたはグレースフル シャットダウン メカニズムを使用します。

  • 容量とスケーリング。 アプリケーションおよびエンドポイントの容量とスケーリングの要件に対応できるようにゲートウェイが設計されていることを確認します。 ゲートウェイがアプリケーションのボトルネックにならないようにし、十分にスケーラブルであることを確認します。 ゲートウェイは、平均負荷だけでなく、ピーク時のトラフィック バーストを処理するようにプロビジョニングする必要があります。 コストを削減するためにゲートウェイをプロビジョニング不足にすることで、その背後にある各サービスのパフォーマンスが直接低下します。

  • スコープのオフロード。 複数のサービスまたはルートで共有されるオフロード機能を一元化すると、重複する実装と管理が削減されます。

  • ビジネス ロジックの分離。 ビジネス ロジックをゲートウェイにオフロードしないでください。

  • トランザクション追跡。 トランザクションを追跡する必要がある場合は、ログ記録のために関連付け ID を生成することを検討します。

  • 待機時間のオーバーヘッド。 ゲートウェイは、すべての要求にネットワーク ホップを追加します。 TLS 終了、認証、要求検査など、ゲートウェイが実行するオフロードされた各関数は、要求パスに処理時間を追加します。 ゲートウェイ接続プールとバックエンド サービスへのキープアライブ接続は、要求ごとに新しい接続を確立するのではなく、接続を再利用することで待機時間のコストを部分的にオフセットできます。 ゲートウェイ ホップとオフロードされた関数の組み合わせ待機時間がワークロードのパフォーマンス 目標で許容されるかどうかを評価します。

  • 運用の複雑さ。 一元化されたゲートウェイは管理を統合しますが、運用上の責任も集中します。 共有の懸念事項として、ゲートウェイの構成、証明書のライフサイクル、ポリシーの更新、バージョンのアップグレードを管理する必要があります。 ゲートウェイを担当するチームに、ゲートウェイに依存するすべてのサービスの規模で管理するための容量とツールがあることを確認します。

  • セキュリティへの影響。 ゲートウェイは、認証、TLS 終了、要求検査などのクロスカット セキュリティ機能を一元化するため、価値の高いターゲットです。 ゲートウェイが侵害された場合、すべてのダウンストリーム サービスが公開される可能性があります。 ゲートウェイを強化し、その管理サーフェイスを制限し、保護するバックエンド サービスとは別に異常な動作を監視します。

  • ゲートウェイのバイパス防止。 目的のゲートウェイ パスを介してのみ要求を受け入れるようにバックエンド サービスを構成します。 それ以外の場合、クライアントはバックエンドに直接接続し、ゲートウェイで認証、調整、要求の検査、ログ記録をバイパスできます。

  • ID 伝達。 各バックエンドが元の呼び出し元、ゲートウェイのワークロード ID、またはその両方を承認するかどうかを定義します。 バックエンドで委任されたユーザー コンテキストが必要な場合にのみ、呼び出し元トークンまたは信頼された要求を保持します。 常にゲートウェイをバックエンドに対して個別に認証します。 未確認の転送ヘッダーを ID の証明として扱わないようにします。

  • TLS メンテナンス。 ゲートウェイが TLS を終了する場合は、バックエンドに TLS を再確立します。 暗号化されていない HTTP 経由でトラフィックを転送しないでください。 すべてのネットワークを信頼されていないものとして扱います。 このトポロジでは、バックエンド証明書の発行、ローテーション、取り消しを行うプロセスが必要です。

  • 転送されたヘッダーとクライアント コンテキスト。 ゲートウェイがクライアント接続を終了し、バックエンド サービスへの新しい接続を確立すると、ゲートウェイが明示的に転送しない限り、クライアント IP アドレス、元のプロトコル、ホスト名などの情報は失われます。 軽減策については、 リバース プロキシとそのバックエンド Web アプリケーションの間で元の HTTP ホスト名を保持する方法に関するページを参照してください。

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

このパターンは次の状況で使用します。

  • アプリケーションのデプロイには、TLS 証明書や暗号化などの共通の懸念事項があります。
  • アプリケーションのデプロイ間で共通の機能には、メモリ リソース、ストレージ容量、ネットワーク接続など、異なるリソース要件がある場合があります。
  • ネットワーク セキュリティ、調整、その他のネットワーク境界の問題などの問題に対する責任を、より特殊なチームに移したいと考えています。

このパターンは、次の場合に適さない場合があります。

  • ゲートウェイには、バックエンド サービスの変更とゲートウェイ構成の変更を密接に結び付ける、サービス固有のロジックまたはルーティング規則が含まれている必要があります。 ゲートウェイ層と内部サービスを結合すると、バックエンドの更新によってゲートウェイの再デプロイが強制され、デプロイの独立性が低下する可能性があります。
  • オフロードされた懸念事項は軽量であり、ワークロードは待機時間に依存します。 オーバーヘッドが集中化の利点を上回る場合、ゲートウェイ経由の追加のネットワーク ホップが正当化されない可能性があります。
  • 懸念事項を共有ゲートウェイに一元化すると、変更管理のボトルネックが発生します。 ゲートウェイ チームのリリース サイクルがサービス チームよりも遅い場合は、オフロードによって証明書、認証ポリシー、またはネットワーク ルールの更新が遅れる可能性があります。

ワークロード設計

設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、ゲートウェイ オフロードパターンをワークロードの設計でどのように使用できるかを評価する必要があります。 例えば次が挙げられます。

柱 このパターンが柱の目標をサポートする方法
信頼性設計の決定は、故障に対するワークロードの回復性を高め、障害の発生後にワークロードを完全な機能状態に回復させるために役立ちます。 この責任をゲートウェイにオフロードすると、バックエンドノード上のアプリケーション コードの複雑さが軽減されます。 場合によっては、オフロードによって、機能が信頼性の高いプラットフォーム提供の機能に完全に置き換えられます。

- RE: 01 シンプルさと効率性
セキュリティ設計の決定により、ワークロードのデータとシステムの機密性、整合性、および可用性が確保されます。 要求フローにゲートウェイを追加すると、Web アプリケーション ファイアウォールやクライアント TLS ポリシーなどの制御を一元化できます。 プラットフォームが提供するオフロード機能は、すでにセキュリティを強化しています。

- SE:06 ネットワーク制御
- SE:08 リソースの強化
コストの最適化では、ワークロードの投資収益率の維持と向上に重点を置いています。 このパターンを使用すると、ノードごとに消費されるリソースからゲートウェイ実装にコストをリダイレクトできます。 集中処理モデルのコストは、分散モデルのコストよりも低いことがよくあります。

- CO:14 コンソリデーション
オペレーショナルエクセレンス は、標準化されたプロセスとチームの結束によってワークロードの品質を提供します。 このパターンでは、オフロードされた機能の構成と維持は、複数のノードからの管理を必要とするのではなく、1 つのポイントに関連付けられます。 この集中化により、横断的な懸念が適用される方法が標準化され、日常的でアドホックな運用上の変更が一貫して予測可能になります。

- OE:02 業務の標準化
パフォーマンス効率 は、スケーリング、データ、およびコードの最適化を通じて、ワークロード の需要を効率的に満たすのに役立ちます。 オフロード ゲートウェイを要求プロセスに追加すると、機能がゲートウェイで一元化されるため、ノードあたりのリソースの使用量を減らできます。 オフロードされた機能の実装は、アプリケーションコードとは無関係に最適化できます。 オフロードされたプラットフォームで提供される機能は、すでに高いパフォーマンスを発揮している可能性があります。

- PE:03 サービスの選択

このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。

Example

Azure Application Gateway WAF_v2は、リージョン Web アプリケーションに対してこのパターンを実装できます。 ゲートウェイはクライアント TLS 接続を終了し、WAF とルーティング ポリシーを適用し、バックエンド サービスへの新しい TLS 接続を確立します。 この設計により、共有要求処理の問題がバックエンド アプリケーション コードから除外されます。

TLS オフロードを使用した Application Gateway

次の図は、Application Gateway が受信 TLS 接続を終了し、トラフィックを検査してフィルター処理し、TLS 経由でバックエンド プールに転送する前に再暗号化する方法を示しています。

Application Gateway がクライアントからの受信 TLS を終了し、WAF とルーティング規則を適用し、TLS 経由でバックエンド プールにトラフィックを再暗号化することを示す図。

このアーキテクチャでは、次の Application Gateway コンポーネントを使用して共有機能をオフロードし、バックエンド トラフィックを再暗号化します。

  • HTTPS リスナー。 ポート 443 の HTTPS リスナーは、クライアントからの受信 TLS 接続を受け入れます。
  • TLS 証明書。 Azure Key Vaultから取得した PFX 証明書が HTTPS リスナーにアタッチされます。 Application Gateway は受信トラフィックを復号化して検査してルーティングし、バックエンド プールに再暗号化します。 バックエンド サーバーは、再暗号化された接続に証明書を必要としますが、多くの場合、プラットフォームで管理される証明書を使用できます。
  • バックエンド プール バックエンド プールは、再暗号化されたトラフィックを受信する HTTPS サーバーのセットを定義します。 バックエンド ターゲットには、仮想マシン、Azure Virtual Machine Scale Sets、IP アドレス、またはAzure App Service インスタンスを指定できます。 クライアントが直接接続して Application Gateway とその WAF ポリシーをバイパスできないように、バックエンド アクセスを制限します。
  • バックエンド HTTP 設定。 バックエンド プロトコルを HTTPS に、ポートをバックエンドの TLS ポート (443 など) に設定します。 証明書の信頼と、バックエンド証明書に一致するホスト名を構成します。 プライベート証明機関の場合は、信頼されたルート証明書を構成します。 詳細については、 v2 SKU を使用したエンド ツー エンド TLS に関するページを参照してください。
  • ルーティング規則。 要求ルーティング規則は、リスナーをバックエンド プールとバックエンド HTTP 設定に関連付けます。 パスベースの規則では、異なる URL パスを異なるバックエンド プールにルーティングできます。
  • WAF ポリシー。 このポリシーは、Geomatch ルールを含め、要求の検査に使用されるマネージド ルールとカスタム ルールを定義します。

Application Gateway はトラフィックを復号化するため、インテリジェント ルーティングの要求コンテンツの検査、HTTP ヘッダーと URL の書き換え、WAF ルールの適用を行うことができます。 その後、バックエンドに要求を転送する前に、トラフィックを再暗号化します。

構成ガイダンスについては、 Application Gateway を使用したエンド ツー エンドの TLS 暗号化に関するトピックを参照してください。

サポート テクノロジ

次のAzure サービスは、このパターンの実装に役立ちます。

  • リージョン Web トラフィックには Application Gateway を使用します。

  • AKS ワークロード向けの Kubernetes ネイティブのイングレスには、Azure Application Gateway for Containers を使用します。

  • グローバル Web トラフィックまたはマルチリージョン Web トラフィックにAzure Front Doorを使用します。

  • 認証、調整、変換、監視などの API 固有の懸念事項には、Azure API Managementを使用します。

次のステップ

  • Last updated on