Azure Application Gateway の機能

[アーティクル]
03/05/2024

Azure Application Gateway は、アプリケーションに対するトラフィックを管理できる Web トラフィックロードバランサーです。

Application Gateway conceptual

Note

Web ワークロードの場合は、新たな DDoS 攻撃から保護するために Azure DDoS 保護と Web アプリケーションファイアウォールを利用することを強くお勧めします。もう 1 つのオプションは、Web アプリケーションファイアウォールと共に Azure Front Door を使用することです。 Azure Front Door は、ネットワークレベルの DDoS 攻撃に対するプラットフォームレベルの保護を提供します。詳細については、Azure サービスのセキュリティベースラインに関するページを参照してください。

Application Gateway には、次のような機能があります。

Secure Sockets Layer (SSL/TLS) 終了

Application Gateway は、ゲートウェイの SSL 終了をサポートします。その後、通常、トラフィックは、暗号化されないままバックエンドサーバーに渡されます。この機能により、Web サーバーは、負荷の大きい暗号化と復号化のオーバーヘッドから開放されます。ただし、サーバーに対する暗号化されていない通信を利用できない場合があります。これは、セキュリティ要件やコンプライアンス要件が理由であったり、セキュリティで保護された接続以外はアプリケーションで受け入れられないためであったりします。このようなアプリケーションのために、Application Gateway では、エンドツーエンドの SSL/TLS 暗号化がサポートされています。

詳細については、「Application Gateway での SSL ターミネーションとエンドツーエンド SSL の概要」を参照してください

自動スケーリング

Application Gateway Standard_v2 では、自動スケーリングがサポートされており、トラフィック負荷パターンの変化に基づいてスケールアップまたはスケールダウンできます。また、自動スケールにより、プロビジョニングの間にデプロイのサイズまたはインスタンスの数を選択する必要がなくなります。

Application Gateway Standard_v2 の機能について詳しくは、「Azure Application Gateway v2 とは」を参照してください。

ゾーン冗長性

Standard_v2 の Application Gateway は、複数の可用性ゾーンを対象にできるため、障害回復性が高く、ゾーンごとに個別の Application Gateway をプロビジョニングする必要がありません。

静的 VIP

Application Gateway Standard_v2 SKU では、静的な VIP の種類だけをサポートします。これにより、アプリケーションゲートウェイに関連付けられた VIP は、Application Gateway の有効期間を過ぎても変化しません。

Web アプリケーションファイアウォール

Web アプリケーションファイアウォール (WAF) は、一般的な悪用や脆弱性から Web アプリケーションを一元的に保護するサービスです。 WAF は、OWASP (Open Web Application Security Project) コアルールセット 3.1 (WAF_v2 のみ)、3.0、2.2.9 の規則に基づいています。

Web アプリケーションが、一般的な既知の脆弱性を悪用した悪意のある攻撃の的になるケースが増えています。よくある攻撃の例として、SQL インジェクション攻撃やクロスサイトスクリプティング攻撃が挙げられます。アプリケーションコードでこのような攻撃を防ぐことは困難な場合があり、厳格な保守、パッチの適用、アプリケーショントポロジの多数のレイヤーの監視が必要になることもあります。 Web アプリケーションファイアウォールを一元化することで、セキュリティの管理がはるかに簡単になり、アプリケーション管理者にとっては侵入の脅威からより確実に保護されるようになります。また、WAF のソリューションは、1 か所に既知の脆弱性の修正プログラムを適用することで、個々の Web アプリケーションをセキュリティで保護する場合と比較して、さらに迅速にセキュリティの脅威に対応できます。既存のアプリケーションゲートウェイは、Web アプリケーションファイアウォールに対応したアプリケーションゲートウェイに簡単に変換できます。

Application Gateway で Azure WAF を使用して DDoS 攻撃から保護する方法については、アプリケーション DDoS 保護に関するページを参照してください。詳しくは、「Azure Web アプリケーションファイアウォールとは」を参照してください。

AKS のイングレスコントローラー

Application Gateway イングレスコントローラー (AGIC) を使うと、Azure Kubernetes Service (AKS) クラスターに対するイングレスとして Application Gateway を使用できます。

イングレスコントローラーは AKS クラスター内でポッドとして実行され、Kubernetes イングレスリソースを消費し、そのリソースを Application Gateway 構成に変換します。これにより、ゲートウェイは、Kubernetes ポッドへのトラフィックを負荷分散できます。イングレスコントローラーでは、Application Gateway Standard_v2 SKU および WAF_v2 SKU のみがサポートされています。

詳細については、Application Gateway イングレスコントローラー (AGIC) に関するページをご覧ください。

URL ベースのルーティング

