Azure Front Door のパスベースルーティングを App Services で試してみる
便利で安心安全な CDN である Azure Front Door の パスベースルーティング機能
を試してみたいと思います。詳細な技術仕様は以下のドキュメントの通り。
参考ドキュメント => ルーティング規則に対する要求の照合方法
今回作成するイメージとしては、東日本と中央アメリカの WebApp をバックエンドで起動させ、/japan
というパスがリクエストされたら東日本のリソースへアクセス、/us
というパスがリクエストされたら中央アメリカのリソースにアクセスするというものです。
ではさっそく作成していきましょう。
バックエンドの App Services の準備
東日本、中央アメリカのそれぞれに App Services をデプロイします。プランは最小のもので問題ありません。今回は B1 プランで二つの App Services をデプロイしました。
このままではどちらにアクセスしたか分からないので、それぞれの App Services にアクセスした際のホーム画面で表示されるページに、東日本の WebApp
、US の webApp
と HTML ベースで追加します。Web App の標準機能である App Services Editor(プレビュー) を使用すると便利です。
少し雑ですが、まぁ分かればよいので、hoststarting.html の中に以下のようにテキストを追加します。US の方も同じように編集します。
そうすると WebApp にアクセスした際にどちらの WebApps にアクセスしているのかが表示でわかるようになります。東日本の WebApps にアクセスした場合はこんな感じです。
これで App Services の準備は完了です!
Azure Front Door でルールを追加する
それでは Azure Front Door でルールを追加していきましょう。Front Door を作成する際には、Front、BackEnd、ルール、の3つを指定して作成することができます。最初の Front は適当な名前、BackEnd には作成した二つのバックエンドプールをまず追加します。ルールは以下のように設定します。
/japan
の Path の場合は東日本リージョンの App Services が含まれているプールにルーティングします。
/us
の Path の場合は US のリージョンの App Services が含まれているプールにルーティングします。
これでルールの設定は完了です。ではさっそく作成した Front Door のフロントエンドアドレス/path
にアクセスしてみましょう!
エラーが発生するので Web.config を作成する
ここまでやるとうまくいくのでは?と思うかもしれませんが、こんな感じのエラーが発生します。
エラーメッセージはこんな感じです。
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
このエラーメッセージは App Services から返されているもので、調べるとこんな感じの回避策が見つかりました。
参考URL => Error : The resource you are looking for has been removed, had its name changed, or is temporarily unavailable
先ほどの App Services Editor で web.config
をディレクトリに追加し、以下のようなコードを追加します。
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Main Rule" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="/" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
これでもう一度アクセスしてみると、リクエストをした方の正しいリージョンにルーティングされるようになります。
正しくルーティングされました。通常の IIS などで作成したすでに Web.config が構成されているアプリケーションにアクセスする際にはこのような手順はいらないですが、ありものの App Services のページを使おうとする場合はこのような工夫が必要です。
使ってみた感想
- GUI ベースでサクサクルールが作成できるし、変更したときの反映スピードも早いので汎用的に使いやすいと思いました。
- Region 内の ロードバランシングツールである Application Gateway だと編集画面で分かりやすい絵がでてきますが、Front Door だとないため、複雑なルールを設定する場合は少し使いにくいかなと思います。これは Application Gateway の画面。
- 同じサブスクに含まれる App Services ならばプルダウン式に選択できるのは便利。ルーティングルールをさくっと作成できる
- パスごとにどれくらいのアクセスがあったかは Log Analytics にメトリックを投げてそこでクエリをかける必要がありそう。過去の膨大なログを見るとなるとそれなりに保管するデータの課金がかかりそう。単純な Health 系のログはデフォルトで抽出可能
全体的に使いやすいですし、WAF機能やキャッシュ機能も付いているので、グローバルに負荷分散させたいアプリケーションを作成する際のフロントエンドには是非たててみたいサービスかと思いました!
Author And Source
この問題について(Azure Front Door のパスベースルーティングを App Services で試してみる), 我々は、より多くの情報をここで見つけました https://qiita.com/komiyasa/items/b04d0a2403e70ed2ee8d著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .