Zenn
NCDCエンジニアブログ
🍄

Azure WebAppsの手前にApplication Gatewayを設置する

いばらき
2022/04/22に公開
Azure
appservice
webapps
applicationgateway
tech

はじめに

Azure WebAppsとAzure Application Gatewayを連携させます。

下記のマインドで書きます。

  • Azureは世の中の情報が少なすぎるので、少しでも情報を残したい。
  • VMを立ち上げて自力でサーバー構築とか今どきのクラウドでやることではないので、モダンな方法でアプリを構築したい。
    • しかし、Azureでサーバレスはあり得ないレベルで難易度が高いので死ねる。
    • なので、間を取って(?)コンテナで開発する。

シリーズもの第2回です。

第1回はこちら
https://zenn.dev/ibaraki/articles/82cd0e70bb1c78

この記事でやること

前回の記事で、Azure WebAppsを使いWebアプリを公開しました。公開されたアプリケーションは直接インターネットに晒されている状態です。怖いので手前にリバースプロキシが欲しいと思いました。ということで、Azure Application Gatewayを配置します。

https://docs.microsoft.com/ja-jp/azure/application-gateway/overview
https://docs.microsoft.com/ja-jp/azure/app-service/networking/app-gateway-with-service-endpoints

最終的に目指すもの

下記の思想で設計しています。

  • それなりの柔軟性を持たせつつ、それなりのセキュリティは確保したいが、その為に糞みたいに高いリソース（例えば最低月10万円のAzure Firewall等）は使いたくない。
  • といってもAzureなのでそれなりの金額になります。課金しないと、それなりの柔軟性もそれなりのセキュリティも確保できないです。Azureなので。
    • 安くWebアプリを構築したい時はAWS Amplify等の他サービスを使おう（本末転倒）

本シリーズのほか記事へのリンク

  1. Azureにコンテナーで作ったWebアプリを公開する
  2. Azure WebAppsの手前にApplication Gatewayを設置する ← いまココ
  3. Azure WebAppsとAzure SQL Databaseをセキュアに接続する
  4. Azure WebAppsにAzure Storageをセキュアにマウントする
  5. (番外編)Django + SQLServer(Azure SQL Database) + SQLAlchemyで、Webアプリを構築

Application Gatewayを置く意味

「既にWebアプリは公開されてるのに、間に余計なものいれる必要なくない？」と思われるかもしれません。実際なくても大丈夫といえば大丈夫です。実装するシステムの非機能要件や予算と相談してください。お金もかかりますし。
置くメリットとしては下記のようなものがあります。

  • アプリケーション本体の前に別のものを挟むことでセキュリティが上がる
  • WAF(Web Application Firewall)を置けるのでセキュリティがかなり上がる
    （今回はWAFは置きません。高いから。）
  • HTTPの要求に応じて、ルーティングができる
    （今回はやりません。アプリ１個しか用意しないから。）
    • 複数のアプリケーションを統合できる
    • 静的コンテンツをアプリケーションから分離することで、負荷軽減できる
    • フロントエンドとバックエンドの分離ができる

Web3層構造に当てはめると、WebAppsがアプリケーションサーバーで、Application GatewayがWebサーバーと思っていただければと。ただし、nginxなどでWebサーバーを作る場合と比べて、キャッシュが出来ないことは要注意です。
キャッシュが欲しい時は、Azure Front DoorなどCDN機能がついたサービスを使いましょう。

Application GatewayとFront Door

Application Gatewayと同じような立ち位置に、Front Doorがあります。
https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-overview
どちらを置くのがベストなのかは、、、正直私はよく分かっていません。なので、説明すると墓穴を掘りそうですが、この記事でFront DoorでなくApplication Gatewayにした理由は書いておきます。正確な情報はAzureのドキュメントを読んでください。

私が理解した相違点をざっくり書くと下記のようになります。（実際はたぶん他にもいろいろあると思います）

  • (同じ)Application GatewayもFront DoorもL7ロードバランサー
  • (違う)Front Doorは非リージョンサービス、Application Gatewayはリージョンサービス
  • (違う)Front DoorはCDN機能がある(キャッシュができる)

AWSで例えると、Azure Application GatewayがAmazon ALBで、Azure Front DoorがAmazon CloudFrontに相当するんですかね？
今回はCDNは要らなかったのと、全リソースを東京に置いたのでリージョンサービスのApplication Gatewayの方がいいのかなぁと思いApplication Gatewayにしました。
CDN機能が必要だったり、複数リージョンを使う場合はFront Doorにしていたと思います。
(嘘です。本当はググって先に出てきた方を使いました。)

CDNといえばAzure CDNというリソースもあり、これとFront Doorの違いも気になりますが今回は関係ないので触れません。

実際に構築する

WebAppsを用意する

WebAppsは、前回の記事を参照してください。
https://zenn.dev/ibaraki/articles/82cd0e70bb1c78

VNetを作る

Application GatewayはVNetの中にしか置けないので、VNetを作ります。

価格

厳密には通信量に応じて課金されるはずですが、誤差みたいな金額なのでVNetの費用は考えないものとします。
https://azure.microsoft.com/ja-jp/pricing/details/virtual-network/#pricing

リソースを作る

Azureのコンソールから画面に従って、リソースを作ります。

サブネットを作る