URL パスベースのルーティングを使用すると、要求の URL パスに基づいてバックエンドサーバープールにトラフィックをルーティングできます。シナリオの 1 つとして、さまざまなコンテンツタイプの要求を異なるプールにルーティングする場合があります。

たとえば、http://contoso.com/video/* の要求は VideoServerPool にルーティングされ、http://contoso.com/images/* は ImageServerPool にルーティングされます。一致するパスパターンがない場合は、DefaultServerPool が選択されます。

詳細については、「URL パスベースのルーティングの概要」を参照してください。

複数サイトのホスティング

Application Gateway を使用すると、同じアプリケーションゲートウェイ上の複数の Web アプリケーションに対して、ホスト名またはドメイン名に基づくルーティングを構成できます。最大で 100 個以上の Web サイトを 1 つのアプリケーションゲートウェイに追加することによって、デプロイに効率的なトポロジを構成できます。各 Web サイトは、独自のバックエンドプールに送られるようにすることができます。たとえば、contoso.com、fabrikam.com、adatum.com という 3 つのドメインで、アプリケーションゲートウェイの IP アドレスが示されています。マルチサイトリスナーを 3 つ作成し、リスナーごとにポートとプロトコル設定を構成します。

http://contoso.com に対する要求は ContosoServerPool にルーティングされ、http://fabrikam.com に対する FabrikamServerPool にルーティングされて、後も同様にルーティングされます。

同様に、同じ親ドメインの 2 つのサブドメインも、同じアプリケーションゲートウェイデプロイでホストすることができます。サブドメインを使用する例としては、単一のアプリケーションゲートウェイデプロイ上でホストされる http://blog.contoso.com 、 http://app.contoso.com などがあります。詳細については、「Application Gateway の複数サイトのホスト」を参照してください。

マルチサイトリスナーでワイルドカードのホスト名を定義し、リスナー 1 つにつき最大 5 つのホスト名を定義することもできます。詳細については、リスナーでのワイルドカードのホスト名に関する記事を参照してください。

リダイレクト

HTTP を HTTPS に自動的にリダイレクトして、アプリケーションとユーザーの間のすべての通信が暗号化されたパスで行われるようにすることは、多くの Web アプリケーションでよくあるシナリオです。

これまでは、HTTP で受信した要求を HTTPS にリダイレクトすることが唯一の目的である専用のプールを作成する手法を使う場合がありました。 Application Gateway は、Application Gateway 上でトラフィックをリダイレクトする機能をサポートしています。これにより、アプリケーションの構成が簡単になり、リソースの使用が最適化され、グローバルなリダイレクトやパスに基づくリダイレクトなどの新しいリダイレクトシナリオがサポートされるようになります。 Application Gateway のリダイレクトのサポートは、HTTP から HTTPS へのリダイレクトだけではありません。これは一般的なリダイレクトメカニズムなので、規則を使用して定義した任意のポート間とリダイレクトできます。同様に、外部サイトへのリダイレクトもサポートします。

Application Gateway のリダイレクトのサポートでは、次の機能が提供されます。

