みなさんこんにちは、武井です。今回はAzureのL7ロードバランサーであるApplication Gatewayについて、わかりみの深く解説したいと思います。

L7のロードバランサーとは？

Application GatewayはL7(レイヤー7)のロードバランサーになります。その比較対象としてよく挙げられるのがL4のロードバランサーですが、この違いについて明確にすることで、L7のロードバランサーの特徴やメリットなどを解説したいと思います。

下図は、L4とL7のロードバランサーの違いを図に示したものです。

L4のロードバランサーとは、その名の通りトランスポート層のプロトコルを解釈して負荷分散するロードバランサーです。トランスポート層のプロトコルはTCPやUDP等色々ありますが、ここではTCPを例に取ってご説明します。

上図の通り、クライアントとサーバー間のsyn、syn+ack、ackのやり取り(3ウェイハンドシェーク)は常にロードバランサーを素通り(?)して、貼られるTCPセッションは常に一本です。ロードバランサーはL4以下(IPアドレスやTCPポートなど)の情報を元に負荷分散先を判断します。つまり、L7のロードバランサーのように、高度な負荷分散はできません。ラウンドロビンで順番に各サーバーにリクエストを降ったり、送信元IPアドレスとポート番号のハッシュ値でリクエスト先のサーバーを決定したりと、L7に比べますと、負荷が特定のサーバーに寄ってしまう可能性があります。

それに対して、L7のロードバランサーは、クライアントがロードバランサーに対して3ウェイハンドシェークでTCPセッションを貼ってHTTPリクエストを送った後、今度はロードバランサーがHTTPクライアントとなり、サーバーに対してTCPセッションを貼ってHTTPリクエストを送ります。つまりTCPセッションは2本貼られます。

つまり、いったんロードバランサー側でSSLによる暗号化通信を解除することとなり、ロードバランサーでHTTPリクエスト及びレスポンスの中身を見ることができます。なので、Cookieパーシステンス(ロードバランサーからブラウザにCookieを発行することにより特定のブラウザからのアクセスは特定のサーバーに分散する機能)や、マルチサイト(HTTPリクエストのホスト名によって分散先のサーバーを決定する機能)といった高度な分散処理やHTTPレスポンスの書き換えが実現できます。ただ、HTTPリクエスト、HTTPレスポンスの検証や書き換え、SSLによる暗号化通信解除などといった処理を伴うので、一般的には高負荷になります。

まとめますと以下のようになります。

Azure Application Gatewayとは？

Azure Application Gatewayとは、Azureが提供するL7のロードバランサーです。以下の特徴があります。

• もちろんマネージド。セキュリティパッチ当てたりなどの運用は一切不要である。
• 負荷に応じて柔軟にスケールする。
• SSLの終端を行うことができる。
• WAF(Web Application Firewall)によって高いセキュリティを確保できる。
• Azureの各種サービスと密な連携が可能である(例えばApp Serviceの前段に配置することも簡単にできる)

と、まぁいろんな特徴があるわけなんですが、以降でそれらの特徴をわかりみ深く説明していきたいと思います。

Azure Application Gatewayの構成

Application Gatewayの概念は少々複雑です。まずはざっくりとした概念図をご説明して、その後により詳細な図でご説明するという流れにします。

ざっくりとした概念図

ざっくり図にすると、以下の通りとなります。

かなりいろんな構成要素が複雑に絡み合っているのがわかります。それぞれの構成要素を説明致します。

フロントエンド

Application Gatewayの入り口になります。具体的には、ユーザーやアプリがアクセスするロードバランサーのIPアドレスです。ユーザーやアプリは、フロントエンドにて定義されたパブリックIPやプライベートIPにアクセスすると、ロードバランサー配下の仮想マシンやApp Serviceなどにアクセスできます。

「パブリックIP」「プライベートIP」の2つがあるのですが、これはその名の通り、パブリックIPはインターネット上に公開されたエンドポイントです。パブリックIPアドレスがフロントエンドに付与されたApplication Gatewayはインターネット上からアクセスが可能です。

