正常性チェックを使用して App Service インスタンスを監視する
Note
2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用して一意の既定のホスト名を生成するオプションが備わります。 既存のアプリ名は変更されません。
例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
詳しくは、App Service リソースの一意の既定のホスト名に関する記事をご覧ください。
この記事では、Azure portal で正常性チェックを使用して App Service インスタンスを監視する方法について説明します。 正常性チェックを行うと、異常なインスタンスを避けて要求を再ルーティングし、正常に戻らないインスタンスを置き換えることができるので、アプリケーションの可用性が向上します。 そのために、選択したパスを使用して Web アプリケーションに毎分 ping が送信されます。
/api/health は単なる例であることに注意してください。 既定の正常性チェック パスはありません。 選択するパスが、アプリケーション内に存在する有効なパスであることを確認する必要があります。
正常性チェックのしくみ
- アプリでパスを指定すると、正常性チェックによって、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 または専用ホスティング プランを使用する必要があります。
- 関数アプリの正常性チェックの詳細については、「正常性チェックを使用して関数アプリを監視する」を参照してください。
注意事項
正常性チェックの構成変更によって、アプリが再起動します。 運用環境のアプリへの影響を最小限に抑えるには、ステージング スロットを構成し、運用環境にスワップすることをお勧めします。
構成
正常性チェックのオプションを構成するだけでなく、次のアプリ設定を構成することもできます。
| アプリ設定の名前 | 使用できる値 | 説明 |
|---|---|---|
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 制限、クライアント証明書、仮想ネットワークなどの機能を使用して、アプリケーション アクセスを制限する必要があります。 それらの機能が適切に準備されたら、ヘッダー 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 ヘッダーは、App Service for Windows でのみ使用できます。
インスタンス
正常性チェックを有効にすると、[インスタンス] タブからアプリケーション インスタンスを再起動して状態を監視できるようになります。[インスタンス] タブには、インスタンスの名前とそのアプリケーションのインスタンスの状態が表示されます。 このタブからインスタンスを手動で再起動することもできます。
アプリケーション インスタンスの状態が "異常" となっている場合は、テーブル内の再起動ボタンを使用してインスタンスを手動で再起動できます。 再起動すると、インスタンスと同じ App Service プランでホストされている他のアプリケーションも影響を受けることに注意してください。 インスタンスと同じ App Service プランを使用している他のアプリケーションがある場合は、再起動ボタンをクリックすると開くブレードに一覧表示されます。
インスタンスを再起動し、再起動プロセスが失敗した場合は、ワーカーを置き換えるオプションが表示されます (置き換えることができるのは、1 時間に 1 つのインスタンスのみです)。これも、同じ App Service プランを使用するすべてのアプリケーションに影響します。
Windows アプリケーションの場合は、Process Explorer を使用してプロセスを表示することもできます。 これにより、スレッド数、プライベート メモリ、合計 CPU 時間など、インスタンスのプロセスに関する詳細な分析情報が得られます。
診断情報の収集
Windows アプリケーションの場合、[正常性チェック] タブで診断情報を収集するオプションがあります。診断の収集を有効にすると、異常なインスタンスのメモリ ダンプを作成し、指定したストレージ アカウントに保存する自動修復規則が追加されます。 このオプションを有効にすると、自動修復の構成が変更されます。 既存の自動修復規則がある場合は、App Service の診断を使用して、これを設定することをお勧めします。
診断の収集を有効にすると、ファイルのためにストレージ アカウントを作成するか、選択することができます。 アプリケーションと同じリージョンにあるストレージ アカウントのみを選択できます。 保存によってアプリケーションが再起動されることに注意してください。 保存の後、継続的に ping を実行してもサイト インスタンスが異常であることが検出された場合は、ストレージ アカウント リソースに移動してメモリ ダンプを表示できます。
監視
アプリケーションの正常性チェック パスを指定したら、Azure Monitor を使用してご利用のサイトの正常性を監視できます。 ポータルの [正常性チェック] ブレードで、上部のツールバーにある [メトリック] を選択します。 これで新しいブレードが開き、サイトの正常性状態の履歴を確認したり、新しいアラート ルールを作成したりできるようになります。 正常性チェック メトリックでは、成功した ping が集計され、正常性チェックの構成に基づいてインスタンスが異常と見なされた場合にのみ、エラーが表示されます。 サイトの監視の詳細については、「Azure App Service のクォータとアラート」を参照してください。
制限事項
- 正常性チェックは、Free および共有の App Service プランで有効にできるため、サイトの正常性に関するメトリックを取得し、アラートを設定できます。 ただし、Free および共有サイトはスケールアウトできないため、異常なインスタンスは置き換えられません。 2 つ以上のインスタンスにスケールアウトし、正常性チェックの恩恵をすべて受けられるようにするには、Basic レベル以上にスケールアップする必要があります。 これは、アプリの可用性とパフォーマンスが向上するので、運用環境向けアプリケーションに推奨されます。
- App Service プランでは、1 時間あたり最大 1 つの異常なインスタンスを置き換えることができ、最大で 1 日に 3 つのインスタンスを置き換えることができます。
- スケール ユニットごとに、正常性チェックに置き換えられるインスタンスの総数には、構成できる数に制限があります。 この制限に達した場合、異常なインスタンスは置き換えられません。 この値は 12 時間ごとにリセットされます。
よく寄せられる質問
アプリが 1 つのインスタンスで実行されている場合は、どうなるでしょうか?
アプリが 1 つのインスタンスだけにスケーリングされていて、異常になった場合、ロード バランサーから削除するとアプリケーションが完全にダウンするため、削除されません。 ただし、異常な ping が 1 時間続いた後、インスタンスは置き換えられます。 正常性チェックの再ルーティングのベネフィットを実現するには、2 つ以上のインスタンスにスケールアウトします。 アプリが 1 つのインスタンスで実行されている場合でも、正常性チェックの監視機能を使用して、アプリケーションの正常性を追跡できます。
正常性チェック要求が Web サーバーのログに表示されないのはなぜですか?
正常性チェック要求はサイトに内部的に送信されるため、この要求は Web サーバーのログには表示されません。 正常性チェックのコードにログ ステートメントを追加して、正常性チェックのパスで ping が行われたときのログを保持できます。
正常性チェック要求は、HTTP または HTTPS のどちらで送信されますか?
App Service for Windows および Linux では、サイトで [HTTPS のみ] が有効になっている場合、正常性チェック要求は HTTPS 経由で送信されます。 それ以外の場合は、HTTP で送信されます。
正常性チェックは、アプリケーション コードで構成された既定のドメインとカスタム ドメイン間のリダイレクトに従いますか?
いいえ。正常性チェック機能は、Web アプリケーションの既定のドメインのパスに ping を実行します。 既定のドメインからカスタム ドメインへのリダイレクトがある場合、正常性チェックが返す状態コードは 200 ではありません。 リダイレクト (301) になります。これはワーカーが異常であることを示します。
同じ App Service プランで複数のアプリがある場合はどうなりますか?
App Service プランに他のアプリがあるかどうかに関係なく、異常なインスタンスはロード バランサーのローテーションから常に削除されます (WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT で指定されている割合まで)。 あるインスタンス上の 1 つのアプリが異常な状態になって 1 時間超えると、正常性チェックが有効になっている他のすべてのアプリも異常である場合にのみ、インスタンスが置き換えられます。 正常性チェックが有効になっていないアプリは考慮されません。
例
たとえば、正常性チェックが有効な 2 つのアプリケーション (または 1 つのスロットがある 1 つのアプリ) があるとします。 これらをアプリ A、アプリ B と呼びます。これらは同じ 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 に移行できます。