Azure App Serviceの正常性チェックの利用方法

2021-03-132024-12-31App Service,Azure

Azure App Serviceの正常性チェックを利用する方法についての紹介です。
正常性チェックの設定方法から、エラー発生時のメトリクスの変化、異常なインスタンスの切り離しまでを確認しています。

※Azure App Service上にNginxのコンテナをデプロイした環境で行っています。
※Premium v3 P0V3プラン(インスタンス数2)のAzure App Serviceを使用しています。

1. Azure App Serviceの正常性チェックの設定、メトリック、インスタンスの切り離し
2. 最後に

Azure App Serviceの正常性チェックの設定、メトリック、インスタンスの切り離し

正常性チェックを利用したApp Serviceのインスタンス監視

App Service の正常性チェックを利用して、App Serviceのインスタンスの状態確認、異常なインスタンスを切り離す事ができます。
異常なインスタンスを自動的に切り離す事で、サイトを正常に保つ事ができます。

正常性チェックを使用して App Service インスタンスを監視する

正常性のチェックはHTTPのレスポンスコードを元に行われます。
HTTPのレスポンスコードが200から299の場合は正常と判断します。

簡単に使える反面、App Service の正常性チェックには注意点もあります。
利用前には必ず公式サイトの注意点をチェックするようにします。

例えば302のリダイレクトには対応してないなどがあります。
またカスタムドメインを設定した場合でも、既定のドメインに対して正常性チェックは実施されます。
1つのApp Service プランに複数のアプリがデプロイされている場合などの挙動にも注意が必要です。

認証やIP制限を行う場合にも注意が必要です。

認証とセキュリティ

App Serviceの正常性チェックを設定

App Service で正常性チェックはデフォルトでは無効となっています。
正常性チェックの有効化、正常性プローブのパス、異常なインスタンスを削除するしきい値を設定します。

正常性チェックでアクセスするパスは正常性チェックの設定で指定します
異常なインスタンスを削除するしきい値は、切り離しまでの時間になります。

App Serviceの正常性チェックを有効化

監視にある正常性チェックを選択します。
正常性チェックを有効にします。
正常性プローブのパス、負荷分散のしきい値を設定します。

パスは"/"と設定しています。
負荷分散のしきい値は2分(デフォルト10分)としています。

正常性チェックの設定を保存の確認メッセージが表示されます。
保存を選択します。

Azure App Serviceの正常性チェック設定画面(Azure App Serviceの正常性チェック)

正常性チェックのメトリックを確認

正常性チェックのメトリックはHealth check statusです。

正常性チェックのメトリックを表示

監視にあるメトリックを選択します。
メトリックの追加を選択します。
メトリックにHealth check statusを選択します。

すべてのインスタンスが正常な場合は100になります。

Webアプリのメトリック画面(Azure App Serviceの正常性チェック)

エラーを発生させて正常性チェックの変化を確認

エラーを発生させて、正常性チェックのメトリックの変化を確認します。
今回はNginxのコンテナイメージを利用しています。
トップページを表示するHTMLファイルを削除してエラーを発生させています。

エラーを発生させて正常性チェックを確認

既定のドメインへアクセスしトップ画面を表示します。

エラーとなるように、index.htmlを削除します。

#index.htmlを削除
root@app-servic_xxxxxxxxxx:/home# cd /usr/share/nginx/html/
root@app-servic_xxxxxxxxxx:/usr/share/nginx/html# ls
50x.html index.html
root@app-servic_xxxxxxxxxx:/usr/share/nginx/html# rm -rf index.html

再度、既定のドメインへアクセスしトップ画面を表示します。
403エラーが表示されています。

Health check statusのメトリックが50まで下がっている事が確認できます。

※2つのインスタンスのうち1つが異常となっている状態です。

異常なインスタンスの削除を確認

トップページにアクセスし、異常なインスタンスが切り離されているかを確認します。
エラー状態となった時点で、403エラーが表示されるようになります。
異常なインスタンスが切り離されて、正常な応答(200)のみになっていることを確認できます。

エラー発生直後からインスタンス切り離し前までの間は、正常なインスタンスと異常なインスタンスが混在した状態となります。
そのため、HTTPレスポンスコード200と403が混在した状態となります。

異常なインスタンスの削除を確認
HTTPのレスポンスコードのメトリックを確認します。 403と2xxのレスポンスコードのメトリックを表示します。切り離しが完了した後、403のメトリックが0となっていることが確認できます。切り離し後も正常なアクセスは継続しています。

※グラフの表示範囲は20分としています。
※異常な状態が1時間継続している場合は、インスタンスは新しいものに置き換えられます。なおインスタンスの置き換えには上限があります。

異常なインスタンスと判断するまでの再試行回数

異常なインスタンスと判断するまでの再試行回数や、一度に切り離しするインスタンス数の割合なども設定できます。
設定は環境変数のアプリ設定にあります。

構成

WEBSITE_HEALTHCHECK_MAXPINGFAILURESが、再試行回数になります。
この値は負荷分散のしきい値と同じ値になります。
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENTが、一度に切り離しするインスタンス数の割合になります。

正常チェックの構成設定
環境変数にWEBSITE_HEALTHCHECK_MAXPINGFAILURESの設定があります。

※WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENTを設定する場合は追加します。

Health check statusのメトリックは監視にも使える

Health check statusのメトリックはアラートルールのシグナルとして利用できます。
Azure Monitorのアラートルールを使って通知する事ができます。

Health check statusのアラートルール設定例
シグナルにHealth check status(プラットフォームメトリック)が選択できます。