こんばんは。Microsoft Azureについて勉強する日々です・・。今日は、Azure Front Doorを触ってみたので、概要から使ってみた感想まで、自分の記憶喪失防止のためにも記録を残しておきます。
なお、今回の記事は、Microsoft公式ドキュメントを参考に、読んだり自分で動かしてみたりした結果を元に記載しております。Microsoft Azureは公式ドキュメントが分かりやすく豊富に用意されているので、何か困ったときにはぜひご参考にしてみることをお勧めします。
https://docs.microsoft.com/ja-jp/azure/frontdoor/
Contents
Azure Front Doorの概要
以下、公式ドキュメントなどを読んで分かったことをまとめておきます。
- 可用性と拡張性が高い、Microsoft の Web アプリケーション アクセラレーション プラットフォーム兼グローバル HTTP （レイヤー７）ロード バランサー
- DDoS 保護や、アプリケーション層のセキュリティとキャッシュを内蔵している
- Front Door を使用すると、エンドユーザー向けに高可用性とパフォーマンスを最大化および自動化するアプリケーションを構築できる
- Front Door は最新の Content Delivery Network (CDN) でもあり、動的サイト アクセラレーションおよび負荷分散に加えて、他の CDN と同様にキャッシュの動作もサポートされる
- Front Door は、Azure サービス (Web Apps、Mobile Apps、Cloud Services、Virtual Machines など) と併用することも、オンプレミスのサービスと組み合わせてハイブリッド展開やスムーズなクラウド移行に役立てることもできる
他のAzureサービスとの使い分け
他のAzureサービスというと、以下の２つの観点で整理できると思います。
- 負荷分散
- CDN
参考になる公式ドキュメントの記載がありますので、以下、そこからの引用です。
他の負荷分散ソリューション
- DNS ベースのグローバルなルーティングを検討中であり、トランスポート層セキュリティ (TLS) プロトコル終端 (“SSL オフロード”) の要件や、HTTP/HTTPS 要求ごとまたはアプリケーション層の処理の要件がない場合は、Traffic Manager を検討してください。
- アプリケーション層でリージョン内のサーバー間の負荷分散が必要な場合は、Application Gateway を検討してください。
- ネットワーク層の負荷分散を行う場合は、Load Balancer を検討してください。
- Front Door と Application Gateway は両方ともレイヤー 7 (HTTP/HTTPS) のロード バランサーであり、主な違いは、Front Door がグローバル サービスであるのに対し、Application Gateway はリージョン サービスであるということです。 Front Door はリージョン全体のさまざまなスケール ユニット/クラスター/スタンプのユニット間で負荷分散ができますが、Application Gateway は、スケール ユニット内にある、仮想マシン/コンテナーなどの間で負荷分散ができます。
- Front Doorの背後にApplication GatewayやLoad Balancerを接続することも比較的一般的ユースケースとのこと。
CDNソリューション
- Azure Front Door と Azure CDN を同時に構成することはできません。これは、どちらのサービスも、要求に応答するときに同じ Azure エッジ サイトを利用するためです。
参考文献：
Azure Front Doorの機能
Azure Front Doorでは以下の機能が提供されています。（公式ページより）
- スプリット TCP ベースの エニーキャスト プロトコル を使用したアプリケーションのパフォーマンスの高速化。
- インテリジェントな 正常性プローブ によるバックエンド リソースの監視。
- 要求の URL パス ベース のルーティング。
- 効率的なアプリケーション インフラストラクチャを実現する、複数の Web サイトのホスティング。
- Cookie ベースの セッション アフィニティ 。
- SSL オフロード と証明書管理。
- 独自の カスタム ドメイン の定義。
- Web Application Firewall (WAF) が統合されたアプリケーション セキュリティ。
- URL リダイレクト による、HTTPS への HTTP トラフィックのリダイレクト｡
- URL 書き換え によるカスタム転送パス。
- エンド ツー エンドの IPv6 接続と HTTP/2 プロトコル のネイティブ サポート。
ルーティングは、URLパスベースのみなんですね。
Azure Front Doorを使ってみる
https://docs.microsoft.com/ja-jp/azure/frontdoor/quickstart-create-front-door
Azure App ServiceでFront Doorと接続するWebアプリを作成する
App Serviceから新規アプリの作成を行います。Front Doorのテスト用なので、設定は特に特別なことは行いません。既定の設定かつ、最も安いApp Service Planで作成します。
リソースの追加から「Webアプリ」を選択して、以下のよう設定します。（何でもOKです）
作成したWeb AppのURLにアクセスして、正常にアプリが稼働していることを確認します。
これでWebアプリの準備が整いました！
Azure Front Doorを作成する
次に、Front Doorリソースを作成してみたいと思います。
０、「リソースの追加」から、フロントドアを選択します。
１、リソースの作成画面では、フロントエンド＋バックエンド＋ルーティング規則を構成します。
はじめに、フロントドアの設定です。ここでは、ユーザの直接のアクセス先になるドメイン名、セッションアフィニティやWAF（Webアプリケーションファイアウォール）の設定を行います。
２、続いてバックエンドプールの設定です。
- Front Door のバックエンド プールとは、アプリに関する同様のトラフィックを受信するバックエンドのセットを指します。 つまり、同じトラフィックを受信し、想定される動作で応答する世界中のアプリ インスタンスの論理グループになります。
- これらのバックエンドは、異なるリージョンにまたがってデプロイされるか、同じリージョン内でデプロイされます。
- バックエンドはすべて、アクティブ/アクティブ デプロイ モードで指定するか、アクティブ/パッシブ構成として定義された内容に含めることができます。
- Front Door のバックエンドは、クライアントの要求を処理するアプリのホスト名またはパブリック IP を指します。 バックエンドを、データベース層やストレージ層などと混同しないでください。
ここでは、フロントドアの後ろに配置するサービスを設定します。その他、フロントエンドとHTTP/HTTPSするポート、ルーティングの優先度、重みを設定可能です。
- 優先順位：すべてのトラフィックにプライマリ サービス バックエンドを使用する場合は、さまざまなバックエンドに優先順位を割り当てます。 さらに、プライマリまたはバックアップのバックエンドが使用できない場合は、バックアップを用意します。 詳細については、優先順位に関するセクションを参照してください。
- 重み：均等にまたは重み係数に従って一連のバックエンド間でトラフィックを分散するには、さまざまなバックエンドに重みを割り当てます。 詳細については、重みに関するセクションを参照してください。
- 正常性プローブ：構成されたバックエンドそれぞれに定期的な HTTP または HTTPS プローブ要求が送信されます。 プローブ要求は、エンドユーザーの要求の負荷を分散するために、各バックエンドの近接性と正常性を判別します。ここでは、正常性プローブで正常と判断する基準や、確認方法についての設定を行うことができます。
３、最後にルーティング規則の設定です。
ここでは、リクエストのパス毎にリクエストをルーティングさせる規則を追加することができます。
- パスのパターン：これがFront Doorのルーティングの一番のキモですね。リクエストのURLのパターン毎に、リクエストを送るバックエンドを切り替えることが可能になります。
- ルートの種類：進む or リダイレクト
- キャッシュ：キャッシュを有効にすると、コンテンツがフロントドアにキャッシュされ、ユーザへの静的コンテンツの提供時間を大幅に短縮することができます。詳細はこちら。https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-caching
４、設定が終わったら、リソースをデプロイします。
以上で、フロントドアの構成も完了です！
Front Door経由でWeb Appにアクセスする
Front Doorが構成できたところで、いよいよFront Door経由でWeb Appにアクセスしてみます。
Front Doorの概要ブレード右上に表示されているのが、先ほど構成したフロントエンドのURLになります。こちらにアクセスしてみます。
すると・・・おお！フロントドアのバックエンドプールに追加したWeb Appのページが表示されました！
最も簡単な例ではありましたが、以上が、フロントドアを実際に構成する手順でした！画面ポチポチで簡単にできてしまう素晴らしい世の中です・・・
感想など
自分はこの辺りの技術は全く使い慣れていないので的外れな感想かもしれないですが・・・
- かなり直感的に構成できて、初心者でも使いやすいサービスだった
- サポートされているルーティングは、パスベースのみなので、同じパスのリクエストの中でさらに不可分散をさせたい場合には、Azure Load Balancerなどと組み合わせて使う必要がある。Azure Front Doorは、グローバルのリージョン間で不可分散を行うことができることが利点なので、グローバルにサービスを提供する場合はFront DoorをLoad BalancerやApplication Load Balancerの前に配置しておくことで、よりパフォーマンスが向上できる、と理解した
- 逆に言うと、地域限定のスモールなサービスだったりすると、Application Load BalancerやLoad Blancerで十分ということかな・・？
- Azureには、同様の不可分散・CDNサービスが色々とあるので、上記含め使い分け方（最初の方にまとめた）はしっかり言えるようにしておきたい。
以上、Azure Front Doorについて勉強してみた話でした！
引き続き、Azureサービスの勉強を続けてまいります・・！最後までご覧いただきありがとうございました！
おしまい
