Go to Qiita Advent Calendar 2024 Top
LoginSignup
81
59

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hikaru_motomiya(hikaru motomiya)inＡＲアドバンストテクノロジ株式会社（ARI）

【Azure】 Application Gateway 設定を解説する

Last updated at Posted at 2021-03-01

1.はじめに

ここ一年、Azureで利用できるL7ロードバランサー、『Application Gateway』をずっと扱ってきましたので、そのまとめもかねて主に設定項目について記事にまとめてみました。
Application Gatewayって理解できるまでが結構大変なのですよね…。

2.前提

  • Application GatewayのSKUは、V2(WAFV2)であるとします。(V1とV2では仕様が異なる)
  • 記事中では「スケールユニット」と統一して表記していますが、「スケールユニット」＝「インスタンス」です。公式ドキュメントもインスタンスで統一されつつあるようなので、一応追記。

設定について

ではさっそく、Application Gatewayで行う設定についてみていきましょう。
それではどん。

図1.png

Application Gatewayの設定要素は、このように分類することができます。
フロントエンド,ルーティング規則,バックエンドプール。
__フロントエンド__と__バックエンドプール__は言わずもがなですが、__ルーティング規則__ってなんでしょうね。
__ルーティング規則__というのは、基本的にフロントエンドに対して行った設定と、バックエンドプールに対して行った設定を結びつけるものだと思ってもらってOKです。

ルーティング規則の中では、さらに2つの構成要素に分けることができます。__リスナー__と、__バックエンドターゲット__ですね。
それぞれ__リスナー__は、フロントエンド側の設定、__バックエンドターゲット__は__バックエンド側の設定__と考えることができます。

はい、大まかにはこんな感じですが…もっと設定を細かく見ていきましょう。
はい、どん。

図2.png

はい、一気に複雑になりましたね。主に真ん中の部分が。
基本的な考え方は変わりません。ルーティング規則はフロントエンドとバックエンドプールをつなぐものです。
特にバックエンドターゲットの要素の中では、さらに3つに分かれます。
それぞれ__パスベース規則__、バックエンドターゲット、__HTTP設定__の小項目です。
__ルーティング規則__はこれらがそれぞれどの組み合わせで動作するのかを定義します。
では次からは、細かく設定を見ていきましょう。

3．基本設定

image.png

ゲートウェイ名などの設定以外のところ。

  • 自動スケール設定・スケール数設定
    • Application GatewayV2は、トラフィック負荷パターンの変化に基づいて自動スケールアウト・インすることが大きな特徴です。
    • 自動スケールを利用するかしないか、及びスケール数を指定します。
    • 自動スケールを利用する場合は最小スケールユニット数・最大スケールユニット数を指定します。
      • 最小値を指定することで、トラフィック等に関係なく動作する最低限のスケールユニット数を指定することができます。最低最小値は0ですが、0を指定するとスケールユニットを予約していない状態からスケールアウトするようになります。
      • シングルで動作しないようにするため、｢2｣以上とするのが一般的です。
    • 自動スケールを利用しない場合は、純粋なスケールユニット数を指定します。
  • 可用性ゾーン設定
    • Application Gatewayは、複数の可用性ゾーンにまたがって展開することができます。
    • __複数ゾーンにわたり冗長性を持ちたい場合は、可用性ゾーンを指定__します。
    • ここで指定したゾーンと、Application Gatewayに関連付けするパブリックIPが持つ可用性ゾーンは一致する必要があります。
  • HTTP2
    • HTTP2のサポートを行う場合は有効にします。
    • 一般的にはHTTP2にすると高速になるので、アプリケーション動作に問題がなければ有効にします。
  • 仮想ネットワーク
    • Application Gatewayのスケールユニットを、どの仮想ネットワークのサブネットに所属させるか指定します。詳しくは下記。
    • Application Gatewayが所属するサブネットは、Application Gatewayのみ所属させなくてはなりません。(ただしV1とV2は同時に所属させられない。)

Application Gatewayとネットワーク

Application GatewayとVnetの関係を表すと、以下の図のようになります。

