次の方法で共有

Azure Well-Architected Framework のレビュー - Azure アプリlication Gateway v2

  • [アーティクル]

この記事では、SKU の Azure Application Gateway v2 ファミリのためのアーキテクチャのベスト プラクティスについて説明します。 このガイダンスは、アーキテクチャの卓越性の 5 つの柱に基づいています。

Azure アプリlication Gateway に関する実用的な知識があり、v2 SKU の機能に精通していることを前提としています。 詳細については、「Azure アプリlication Gateway の機能」を参照してください。

前提条件

  • 適切に設計されたフレームワークの柱を理解することは、高品質で安定した効率的なクラウド アーキテクチャを生み出すのに役立ちます。 Azure Well-Architected Framework Review 評価を使用してワークロードを 確認 することをお勧めします。
  • 参照アーキテクチャを使用して、この記事で提供されているガイダンスに基づいて考慮事項を確認します。 まず 、Application Gateway と API Managementと IaaS: リレーショナル データベースを使用した Web アプリケーションを使用して API を保護することをお勧めします。

信頼性

クラウドでは、障害が発生することを認識しています。 目標は、障害がまったく発生しないように努力することではなく、障害が発生した単一コンポーネントの影響を最小限に抑えることです。 失敗したインスタンスを最小限に抑えるには、次の情報を使用します。

設計チェック リスト

Application Gateway の設計上の選択を行う際は、信頼性設計の原則を 確認してください。

  • 可能であれば、ゾーンに対応した構成にインスタンスをデプロイします。
  • 仮想ネットワーク内の Web アプリケーション ファイアウォール (WAF) で Application Gateway を使用して、インターネットからの受信 HTTP/S トラフィックを保護します。
  • 新しいデプロイでは、Azure アプリlication Gateway v1 を使用する説得力のある理由がない限り、Azure アプリlication Gateway v2 を使用します。
  • ルールの更新の計画
  • 正常性プローブを使用したバックエンドの利用不可の検出
  • 正常性プローブに対する間隔としきい値の設定の影響の確認
  • 正常性エンドポイントを使用したダウンストリームの依存関係の確認

推奨事項

信頼性のために Application Gateway の構成を最適化するための推奨事項の次の表を参照してください。

推奨事項 特長
ルールの更新の計画 Azure Application Gateway へのアクセスや、さらに変更を加える前に、更新に十分な時間を計画します。 たとえば、サーバーをバックエンド プールから削除すると、既存の接続をドレインする必要が生じ、時間がかかる場合があります。
正常性プローブを使用したバックエンドの利用不可の検出 受信トラフィックを複数のバックエンド インスタンスに負荷分散するために Azure Application Gateway を使用する場合は、正常性プローブを使用することをお勧めします。 これにより、トラフィックを処理できないバックエンドに、トラフィックがルーティングされないようにします。
正常性プローブに対する間隔としきい値の設定の影響の確認 正常性プローブは、設定された間隔で構成されたエンドポイントに要求を送信します。 また、バックエンドが異常とマークされる前に許容される、失敗した要求のしきい値もあります。 これらの数はトレードオフの関係にあります。

- 間隔を大きく設定すると、サービスの負荷が高くなります。 各 Azure Application Gateway インスタンスは、独自の正常性プローブを送信します。そのため、30 秒ごとに 100 個のインスタンスがあれば、30 秒あたり 100 個の要求があることを意味します。
- 間隔を低く設定すると、停止が検出されるまでの時間が長くなります。
- 異常なしきい値を低く設定すると、短い一時的な障害によってバックエンドがダウンする可能性があります。
- 高いしきい値を設定すると、バックエンドがローテーションから外れるのに時間がかかる場合があります。
正常性エンドポイントを使用したダウンストリームの依存関係の確認 各バックエンドに、障害を確実に分離するための独自の依存関係があるとします。 たとえば、Application Gateway の背後でホストされているアプリケーションには複数のバックエンドがあり、それぞれが異なるデータベース (レプリカ) に接続されている場合があります。 このような依存関係が失敗した場合、アプリケーションは動作している可能性がありますが、有効な結果は返されません。 このため、正常性エンドポイントで、すべての依存関係を検証する必要があります。 正常性エンドポイントへの各呼び出しに直接依存関係がある呼び出しがある場合、そのデータベースは、30 秒ごとに 1 個でなく 100 個のクエリを受け取る点に注意してください。 これを回避するには、正常性エンドポイントで依存関係の状態を短時間キャッシュする必要があります。
Azure Front Door と Application Gateway を使用して HTTP/S アプリケーションを保護する場合は、Front Door で WAF ポリシーを使用し、Application Gateway をロックダウンして、Azure Front Door からのトラフィックのみを受信します。 特定のシナリオでは、特に Application Gateway にルールを実装することが強制される場合があります。 たとえば、ModSec CRS 2.2.9、CRS 3.0、または CRS 3.1 の規則が必要な場合、これらの規則は Application Gateway でのみ実装できます。 一方、レート制限とジオフィルタリングは、Azure Front Door でのみ使用でき、AppGateway では使用できません。