Gateway 上のあるポートから別のポートへのグローバルなリダイレクト。これにより、サイトでの HTTP から HTTPS へのリダイレクトが可能になります。
パスに基づくリダイレクト。このタイプのリダイレクトを使うと、特定のサイト領域でのみ HTTP から HTTPS へのリダイレクトが可能になります (たとえば、/cart/* で示されたショッピングカート領域など)。
外部サイトへのリダイレクト

詳細については、「Application Gateway のリダイレクトの概要」を参照してください。

セッションアフィニティ

Cookie ベースのセッションアフィニティ機能は、同じサーバー上にユーザーセッションを保持する場合に便利です。ゲートウェイで管理される Cookie を使用すると、Application Gateway は、ユーザーセッションの後続のトラフィックを、処理のために同じサーバーに送ることができます。この機能は、ユーザーセッションのためにセッションの状態をサーバー上でローカルに保存する場合に重要です。

詳細については、「アプリケーションゲートウェイの動作」を参照してください。

Websocket と HTTP/2 トラフィック

Application Gateway は、WebSocket および HTTP/2 プロトコルをネイティブにサポートしています。ユーザーが構成可能な、WebSocket のサポートを選択的に有効または無効にするための設定はありません。

WebSocket および HTTP/2 プロトコルによって、長時間実行されている TCP 接続上でサーバーとクライアント間の全二重通信が可能になります。この機能により、HTTP ベースの実装では必須だったポーリングを使用することなく、Web サーバーとクライアントの間により対話的な双方向通信が可能になります。これらのプロトコルは、HTTP とは異なってオーバーヘッドが少なく、複数の要求や応答で同じ TCP 接続を再利用できるため、リソースをより効率的に使用できます。これらのプロトコルは、従来の HTTP ポート 80 および 443 上で動作するよう設計されています。

詳細については、WebSocket のサポートと HTTP/2 のサポートに関するページを参照してください。

接続のドレイン

接続ドレインは、計画的なサービスの更新中やバックエンドの正常性に関する問題が発生した場合に、バックエンドプールメンバーを正常に削除するのに役立ちます。この設定は、[バックエンド設定] を通じて有効にされ、ルールの作成時にすべてのバックエンドプールメンバーに適用されます。アプリケーションゲートウェイが有効になると、バックエンドプールのすべての登録解除インスタンスが新しい要求を受け取らなくなり、既存の要求は構成された制限時間内に完了するようになります。これは、バックエンドインスタンスが次の場合に適用されます。

ユーザーによる構成変更後にバックエンドプールから明示的に削除される
正常性プローブによって異常として報告される、または
スケールイン操作中に削除される

唯一の例外は、ゲートウェイで管理されるセッションアフィニティが原因で、登録解除インスタンスに対して要求がプロキシ処理され続ける場合です。

接続ドレインは、WebSocket 接続にも適用されます。接続ドレインは、ゲートウェイへの更新が行われるたびに呼び出されます。バックエンドプールの既存のメンバーへの接続の切断を防ぐため、必ず接続ドレインを有効にしてください。

時間制限については、バックエンド設定の構成に関するセクションを参照してください。

カスタムエラーページ

Application Gateway では、既定のエラーページを表示する代わりに、カスタムエラーページを作成することができます。カスタムエラーページでは、独自のブランディングとレイアウトを使用することができます。

詳細については、カスタムエラーに関するページを参照してください。

HTTP ヘッダーと URL を書き換える

クライアントとサーバーは、HTTP ヘッダーを使用して、要求または応答に追加の情報を渡すことができます。これらの HTTP ヘッダーの書き換えによって、次のようないくつかの重要なシナリオを実現できます。

HSTS/ X-XSS-Protection などのセキュリティ関連ヘッダーフィールドを追加する。
機密情報が漏れる可能性がある応答ヘッダーフィールドを削除する。
X-Forwarded-For ヘッダーからポート情報を削除する。

Application Gateway と WAF v2 SKU では、要求/応答パケットがクライアントとバックエンドプールの間を移動する間に、HTTP 要求および応答ヘッダーを追加、削除、または更新する機能がサポートされます。 URL、クエリ文字列パラメーター、およびホスト名を書き換えることもできます。 URL の書き換えと URL パスベースのルーティングでは、パスマップの再評価オプションを使用して、元のパスまたは書き換えられたパスに基づいて、要求をバックエンドプールのいずれかにルーティングすることができます。

また、条件を追加して、特定の条件が満たされた場合にのみ特定のヘッダーまたは URL が書き換えられるようにする機能も提供されます。これらの条件は、要求と応答の情報に基づいています。

詳細については、HTTP ヘッダーと URL の書き換えに関するページを参照してください。

サイズ変更

Application Gateway Standard_v2 は、自動スケーリング用、または固定サイズデプロイ用に構成できます。 v2 SKU には、さまざまなインスタンスサイズは用意されていません。 v2 のパフォーマンスと料金の詳細については、v2 の自動スケーリングに関するページと価格の理解に関するページをご覧ください。

Application Gateway Standard (v1) は、Small、Medium、Large の 3 つのサイズで提供されています。 Small サイズのインスタンスは、開発用およびシナリオのテスト用です。

アプリケーションゲートウェイの制限の詳細な一覧については、Application Gateway サービスの制限に関するページをご覧ください。

次の表では、SSL オフロードが有効になっているアプリケーションゲートウェイ v1 インスタンスごとにパフォーマンススループットの平均値を示します。

バックエンドページの平均応答サイズ	Small	中	Large
6 KB	7.5 Mbps	13 Mbps	50 Mbps
100 KB	35 Mbps	100 Mbps	200 Mbps

Note

これらの値は、アプリケーションゲートウェイスループットのおおよその値です。実際のスループットは、平均ページサイズ、バックエンドインスタンスの場所、ページの処理時間など、さまざまな環境の詳細によって異なります。パフォーマンス面の正確な数値は、ご自身でテストを実施のうえご確認ください。ここに挙げた数値は、容量計画の参考とすることを目的として記載したものにすぎません。

バージョンの機能の比較

Application Gateway v1 と v2 の機能の比較については、Azure Application Gateway v2 の概要に関する記事を参照してください。

次のステップ

アプリケーションゲートウェイの動作について説明します
「Azure Application Gateway に関してよく寄せられる質問」を確認してください。