広告

Application Gatewayとは

Azure

初めに

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 プロトコル違反および異常
    • カスタマイズ可能

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

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.comfabrikam.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ロードバランサー)についてもざっと紹介したことがありましたが、興味を持つ方はそちらもチェックしていただければと思います。

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

参考サイト

コメント

タイトルとURLをコピーしました