Azure Advisor は、ビジネスクリティカルなアプリケーションの継続性を確保し、向上するのに役立ちます。 Azure Advisor の 推奨事項を確認します。

セキュリティ

セキュリティは、あらゆるアーキテクチャの最も重要な側面の 1 つです。 Azure Application Gateway は、最小限の特権の原則と多層防御の両方を採用する機能を提供します。 セキュリティ設計の原則を確認することをお勧めします。

設計チェック リスト

  • セキュリティ強化のための TLS ポリシーの設定
  • AppGateway を使用した TLS の終了
  • Azure Key Vault を使用して TLS 証明書を格納する
  • バックエンド トラフィックを再暗号化するときは、バックエンド サーバー証明書にルート証明機関と中間証明機関 (CA) の両方が含まれていることを確認します
  • バックエンド プール リソースに適切な DNS サーバーを使用する
  • Application Gateway のすべての NSG 制限に準拠する
  • Application Gateway サブネットで UDR を使用しないようにする
  • WAF を有効にする場合は、Application Gateway の容量の変更に注意してください

推奨事項

次の推奨事項の表を参照して、Application Gateway のセキュリティ構成を最適化します。

推奨事項 特長
セキュリティ強化のための TLS ポリシーの設定 セキュリティ強化のための TLS ポリシーを設定します。 常に使用可能な最新の TLS ポリシー バージョンを使用していることを確認します。 これにより、TLS 1.2 と、より強力な暗号が適用されます。
AppGateway を使用した TLS の終了 TLS の終了に Azure Application Gateway を使用すると、次のような利点があります。

