Azure Well-Architected Framework レビュー - v2 Azure Application Gateway

  • [アーティクル]

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

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

前提条件

[信頼性]

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

設計チェック リスト

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

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

Recommendations

次の推奨事項の表を参照して、信頼性の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 の推奨事項を確認します。

Security

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

設計チェック リスト

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

Recommendations

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

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

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

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

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

ポリシーの定義

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

Azure ネットワークに関連するすべての組み込みポリシー定義は、「 組み込みポリシー - ネットワーク」に記載されています。

コスト最適化

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

設計チェック リスト

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

Recommendations

次の推奨事項の表を調べて、コストの最適化のためにApplication Gateway構成を最適化します。

推奨 特長
Application Gateway価格について理解する Application Gateway価格の詳細については、「Azure Application GatewayとWeb Application Firewallの価格について」を参照してください。 料金計算ツールを利用することもできます。

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

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

詳細については、「v2 Azure Application Gatewayとは」を参照してください。
さまざまなパラメーター間の使用量メトリックの確認 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 ポートの制限を考慮する

Recommendations

次の推奨事項の表を調べて、オペレーショナル エクセレンスのために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 機能を利用して、自動スケーリングとパフォーマンスの利点を得る

Recommendations

パフォーマンス効率のために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 リソースをデプロイすることもできます。

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

- Application Gatewayでは、プライベート フロントエンド IP が構成されている場合は、インスタンスごとに 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 と Standard v2 の両方の最大インスタンス数に必要な追加の IP アドレスを検討してください。
自動スケーリングとパフォーマンスの利点のために機能を活用する v2 SKU では自動スケールが提供され、トラフィックの増加に合わせて Application Gateway がスケールアップできることが保証されています。 v1 SKU と比較すると、v2 にはワークロードのパフォーマンスを向上させる能力があります。 たとえば、TLS オフロードのパフォーマンスの向上、デプロイと更新時間の短縮、ゾーン冗長性などがあります。 自動スケール機能の詳細については、「Application Gateway v2 と WAF v2 のスケーリング」を参照してください。

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

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

Azure Advisor の推奨事項

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

[信頼性]

その他のリソース

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

次の手順