Azure でリバースプロキシを使うときに覚えておきたいこと
はじめに
こんにちは、Acompany プロダクト部門 DCR チーム チーフエンジニア イナミです。
最近 Azure を業務で使う機会があったのですが、Azure のリバースプロキシサービスの比較や網羅的な知見がまとまっている記事が見つからず少々苦労したので、備忘録にしてみました。
今回は Azure のリバースプロキシサービスである Azure Front Door を数ヶ月使ってみて残しておきたい備忘録を網羅的に書いています。
リバースプロキシとは?
まずはじめにリバースプロキシとはなにかについて簡単に説明します。
Web サイトに必要不可欠なコンテンツデリバリネットワーク(CDN)のうち 79.9% のサイトに選ばれている Cloudflare[1] はリバースプロキシについてこのように説明しています。
リバースプロキシは、1つ以上のWebサーバーの前に置かれ、クライアントからのリクエストを傍受するサーバーです。
リバースプロキシサーバーは、配信元サーバーにリクエストを送信し、配信元サーバーから応答を受信します。
リバースプロキシは配信元サーバーの前にあり、クライアントがその配信元サーバーと直接通信しないようにします。
https://www.cloudflare.com/ja-jp/learning/cdn/glossary/reverse-proxy
つまり Web システムを構築する際にまずクライアントからのリクエストを受け取る部分であり、ユーザとリバースプロキシの間に HTTPS 通信が発生している場合は基本的にリバースプロキシが TLS 終端です。
Cloudfrareが解説するリバースプロキシのイメージ [2]
サービス比較
まずは Azure のリバースプロキシサービスの一覧を見てみます。
今回紹介する Azure Front Door の特徴はリージョナルリソースではなくグローバルリソースであること、 Azure Front Door マネージド TLS 証明書 が使えることが挙げられます。
類似のリバースプロキシサービスでは Azure Application Gateway がありますが、こちらの特徴はリージョナルリソースであること、基本的に証明書の管理が必要であることが挙げられます。
Azure Front Door と Azure Application Gateway のどちらを選定すべきかについてはシーンごとに対応する必要があるため本記事の対象外としており、詳細については公式 FAQ や他記事をご確認ください。
Azure Front Door をバックエンドリソースに接続する
Azure Front Door を API サーバなどバックエンドリソースと接続する方法は2種類あります。
公式からの引用という形でそれぞれの接続方法を列挙してみます。
-
Azure Private Link を使ったプライベート IP アドレスでの接続
Azure Private Link を使用すると、お使いの仮想ネットワーク内のプライベート エンドポイント経由で、Azure PaaS サービスと Azure でホストされているサービスにアクセスできます。
https://learn.microsoft.com/ja-jp/azure/frontdoor/private-link -
Azure Network Security Group のサービスタグを使ったパブリックな接続
バックエンドに Azure 仮想マシンを配置されている構成であれば、NSG のサービス タグで「AzureFrontDoor.Backend」からの HTTP/HTTPS 通信のみ許可することで、Azure Front Door のパブリック IP アドレス以外からの HTTP/HTTPS 接続を許可しない構成が可能です。
https://jpaztech.github.io/blog/network/AzureFrontDoor-LockDown/#Azure-Front-Door-で用いられる-IP-アドレス-FAQ
しかしながら概要だけではどのような技術的制約が発生するかわかりにくいので、更に接続方法ごとに Pros/Cons の比較を行ってみます。
Azure Private Link を使う場合の Pros/Cons
- Pros
- 仮想ネットワーク内での接続が可能[5]
- Azure App Service にもプライベートエンドポイントで安全に接続できる
- アプリケーションをパブリックに公開する検討が不要になる
- Azure Load Balancer のような内部ロードバランサも併用することができる
- 仮想ネットワーク内での接続が可能[5]
- Cons
-
Azure Private Link を使う場合は必ず Azure Front Door Premium を選択しなければならず、リバースプロキシのコストが10倍以上になる
-
複合可用性が低下する
バックエンドリソースを VM と仮定したとき SLA が約 0.02% 低下する
-
複合可用性については下記ドキュメントをご覧ください。
Azure Network Security Group のサービスタグを使う場合の Pros/Cons
- Pros
- Azure Private Link を使わなくてよい
- Microsoft Service バックボーン通信によってトラフィックがパブリックインターネットを経由しない
-
公式ドキュメント にバックボーン通信に関する記載がある
Microsoft サービスの使用時はすべてのトラフィックがこのようにルーティングされるのでしょうか。 はい。Microsoft Azure 内のデータセンター間、または Virtual Machines、Microsoft 365、Xbox、SQL DB、Storage、仮想ネットワークなどの Microsoft サービス間のあらゆるトラフィックはこのグローバル トラフィック内でルーティングされ、決してパブリック インターネットを経由しません。
- 念の為に Azure の技術サポートに問い合わせ確認を取ったが、VM のパブリック IP を指定していてもトラフィックが Microsoft Service ネットワーク外部を経由することはないとのことだった
-
公式ドキュメント にバックボーン通信に関する記載がある
- Cons
- インターネット上のドキュメントが非常に少なく暗黙知になっている
Azure Front Door が Microsoft Service バックボーン通信を利用可能であると明言されたドキュメントが存在しないと思われるため不安が残る - HTTP ヘッダー
X-Azure FDID
を使ったリソースフィルタリングをバックエンドリソースに追加実装する必要がある
- インターネット上のドキュメントが非常に少なく暗黙知になっている
X-Azure FDID
の設定方法については下記ドキュメントをご覧ください。
おわりに
今回は簡単にマネージド TLS 証明書が使える Azure Front Door を中心に、Azure のリバースプロキシサービスの備忘録を書きました。
インターネット上のドキュメントと Azure 技術サポートを掻き集めて書き上げましたので技術選定の参考になれば幸いです。
Azure Application Gateway に関しては利用したことがなかったため、経験を積んでから更に書き足していきたいと思います。
-
https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview#azure-load-balancing-services ↩︎
-
https://www.cloudflare.com/ja-jp/learning/cdn/glossary/reverse-proxy ↩︎
-
https://learn.microsoft.com/ja-jp/azure/app-service/configure-ssl-certificate?tabs=apex ↩︎
-
https://learn.microsoft.com/ja-jp/azure/frontdoor/understanding-pricing#pricing-model-comparison ↩︎
-
https://learn.microsoft.com/ja-jp/azure/frontdoor/standard-premium/how-to-enable-private-link-web-app ↩︎
Discussion