- 異なるバックエンドに送信される要求は、各バックエンドに対して再認証する必要があるため、パフォーマンスが向上します。
- TLS 処理を実行する必要がないため、バックエンド サーバーの使用率が向上する
- 要求コンテンツにアクセスしてインテリジェント ルーティングを行う。
- 証明書は Application Gateway にのみインストールする必要があるため、証明書の管理が容易になります。
Azure Key Vault を使用して TLS 証明書を格納する Application Gateway は Key Vault と統合できます。 これにより、セキュリティが強化され、ロールと責任の分離が容易になり、管理証明書のサポート、証明書の更新、ローテーションのプロセスが容易になります。
バックエンド トラフィックを再暗号化するときは、バックエンド サーバー証明書にルート証明機関と中間証明機関 (CA) の両方が含まれていることを確認します バックエンド サーバーの TLS 証明書は、既知の CA によって発行されている必要があります。 証明書が信頼された CA によって発行されなかった場合、Application Gateway は、信頼された CA 証明書が見つかるまで、証明書が信頼された CA によって発行されたかどうかを確認します。 その後、セキュリティで保護された接続が確立されます。 それ以外の場合、Azure Application Gateway はバックエンドを異常としてマークします。
バックエンド プール リソースに適切な DNS サーバーを使用する バックエンド プールに解決可能な FQDN が含まれている場合、DNS 解決は、プライベート DNS ゾーンまたはカスタム DNS サーバー (VNet で構成されている場合) に基づいて行われるか、Azure で提供されるデフォルトの DNS を使用します。
Application Gateway のすべての NSG 制限に準拠する NSG は Application Gateway サブネットでサポートされていますが、いくつかの制限があります。 たとえば、特定のポート範囲との通信が禁止されています。 これらの制限事項の影響を必ず理解しておいてください。 詳細については、ネットワーク セキュリティ グループに関する記述を参照してください。
Application Gateway サブネットで UDR を使用しないようにする Application Gateway サブネットでユーザー定義ルート (UDR) を使用すると、いくつかの問題が発生する可能性があります。 バックエンドの正常性状態が不明である可能性があります。 Azure Application Gateway ログとメトリックが生成されない可能性があります。 バックエンドの正常性、ログ、およびメトリックを表示できるように、Application Gateway サブネット上で UDR を使用しないことをお勧めします。 組織で Azure Application Gateway サブネットに UDR を使用する必要がある場合は、サポートされているシナリオを必ず確認してください。 詳細については、「サポートされているユーザー定義のルート」を参照してください。
WAF を有効にする場合は、Application Gateway の容量の変更に注意してください WAF が有効になっている場合は、アプリケーション ゲートウェイが完全に到着するまですべての要求をバッファーに格納し、その要求がコア ルール セット内のルール違反と一致するかどうかを確認してから、パケットをバックエンド インスタンスに転送する必要があります。 大きなファイルのアップロード (サイズが 30 MB 以上) がある場合、大幅な待機時間が発生する可能性があります。 Azure Application Gateway の容量要件は WAF とは異なるため、適切なテストと検証を行わずに Azure Application Gateway で WAF を有効にしないことをお勧めします。

その他の推奨事項については、「セキュリティの重要な原則」を参照してください。

Azure Advisor は、ビジネスクリティカルなアプリケーションの継続性を確保し、向上するのに役立ちます。 Azure Advisor の 推奨事項を確認します。

ポリシーの定義

  • Application Gateway に対して Web アプリケーション ファイアウォール (WAF) を有効にする必要があります。 受信トラフィックをさらに検査するために、公開されている Web アプリケーションの前に Azure Web Application Firewall (WAF) をデプロイします。 Web Application Firewall (WAF) を使用すると、SQL インジェクション、クロスサイト スクリプティング、ローカルおよびリモートのファイル実行などの一般的な悪用や脆弱性から Web アプリケーションが一元的に保護されます。 また、カスタム ルールを使用して、国/リージョン、IP アドレス範囲、およびその他の HTTP(S) パラメーターによって Web アプリケーションへのアクセスを制限することもできます。
  • Web アプリケーション ファイアウォール (WAF) では、Application Gateway に対して指定されたモードを使用する必要があります。 Application Gateway のすべての Web アプリケーション ファイアウォール ポリシーで、[検出] または [防止] モードの使用をアクティブにするように義務付けます。
  • Azure DDoS Protection を有効にする必要があります。 パブリック IP を持つアプリケーション ゲートウェイの一部であるサブネットを含むすべての仮想ネットワークに対して DDoS Protection を有効にする必要があります。

Azure ネットワークに関連するすべての組み込みポリシー定義は、組み込みポリシー - ネットワークに一覧表示されます。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 コスト最適化の設計原則を確認することをお勧めします。

設計チェック リスト

  • Application Gateway の価格について理解する
  • 使用率が低いリソースの確認
  • 使用されていない Application Gateway インスタンスを停止する
  • スケールインおよびスケールアウト ポリシーの設定
  • さまざまなパラメーター間の使用量メトリックの確認

推奨事項

コストの最適化のために Application Gateway の構成を最適化するための推奨事項の次の表を確認します。

推奨事項 特長
Application Gateway の価格について理解する Azure Application Gateway の価格の詳細については、「Azure Application Gateway と Web アプリケーション ファイアウォールの価格について」を参照してください。 料金計算ツールを利用することもできます。

