正常性チェックを使用して App Service インスタンスを監視する
この記事では、Azure portal の正常性チェックを使用して App Service インスタンスを監視します。 正常性チェックを行うと、異常なインスタンスを避けて要求を再ルーティングし、正常に戻らないインスタンスを置き換えることができるので、アプリケーションの可用性が向上します。 これは、任意の Web アプリケーションのパスを毎分 ping することで行われます。
/api/health は、説明のために追加された単なる例であることに注意してください。 既定では、正常性チェック パスは作成されません。 選択するパスが、アプリケーション内に存在する有効なパスであることを確認する必要があります
App Service で正常性チェックを使用した処理
- アプリでパスを指定すると、正常性チェックによって、App Service アプリのすべてのインスタンスで 1 分間隔でこのパスに対する ping が実行されます。
- 特定のインスタンスで実行されている Web アプリが、10 回要求しても 200 から 299 (包括) の間の状態コードで応答しない場合、App Service によって異常と判断され、この Web アプリのロード バランサーから削除されます。 インスタンスが異常であると判断するために必要な失敗した要求の数は、少なくとも 2 つの要求で構成できます。
- 削除後、正常性チェックによる異常なインスタンスへの ping が継続されます。 インスタンスが正常な状態コード (200 - 299) で応答し始める場合、インスタンスはロード バランサーに返されます。
- インスタンスで実行されている Web アプリが 1 時間異常なままの場合、そのインスタンスは新しいものに置き換えられます。
- スケールアウトする場合は、新しいインスタンスの準備ができていることを保証するために、App Service によって正常性チェック パスに対して ping が実行されます。
Note
- 正常性チェックは 302 リダイレクトには従いません。
- App Service プランによれば、1 時間あたり最大で 1 つのインスタンス、1 日あたり最大で 3 つのインスタンスが置き換えられます。
- 正常性チェックによって状態
Waiting for health check responseが表示されている場合は、HTTP 状態コード 307 が原因でチェックが失敗している可能性があります。これは、HTTPS リダイレクトが有効になっているがHTTPS Onlyが無効になっている場合に発生する可能性があります。
正常性チェックを有効にする
- 正常性チェックを有効にするには、Azure portal にアクセスし、App Service アプリを選択します。
- [監視] で [正常性チェック] を選択します。
- [有効] を選択し、
/healthや/api/healthなど、ご利用のアプリケーションの有効な URL パスを指定します。 - [保存] を選択します。
注意
- 正常性チェックを完全に利用するには、App Service プランを 2 つ以上のインスタンスにスケーリングする必要があります。
- 正常性チェック パスによって、ご利用のアプリケーションの重要なコンポーネントが確認されます。 たとえば、ご利用のアプリケーションがデータベースとメッセージング システムに依存している場合、正常性チェックのエンドポイントはそれらのコンポーネントに接続する必要があります。 アプリケーションが重要なコンポーネントに接続できない場合は、アプリケーションが異常であることを示す 500 レベルの応答コードがパスから返されます。 また、パスが 1 分以内に応答を返さない場合、正常性チェックの ping は異常と見なされます。
- 正常性チェック パスを選択するときは、アプリが完全にウォームアップされている場合にのみ、状態コード 200 を返すパスを選択していることを確認します。
- 関数アプリで正常性チェックを使用するには、Premium またはDedicated ホスティング プランを使用する必要があります。
- 関数アプリの正常性チェックの詳細については、「正常性チェックを使用して関数アプリを監視する」を参照してください。
注意事項
正常性チェックの構成変更によって、アプリが再起動します。 運用環境のアプリへの影響を最小限に抑えるには、ステージング スロットを構成し、運用環境にスワップすることをお勧めします。
構成
正常性チェックのオプションを構成するだけでなく、次のアプリ設定を構成することもできます。
| アプリ設定の名前 | 使用できる値 | 説明 |
|---|---|---|
WEBSITE_HEALTHCHECK_MAXPINGFAILURES |
2 ～ 10 | インスタンスを異常と見なし、ロード バランサーから削除するために必要な、失敗した要求の数。 たとえば、2 に設定すると、ping に 2 回失敗した後にインスタンスが削除されます。 (既定値は 10) |
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT |
1 - 100 | 既定では、残りの正常なインスタンスに負荷がかかりすぎるのを避けるため、一度にロード バランサーから除外されるインスタンスの数は半分以下です。 たとえば、App Service プランが 4 つのインスタンスにスケーリングされ、3 つに異常が発生した場合、2 つが除外されます。 他の 2 つのインスタンス (1 つは正常、1 つは異常) は、引き続き要求を受信します。 すべてのインスタンスが異常であるという最悪のシナリオでは、何も除外されません。 この動作をオーバーライドするには、アプリ設定を 1 ～ 100 の値に設定します。 値を大きくするほど、削除される異常なインスタンスが増えます (既定値は 50)。 |
認証とセキュリティ
正常性チェックは、App Service の認証および認可機能と統合されます。 これらのセキュリティ機能が有効になっている場合、他の設定は必要ありません。
独自の認証システムを使用する場合は、正常性チェック パスで匿名アクセスを許可する必要があります。 正常性チェック エンドポイントをセキュリティで保護するには、まず IP 制限、クライアント証明書、Virtual Network などの機能を使用して、アプリケーション アクセスを制限する必要があります。 それらの機能が適切に準備されたら、ヘッダー x-ms-auth-internal-token を検査し、環境変数 WEBSITE_AUTH_ENCRYPTION_KEY の SHA256 ハッシュと一致することを検証することで、正常性チェック要求を認証できます。 一致する場合、正常性チェック要求は有効であり、App Service から送信されています。
Note
特に Azure Functions 認証の場合、正常性チェック エンドポイントとして機能する関数は、匿名アクセスを許可する必要があります。
using System;
using System.Text;
/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
var sha = System.Security.Cryptography.SHA256.Create();
String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
return hash == headerValue;
}
Note
x-ms-auth-internal-token ヘッダーは、Windows App Service でのみ使用できます。
インスタンス
正常性チェックを有効にすると、[インスタンス] タブでアプリケーション インスタンスを再起動し、その状態を監視できます。[インスタンス] タブにはインスタンスの名前とそのアプリケーションのインスタンスの状態が表示され、インスタンスを手動で再起動するオプションが表示されます。
アプリケーション インスタンスの状態が異常となっている場合は、テーブル内の再起動ボタンを使用してインスタンスを手動で再起動できます。 再起動すると、インスタンスと同じ App Service プランでホストされている他のアプリケーションも影響を受けることに注意してください。 インスタンスと同じ App Service プランを使用している他のアプリケーションがある場合は、再起動ボタンをクリックすると開くブレードに一覧表示されます。
インスタンスを再起動し、再起動プロセスが失敗した場合は、ワーカーを置き換えるオプションが表示されます (置き換えは 1 時間あたり 1 つのインスタンスのみ可能です)。 これも、同じ App Service プランを使用するすべてのアプリケーションに影響します。
Windows アプリケーションには、プロセス エクスプローラーを使用してプロセスを表示するオプションもあります。 これにより、スレッド数、プライベート メモリ、合計 CPU 時間など、インスタンスのプロセスに関する詳細な分析情報が得られます。
診断情報の収集
Windows アプリケーションの場合は、[正常性チェック] タブで診断情報を収集するオプションがあります。診断の収集を有効にすると、異常なインスタンスのメモリ ダンプを作成し、それを指定されたストレージ アカウントに保存する自動修復規則が追加されます。 このオプションを有効にすると、自動修復の構成が変更されます。 既存の自動修復規則がある場合は、App Service の診断を使用して、これを設定することをお勧めします。
診断の収集が有効になったら、ファイルのための既存のストレージ アカウントを作成または選択できます。 アプリケーションと同じリージョンにあるストレージ アカウントのみを選択できます。 保存によってアプリケーションが再起動されることに注意してください。 保存の後、継続的に ping を実行してもサイト インスタンスが異常であることが検出された場合は、ストレージ アカウント リソースに移動してメモリ ダンプを表示できます。
監視
アプリケーションの正常性チェック パスを指定したら、Azure Monitor を使用してご利用のサイトの正常性を監視できます。 ポータルの [正常性チェック] ブレードで、上部のツールバーにある [メトリック] を選択します。 これにより新しいブレードが開き、サイトの過去の正常性状態や、新しいアラート ルールの作成オプションが表示されます。 正常性チェック メトリックでは、成功した ping が集計され、正常性チェックの構成に基づいてインスタンスが異常と見なされた場合にのみ、エラーが表示されます。 サイトの監視方法の詳細については、Azure Monitor に関するガイドを参照してください。
制限事項
- 正常性チェックは Free と Shared の App Service プランに対して有効にできるので、サイトの正常性に関するメトリックを取得し、アラートを設定できますが、Free と Shared のサイトはスケールアウトできないので、異常なインスタンスは置き換えられません。 2 つ以上のインスタンスにスケールアウトし、正常性チェックのベネフィットを完全に利用できるようにするには、Basic レベル以上にスケールアップする必要があります。 これは、アプリの可用性とパフォーマンスが向上するので、運用環境向けアプリケーションに推奨されます。
- App Service プランでは、1 時間あたり最大 1 つの異常なインスタンスを置き換えることができ、最大で 1 日に 3 つのインスタンスを置き換えることができます。
- スケール ユニットごとに、正常性チェックに置き換えられるインスタンスの総数には、構成できる数に制限があります。 この制限に達した場合、異常なインスタンスは置き換えられません。 この値は 12 時間ごとにリセットされます。
よく寄せられる質問
アプリが 1 つのインスタンスで実行されている場合は、どうなるでしょうか?
アプリが 1 つのインスタンスだけにスケーリングされていて、異常になった場合、ロード バランサーから削除するとアプリケーションが完全にダウンするため、削除されません。 ただし、異常な ping が 1 時間続いた後、インスタンスは置き換えられます。 正常性チェックの再ルーティングのベネフィットを実現するには、2 つ以上のインスタンスにスケールアウトします。 アプリが 1 つのインスタンスで実行されている場合でも、正常性チェックの監視機能を使用して、アプリケーションの正常性を追跡できます。
正常性チェック要求が Web サーバーのログに表示されないのはなぜですか?
正常性チェック要求はサイトに内部的に送信されるため、この要求は Web サーバーのログには表示されません。 正常性チェックのコードにログ ステートメントを追加して、正常性チェックのパスで ping が行われたときのログを保持できます。
正常性チェック要求は、HTTP または HTTPS のどちらで送信されますか?
Windows App Service では、サイトで HTTPS のみが有効になっている場合、正常性チェック要求は HTTPS で送信されます。 それ以外の場合は、HTTP で送信されます。 Linux App Service では、正常性チェック要求は HTTP を使用してのみ送信され、現時点では HTTPS を使用して送信することはできません。
構成されたアプリケーション コードに続く正常性チェックは、既定のドメインとカスタム ドメインの間でリダイレクトされますか?
いいえ。正常性チェック機能は、Web アプリケーションの既定のドメインのパスに ping を実行しています。 既定のドメインからカスタム ドメインへのリダイレクトがある場合、正常性チェックで返される状態コードは 200 ではなく、リダイレクト (301) になり、worker に異常を示します。
同じ App Service プランで複数のアプリがある場合はどうなりますか?
App Service プランに他のアプリがあるかどうかに関係なく、異常なインスタンスはロード バランサーのローテーションから常に削除されます (WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT で指定されている割合まで)。 インスタンス上の 1 つのアプリが 1 時間より長く異常状態のままになっているときは、正常性チェックが有効になっている他のすべてのアプリも異常である場合にのみ、インスタンスが置き換えられます。 正常性チェックが有効になっていないアプリは考慮されません。
例
正常性チェックが有効になっている、アプリ A およびアプリ B という名前の 2 つのアプリケーション (またはスロットがある 1 つのアプリ) があるとします。それらは同じ App Service プラン上にあり、プランは 4 つのインスタンスにスケールアウトされます。 2 つのインスタンスでアプリ A が異常になると、ロード バランサーによって、それら 2 つのインスタンス上のアプリ A への要求の送信は停止されます。 その場合でも、アプリ B が正常であるとすると、要求はそれらのインスタンス上のアプリ B にルーティングされます。 それら 2 つのインスタンスでアプリ A の異常状態が 1 時間を超えると、それらのインスタンスでアプリ B もやはり異常である場合にのみ、それらのインスタンスは置き換えられます。 アプリ B が正常な場合は、インスタンスは置き換えられません。
Note
プランに正常性チェックが有効になっていない別のサイトまたはスロットがある場合 (サイト C)、それはインスタンスの置換には考慮されません。
すべてのインスタンスが異常になった場合はどうなりますか?
アプリケーションのすべてのインスタンスが異常なシナリオでは、App Service によってロード バランサーからインスタンスが削除されません。 このシナリオでは、すべての異常なアプリ インスタンスがロード バランサーのローテーションから外されると、アプリケーションは実質的に停止します。ただし、インスタンスの置換は行われます。
正常性チェックは App Service Environment で機能しますか?
はい。App Service Environment v3 では正常性チェックを使用できますが、バージョン 1 または 2 では使用できません。 旧バージョンの App Service Environment を使用している場合は、移行機能を使用して、App Service Environment をバージョン 3 に移行できます。