Azure Application Gatewayの概要から作成手順、動作確認まで

2019-05-26Application Gateway,Azure

　Azure Application Gateway(アプリケーションゲートウェイ)の作成手順や概要について纏めてみました。
　インターネットからHTTPを受信する基本構成で作成しブラウザでアクセス確認しています。

　※2022年7月にv2版に記事を更新しました。

スポンサーリンク

Azure Application Gateway(アプリケーションゲートウェイ)はどういうサービス

Azureで提供される負荷分散サービスの1つ

Azure Application Gateway とは

アプリケーションゲートウェイは(L7(アプリケーションレイヤ))でサーバー負荷分散を行うサービスです。
同じような負荷分散サービスとしてはAzure ロードバランサー(L4(OSIレイヤー))があります。

Azure Application Gateway の機能

Azure ロードバランサーと機能面の一番の違いは、アプリケーションゲートウェイがWebアプリケーション(HTTP(S))に対するトラフィックに特化している事があります。

    • URIパスに基づいた負荷分散等を行う事が出来る(バックエンドでパスベースの規則を選択)
    • ホスト名またはドメイン名に基づくルーティングが可能
    • SSLの終端が出来る
    • Web Application Firewall(WAF)が利用可能

v1とv2がある

アプリケーションゲートウェイにはv1とv2があります。

Azure Application Gateway v2 とは

v1、v2の違いについてはこちらに記載があります。

Azure Application Gateway v2 とは(v1 SKU と v2 SKU の機能比較)　

基本的な負荷分散的な機能面では大きな差異はありません。
v2ではゾーン冗長と言った可用性、静的IPのサポート、AKSのイングレスコントローラーと言った機能が使えます。

※公式ブログを見るとv2が強く推奨されており、将来的にはv1は廃止されていく模様です。

新しい Azure Application Gateway V2 の利用方法

Web Application Firewall(WAF)が使える

アプリケーションゲートウェイではWeb Application Firewall(WAF)を使う事が出来ます。
Web Application Firewall(WAF)はv1､v2ともに使えます。
v2ではカスタムWAFが使えます。

Azure Application Gateway 上の Azure Web アプリケーション ファイアウォールとは
Application Gateway 用の Web アプリケーション ファイアウォール ポリシーの作成

SKUは4パターン

アプリケーションゲートウェイとWAFの組み合わせで4パターンあります。
アプリケーションゲートウェイとWeb Application Firewall(WAF)両方に対して課金が発生します。

Application Gateway の価格

SKU APGW WAF
Standard v1 v1(S,M,L)(インスタンス数) ×
WAF v1(S,M,L)(インスタンス数) 〇
Standard v2 v2(インスタンス数) ×
WAF v2 v2(インスタンス数) 〇(カスタムWAF)

WAFについてはこちら。

Azure Application Gateway(アプリケーションゲートウェイ)の構成要素

アプリケーションゲートウェイは複数の要素で構成されます。

フロントエンドIPアドレス

Application Gateway のフロントエンド IP アドレスの構成

アプリケーションゲートウェイが受信するIPアドレスになります。
パブリック IP アドレス、プライベート IP アドレスがあります。(v2はパブリックIPアドレスが必須)
パブリックIPアドレスの場合はインターネットに公開するアドレスになります。

※リスナーと関連付けられる事でアプリケーションゲートウェイが受信するIPアドレスとなります。

フロントエンドIPアドレス
パブリックとプライベートがあります。
リスナーと関連付けて利用します。

リスナー

Application Gateway リスナーの構成

リスナーはアプリケーションゲートウェイがアクセスを受け付ける為の設定になります。
プロトコル(HTTPもしくはHTTPS)、ポート、ホスト、IP アドレスの組み合わせで設定します。
マルチドメインやSSLオフロード設定もリスナー単位で行います。

リスナー
リスナーはルールに関連付ける事でバックエンドへ転送します。
マルチサイトやエラーページの設定が出来ます。
HTTPSを選択すると証明書登録が可能となります。(SSLオフロード設定が出来ます。)

バックエンド(HTTP設定)

Application Gateway の HTTP 設定の構成

バックエンド設定(HTTP設定)です。
バックエンドではバックエンドプールへの転送方式を設定します。
カスタムプローブの設定等もバックエンド設定で行います。

バックエンド設定
バックエンドの転送方法設定になります。
バックエンドの転送プロトコルやポート指定が出来ます。
正常性プローブ(個別に作成した場合)をカスタムプローブとして設定する事も出来ます。

ルール

Application Gateway 要求ルーティング規則

リスナー、バックエンド プール、バックエンドを結びつける設定になります。
リスナーで受け付けたトラフィックをどのバックエンドに転送するかを設定します。
パスベースで転送するバックエンドプールを変更すると言った設定もルールで行います。

ルール
リスナーに対してルーティング規則を設定していきます。
リスナーのタブでWEBトラフィックを受信するリスナーを指定しています。
バックエンドターゲットでは、バックエンドプール、バックエンド設定との関連付けを行います。

バックエンドプール

Application Gateway 構成の概要(バックエンド プール)

転送先のWEBサーバの設定になります。
バックエンドプールに複数のWEBサーバを設定すると負荷分散したトラフィックの転送が出来ます。
負荷分散方式はラウンドロビンになります。

バックエンドプール
バックエンドプールではトラフィック転送先の指定を行います。
バックエンドターゲットで転送先を指定します。
バックエンドプールは仮想マシン、VMSS、App Service、IPアドレス(FQDN含む)で指定出来ます。

Azure Application Gateway(アプリケーションゲートウェイ)で必要になるリソース

