このエントリは2023/11/22現在の情報に基づいています。将来の機能追加や変更に伴い記載内容からの乖離が発生する可能性があります。
問い合わせ
先日以下のような問い合わせが届いた。
現在Front Door (Premium) を前段に構え、App ServiceでホストするWebアプリケーションがある。App Serviceは様々なリージョンに配置されているが、各リージョンに1個だけ存在し、トラフィックに応じてスケールアウトするように構成済みである。また、health probeに使えるAPIを構成済みである。対してFront Doorは、最低遅延のoriginにルーティングするよう構成済みである。この条件下で各App Serviceがhealthyかどうかを確認したいのだが、どうすればよいか?
絵にすると以下のよう。

で、ふつうにFront DoorからHealth Probe APIにアクセスすると、一番近いリージョンのApp ServiceのAPIを呼び出すだけになってしまうし、わざわざVMを各リージョンのVNetに立ててスケジュール起動するのもメンテナンスが大変で、かつエレガントではないのでどうしたものか、ということらしい。
対応策
いろいろやり方は考えられるが、コンポーネントを新規追加しなくてもよい方法として、以下を案内した。
Front DoorでOrigin group(配信元グループ)をリージョンごとに作成し、そのOrigin groupに対してルーティングできるようにしておく。Probe APIへのアクセスは、特定のIPアドレスからの、特定のHTTP Headerを付与したトラフィックのみFront Doorで許可する。
もうちょっと具体的に
この問い合わせ主のWebアプリケーションを束ねるOrigin groupには複数のApp Serviceが含まれている。App Serviceは各リージョンに1個ずつ配置していたので、リージョンごとにOrigin groupを構成し、その中にApp Serviceを配置してトラフィックを当該Origin groupに流すようにした。2023/11/22現在のFront Doorの課金ルールは以下のようになっているため、Endpointやルールの追加は直接費用に関係しない。
- 稼働時間に基づく基本料金
- データ伝送に関連する料金
- Edge からクライアントへの送信用データ転送
- Edge から配信元への送信用データ転送
- リクエストに基づく料金 (Premium/Standardで異なる金額)
Azure Front Door の価格 / Azure Front Door pricing
https://azure.microsoft.com/pricing/details/frontdoor/#pricing
ルーティング方法はPath、Query Parameter、Endpointなど様々な方法があるので好きなものでどうぞ。
他の方法は?
Front Door経由のEnd to Endチェックではなく、App Serviceだけをチェックしたいなら、Function AppやAPI Managementなどを使って、VNetから直接各App Serviceを呼び出す、ということももちろん可能。ただ新規サービスコンポーネントを入れることになるので、追加費用が発生する(Flex Consumption planやAPI Management Standard V2は、2023/11/22時点では一部リージョンでしか使えない)。