Application Gatewayとは

初めに

Azureが扱っているロードバランサーは以下の2種類があります。

• Azure Load Balancer：レイヤー4(OSI)ロードバランサー
  
• Application Gateway：レイヤー7(OSI)ロードバランサー
  

前回Azure load balancerについて、説明をしました。
今回は続いて、Application Gatewayの方について説明しようと思います。

Application Gatewayとは

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

※Application GatewayはApp Gatewayに略称可能
レイヤー4ロードバランサー(Azure Load Balancer)とレイヤー7ロードバランサー(Application Gateway)は何が違うのでしょうか。

ざっと説明すると、以下の違いです。

• レイヤー4：送信元 IP アドレスとポートに基づくトラフィックを送信先 IP アドレスとポートにルーティングします。
• レイヤー7：URIパスやホストヘッダーなど、HTTP要求の追加属性に基づいてルーティングを決定できます。
  ※ もっと詳しく知りたい方は、「OSI 7階層構造」について調べていただければと思います。

Application Gatewayの場合、パスベースのルーティングと複数サイトのホスティングの2つのルーティング方法があります。
※以下の内容で、詳しく説明します。

Application Gatewayは実在の仮想アプライアンス(仮想マシン)のため、仮想ネットワーク(サブネット)上で作成する必要があります。
それに対して、Azure load balancerはAzureで直接提供している仮想サービスで、仮想アプライアンス(仮想マシン)ではありません。

Application Gatewayの構造

Application Gatewayの機能をよりスムーズに理解できるために、まずApplication Gatewayの構造と役割を理解していきたいと思います。

Application Gatewayの各コンポーネントと役割を以下に抜粋します。

• App Gateway フロントエンドIP/FQDN：APPGWのListenerに関連付けるためのIPアドレス(またはFQDN)
  • パブリックIPのみ、プライベートIPのみ、または両方を持つように構成可能
    • 外部向け、内部向け、内部外部両方のアクセスを受け付けるApp Gatewayの作成が可能
  • 静的パブリックIPのサポート(SKU v2のみ)
    • 静的プライベートIPのみの構成はサポートしない(SKU v2のみ)
  • パブリックIPにFQDNを付けて、CNAMEでDNSに登録することを推奨する(動的IPの影響がなくなる)
  • App GatewayとパブリックIPと仮想ネットワークは同じリージョンにいる必要がある
• HTTP/HTTPS リスナー：入ってくる接続要求をチェックする論理エンティティ。(通信を受理するかどうかを決めるコンポーネントです)
  • リスナーの種類
    • Basic：1つのドメイン サイトをリッスンする
    • マルチサイト：App Gatewayの背後に複数サイトがあり、ホスト名またはドメイン名に基づいてルーティングを構成する場合に必要。構成方法
  • 接続要求の以下の情報がリスナーの設定と合致する場合、接続を受理する
    • プロトコル：HTTP、HTTPS、HTTP/2、WebSocket
    • ポート：1~65502(suk v1)、1~65199(suk v2)
    • ホスト名
    • IPアドレス
  • 受理した通信はルーティングルールに沿って、バックエンドプールに転送する
  • 1つのApp Gatewayは複数のリスナーを持つことが可能