容量の需要に合わせてこれらのオプションが適切にサイズ設定されていることを確認し、リソースを無駄にすることなく期待されるパフォーマンスを実現します。
使用率が低いリソースの確認 不要なコストを回避するために、空のバックエンド プールを持つ Application Gateway インスタンスを特定して削除します。
不使用時の Azure Application Gateway インスタンスの停止 Azure Application Gateway が停止状態のときは課金されません。 継続的に Azure Application Gateway インスタンスを実行すると、余分なコストが発生する可能性があります。 使用パターンを評価し、必要ないときにインスタンスを停止します。 たとえば、Dev/Test 環境で営業時間後の使用は少なくなると予想されます。

インスタンスを停止および開始する方法については、次の記事を参照してください。
- Stop-AzApplicationGateway
- Start-AzApplicationGateway
スケールインおよびスケールアウト ポリシーの設定 スケールアウト ポリシーを使用すると、受信トラフィックとスパイクを処理するのに十分なインスタンスを確保できます。 また、要求が削除されたときにインスタンスの数が少なくなるように、スケールイン ポリシーを設定します。 インスタンス サイズの選択を検討します。 このサイズは、コストに大幅な影響を与える可能性があります。 いくつかの考慮事項については、「Azure Application Gateway インスタンス数の推定」を参照してください。

詳細については、「Azure アプリlication Gateway v2 とは」を参照してください。
さまざまなパラメーター間の使用量メトリックの確認 Azure によって追跡されるメトリックに基づく Azure Application Gateway の従量制インスタンスに基づいて課金されます。 さまざまなメトリックと容量ユニットを評価し、コスト ドライバーを決定します。 詳細については、「Microsoft Cost Management and Billing」を参照してください。

Application Gateway では、次のメトリックが重要です。 この情報を使用して、プロビジョニングされたインスタンス数が着信トラフィックの量と一致することを検証できます。

- 推定請求容量ユニット
- 固定請求可能容量ユニット
- 現在の容量ユニット

詳細については、「Azure Application Gateway メトリック」を参照してください。

ご使用のアカウントの帯域幅コストを確認します。

その他の提案については、コスト最適化の柱の原則を参照してください。

Azure Advisor は、ビジネスクリティカルなアプリケーションの継続性を確保し、向上するのに役立ちます。 Azure Advisor の 推奨事項を確認します。

オペレーショナルエクセレンス

監視と診断は、Application Gateway と、ゲートウェイの背後にある Web アプリケーションまたはバックエンドのオペレーショナル エクセレンスを確保するために重要です。 パフォーマンス統計を測定するだけでなく、メトリックを使用して問題のトラブルシューティングと修復をすばやく行うこともできます。 オペレーショナル エクセレンス設計の原則を確認することをお勧めします。

設計チェック リスト

  • 容量メトリックの監視
  • Application Gateway と Web Application Firewall (WAF) で診断を有効にする
  • Azure Monitor Network Insights の使用
  • バックエンド アプリケーションとのタイムアウト設定の一致
  • Azure Advisor を使用して Key Vault の構成に関する問題を監視する
  • SNAT ポートの制限を構成して監視する
  • 設計で SNAT ポートの制限を検討する

推奨事項

次の推奨事項の表を参照して、Application Gateway の構成をオペレーショナル エクセレンスに最適化します。

推奨事項 特長
容量メトリックの監視 これらのメトリックは、プロビジョニングされた Azure Application Gateway 容量の使用状況のインジケーターとして使用します。 容量に関するアラートを設定することを強くお勧めします。 詳しくは、「Azure Application Gateway の高トラフィックのサポート」をご覧ください。
メトリックを使用したトラブルシューティング その他のメトリックは、Azure Application Gateway またはバックエンドのいずれかの問題を示す可能性があります。 次のアラートを評価することをお勧めします。

- 異常なホスト数
- 応答の状態 (ディメンション 4xx と 5xx)
- バックエンド応答の状態 (ディメンション 4xx と 5xx)
- バックエンドの最後のバイト応答時間
- Application Gateway の合計時間

