みなさん、こんにちは！杉山です。
Azure は日々進化しており、毎週新しいサービスや機能が提供されています。
先日、Traffic Manager のエンドポイントの正常性監視で新しい方式が提供されました。
本記事では、その新しい方式について紹介します。
Traffic Manager は Azure のグローバル負荷分散リソースです。
Traffic Manager の従来の正常性監視は既定で有効になっており、無効にすることはできませんでした。
今回、正常性監視を無効にする「Always Serve」という方式が提供され、正常性監視の有効/無効をユーザ側で選択できるようになりました。
該当の更新情報は以下になります。
General availability: Always Serve for Azure Traffic Manager
Traffic Manager の正常性監視は既定で有効でした。
そのため、正常性が確認できないエンドポイントにはトラフィックを送信されないような動作となっていました。
今回提供された「Always Serve」では、エンドポイントの正常性監視が除外され、エンドポイントのステータスに関わらず、エンドポイントにトラフィックが送信されるようになります。
※ 2024 年 3 月時点で、「入れ子になっているエンドポイント」では Always Serve はサポートされていません。
※ Always Serve を使用した場合でも、Azure 利用料として正常性チェックの課金は発生します。
次に、設定箇所になります。
正常性監視はエンドポイント追加時に設定可能です。
「有効化」は正常性監視を実施する、従来の正常性監視になります。
「常にトラフィックを処理する」は正常性監視を実施しない、Always Serve になります。
※ 正常性監視はエンドポイント追加後にも変更可能です。
本記事では、以下のパターンで Always Serve の動作を検証します。
| No. | エンドポイント | 正常性監視の方式 | 備考 |
|---|---|---|---|
| 1 | app01 | 常にトラフィックを処理する | -- |
| 2 | app01 | 常にトラフィックを処理する | App Service は停止 |
| 3 |
|
|
-- |
No.1 で、正常性監視が「Always Serve」のエンドポイントにトラフィックがルーティングされるかを確認します。
No.2 で、正常性監視が「Always Serve」のエンドポイントがサービス ダウンした状態でもトラフィックがルーティングされるかを確認します。
No.3 で、正常性監視が「Always Serve」と「有効化」が混在したエンドポイントでもトラフィックが分散されるかを確認します。
検証に必要なリソースのパラメータは以下になります。
| No. | リソース | 設定項目 | パラメータ | 備考 |
|---|---|---|---|---|
| 1 | Traffic Manager | ルーティング方法 | 重み付け | -- |
| 2 | App Service (app01) |
|
|
正常性監視は HTTP で行うため、HTTPS をオフに変更 |
| 3 | App Service (app02) |
|
|
正常性監視は HTTP で行うため、HTTPS をオフに変更 |
| 4 | Log Analytics ワークスペース | リージョン | 東日本 | -- |
App Service は既定でトップ ページが用意されています。
ですが、既定のトップ ページではどの App Service にルーティングされるか判断が難しいため、以下のような簡単な初期ページ (app01 のみを掲載) を App Service 毎に用意しました。
ケース 1 の構成図は以下になります。
ブラウザで Traffic Manager のドメイン (.trafficmanager.net) でアクセスするとエンドポイントである app01 のトップ ページが表示されました。
app01 に本当に正常性プローブが送信されていないかログで確認してみます。
正常性プローブは UserAgent 列で「Azure + Traffic + Manager + Endpoint + Monitor」と表示されます。
ログを確認してみると、そのレコードが見当たりません。
このことから、正常性プローブが本当に送信されていないことを確認できました。
以上より、Always Serve によって正常性監視が無効になった状態でも、エンドポイントにトラフィックが送信されていることがわかりました。
ケース 2 の構成図は以下になります。
エンドポイントがサービス ダウンした状態でもトラフィックがルーティングされるかを確認するため、App Service を停止します。
App Service を停止し、ブラウザで App Service の既定のドメイン (.azurewebsites.net) でアクセスすると以下の様に表示されます。
App Service が停止しているので、403 エラーが表示されていますね。
この状態で、ブラウザで Traffic Manager のドメイン (.trafficmanager.net) でアクセスするとエラーが表示されました。
私の予想では、App Service に直接アクセスした際に表示されるページが表示される想定でした。
ですが、実際には異なる画面が表示されています。
念のため Microsoft 社に確認したところ、本ケースの場合でも本来は App Service のページが表示されるはずであり、今回の事象は想定していない動作であるとのことでした。
こちらについては、今後修正予定とのことです。
ですので、本来であれば、App Service と同じページ「Error 403 - This web app is stopped」が表示されるとのことです。
今回の検証では実際に確認できませんでしたが、Always Serve のエンドポイントがサービス ダウンした状態でもトラフィックはルーティングされ、エンドポイントと同じページが表示されることが正しい動作のようです。
ケース 3 の構成図は以下になります。
ブラウザで Traffic Manager のドメイン (.trafficmanager.net) でアクセスします。
アクセスを何回か繰り返すと、エンドポイントである app01 と app02 のトップ ページが表示されました。
以上より、正常性監視が「Always Serve」と「有効化」が混在したエンドポイントでもトラフィックは分散されることがわかりました。
本検証から Always Serve のメリット・デメリットを考察します。
