Azure Application Gatewayを爆速で理解する

こんにちは、コンテナソリューション事業部の髙井です。

本日は「爆速で理解する」シリーズの第二弾、Application Gatewayです。

第一弾の「Azure Policyを爆速で理解する」に続く記事が出せたことに内心ホッとしています。
（安易に第一弾と銘打ってしまうことの大変さを学ぶいい機会でした）

techblog.ap-com.co.jp

さて、本日のお品書きは以下です。

• Application Gatewayとは
  • ほかのWAF利用可能なサービスとの違い
  • ほかのロードバランサーとの違い
• Application Gatewayの構成要素
  • リスナー
  • ルール
  • バックエンドプール

爆速で理解していきましょう。

Application Gatewayとは

Application Gatewayを一言で表すと

Applicaition Gatewayは、WAF を搭載可能な L7ロードバランサー です。

これだけだと「で？」となってしまうので、

• ほかのWAF利用可能なサービスとの違い
• ほかのロードバランサーとの違い

について補足します。

何かしらを理解するには他との差分を見ることが大切です。

17世紀の学者リンネは、「自然の階段」と呼ばれる宗教的価値観に基づいた生物の分類を、客観的な類似度によって分類し直すことで今日にも繋がる分類学の基礎をつくりました。

正確な峻別により、体系的な知識を得ることができます。

ほかのWAF利用可能なサービスとの違い

AzureのWAF

AzureでWAF（Web Application Firewall）が利用可能なサービスとして、以下の3つがあります。

• Azure CDN
• Front Door
• Application Gateway

Azure CDNは静的アセットをグローバルにキャッシュするためのサービスであり、他の2つと性質は大きく異なります。

一方、Front DoorとApplication GatewayはどちらもL7のロードバランシング用途であり、非常に似たサービスです。

違いとしては、Front Doorはグローバル サービスであるのに対し、Application Gatewayはリージョン サービスである点が異なります¹。

また、課金形態でも、Application Gatewayが起動時間を主体とするのに対し、Front Doorは処理リクエスト量を主体とする点に違いがあります。

ほかのロードバランサーとの違い

Azureのロードバランサー

Azureでロードバランシングをおこなう主要なサービスとして、以下の3つがあります。

• Azure Load Balancer
• Traffic Manager
• Application Gateway

このうち、Azure Load Balancerは L4 で作動する点、Traffic ManagerはDNSベースのトラフィック ロードバランサーである点が異なります。

Application Gatewayは L7 で作動するため、HTTPのリクエストヘッダーに応じたルーティングが可能です。

具体的には、〈ホスト名〉や〈パス〉に応じた細やかなルーティングをおこなうことができます。

Application Gatewayの構成要素

Application Gatewayの主要3要素

• フロントエンドIP
• ルール
• バックエンドプール

Application Gatewayの構成要素（設定項目）はとても多いのですが、まずは上記3点を押さえることで全体感を掴むことができるかと思います。

クライアントからサーバーまでの通信を考えた際に、それぞれの役割は以下のようになっています。

1. クライアントからの最初のアクセス先が〈フロントエンドIP〉
2. 最終的なアクセス先のサーバーが〈バックエンドプール〉
3. その2つの間をつなぐのが〈ルール〉

順に見ていきましょう。

接続フローのイメージ

flowchart LR
    Client((Client))
    Client --> FIP
    subgraph AG["Application Gateway"]
        FIP["フロントエンドIP"] -.-> Rule["ルール"]
        Rule -.-> BEP["バックエンド プール"]
    end
    BEP --- SV((Server))

フロントエンドIP

Application Gateway自体にアクセスするためのIPアドレスです。

動的アドレスは不可で、静的アドレスでなければなりません。また、VNet内部に公開するためのプライベート・フロントエンドIPを持つこともできます。

ただし、プライベートIPのみでの構成は現状できません。必ずパブリック・フロントエンドIPが必要です。

ルール

ホスト名やパス名によりどのバックエンドへ振り分けるのかを指定する論理ユニットです。

ルールは、大きく分けて以下の2つから成ります。

1. リスナー
2. バックエンド ターゲット or リダイレクト

構造としては、if-thenの形になります。if（この受け口に来たら）then（このバックエンドに流す）といったイメージです。

先ほどの図に詳しく書き加えるなら、以下のようになります。

「ルール」の中身

flowchart LR
    Cli((Client))
    Cli --> Ip
    subgraph AG["Application Gateway"]
    subgraph dummy[ ]
    style dummy fill:none,stroke:none
        Ip["フロントエンドIP"] -.-> Lis1
        Ip -.-> Lis2
        subgraph Rule["ルール"]
        style Rule stroke-dasharray: 5 5
            Lis2["リスナー
(HTTP)"] -.->|"リダイレクト"| Lis1["リスナー
(HTTPS)"]
            style Lis2 stroke-dasharray: 5 5
            Lis1 -.-> Tgt["バックエンド
ターゲット"]
        end
        Pool["バックエンド
プール"]
    end
    end
    Tgt -.->|"接続条件"| Pool
    Pool --- Sv((Server))

リスナーで、パブリック／プライベートどちらのフロントエンドIPを経由してきたかに加え、ホスト名やポートで受け口を指定してやります。

そして、それぞれの受け口（リスナー）に来たものをどこに流すか、バックエンド ターゲットとして指定してあげるイメージです。

リダイレクトの主な用途は、リスナーからリスナーへの転送です（※外部サイトを指定することも可能です）。たとえば、HTTPのHTTPS転送などがメインのユースケースになります。

バックエンド プール

最終的にクライアントに到達させたいバックエンドのサーバーを指します。

バックエンド プールには、以下が指定可能です。

• IPアドレス
• FQDN
• 仮想マシン（VM）
• 仮想マシンスケールセット（VMSS）
• App Service

同一サブスクリプションであれば、Azure Portalでバックエンド プールを指定するとき、App Serviceをプルダウンで簡単に選択できたりします。

さて、ここで気になるのが、バックエンド ターゲットとバックエンド プールの違いかと思います。

バックエンド ターゲットには、バックエンド プールへの接続情報が含まれると考えればOKです。

具体的には、バックエンド プールへの接続の際に どのプロトコルでどのポート番号にアクセスするのか などをバックエンド ターゲットで指定してあげるイメージです。

おわりに

主要概念に絞って爆速でお伝えしたつもりですが、それでも長くなりました。

とはいえApplication Gatewayには、他にもWAFの細かい設定方法やヘッダーの書き換え、Kubernetesとの連携に使うAGICなど詳しく見ていくとたくさんあります。

はい、まだまだ書き足りない、というわけで次回、

「Application Gatewayを完全に理解する」

の記事でお会いしましょう！（また風呂敷を広げる）

---

1. Azure Front Door と Azure Application Gateway の違いは何ですか?↩