詳細については、「Application Gateway のメトリック」を参照してください。
Application Gateway と Web Application Firewall (WAF) で診断を有効にする 診断ログでは、ファイアウォール ログ、パフォーマンス ログ、およびアクセス ログを確認できます。 これらのログを使用して、Azure Application Gateway インスタンスに関する問題を管理してトラブルシューティングします。 詳細については、Application Gateway のバックエンドの正常性と診断ログに関する記事を参照してください。
Azure Monitor Network Insights の使用 Azure Monitor Network Insights を使用すると、Azure Application Gateway を含むネットワーク リソースの正常性とメトリックを包括的に把握できます。 Azure Application Gateway の追加の詳細とサポートされている機能については、Azure Monitor Network Insights に関するトピックを参照してください。
バックエンド アプリケーションとのタイムアウト設定の一致 バックエンド アプリケーションのリスナーとトラフィックの特性に一致するように、IdleTimeout 設定を構成済みである必要があります。 既定値は 4 分に設定され、最大 30 に構成できます。 詳細については、「Load Balancer の TCP リセットおよびアイドルのタイムアウト」を参照してください。

ワークロードに関する考慮事項については、「信頼性のためのアプリケーションの正常性の監視」を参照してください。
Azure Advisor を使用して Key Vault の構成に関する問題を監視する Application Gateway は、リンクされた Key Vault 内の更新された証明書バージョンを 4 時間間隔ごとに確認します。 Key Vault の構成が正しくないためアクセスできない場合は、そのエラーをログに記録し、対応する Advisor の推奨事項をプッシュします。 コントロールまたはデータ プレーンに関連する問題を回避するには、Advisor アラートを構成して最新の状態を維持し、そのような問題を直ちに修正する必要があります。 詳細については、「キー コンテナーのエラーの調査と解決」を参照してください。 この特定のケースのアラートを設定するには、Application Gateway の Azure Key Vault の問題を解決するための 推奨事項の種類を使用します。
設計で SNAT ポートの制限を検討する SNAT ポートの制限は、Azure Application Gateway のバックエンド接続に重要です。 Azure Application Gateway が SNAT ポートの制限に達する方法への影響には、それぞれの要因があります。 たとえば、バックエンドがパブリック IP アドレスの場合は、独自の SNAT ポートが必要になります。 SNAT ポートの制限を回避するには、Application Gateway あたりのインスタンス数を増やすか、バックエンドをスケールアウトして IP アドレスを増やすか、バックエンドを同じ仮想ネットワークに移動し、バックエンドにプライベート IP アドレスを使用します。

SNAT ポートの制限に達すると、Azure Application Gateway の 1 秒あたりの要求数 (RPS) が影響を受ける可能性があります。 たとえば、Application Gateway が SNAT ポートの制限に達した場合、バックエンドへの新しい接続を開くことができず、要求は失敗します。

その他の提案については、オペレーショナル エクセレンスの柱の原則を参照してください。

Azure Advisor は、ビジネスクリティカルなアプリケーションの継続性を確保し、向上するのに役立ちます。 Azure Advisor の 推奨事項を確認します。

パフォーマンス効率

パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 パフォーマンス効率の原則を確認することをお勧めします。

設計チェック リスト

  • Azure Application Gateway インスタンス数の推定
  • 最大インスタンス数の定義
  • 最小インスタンス数の定義
  • Azure Application Gateway サブネットのサイズの定義
  • Application Gateway V2 の機能を利用して自動スケールとパフォーマンスの利点を得る

推奨事項

パフォーマンス効率のために Application Gateway の構成を最適化するための推奨事項の次の表を参照してください。

推奨事項 特長
Azure Application Gateway インスタンス数の推定 Application Gateway v2 は、CPU、ネットワーク スループット、現在の接続など、さまざまな側面に基づいてスケールアウトされます。 おおよそのインスタンス数を調べるには、次のメトリックの要因を考慮します。

現在のコンピューティング ユニット — CPU 使用率を示します。 1 つの Azure Application Gateway インスタンスは、約 10 個のコンピューティング ユニットです。
スループット — Application Gateway インスタンスは、最大 500 Mbps のスループットを提供できます。 このデータは、ペイロードの種類によって異なります。

インスタンス数を計算するときは、この式を検討してください。
おおよそのインスタンス数