リスナー

後述するルーティング規則とフロントエンドを結びつける構成要素です。リスナーはHTTPのスキーム(HTTP or HTTPS)やホスト名などで構成されております。

例えば、XXX.XXX.XXX.XXXというパブリックIPを持つフロントエンドと、HTTPSのスキームをもつリスナーを結びつけると、「https://XXX.XXX.XXX.XXX」というURLを持つロードバランサーが構成されます。

ルーティング規則

フロントエンド+リスナーの組み合わせで作成されたURLで受信したHTTPリクエストを、どのバックエンド(Application GatewayからHTTPリクエストを受け付けてHTTPレスポンスを生成し、Application Gatewayに返すサーバー)に流すのかというルール決めを行う構成要素です。

ルーティング規則の中にも様々な構成要素があるのですが、その代表は「バックエンドターゲット」です。バックエンドターゲットは、その名の通り、そのバックエンドプールにHTTPリクエストを流すのかというルールを決めます。

バックエンドプール

バックエンドを配置するための構成要素です。VMやApp Service、IPアドレスを配置できます。

簡単な実例

ではここで、簡単な実例を交えて説明してみたいと思います。

https://XX.XX.XX.XXというURLでリクエストを受け付けて、2台のVM(VM1とVM2)にリクエストを分散させる構成を考えてみます。以下のような構成になります。

このようなApplication Gatewayを作り出すための手順は以下になります。

1. XX.XX.XX.XXというパブリックIPを作成しフロントエンドに配置します。
2. httpsでリクエストを受け付けるリスナーを作成して、ルーティング規則とフロントエンドを結びつけます。
3. ルーティング規則の中に、バックエンドプールを作成し、分散対象のVM1とVM2を配置します。
4. ルーティング規則の中にバックエンドターゲットを作成し、バックエンドプールを紐付けます。

このような流れで、Application Gatewayを作成します。

これは最も単純な例であり、本番で稼働するApplication Gatewayはもう少々複雑な設定が必要になることが多くあります。次章では、今回説明したリスナーやルーティング規則などの構成要素を更に細かく分解して見ていきます。

もっと細かい構成図

先で示したのはApplication Gatewayのざっくりとした概念図でした。本当は以下のような構成図になり、かなりいろいろな構成要素が登場して一気に複雑になります。

なんだか図がごちゃごちゃしてきました。でも、基本的なApplication Gatewayの動きは「ざっくりとした概念図」で提示したものとかわりありません。これから説明しますのは、「ざっくりとした概念図」では説明しきれなかった便利機能の数々といったイメージです。

では一つずつ説明していきます(^^)

リスナー

リスナーはさらに以下の細かい構成要素から成り立ちます。

• フロントエンドIP
• プロトコル
• ポート
• リスナーの種類
• エラーページのURL

以降で詳しく説明していきます。

フロントエンドIP

Application Gateway自身に付与するIPアドレスになります。先程も説明したように「パブリックIP」「プライベートIP」を付与することが可能です。Application GatewayのURLが「https://xx.xx.xx.xx/」だとすると、「xx.xx.xx.xx」の部分です。

プロトコル

HTTPもしくはHTTPSが選択可能です。Application GatewayのURLが「https://xx.xx.xx.xx/」だとすると、「https」の部分です。

ポート

Application GatewayのURLのポートは80、443以外にも任意のポートを指定することが出来ます。

リスナーの種類

「Basic」「マルチサイト」の2つがあります。「マルチサイト」にすると、URLのホスト名の部分は異なるけれど、同じルーティング設定を共有することが出来ます。

つまり、https://hoge.contoso.com/、https://fuga.contoso.com/という2つのURLのどちらにアクセスしても、同じサーバーに負荷分散させるような仕組みを作ることが出来ます。図にすると以下のような感じです。

Application GatewayはHTTPリクエストのHostヘッダーによって、接続するリスナーを判別します。

エラーページ

エラーが発生した際のエラーページを表示することが出来ます。ただし、どんなエラーのときでもエラーページが表示されるわけではなく、以下の2つのケースの場合に限られます。