![図3.png]image.png
  • 図上にも記載しましたが、サブネットの範囲により、スケールユニットの最大数が決まります。
  • Azure は内部使用のために各サブネットに 5 個の IP アドレス (最初の 4 個の IP アドレスと最後の IP アドレス) を予約しているので、__『(サブネットの範囲)-5』__の数がスケールユニットの最大数となります。
  • Application GatewayV2は最大125スケールユニットまでスケールアウトできますので、最小の推奨値は、__『/24』(256個)__です。
  • また、スケールユニットはサブネットに所属しているので、NSGによるアクセス制御が可能です。
    • V2 の場合は TCP ポート 65200 ～ 65535 で、宛先サブネットが [すべて] 、ソースが GatewayManager サービス タグである着信インターネット トラフィックを許可する必要があります。
    • 送信インターネット接続はブロックできません。
    • AzureLoadBalancer タグで宛先サブネットが [すべて] のトラフィックを許可する必要があります。

2021/06追記:

  • Application Gatewayv2は、サブネットが「/24」以下の範囲ではポータル上からは作成できなくなります。
  • その後、ユーザーからの要望を受け、作成できなくなるのではなく、「強い推奨」となったとのこと。

2021/08追記:

  • 図中では最大ユニット数が「128」になっていたので訂正しました。

4.フロントエンドIPの設定

image.png

__インターネット(もしくはプライベート)からApplication Gatewayにアクセスする入口をどうするかの設定__です。

  • パブリック
    • インターネットからアクセスできるようにしたい場合は、パブリックIPを選択します。
    • パブリックIPは、すでに作成済みのパブリックIPアドレスリソースから選択します。
      • Application Gatewayで選択するパブリックIPはSKUが「Standard」で、割り当てが「静的」である必要があります。
      • また、Application GatewayV2は可用性ゾーン対応していることから、Application Gatewayで指定した可用性ゾーンの範囲をパブリックIPリソースでも指定する必要があります。
  • プライベート
    • Application Gatewayv2は、プライベートIPアドレスのみでは動作させることができません。(Application Gatewayv1では可能。ただし自動スケールできないなどの制限あり)
  • 両方
    • パブリックIPと任意のプライベートIPをそれぞれ指定します。
      • プライベートIPは、Application Gatewayの所属するサブネット範囲から一つ__静的__に指定します。
      • Azureが内部使用のために利用するＩＰアドレス以外を指定します。

5.ルーティング規則設定

3回目ですが、ルーティング規則はフロントエンドとバックエンドプールをつなぐものです。

##リスナー
リスナーでは、フロントエンド側の設定を行います。

image.png

  • フロントエンドIP

    • フロントエンドで指定した設定値のうち、どれをこのリスナー設定で利用するのか選択します。

  • プロトコル

    • フロントエンド側で利用するプロトコルとして、HTTPかHTTPSを選択します。
    • HTTPSを利用する場合は、利用する証明書をインポートします。

  • ポート

    • フロントエンド側で利用するポート番号を指定します。

  • 追加設定

    • リスナーの種類
    • Basicかマルチサイトかを選択します。
      • マルチサイトの場合、__Application Gatewayに接続されるホスト名ごとに通信振り分けを行います。__詳しくは下記。

  • エラー ページの URL

    • 403エラーか502エラーが発生した場合、ここで指定したURLを表示させることができます。

マルチサイト

Application Gateway は、HTTP 1.1 ホスト ヘッダーを使用して、同じパブリック IP アドレスとポートで複数の Web サイトをホストします。

図4.png

上図であれば、「AAA.BBB.com」と「CCC.DDD.net」を異なるバックエンドターゲットに関連付けすることができます。

2024/02/19追記：
リスナーを抽象化して誤って記載しておりましたので修正しました。
正しくは、
「AAA.BBB.com」と「CCC.DDD.net」を持った2つのリスナーを異なるバックエンドターゲットに紐づけできる、です。
1つのリスナーを複数のバックエンドに紐づけすることはできません。

バックエンドターゲット

バックエンドターゲットでは、バックエンド側の設定を行います。

image.png
  • ターゲットの種類
    • バックエンド プール
      • 　バックエンドプールに通信を流します。また、バックエンドターゲットに関連付けを行うバックエンドプールを指定します。
    • リダイレクト
      • バックエンドプールに通信を流すのではなく、他のリスナーや指定した外部のサイトへリダイレクトさせることができます。