• ルーティング ルール(HTTP設定)：リスナーのトラフィックを転送する方法を決定するコンポーネント
  • ルーティングルールの種類
    • Basic：リスナーが受理したすべてのリクエスト(例:contoso.com/*)をバックエンドプールプールに転送する(ラウンドロビン形式で)
    • パスベース：リスナーが受理したリクエストのURL path(例:contoso.com/path01/、contoso.com/path02/)に基づいて、指定のバックエンドプールに転送する
      • 設定のどれにもマッチしないpathは既定のバックエンドプールとHTTP設定に従って転送する
  • リクエストのリダイレクトが可能
    • HTTPをHTTPSにリダイレクト(ポートのリダイレクト)
    • パスに基づくリダイレクト(指定のパスのみリダイレクト)
    • 外部サイトへのリダイレクト
  • HTTPヘッダーとURLを書き換える(もっと詳しく)
  • リスナーとルーティングルールは1対1の関係
  • HTTP設定で以下のことが可能
    • Cookieベースのセッション アフィニティ(セッションの持続性)：ユーザー セッションを同じサーバー上で維持する
    • 接続のドレイン：バックエンドプール メンバーを正常に削除する
    • カスタム プローブ：バックエンドの正常性を監視する設定
      • 規定の正常性プローブ：異常なメンバーは自動削除され、正常に戻ったらまた追加される動き
      • HTTP応答の状態コードが200~399の範囲であれば、正常と見なされる(GCPより優れている)
• バックエンドプール(Application Gatewayのルーティング先のリソース)
  • バックエンド プールに含まれるもの:
    • NIC(仮想マシン)
    • 仮想マシン スケール セット(VMSS)
    • パブリックIPアドレス(Azure外部のものもOK)
    • 内部IPアドレス(VPNやExpressRouteの場合、オンプレミスのIPでもOK)
    • FQDN(Azure外部のものもOK)
    • マルチテナント バックエンド (App Service など)
• WAF(Web アプリケーション ファイアウォール)：
  • Open Web Application Security Project (OWASP) に基づいて、以下攻撃を防ぐ(CRS3.0が既定のセット)
    • SQL インジェクション
    • クロスサイト スクリプティング
    • コマンド インジェクション
    • HTTP 要求スマグリング
    • HTTP 応答分割
    • リモート ファイル インクルージョン
    • ボット、クローラー、スキャナー
    • HTTP プロトコル違反および異常
  • カスタマイズ可能

公式ドキュメントから画像を引っ張てきます。

Application Gatewayの機能

Application Gatewayの機能及び説明について、以下で抜粋して纏めてから、必要に応じて個別の説明を入れておきます。

• URLベースのルーティング(パスベース ルーティングルール)
• 複数サイトのホスティング(マルチサイト リスナー)
• リダイレクト
• HTTPヘッダーとURLの書き換え
• カスタム エラー ページ：既定のエラー ページを表示する代わりに、カスタム エラー ページを作成することができる
• Secure Sockets Layer (SSL/TLS) 終了(App Gatewayに証明書を持たせることで、暗号化通信の復号が可能)
• セッション アフィニティ(セッションの持続性)
• ゾーン冗長性：
  • Standard_v2 SKU が前提
• AKSのイングレス コントローラー
• Webアプリケーション ファイアウォール(WAF)
• 要求のエンド ツー エンドの暗号化
• 自動スケーリング：トラフィック量に応じて、Application Gatewayのスペックを自動スケールアップとスケールダウンする機能
  • Standard_v2 SKU が前提
• 接続のドレイン：計画的なサービスの更新中にバックエンド プール メンバーを正常に削除することができる

sku v1とsku v2の比較

URLについて

次のを説明をする前に、パスについて理解しておきたいと思うので、URLの構成について説明します。
URL构成：

プロトコル://IP(またはFQDN):ポート/パス

※「:ポート」を省略する場合、プロトコルの規定のポートを使用する
※ 「IP(またはFQDN)」の部分はホスト部とも呼ばれている

例：

https://hyoublog.com/category/azure/

この例では、/category/azure/の部分がパスになります。

では、パスベースのルーティングについて説明に入ります。

パスベースルーティング

パスベースのルーティングでは、URL のパスを変えることで、バックエンド サーバーの異なるプールに要求を送信できます。 Document

パスベースルーティングは簡単に説明すると、違うパスを指定することで、違うバックエンドプールに転送されることです。

公式ドキュメントの図をお借りします。

この構成図では、クライアントのリクエストURLの/images/* と /video/*のパスで、それぞれ違うバックエンドプールに転送されました。

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

Application Gateway を使用すると、同じアプリケーション ゲートウェイ上の複数のWebアプリケーションに対して、ホスト名またはドメイン名に基づくルーティングを構成できます。Document

パスベースルーティングと違って、一つのApp Gatewayで複数のサイト(ホスト)をルーティングできます。

ここも公式ドキュメントの図をお借りします。

この構成図では、クライアントのリクエストURLのcontoso.com と fabrikam.comのホスト部で、それぞれ違うバックエンドプールに転送されました。

Secure Sockets Layer (SSL/TLS) 終了

この機能は特に理解が難しいというものではなく、単純によく使われる機能なので、書いておこうと思います。

リスナーに証明書を持たせることで、外部からの暗号化通信を復号して、バックエンドプールに送信することが可能になります。

Application Gatewayがない場合、WEBサーバに証明書を持たせて、複合をするため、Webサーバに復号の負荷がかかってしまいます。
また、証明書は自分でアップロードすることも、Azure Key Vaultに登録しているものを使うことも可能です。

Application Gatewayの作成

App Gateway作成の参考情報と注意点をざっとご紹介します。

詳細な作成手順は公式ドキュメント にあるので、参考にしていただければと思います。

Application Gateway のネットワーク要件

App Gatewayは仮想ネットワーク(のサブネット)に作成する必要があります。
そのため、サブネットのサイズについて、考慮が必要です。

4 インスタンスにスケールアウトする場合は、/28 サイズのサブネットを作成します。 もっと多くのインスタンスに拡大する可能性がある場合は、さらに大きいサブネットを作成します。Document

実際の環境で、今後の拡張性も含めてApp Gatewayは最大何インスタンスが必要かを検討した上で、決めていただければと思います。

最後に

今回レイヤー7のロードバランサーApplication Gatewayについてご紹介しました。
同じロードバランサーですが、L4とL7の機能が違うので、使うところも違います。

ちなみに、以前Kubernetesの記事でGCPのIngress(GCPのレイヤー7ロードバランサー)についてもざっと紹介したことがありましたが、興味を持つ方はそちらもチェックしていただければと思います。

ここまで読んで頂いて、お疲れ様でした。

参考サイト

• Azure Application Gateway とは
• アプリケーション ゲートウェイのコンポーネント
• アプリケーション ゲートウェイを作成し、構成します
• アプリケーション ゲートウェイの動作
• Application Gateway でトラフィックをルーティングする
• v1 SKU と v2 SKU の機能比較
• Application Gateway 用のWAFの作成
• Application Gateway での TLS 終端とエンド ツー エンド TLS の概要