• HTTPリクエストをルーティングするバックエンドが落ちているとき
• WAF利用時、悪意あるトラフィックを検出したとき

なので、例えばApplication Gatewayそのものが落ちているときには、上記で定義したエラーページには遷移しません。

バックエンドターゲット、バックエンドプール、パスベースの規則

バックエンドターゲットの中には、バックエンドプール、パスベースの規則という構成要素があります。

バックエンドプールはその名のとおり、Application Gatewayがリクエストを分散させるバックエンドを指定します。

パスベースの規則は、パスによって異なるバックエントにリクエストを振り分けることができる機能です。以下の図は、パスが/images/から始まる場合はバックエンドプール1に、パスが/videos/*から始まる場合はバックエンドプール2にリクエストを振る構成になります。

バックエンド設定

バックエンドに接続するための設定になります。バックエンドに接続するための様々なルールを定義します。設定項目を一つずつ見ていきましょう。

バックエンドプロトコル

バックエンドに接続するプロトコルを定義します。「http」「https」の2択です。例えば、「http」を選べば以下のような経路となり、SSL証明書はApplication Gatewayだけで持てばよいということになります。

ブラウザ→(https)→Application Gateway→(http)→バックエンド

バックエンドポート

バックエンドに接続するポートを定義します。任意のポート番号を設定出来ます。

Cookieベースのアフィニティ

いわゆる「Cookieパーシステンス」なロードバランサーを実現出来ます。Application GatewayがブラウザにCookieを発行し、そのCookieの値をもとに、同一ブラウザからのリクエストは同一バックエンドに振り分けます。

接続のドレイン

この設定を有効にしていると、バックエンドプールからバックエンドが削除されても、削除されたときに行われていた通信が最後まで完了するまで、バックエンドの切り離しを待ちます。

例えば、上記の例で言えば、ユーザーはVM2から画像ファイルをダウンロードしていたとします。このとき、計画メンテナンスなどで、バックエンドプールからVM2を削除したとしても、すぐには削除されず、「ドレイン タイムアウト(秒)」で指定した秒数まではこの通信を継続して、この通信が終了してからVM2がバックエンドプールから削除されます。

このようにすれば、計画メンテナンスなどでバックエンドをバックエンドプールから切り離す必要が発生したとしても、ユーザーには影響なく作業ができます。

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

URLのロケーションの部分を変換する機能です。バックエンドパスのオーバーライドを「/override/」に設定すると、以下のようにロケーションの変換が行われます。

ホスト名のオーバーライド

Application Gatewayからバックエンドに送出するホストヘッダーを変更することが出来ます。

まずは特に何もホストヘッダーを変更しない場合は以下の挙動になります。

これはユーザーがApplication Gatewayにリクエストしてきたホストヘッダーをそのままバックエンドに渡す形式となります。

次は、バックエンドからホスト名を取得する方式です。

バックエンドに設定されたホスト名を取得して、Application Gatewayからバックエンドにそのホスト名を渡します。これは、特にApp Serviceを使う場合は必須で、App Serviceのロードバランサーはホストヘッダーの値を見て、リクエストを送るインスタンスを決定するからです。

最後に、任意のホストヘッダーを指定する方式です。

Application Gateway側で指定した任意のホストヘッダーをバックエンドに送ることが出来ます。

カスタムプローブ

Application Gatewayは何らかの異常が発生したバックエンドを振り分け対象から外すことが可能です。何を持ってして異常と判断するかを細かくカスタマイズが可能で、その設定が「カスタムプローブ」になります。

以下のようなカスタマイズが可能です。

試してみよう

では、百聞は一見にしかずということで、実際にApplication GatewayでL7のロードバランサーを作ってみましょう。今回は以下の要件を満たすものを作ることとします。

• インターネット経由でアクセスできるIPアドレスをエンドポイントに持つ。
• ユーザーからApplication Gatewayのエンドポイントまでの通信はHTTPSとする。
• Application Gatewayからバックエンドまでの通信はHTTPとする。
• /images/から始めるロケーションにアクセスした場合はバックエンドプール2に振り分け、それ以外はバックエンドプール1に振り分ける。
• Application Gatewayは、バックエンドプール内に事前に用意したヘルスチェック用エンドポイントにアクセスし、以下の応答が返ってこなかったら、そのバックエンドを振り分け対象から外す。
  • HTTPステータスコードが200
  • HTTPレスポンスの本文内に「OK」の文字列を含む。

上図のバックエンドプール内にはそれぞれ1台ずつ仮想マシンを配置するものとし、Application Gatewayを作成するに先立ち、事前に作成されているものとします。

まずはApplication Gatewayのリソースを作成します。

Azureポータル上部のテキストボックスに「Application Gateway」と入力しますと、以下の画面の用に「アプリケーションゲートウェイ」と表示されますので、それをクリックします。

「作成」をクリックします。

以下のような画面が表示されます。

入力項目の詳細は以下のとおりです。

フロントエンドのIPアドレスの設定を行います。今回はパブリックのみとします。その場合、パブリックIPアドレスのリソースを選択する必要があります。もしなければ「新規追加」をクリックして作成します。

バックエンドプールを追加します。「バックエンドプールの追加」をクリックします。

「名前」には任意の値を入力します。「ターゲットを持たないバックエンド プールを追加します」はもちろん「いいえ」を選択します。「ターゲットの種類」には「仮想マシン」、「ターゲット」には冒頭の図の「バックエンドプール1」に配置すべき仮想マシンのリソースを選択します。最後に「追加」をクリックします。

「バックエンドプール2」に配置すべき仮想マシンも同様の手順で追加します。

こんな感じになるはずなので、次に「次: 構成 >」をクリックします。

次にルールを追加します。「ルール」をクリックします。

以下のような画面が表示されます。

「ルーティング規則」の入力項目の詳細は以下のとおりです。

次にバックエンドターゲットを指定します。「ターゲットの種類」で「バックエンドプール」を選択して、「バックエンドターゲット」には、先程作成した「backendpool01」を選択します。そして、「バックエンド設定」を作成するために「バックエンド設定」の項目のところにある「新規追加」をクリックします。

以下のようにバックエンド設定の設定画面が表示されます。

バックエンド設定画面の設定項目の詳細は以下のとおりです。

次に、要件「/images/から始めるロケーションにアクセスした場合はバックエンドプール2に振り分け、それ以外はバックエンドプール1に振り分ける。」を満たすために、パスベースの規則を作成します。以下の画面下部の「パスベースの規則を作成するには複数のターゲットを追加します」をクリックします。

以下のようにパスベースの規則の設定画面が表示されます。

パスベースの規則の設定項目の詳細は以下のとおりです。入力したら「追加」をクリックします。

以下のような画面が表示されます。「追加」をクリックします。

以下のような画面が表示されます。「次: タグ>」をクリックします。

特にタグの付与は今回考えていません。なので、「次: 確認および作成>」をクリックします。

確認画面が表示されます。設定した内容に問題がなければ「作成」をクリックします。

次にカスタムプローブの設定を行います。カスタムプローブは、バックエンドプール内のターゲットが正常に稼働しているかどうかを監視する機能になります。詳細はこちらで説明しています。

Application Gatewayのリソースの作成に成功していれば、リソースグループ内にApplication Gatewayのリソースがあるはずなので(以下画面のagw-demo-prd参照)、それをクリックします。

「正常性プローブ」をクリックします。

「追加」をクリックします。

正常性プローブの追加画面が表示されます。

以下の通り入力してください。

正常性プローブの追加画面で、上記の内容を入力して「テスト」をクリックするのですけど、その前に「パス」の部分で入力したhealthckek.phpは、以下のようなPHPスクリプトであることを前提としています。

<?php
http_response_code( 200 ) ;
echo "OK";
?>

これは冒頭の方で説明した、今回作成するApplication Gatewayの以下の要件を満たしたものです。

• Application Gatewayは、バックエンドプール内に事前に用意したヘルスチェック用エンドポイントにアクセスし、以下の応答が返ってこなかったら、そのバックエンドを振り分け対象から外す。
  • HTTPステータスコードが200
  • HTTPレスポンスの本文内に「OK」の文字列を含む。

つまり、正常性プローブの通信の結果が、HTTPレスポンスコード200であり、かつHTTPレスポンスの中に「OK」という文字列が含まれないと、正常とみなされないということです。

上記のPHPスクリプトは今回都合上、無条件にHTTPステータスコード200、HTTPレスポンス内に「OK」という文字列を返しているだけですが、実際はデータベースなどの間連システムの正常性を確認した上で、結果を返します。

話がそれましたが、正常性プローブの追加画面で「テスト」をクリックしてみましょう。

以下のような画面が表示され、先程設定したバックエンド設定が関連付けられたバックエンドプール内のターゲットに対して、正常性プローブのリクエストが送られます。問題なければ、以下のように「健全」と表示されるはずなので、「追加」をクリックしてみましょう。

以下のような画面が表示されればOKです。

これで、要件を満たしたApplication Gatewayの完成です！！

価格

本章では、Application Gatewayの価格について説明します。

まずその前にApplication Gatewayのレベルについて説明します。Application Gatewayにはv1とv2というレベルがあり、選択したレベルによって使える機能が異なります。例えば、v2だとWAFや自動スケールと言った便利な機能が利用できます。

昨今利用されるのはほとんどv2であると思うので、今回ご説明する価格については、v2をベースとします。

Application Gatewayの構成要素

価格を説明する上で重要になるのがApplication Gatewayの構成要素であり、以下の3つからなります。

• Application Gatewayのリソース
• インスタンス
• 容量ユニット

一つずつ説明してまいります。ざっくり図解すると以下のような感じになります。

Application Gatewayのリソース

Azureポータルから作成したApplication Gatewayのリソースそのものです。Azureポータルから以下のように見えるやつです。

容量ユニット

Application Gatewayの課金単位です。Application Gatewayが処理するHTTPリクエストが増えれば増えるほど、多くの容量ユニットが必要になり、さらに多くの課金がかかります。例えば、2023年7月8日現在、東日本リージョンで1容量ユニットが1時間利用された場合にかかる課金は、1.1564円となります。当然容量ユニットが2つになれば、その倍かかります。

先程「HTTPリクエストが増えれば増えるほど、多くの容量ユニットが必要になり・・・」と説明しましたが、容量ユニットが増える一定のルールがあります。以下の3つの条件のうちの一つでも超えるとさらに多くの容量ユニットが必要になります。

•  2500 個の永続的な接続
• 2.22 Mbps のスループット
• 1コンピューティングユニット

容量ユニットを消費する要因としては上記3つがあるのですが、これを事前に机上で計算してインスタンス数を決めるのはほぼ不可能かと思います。事前に本番と同程度の負荷かけるか、もしくは実際に本番運用に入ってからメトリック(スループットやコンピューティングユニットなど)を確認して、適切なインスタンス数を調整するのが妥当な方法です。

インスタンス

容量ユニットはインスタンスの中に格納されます。一つのインスタンスの中に10個の容量ユニットが格納され、必要な容量ユニットが10個を超えると、新たなインスタンスが必要となります。

つまり、Application Gatewayのスケールはインスタンスという単位で行われます。

そしてインスタンスのスケールには、「自動スケーリング」「手動」の2つがあり、後で説明するコストの計算にも重要な概念となりますので、ここで説明します。

■ 自動スケーリング

インスタンスの自動スケールについては、Application Gatewayのリソースを作成するときに、以下の設定を行ったのを覚えてますでしょうか？

ここで「はい」を選択すると、自動スケールするようになります。

最小インスタンス数と最大インスタンス数を指定でき、まず初めは最小インスタンス数で指定した値でApplication Gatewayが起動し、負荷が増えればインスタンスが最大インスタンス数に指定した値までスケールアウトします。また、負荷が収束すれば、最小インスタンスで指定した値までスケールインします。

つまり、自動スケーリングの場合は、現在のインスタンス内にある容量ユニットで処理しきれないくらいのリクエストがあった場合、インスタンスが増えて、そのインスタンスに新たな容量ユニットが出来上がり、その容量ユニットでリクエストを処理するわけです。図にすると以下のようになります。

■ 手動の場合

先に説明した「自動スケール」の項目で「いいえ」を選択すると、以下の様な画面になります。

この場合インスタンス数は固定になります。例えばインスタンス数が2の場合に、最初は1つ目のインスタンスで処理しきれていたが、リクエストが多くなり1つ目のインスタンスだけでは処理しきれなくなった場合の動きは以下の通りとなります。

価格の構成要素

Application Gatewayの構成要素を説明しましたので、次はApplication Gatewayの価格がどのような要素で決定づけられるのかを説明したいと思います。以下の2つの要素によってApplication Gatewayの価格が決まります

• 固定コスト
• 容量ユニットのコスト

固定コスト

Application Gatewayのリソースを削除しない限り、たとえ接続がなくても、発生し続けるコストです。例えば東日本リージョンですと、2023年7月16日時点では、1時間あたり41.9181円のコストが発生します。つまり1ヶ月稼働させていると以下になります。

41.9181円/時間 × 24時間 × 30日 ＝ 約30,181円

変動コスト

先程ご説明した容量ユニットに発生するコストです。例えば東日本リージョンですと、2023年7月16日時点では、一つの容量ユニットが1時間稼働すると、1.1564円のコストが発生します。10個の容量ユニットが1ヶ月稼働すると以下になります。

1.1564円/容量ユニット時間 × 10 × 24時間 × 30日 ＝ 約8,326円

超過コストが発生しない手動スケーリングの場合

ここからは、いくつかの例を用いて、実際に発生する費用のシミュレーションをしてみたいと思います。

では、手動スケーリングの場合からです。以下の条件であったと仮定します。

•  スケーリングは手動
• インスタンス数は6で固定
• ある特定の月に平均88.8Mbpsのデータを受信

この場合のApplication Gatewayの構成は以下のようになります。

一つの容量ユニットで2.22Mbpsのスループットを処理できて、今回は88.8Mbpsのスループットがありましたので、必要な容量ユニットは以下になります。

88.8Mbps ÷ 2.22Mbps/容量ユニット = 40容量ユニット

今回は、固定で6インスタンス起動しており、常時60容量ユニットがあります。

60容量ユニット(現在動いている分) > 40容量ユニット(必要な分)

なので、追加コストは発生しません。よってコストは以下となります。

固定コスト = 41.9181円/時間 × 24時間 × 30 ＝ 約30,181円

変動コスト = 1.1564円/容量ユニット時間 × 60容量ユニット × 24時間 × 30 ＝ 約49,965円

合計コスト = 固定コスト+変動コスト = 約80,146円

超過コストが発生する手動スケーリングの場合

そもそもタイトルから矛盾しているように思えるのですが、今回は超過コストが発生する手動スケーリングの場合です。以下の条件であったと仮定します。

•  スケーリングは手動
• インスタンス数は3で固定
• ある特定の月に平均88.8Mbpsのデータを受信

この場合のApplication Gatewayの構成は以下のようになります。

一つの容量ユニットで2.22Mbpsのスループットを処理できて、今回は88.8Mbpsのスループットがありましたので、必要な容量ユニットは以下になります。

88.8Mbps ÷ 2.22Mbps/容量ユニット = 40容量ユニット

今回は、固定で3インスタンス起動しており、常時30容量ユニットがあります。

30容量ユニット(現在動いている分) < 40容量ユニット(必要な分)

つまり、今回の容量ユニットでは処理がさばききれず、追加コストが発生しない場合は、以下のようになります。

固定コスト = 41.9181円/時間 × 24時間 × 30 ＝ 約30,181円

変動コスト = 1.1564円/容量ユニット時間 × 30容量ユニット × 24時間 × 30 ＝ 約24,978円

合計コスト = 固定コスト+変動コスト = 約55,159円

「追加コストが発生しない場合」と書きましたが、実は「追加コストが発生する場合」もあります。1インスタンスの中には最大10個の容量ユニットを格納できると説明しましたが、場合によっては10個を超えて格納できることがあるそうです。ただ、どれくらい格納できるかはいろんな条件に応じて左右されるとのことです。

ここで、各インスタンスで1つだけ多くの容量ユニットを格納できたとしましょう。

つまり、3容量ユニット分の超過コストが発生することになります。よってコストは以下となります。

固定コスト = 41.9181円/時間 × 24時間 × 30 ＝ 約30,181円

変動コスト = 1.1564円/容量ユニット時間 × 33容量ユニット × 24時間 × 30 ＝ 約27,476円

合計コスト = 固定コスト+変動コスト = 約57,657円

つまり、2,498円の超過コストが発生します。

超過コストが発生する自動スケーリングの場合

今度は自動スケーリングの場合です。以下の条件であったと仮定します。

•  スケーリングは自動
• 最小インスタンス数は3
• 一ヶ月全体に渡って34容量ユニットを利用するようなリクエストを受信

この場合、Application Gatewayの構成は以下となります。

コストは以下の通りとなります。

固定コスト = 41.9181円/時間 × 24時間 × 30 ＝ 約30,181円

変動コスト = 1.1564円/容量ユニット時間 × 34容量ユニット × 24時間 × 30 ＝ 約28,308円

合計コスト = 固定コスト+変動コスト = 約58,489円

各種機能の紹介

本章では、今まで紹介しきれなかったApplication Gatewayの細かい便利機能について説明します。

クライアント証明書による認証

Application Gatewayはクライアント証明書による認証も可能です。実際に試してみたいと思います。

手順としては以下になります。

1. クライアント証明書を作成する。
2. SSLプロファイルを作成して、CA証明書を登録する。
3. 作成したSSLプロファイルをリスナーに紐付ける。

クライアント証明書を作成する

まずは以下の手順で認証局とクライアント証明書を作成しましょう。opensslコマンドを使います。

認証局を作成します。
$ openssl req -newkey rsa:4096 -keyform PEM -keyout clientca.key -x509 -days 3650 -extensions v3_ca -outform PEM -out clientca.cer -addext basicConstraints=CA:true

クライント証明書の秘密鍵を作成します。
$ openssl genrsa -out client.key 4096

クライント証明書のCSRを作成します。
$ openssl req -new -key client.key -out client1.req

クライアント証明書を作成します。
$ openssl x509 -req -in client1.req -CA clientca.cer -CAkey clientca.key -set_serial 101 -extensions client -days 365 -outform PEM -out client1.cer

Windowsなどでも読み込めるように、P12形式に変換します。
$ openssl pkcs12 -export -inkey client.key -in client1.cer -out client1.p12

SSLプロファイルを作成して、CA証明書を登録する

AzureのポータルからApplication Gatewayのリソースを表示して、左部メニューの「SSL設定」をクリックします。それから、「+ SSLプロファイル」をクリックします。

「SSLプロファイル名」に任意の名称を入力します。そして、「新しい証明書のアップロード」をクリックします。

「証明書」に証明書を識別するための一意な名前を入力します。そして、先程作成したCA証明書(ファイル名clientca.cer)を選択して、「OK」をクリックします。

最後に以下の画面で「追加」をクリックします。

作成したSSLプロファイルをリスナーに紐付ける

クライアント証明書による認証を行いたいリスナーにアクセスします。Azureのポータルにアクセスして、左部メニューの「リスナー」をクリックします。画面右部にリスナーの一覧が表示されるので、クライアント証明書による認証を行いたいリスナーをクリックします。

「SSLプロファイルを有効にする」をチェックしますと、「SSLプロファイル」というセレクトボックスが現れます。そこで、先程作成した名称のSSLプロファイルを選択して、「保存」をクリックします。

これで設定は完了です。サイトにアクセスすると、クライアント証明書による認証が要求されるはずです。

HTTPヘッダーとURLの書き換え

Application GatewayはHTTPリクエストヘッダーやHTTPレスポンスヘッダー、URLを様々な条件で書き換えることが可能です。

この設定は、「書き換えセット」「書き換えルール」「条件」「アクション」の4つで構成され、その関係は図に示す通りとなります。

これは理論を説明するよりも、いろんな実例をもとに説明したほうがわかりやすいとおもいます。マイクロソフトのドキュメントに乗っている実例を挙げてわかりみ深く解説します。

X-Forwarded-For ヘッダーからポート情報を削除する

X-Forwarded-ForヘッダーにはIPアドレスに加えてポート番号が付与されてくるケースもありますが、このポート番号は不要であることが多いので、これを削除したいと思います。以下のようなイメージです。X-Forwarded-Forには203.0.113.7:8080の値が設定されてユーザからApplication Gatewayに送られてきましたが、Application Gateway側でポート番号を削除して203.0.113.7という値にして、バックエンドに送ります。

AzureのポータルからApplication Gatewayのリソースを表示して、左部メニューの「書き換え」をクリックします。画面右部に表示されている「+ 書き換えセット」をクリックします。

「名前」には、書き換えセットを一意に識別する名称を入力します。「関連付けられているルーティング規則」には、この書き換えセット(X-Forwarded-Forからポート番号を削除する)を適用するルーティング規則を選択します。そして、「次へ」をクリックします。

「+書き換え規則の追加」をクリックします。

以下のような画面になります。「実行」をクリックして、アクションを編集します。

以下のように設定します。

上記の設定内容の詳細は以下のとおりです。

最後に「作成」をクリックして完了です。

クエリパラメータの値によって振り分けるバックエンドを変える

今度はクエリパラメータの値によって振り分けるバックエンドを変えてみます。

クエリパラメーターにcategory=foodsが設定されていたら、ロケーションを/listfoodsに変換してバックエンドにルーティングします。つまり、図にしますと以下のような感じです。バックエンドは2つあり、バックエンド02は/listfoodsのロケーションにアクセスした場合にルーティングされるバックエンド、バックエンド01はそれ以外のすべてのリクエストがルーティングされるバックエンドです。

上記のパスマップは、Azureポータルでは以下のような構成となります。

では早速設定してみましょう。AzureのポータルからApplication Gatewayのリソースを表示して、左部メニューの「書き換え」をクリックします。画面右部に表示されている「+ 書き換えセット」をクリックします。

「名前」には、書き換えセットを一意に識別する名称を入力します。「関連付けられているルーティング規則」には、「種類」が「パスベースの規則(既定の書き換え設定)」のものを選択します。そして、「次へ」をクリックします。

「+書き換え規則の追加」をクリックします。

以下のような画面になります。「+条件の追加」をクリックします。

先程追加した条件(「If – クリックしてこの条件を構成」と記載されているもの)をクリックします。

以下のように設定します。

上記の設定内容の詳細は以下のとおりです。

次に、「結果 – クリックしてこのアクションを構成」をクリックします。先程の条件が真だった場合に実行されるアクションとなります。

「パスマップの再評価」については以下の図のとおりとなります。

「パスマップの再評価」をチェックしないと、以下のようにデフォルトのバックエンドにルーティングされます。つまり、Application Gatewayはバックエンド01にhttp://example.com/listfoodsというURLでアクセスします。

「パスマップの再評価」をチェックすると、「パスベースの規則」にて追加したバックエンドにルーティングされます。バックエンドが複数あれば、http://example.com/listfoodsのURLにマッチしたバックエンドにルーティングされることとなります。今回であればバックエンド02にルーティングされるというわけです。

最後に「作成」をクリックして完了となります。

最後に

Application Gatewayは、なかなかに設定が複雑で構築が大変ですが、もしこのブログがそんなみなさんの一助になれば幸いでございます。