Azureのコンソールから、VNetの中にApplication Gatewayを置くためのサブネットを追加します。

Application Gatewayを作る

本命のApplication Gatewayを作ります。

価格

https://azure.microsoft.com/ja-jp/pricing/details/application-gateway/#pricing
最新のV2を使いまｓ。。。いや高くね？？？？？
V1のSを使います！月額約2400円。

リソースを作る

Azureのコンソールから画面に従って、リソースを作ります。
作成時点で設定項目がめちゃくちゃ多いですし、UIがとても分かりにくいので要注意です。
（納得の☆2.8。価格含めて改善してほしい。）

  • スタンダード・インスタンス数1・SKUサイズSを選択

  • さっき作ったVnetとサブネットを選択します。

  • フロントエンドは新規でPublic IPを追加します。

    • 課金が足りないので、動的IPしか選べません。
      • Azureのこういうクソみたいな制限が嫌いです。

  • バックエンドプールも新規で追加します。
    ターゲットの種類をApp Serviceにして、事前に用意したWebappsを選択してください。

  • ルーティング規則も新規で追加します

    • まずリスナー。httpsがいいんですけど、サンプルアプリでそこまで頑張るつもりがないのでhttpにします。
    • 続いてバックエンド。さっき作ったバックエンドプールを設定。HTTP設定は新規追加。(ネストが深くてイライラしてきた...)
      • HTTP設定。接続のドレインを有効化。ホスト名のところ、オーバライドをはい、バックエンドターゲットからホスト名を選択する、カスタムプローブはい。

設定項目が多すぎるのは仕方がないとしても、新規作成のネストが深すぎてめっちゃ混乱する。改善して欲しいです。（IaC書こうとしたら地獄では？）

  • 最後に正常性プローブでレスポンスが2xx or 3xxになるパスを指定。
    • v2だとカスタムプローブ設定しなくても動いたのですが、v1だと設定しないと動かなかったです。謎です。(v2に誘導する罠でしょうか。。。値段。。。)

確認

途中で作ったPublic IPにアドレスが振られているはずなので、ブラウザからhttpでアクセスしてみてください。WebAppsのアプリが表示されたら成功です。

WebAppsにApplication Gateway以外からのアクセスを拒否

Application Gateway経由でWebAppsにアクセスできるようになりましたが、
現状ではインターネットから直接WebAppsにアクセスすることも出来ます。
Application Gateway以外からの接続は拒否してしまいましょう。

WebAppsにアクセス制限を設定する

コンソールで、WebAppsのリソースを開き、左のメニュからネットワークを選んでください。
下のような画面が表示されるので、アクセス制限を押してください。

  • 「規則の追加」を押して、Application Gatewayからのアクセスを許可してください。
    • 種類 : 仮想ネットワーク
    • 仮想ネットワーク : Application GatewayがあるVNet
    • サブネット : Application Gatewayがあるサブネット

許可設定を追加した時点で、デフォルトが拒否になるので、これにて設定完了です。

確認

  • Application Gateway(に設定したPublic IP)へアクセスして、アプリが表示されることを確認
  • WebAppsに直接アクセスして、アクセス拒否されることを確認

以上で、Azure WebAppsの手前にApplication Gatewayを設置できました。

補足:サービスエンドポイントとプライベートエンドポイント

Azureで複数サービスを連携する時にセキュリティについて調べてみると、
サービスエンドポイントとプライベートエンドポイントという言葉が出てきます。
今回はサービスエンドポイントのほうを使ってます。
構築手順を読んだ奇特な方は「いつ使ったんだよ？」と思われるかも知れませんが、実はWebAppsにApplication Gatewayからの接続を許可したときにサービスエンドポイントが作られています。

サービスエンドポイントとプライベートエンドポイントの違いについては、他の方(tomotさん)が書いた記事を貼っておきます。
https://zenn.dev/tomot/articles/89d561c36bc52c

Azure費用(月額)

最後に、Azure費用です。(第１回の内容含む)

約2200円/月 → 約4600円/月

  • Azure Container Registry : 約600円/月
  • Azure App Service Plan : 約1600円/月
  • Azure Application Gateway 約2400円/月 (new)

前回の倍以上の金額になり、気軽に試してみてくださいと言いづらくなってきました。最低ランクのプランなのに。。。
2022/04時点ではApplication GatewayよりFront Doorのほうがコスパいいのでそちらを使ったほうが良かったかもと思いましたが、Front Doorは5月から値上げされるから結局は微妙なんですよね。

Amazon Cloudfrontみたいに無料枠は無いのでしょうか？

(2022/05/13追記)

５月になってFront Doorからプレビューが消えて正式版になりました。
価格も正式版になりました。
https://azure.microsoft.com/ja-jp/pricing/details/frontdoor/#pricing
Standardプランで約4500円/月です。
機能を考えるとApplication Gatewayと比べて相対的にコスパがいい印象です。
Application Gatewayの設定の複雑さを考えると、Front Doorを積極的に使ったほうが良いかもです。

でもデータ転送が結構高いのが怖いな。。。

次の記事

https://zenn.dev/ibaraki/articles/2dca271069c851

NCDCエンジニアブログ
NCDCエンジニアブログ

NCDC株式会社( ncdc.co.jp/ )のエンジニアチームです。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください！ ※エンジニア以外も記事を投稿することがあります

Discussion