Azure App Service と Application Gateway の連携（ルーティング編）
はじめに
この記事はAzure App Service Team BlogのZero to Heroシリーズの記事に感銘を受けて、和訳＆改変＆自分で新規執筆した記事です。 この記事を通してWeb Appsの基礎から実運用の方法まで、筆者自身が見直す機会としてシリーズ化して掲載する事にしました。 本家の「Zero to Hero」というフレーズの通り、Azure App Serviceを使ったことの無い方は一人前になれるように、すでに利用している方は知識のアップデートに役立てていただければと思います。
なお、連載の５回目からは筆者オリジナルのコンテンツを掲載しています。目次からまとめて読めますので、是非どうぞ。
【Azure初心者から上級者まで！】Azure App Service を使いこなしてゼロからヒーローになる
概要
この記事は App Service でゼロからヒーロー シリーズの第6回です。 この記事を読むためには初回記事を読み終えていることを想定しています。
今回はApplication GatewayとWeb Appの連携についてご紹介したいと思います。ルーティング編ではApplication Gatewayのルーティング機能を使って複数のWeb AppからWebアプリケーションを構成する方法を説明します。
Application Gatewayのルーティング機能とは
Application GatewayはWEBアプリケーションのトラフィックを管理するアプリケーション レイヤー（OSI参照モデルの第７層）で動作するロードバランサーです。アプリケーションレイヤーのロードバランサなのでL7 LBと表記されることもあります。
Application Gatewayには様々な機能がありますが、URLパスペースのルーティング機能が存在します。Application Gatewayの機能についてはこちらを参照してください。
この機能を利用すると、sigmact.zero-to-hero.com/api/*でアクセスした場合はzero-to-hero-api.azurewebsites.netのWeb Appへルーティングされるようになり、それ以外のアクセスはzero-to-hero.azurewebsites.netへルーティングされるようにする事が可能です。
URLパスベースのルーティングの利点
URLパスベースのルーティングを利用するとAPIとフロントエンドをWeb App単位で管理できるため、アプリケーションをデプロイする際の影響範囲やリソース管理が容易になります。
アプリケーションに対する受信トラフィックが全てApplication Gatewayを通過するようになるため、Application Gateway配下のWeb Appを同一ドメインでアクセスできるようになります。そのため、証明書やドメイン管理が柔軟になりトラフィックの安全性も担保しやすくなります。
Application Gatewayを作成する
-
Application Gatewayを作成するにはApplication Gatewayを含めるVNetが必要です。存在しない場合はこちらの手順で作成してください。
-
Application Gatewayをこちらの手順に従って作成してください。
「基本」タブ
Application Gatewayを含める仮想ネットワークとサブネットは「1」の手順にて作成した仮想ネットワークを選択してください。作成した仮想ネットワークが表示されない場合はApplication Gatewayの地域と仮想ネットワークの地域が同じ地域になっているか確認してください。
「フロントエンドの数」タブ
Appliation Gatewayを外部に公開するのでパブリックIPアドレスを指定してください。
「バックエンド」タブ
規定のバックエンドプールとAPI用のバックエンドプールの合計２つのバックエンドプールを作成します。
「構成」タブ
ルーティング規則を作成してフロントとバックエンドプールを紐づけます。
ルーティング規則は以下のような項目で構成されています。
| 項目名 | 内容 |
|---|---|
| リスナー | フロントエンドのIPが主審するプロトコルとポート番号の組み合わせを管理する |
| HTTP設定 | バックエンドプールに転送する際のプロトコルやポート。パス変換やホスト名の変換に関する設定を管理する |
| バックエンドターゲット | リスナーとバックエンドプールとHTTP設定の組み合わせを管理する |
今回はHTTPの80番を対象とするようにリスナーを設定しました。
API以外のリクエストはzero-to-hero.azurewebsites.netにHTTPSでルーティングするようにdefault-settingを作成します。
APIのリクエストはzero-to-hero-api.azurewebsites.netへHTTPSでルーティングするようにHTTP設定を作成します。
上図ではカスタムプローブが使用されていますが、初回作成時は[いいえ]を選択してください。カスタムプローブに関しては後述します。
[バックエンドパスのオーバーライド]は「/」を指定してください。この設定を行う事で「http://%public_ip%/api/hoge」のアクセスをhttps://zero-to-hero-api.azurewebsites.net/api/hogeとならないようにする事ができます。詳しくはこちらのドキュメントを参照してください。
/api*の場合はAPIバックエンドプール用のHTTP設定、それ以外は既定のHTTP設定となるようにバックエンドターゲットを構成します。
ここまでの設定でApplication Gatewayを通したリクエストは以下のようになります。
カスタムプローブを設定する
Application Gatewayではバックエンドプールのリソースを監視しており、異常があるバックエンドリソースはApplication Gatewayから切り離されるようになっています。規定の正常性プローブはHTTP設定で指定したプロトコルとポートを使用して正常性を確認します。規定の正常性プローブに関してはこちらを確認してください。
ルートパスにアクセスできない場合は認証がかかている場合などは規定の正常性プローブでは404や403のステータスが返却されるため、正常にルーティングできないケースが存在します。そのような場合はカスタムプローブを作成して任意の条件で正常性を確認してください。
Azureポータルで、[正常性プローブ]メニューに遷移します。
[追加]をクリックして、カスタムプローブの内容を入力します。今回の例では確認するパスを/WeatherForecastに変更しています。
[テスト]ボタンを押してプローブが正常に動作する事を確認して、カスタムプローブの設定を[保存]します。
バックエンドの正常性を確認する
すべてのバックエンドの正常性は監視セクションの[バックエンド正常性]のメニューから確認する事ができます。
まとめ
おめでとうございます。これでApplication GatewayのURLベースのルーティングを使用してAPIとアプリケーションのリクエストを適切に振り分けることができるようになりました。
アプリケーションが大規模になり複数のWeb Applicationから構成される場合でも同様にバックエンドプールへの設定を追加していく事で、柔軟に対応する事が可能です。
役に立つリンク
お問い合わせはこちらから
問い合わせる
