Azure Application Gatewayのサービス概要、構成要素、リソース作成手順
アプリケーションゲートウェイ(Azure Application Gateway)のサービス概要、構成要素、リソース作成手順について紹介します。
インターネットからのHTTPアクセスを受信してバックエンドのWEBサーバ(仮想サーバ)へ転送するまでの一連の手順を確認しています。
※2024年3月に一部記事内容を修正しています。
※本記事内ではAzure Application Gatewayをアプリケーションゲートウェイ、WEB Application FirewallをWAFとして表記しています。
Azure Application Gatewayはどういうサービス
Azureで提供される負荷分散サービス
アプリケーションゲートウェイは(L7(アプリケーションレイヤ))で負荷分散を行うサービスです。
アプリケーションゲートウェイでは負荷分散機能以外にもSSL終端やURLリダイレクト等の機能が提供されています。
ゾーン冗長やprivate linkもサポートされています。
Azure Kubernetes Service (AKS)のイングレスコントローラーなどにも使用されます。
Application Gateway for Containersとしてイングレス コントローラー (AGIC) を進化させたアプリケーションゲートウェイも提供されています。
Application Gateway for Containers とは
AzureではWEBアプリケーションの負荷分散サービスを行うサービスが複数提供されています。
同様のサービスがFront DoorやTraffic Managerなどとして提供されています。
それぞれのサービスの違いについてはこちらに記載があります。
Azure Front Door と Azure Application Gateway の違いは何ですか?
Azure で負荷分散サービスを使用する
リージョン内での負荷分散としてはAzure ロードバランサーがあります。
Azure ロードバランサーと機能面の一番の違いは、レイヤーの違いがあります。
Azure Load Balancer と Azure Application Gateway の比較
-
- アプリケーションゲートウェイでのみで出来る事
- URIパスに基づいた負荷分散等
- ホスト名またはドメイン名に基づくルーティング
- SSLの終端
- WAFの利用
- アプリケーションゲートウェイでのみで出来る事
以前はアプリケーションゲートウェイはWEBアプリケーションアクセスに特化していたのですが、2024年3月時点ではTCP/TLSプロキシの機能も提供されています。
Application Gateway TCP/TLS プロキシの概要
v2をベースにした記載としています。
v1とv2の違いについてはこちらに記載があります。
Azure Application Gateway v2 とは(v1 SKU と v2 SKU の機能比較)
WEB Application Firewall(WAF)も提供されている
アプリケーションゲートウェイでは同一リソース内でWEB Application Firewall(WAF)を利用できます。
アプリケーションゲートウェイでのWAF利用についてはこちらに纏めています。
SKUは4パターン
アプリケーションゲートウェイとWAFの組み合わせで4パターンあります。
アプリケーションゲートウェイとWAF両方に対して課金が発生します。
また現時点ではプレビューですが、Application Gateway for Containersも提供されています。
SKU | APGW | WAF |
Standard v1 | v1(S,M,L)(インスタンス数) | × |
WAF | v1(S,M,L)(インスタンス数) | 〇 |
Standard v2 | v2(インスタンス数) | × |
WAF v2 | v2(インスタンス数) | 〇(カスタムWAF) |
アプリケーションゲートウェイの構成要素
アプリケーションゲートウェイは複数の要素で構成されます。
フロントエンドIPアドレス
アプリケーションゲートウェイがトラフィックを受信するIPアドレスです。
アクセスするIPアドレスに該当します。
フロントエンドIPアドレスはリスナーと関連付けて使用します。
Application Gateway のフロントエンド IP アドレスの構成
フロントエンドのIPアドレスには、パブリック IP アドレス、パブリックIPとプライベート IP アドレス、プライベートIPアドレスがあります。
パブリックIPアドレスの場合はインターネットに公開するアドレスになります。
※2024年3月時点ではプライベートIPアドレスはパブリックプレビュー段階です。
フロントエンドIPアドレス | |
パブリックとプライベートがあります。 リスナーと関連付けて利用します。 |
リスナー
リスナーはアプリケーションゲートウェイがアクセスを受け付ける為の設定です。
リスナーはルールに関連付けて利用します。
プロトコル(HTTPもしくはHTTPS)、ポート、ホスト、IP アドレスの組み合わせで設定します。
カスタムエラーページもリスナーで設定します。
マルチドメインやSSLオフロードもリスナー単位で設定します。
リスナー | |
プロトコルにHTTPSを選択すると証明書登録、SSLオフロード設定ができます。 マルチサイトやエラーページもリスナーの設定に含まれます。 |
|
バックエンド設定(HTTP設定)
バックエンドプールへの転送方式を設定します。
Application Gateway の HTTP 設定の構成
バックエンドへの転送プロトコル、ポート番号、正常性プローブなど設定します。
ホスト名のオーバーライド(書き換え)などもバックエンド設定(HTTP設定)に含まれます。
カスタムプローブを利用する場合もバックエンド設定(HTTP設定)で指定します。
バックエンド設定 | |
バックエンドの転送プロトコルやポートを指定します。 ホスト名のオーバーライドやカスタムプローブもバックエンドの設定項目に含まれています。 |
|
バックエンドプール
バックエンドプールでは転送先サーバを指定します。
転送先にはApp ServiceなどのAzureサービスも含まれます。
Application Gateway 構成の概要(バックエンド プール)
バックエンドプールに指定したサーバ間でトラフィック転送を負荷分散します。
負荷分散方式はラウンドロビンになります。
バックエンドプール | |
バックエンドターゲットとして転送先サーバを指定します。 バックエンドプールは仮想マシン、VMSS、App Service、IPアドレス(FQDN含む)などを指定できます。 |
|
ルール
リスナー、バックエンド プール、バックエンドを関連付けします。
リスナーで受け付けたトラフィックをバックエンド設定(HTTP設定)でどのバックエンドプールに転送するかを関連付けします。
Application Gateway 要求ルーティング規則
パスベースで転送するバックエンドプールを変更すると言った設定もルールで行います。
ルール | |
リスナーに対するルーティング規則を設定します。 リスナーのタブでWEBトラフィックを受信するリスナーを指定します。 リダイレクト設定などもルール設定に含まれます。 |
|
—広告—
アプリケーションゲートウェイに関連して必要となるリソース
必要になる関連リソース
アプリケーションゲートウェイ作成時に必要となる関連リソースがあります。
-
- サブネット
- パブリックIP
- ネットワークセキュリティグループ(NSG)
- GatewayManager サービスタグからの許可設定が必要
※サブネット、パブリックIPなどの関連リソースはアプリケーションゲートウェイと同時に作成できます。
※プライベートIPアドレスのみの構成もサポートされています。(2024年3月現在ではプレビュー)
サブネットは共用不可
アプリケーションゲートウェイ専用のサブネットを準備する必要があります。
v2ではインスタンス拡張を考慮して/24での利用が推奨されています。
Application Gateway インフラストラクチャの構成(サブネットのサイズ)
サブネットの中に他のリソースを作成する事は許可されていません。
サブネット | |
/24で言うサブネットを作成します。 |
※今回はAPGWという名前でサブネットを作成しています。
ネットワークセキュリティグループ
アプリケーションゲートウェイのサブネットに関連付けするネットワークセキュリティグループが必要です。
Application Gateway インフラストラクチャの構成(ネットワークセキュリティグループ)
GatewayManagerやAzureLoadBalancerからの通信許可が受信のセキュリティ規則に必要です。
ネットワークセキュリティグループ | |
GatewayManagerからの通信許可ポートはv2(65200 ~ 65535(TCP))となります。 |
パブリックIP
インターネットからのアクセスを受信する場合にはパブリックIPが必要です。
v2の場合はパブリックIPのSKUはStandard(静的)になります。
アプリケーション ゲートウェイのコンポーネント(静的パブリック IP アドレスと動的パブリック IP アドレス)
※プライベートIPアドレスのみの構成もサポートされています。(2024年3月現在ではプレビュー)
Azure Application Gateway(アプリケーションゲートウェイ)を作成
インスタンス数は2以上が推奨となっています。
今回は操作手順確認を目的としており性能やSLAは問わないため、最小規模(インスタンス数1)で作成します。
バックエンドプールではIISを利用したWEBサーバ(仮想マシン)を2台配置しています。
設定値
今回作成したアプリケーションゲートウェイの設定値です。
HTTPで受信したWEBトラフィックをバックエンドのにHTTPで負荷分散するようにしています。
※検証目的の設定値としています。実利用の際には環境に合わせた設定値とします。
タブ | 設定項目 | 設定値 |
基本 | ゲートウェイ名 | TEST-APGW |
地域 | East US 2 | |
レベル | Standard v2 | |
インスタンス数 | 1 | |
仮想ネットワーク名 | APGW-TEST-VNET | |
サブネット名 | APGW | |
フロントエンドの数 | フロントエンドIPの種類 | パブリック |
パブリックIPアドレス | APGW-TEST-PubIP-Standard | |
バックエンド | 名前 | APGW-TEST-BackendPool |
ターゲット | 仮想マシン(事前準備した仮想マシンを指定) | |
ルーティング規則 | ルール名 | APGW-TEST-Rule |
優先度 | 1 | |
リスナー名 | APGW-TEST-Listener | |
フロントエンドIPプロトコル | HTTP(ポート番号80) | |
ターゲットの種類 | バックエンドプール(APGW-TEST-BackendPool) | |
バックエンドターゲット | APGW-TEST-Backend | |
バックエンドプロトコル | HTTP(ポート番号80) |
作成手順を確認
Azure Portalを使ってアプリケーションゲートウェイを作成します。
アクセスして確認
ブラウザでフロントエンドのIPアドレスにアクセスして動作確認します。
バックエンドの仮想マシンでWEBサービス立ち上げ
こちらの手順を参考にIISを立ち上げた仮想マシンを2台用意しています。
ブラウザでフロントエンドのIPアドレスへアクセス
http://フロントエンドのIPアドレスへアクセスします。
各仮想マシンにブラウザアクセスした場合にはホスト名を表示するようにしています。
アクセス先のサーバによりAPGW-TEST-VM-01、02とそれぞれのホスト名が表示されます。
アクセス確認 | |
アプリケーションゲートウェイに割り当てたパブリックIPアドレスにブラウザでアクセスします。 1号機のホスト名が表示されました。 ブラウザを更新します。 2号機のホスト名が表示されます。 負荷分散されてバックエンドのサーバに転送されている事が確認できます。 |
|
バックエンド正常性の確認方法
バックエンドへの正常性確認についてはこちらの記事に纏めています。
アクセスログについて
アプリケーションゲートウェイのアクセスログについてはこちらに纏めています。
併せて見て頂けると大変有難いです。
リソースを停止すると課金も停止する
アプリケーションゲートウェイは停止する事で課金を止める事が出来ます。起動停止方法についてはこちらに纏めています。
最後に
今回はアプリケーションゲートウェイの構成要素、リソース作成手順、アクセスの負荷分散までを確認しました。
アプリケーションゲートウェイは複数の設定で構成されている事が分かりました。
リスナーでトラフィックの受信方法を設定、バックエンドプールで転送先サーバを指定、バックエンド設定(HTTP設定)でバックエンドのサーバへの転送方法を設定している事。
ルールでそれぞれの設定を関連付けするという事が分かりました。
各項目の設定内容を確認するとどこで何が設定されているのかが分かり勉強になりました。
引き続き色々試してみたいと思います。
パスベースのルールの作成についてはこちらにまとめています。