必要になる関連リソース

アプリケーションゲートウェイ作成時に必要となる関連リソースがあります。

    • サブネット
    • パブリックIP
      • V1ではパブリック選択時のみ必須
      • V2では必須
    • ネットワークセキュリティグループ(NSG)
      • GatewayManager サービスタグからの許可設定が必要

※サブネットもパブリックIPもアプリケーションゲートウェイと同時に作成出来ます。

サブネットは共用不可

Application Gateway インフラストラクチャの構成(サブネットのサイズ)

アプリケーションゲートウェイ専用のサブネットを準備する必要があります。
このサブネットの中に他のリソースを作成する事は許可されていません。
今回はAPGWと言うサブネットを準備しています。

サブネット
/24でAPGWと言うサブネットを作成しています。

ネットワークセキュリティグループ

Application Gateway インフラストラクチャの構成(ネットワークセキュリティグループ)

受信セキュリティ規則でGatewayManagerからの通信とHTTP(S)の通信許可が必要になります。

ネットワークセキュリティグループ
GatewayManagerからの通信許可ポートはv1(65503 ～ 65534(TCP))とv2(65200 ～ 65535(TCP))で異なっています。
HTTP(S)の通信許可が必要になります。

パブリックIP

インターネットからのアクセスを受信する場合にはパブリックIPが必要になります。
v1とv2でパブリックIPに必要な要件が異なります。

アプリケーション ゲートウェイのコンポーネント(静的パブリック IP アドレスと動的パブリック IP アドレス)

v2の場合はパブリックIPのSKUはStandard(静的)になります。
v1の場合はパブリックIPのSKUはBasic(動的)になります。

Azure Application Gateway(アプリケーションゲートウェイ)を作成

今回は試験用なので最小規模(インスタンス数1)で作成しています。
インスタンス数は2以上が推奨なので実際の利用時は注意して下さい。
バックエンドプールでは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を使ってアプリケーションゲートウェイを作成します。

アプリケーションゲートウェイの作成

ゲートウェイ名、SKU等を指定します。
デプロイする仮想ネットワークを指定します。仮想ネットワークはアプリケーションゲートウェイと同じ地域にある必要があります。

※今回は動作確認のみなのでHTTP2無効にしていますが、一般的な使い方では有効にします。
フロントエンドの数タブでは利用するパブリックIPを選択します。
v2の場合はパブリックIPのSKUがStandard(静的IP)である必要があります。
バックエンドのタブではバックエンドプールの設定を行います。
バックエンドプールの追加を選択します。
バックエンドプールでは転送する仮想マシン等のバックエンドターゲットを選択します。
今回は仮想マシンへ2台への転送設定します。

構成のタブではルーティング規則(ルール)の設定を行います。
ルーティング規則の追加を選択します。

※フロントエンドやバックエンドプールの追加も本画面で設定可能です。

ルーティング規則ではリスナーやバックエンドターゲットを設定します。
ルール名や優先度の設定します。
リスナー名やポートの設定を行います。
フロントエンドプロトコルはアプリケーションゲートウェイで受信するプロトコルを選択します。(HTTPSの場合はSSL証明書が必要になります。)

※今回はHTTP受信をそのままバックエンドの仮想マシンへ転送する設定にしています。
バックエンドターゲットでは転送先のバックエンドプールを選択します。
バックエンドターゲットは存在しませんので新規追加を選択します。

バックエンド設定名やバックエンド(WEBサーバ側で受信するプロトコルやポート)を指定します。

※個別に作成した正常性プローブを利用したい場合はアプリケーションゲートウェイ作成後に設定します。
バックエンド設定が終わったら追加を選択します。

構成の設定が終わったら次へを選択します。

※タグ設定は割愛しています。
確認画面になります。
内容を確認し問題が無ければ作成を選択します。

Webアクセスで動作確認してみる

ブラウザアクセスして動作確認してみます。

バックエンドの仮想マシンでWebサービス立ち上げ

こちらの手順を参考にIISを立ち上げた仮想マシンを2台用意しています。

アクセス確認する

アクセスはhttp://フロントエンドのアドレスで行います。
仮想マシンのホスト名はAPGW-TEST-VM-01、02としそれぞれのホスト名を表示するようにしています。

アクセス確認
アプリケーションゲートウェイに割り当てたパブリックIPアドレスにブラウザでアクセスします。
ホスト名が表示される事が確認出来ます。
ブラウザを更新します。
そうすると2号機が表示されます。
アプリケーションゲートウェイで負荷分散されている事が確認出来ます。

バックエンド正常性の確認方法

バックエンドのWEBサーバへのアクセス状況をAzure Portalで確認する事が出来ます。

バックエンド正常性
状態が健全と表示されていれば正常です。
アプリケーションゲートウェイからの転送されます。
異常と表示されている場合はそのホストには転送されません。
仮想マシン側に設定されたNSG等でアプリケーションゲートウェイからの通信が許可されていない場合はここで異常と表示されます。

アプリケーションゲートウェイのアクセスログについてはこちらに纏めています。併せて見て頂けると大変有難いです。

 

最後に

今回はアプリケーションゲートウェイの基本の纏めから初期構築、HTTPアクセスでの確認までやってみました。
リスナーで受信方法を設定、バックエンドプールで転送先を指定、バックエンド設定で転送方法を設定、ルールでそれぞれの関連付けを行い設定するという事が分かりました。
アプリケーションゲートウェイについて引き続き色々試してみたいと思います。

WAFの設定についてはこちら。

パスベースのルールの作成についてはこちら。

Application Gateway,Azure