image.png

こんな感じ。

HTTP設定

HTTP設定は、さらに細かいバックエンド側の設定です。

image.png

  • バックエンド プロトコル

    • バックエンドに通信するプロトコルを指定します。
      • HTTP
      • HTTPS
        • HTTPSの場合は、証明書を登録する必要があります。(フロントエンドと同一の場合は必要なし)

  • バックエンド ポート

    • バックエンドで通信を行うポートを指定します。

  • 既知の CA 証明書を使用する

    • バックエンドにAzureで利用されているCA証明書を利用する場合は、こちらを使用します。すると、自動的に証明書を更新してくれます。
    • 例えばストレージアカウント、AppServiceを指定する場合など。

  • 追加設定

    • Cookie ベースのアフィニティ
      • Cookieを利用し、ユーザーセッションを同じサーバーへ通信できるようにします。通常はラウンドロビン方式で通信を行います。

  • アフィニティ Cookie 名

    • Cookie名を指定するのですが、マルチサイトの場合は同じ名称を利用しないように注意。Cookieが上書きされ、正しくセッションが維持できない可能性があります。

  • 接続のドレイン

  • 要求のタイムアウト

    • アプリケーション ゲートウェイが "接続がタイムアウトしました" というエラー メッセージを返す前に、バックエンド プールからの応答を受信するまで待機する秒数です。
    • バックエンドのサーバやDBなどのタイムアウト設定を吟味し調整が必要。

  • バックエンド パスのオーバーライド

    • 指定すると、自動的にパスのついた要求に変換してアクセスします。

  • 新しいホスト名でオーバーライドする

    • Application Gatewayを経由した場合のホストヘッダーは、バックエンド側からみるとApplication Gatewayのホスト名になってしまいます。
    • そのため、アプリケーションでホストヘッダーを読み取る処理などがあると、問題が発生します。
    • ここで特定のドメイン名でオーバーライドしておくと、ホストヘッダーが書き換わってバックエンドに伝達されます。

  • カスタム プローブを作成する

    • カスタムプローブにしておかないと、://127.0.0.1:/でヘルスチェックを行います。
    • ホスト名をオーバーライドする場合は、カスタムプローブを作成するのが無難です。

パスベース規則

image.png
  • 設定することで、この規則のリスナーから別のバックエンド ターゲットへ、要求の URL パスに基づいてトラフィックをルーティングできます。
  • URL パスに基づいて HTTP 設定の別のセットを適用することもできます。
    • つまり、特定のパスだけ特定のサーバーの特定のポートに対して通信させることもできる、ってことです。

| 図6.png
|
|:--|

上図だと、「/main」と「/sub」のパスで関連付けされたバックエンドプールが異なり、別のバックエンドへ通信を行います。

#6．バックエンドプール

バックエンドプールでは、__具体的にどこに対して通信を流すのか__を指定します。

image.png
  • ターゲットの種類
    • IPアドレスまたはFQDN:IPかFQDNを自由指定します。
      • 外部のサーバをターゲットにすることもできます。
    • 仮想マシン:作成済みの仮想マシンから選択します。
    • VMSS(VMスケールセット):作成済みのVMスケールセットから選択します。
    • AppService:作成済みのAppServiceから選択します。
image.png

はい、これでリソース作成時に指定できる設定値についてはこれですべてです。
いっぱいですね…。

あとは正常性プローブの設定とかがありますが、正常性プローブについては、疲れたのでまた別の機会にかきます。

7.終わりに

Application GatewayってAzureを利用する上で基本的なものなのです。
それだけに、ネットワークだったり、VMだったり、証明書だったり、DNSだったり、いろいろなところを知らないと難しいところがあります。

Azure の負荷分散サービスは全部で4つあります。それぞれを単独で利用する場合もありますが、もちろん組み合わせて利用する場合もあります。
このあたり、アーキテクトの実力の見せ所ですね。負荷分散サービスの選択については、以下をご参考ください。
https://docs.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview

参考

Azure Application Gateway のドキュメント
https://docs.microsoft.com/ja-jp/azure/application-gateway/

81
59
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
81
59

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?