インスタンス数を推定した後、その値を最大インスタンス数と比較します。 これにより、使用可能な最大容量にどの程度近づいているかが示されます。
最小インスタンス数の定義 Azure Application Gateway v2 SKU の場合、追加のインスタンスのセットがトラフィックに対応できるようになるまでに、自動スケーリングには少し時間がかかります (約 6 から 7 分)。 その間にトラフィックの急増が発生する場合は、一時的な待機時間やトラフィックの損失を予想します。

最小インスタンス数は最適なレベルに設定することをお勧めします。 平均インスタンス数を推定し、Azure Application Gateway の自動スケーリングの傾向を判断したら、アプリケーション パターンに基づいて最小インスタンス数を定義します。 詳しくは、「Azure Application Gateway の高トラフィックのサポート」をご覧ください。

過去 1 か月間の現在のコンピューティング ユニットを確認します。 このメトリックは、ゲートウェイの CPU 使用率を表します。 最小インスタンス数を定義するには、ピーク時の使用量を 10 で除算します。 たとえば、過去 1 か月間の現在のコンピューティング ユニットの平均が 50 の場合は、最小インスタンス数を 5 に設定します。
最大インスタンス数の定義 自動スケーリング インスタンスの最大数として 125 をお勧めします。 Azure Application Gateway が含まれているサブネットに、インスタンスのスケールアップ セットをサポートするのに十分な数の IP アドレスがあることを確認します。

最大インスタンス数を 125 に設定すると、消費された容量に対してのみ課金されるため、コストに影響はありません。
Azure Application Gateway サブネットのサイズの定義 Azure Application Gateway には、仮想ネットワーク内の専用サブネットが必要です。 このサブネットは、デプロイされた Azure Application Gateway リソースの複数のインスタンスを持つことができます。 そのサブネット、v1、または v2 SKU に他の Azure Application Gateway リソースをデプロイすることもできます。

サブネットのサイズを定義する際の考慮事項を次に示します。

- プライベート フロントエンド IP が構成されている場合、Application Gateway ではインスタンスごとに 1 つのプライベート IP アドレスと別のプライベート IP アドレスが使用されます。
- Azure では、内部使用のために各サブネットに 5 つの IP アドレスが予約されます。
- Application Gateway (Standard または WAF SKU) では、最大 32 個のインスタンスをサポートできます。 32 個のインスタンス IP アドレス + 1 つのプライベート フロントエンド IP + 5 つの予約済み Azure とすると、最小サブネット サイズは /26 をお勧めします。 Standard_v2 または WAF_v2 SKU は最大 125 個のインスタンスをサポートできるため、同じ計算を使用すると、サブネット サイズは /24 をお勧めします。
- 同じサブネットに追加の Application Gateway リソースをデプロイする場合は、Standard v2 と Standard v2 の両方の最大インスタンス数に必要な追加の IP アドレスを検討してください。
自動スケールとパフォーマンスの利点のために機能を活用する v2 SKU では自動スケールが提供され、トラフィックの増加に合わせて Application Gateway がスケールアップできることが保証されています。 v1 SKU と比較すると、v2 にはワークロードのパフォーマンスを向上させる能力があります。 たとえば、TLS オフロードのパフォーマンスの向上、デプロイと更新時間の短縮、ゾーン冗長性などがあります。 自動スケール機能の詳細については、「Application Gateway v2 と WAF v2 のスケーリング」を参照してください。

v1 SKU Application Gateway を実行している場合は、Application Gateway v2 SKU への移行を検討してください。 詳細については、「Azure Application Gateway と Web アプリケーション ファイアウォールを v1 から v2 に移行する」を参照してください。

Azure Advisor は、ビジネスクリティカルなアプリケーションの継続性を確保し、向上するのに役立ちます。 Azure Advisor の 推奨事項を確認します。

Azure Advisor の推奨事項

Azure Advisor は、ベスト プラクティスに従って Azure デプロイメントを最適化できるようにする、個人用に設定されたクラウド コンサルタントです。 Application Gateway の信頼性、セキュリティ、コスト効率、パフォーマンス、オペレーショナル エクセレンスの向上に役立つ推奨事項を次に示します。

信頼性

その他のリソース

Azure アーキテクチャ センターのガイダンス

次のステップ