Azure App Serviceの「Monitor the Health of App Service Instances – Azure App Service」で押さえるべき結論は、Health checkを有効にするだけでは不十分で、ヘルスチェック用パスの設計、2インスタンス以上の構成、デプロイスロットとの整合性、認証・リダイレクト設定まで確認する必要があるという点です。
Health checkは、Azure App Service上の異常なインスタンスをロードバランサーから外し、状態が戻れば復帰させ、異常が続く場合はインスタンスの置き換えまで行う可用性向上のための機能です。特に本番環境では、単なる監視メトリックではなく「障害時にどのインスタンスへトラフィックを流すか」を左右する設定として扱う必要があります。Microsoft Learnの日本語ページでは最終更新日が2025年11月4日と表示されているため、本稿では2026年5月6日時点で確認すべきAzure App Service Health checkの運用ポイントとして整理します。(Microsoft Learn)
Azure App ServiceのHealth checkとは
Azure App ServiceのHealth checkは、指定したアプリケーション内のURLパスに対して、App Serviceが定期的にpingを行い、各インスタンスの状態を判定する機能です。指定するパスに既定値はなく、/health や /api/health など、アプリ側で実際に存在するエンドポイントを用意する必要があります。(Microsoft Learn)
重要なのは、Health checkが「サイトが落ちているかを見るだけ」の機能ではないことです。異常と判定されたインスタンスは、Webアプリのロードバランサーから除外されます。復旧して200〜299のステータスコードを返すようになれば、再びロードバランサーに戻されます。さらに、異常状態が1時間続いた場合は、新しいインスタンスへの置き換えも行われます。(Microsoft Learn)
つまりHealth checkは、次の3つを組み合わせた機能です。
| 観点 | 役割 | 実務上の意味 |
|---|---|---|
| 監視 | 指定パスを1分間隔で確認 | アプリ単位でインスタンスの状態を把握できる |
| トラフィック制御 | 異常インスタンスをロードバランサーから除外 | ユーザーを壊れたインスタンスに誘導しにくくなる |
| 自動復旧 | 異常が続くインスタンスを置き換え | 手動対応前に一定の自己回復が期待できる |
何が変わるのか：運用上の焦点は「有効化」から「正しく効く設計」へ
今回確認すべきポイントは、新しい画面操作そのものよりも、Health checkを本番運用に組み込む際の判断基準です。Azure Advisorでも、App Serviceの本番ワークロードではHealth checkの利用が推奨事項として扱われており、異常インスタンスの回避と置き換えによる信頼性向上が期待されると説明されています。(Microsoft Learn)
特に、管理者や開発者が意識すべき変更点・確認点は次のとおりです。
| 確認ポイント | これまで見落としやすかった点 | 対応の方向性 |
|---|---|---|
| ヘルスチェックパス | トップページや単純な静的URLを指定してしまう | 依存先を含めてアプリが本当に使える状態か確認する |
| インスタンス数 | 1インスタンスで有効化して満足してしまう | 本番は2インスタンス以上を基本にする |
| ステータスコード | リダイレクトや認証で200以外になる | 200〜299を返す専用パスを用意する |
| デプロイ | 設定変更でアプリが再起動する | ステージングスロットで検証してから本番反映する |
| 複数アプリ構成 | 同じApp Serviceプラン上の他アプリへの影響を見落とす | プラン単位の影響範囲を事前に確認する |
Health checkの動作を具体的に理解する
Health checkは、指定したパスに対してすべてのApp Serviceインスタンスから1分間隔でpingを実行します。既定では、10回の要求で200〜299のステータスコードが返らない場合、そのインスタンスは異常と判断され、ロードバランサーから削除されます。失敗回数のしきい値は、アプリ設定で最小2回まで変更できます。(Microsoft Learn)
動作を時系列で見ると、次のようになります。
| タイミング | App Serviceの動作 | 管理者・開発者が見るべきこと |
|---|---|---|
| Health check有効化後 | 指定パスへ1分間隔でping | /health などが確実に応答するか |
| 連続失敗 | インスタンスを異常と判定 | 500系、タイムアウト、リダイレクト、認証エラーを確認 |
| 異常判定後 | ロードバランサーから除外 | 残りインスタンスに負荷が集中しないか |
| 正常応答に回復 | ロードバランサーへ復帰 | 復旧後に自動復帰できるか |
| 1時間異常が継続 | インスタンス置き換え | 同一プラン上の他アプリへの影響を確認 |
ここで注意したいのは、Health checkの失敗は「アプリが完全に停止している」場合だけでは発生しないことです。たとえば、データベース接続が枯渇している、メッセージング基盤に接続できない、ウォームアップが終わっていない、認証リダイレクトが発生している、といった状態でも異常判定につながります。
対象者と影響範囲
Health checkの設定は、Azure App Serviceを運用する複数の担当者に影響します。特に本番アプリ、API、社内業務システム、BtoC向けWebサービスでは、開発・インフラ・運用の担当範囲を分けずに確認したほうが安全です。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| Azure管理者 | App Serviceプラン、スケール、監視、アラートに影響 | インスタンス数、プラン、Azure Monitor設定 |
| アプリ開発者 | ヘルスチェック用エンドポイントの実装が必要 | 200〜299を返す条件、依存先チェック、認証除外 |
| SRE・運用担当 | 障害時の切り離し、復旧、通知に影響 | アラート、ログ、手動再起動手順 |
| セキュリティ担当 | 匿名アクセスや内部ヘッダー検証に影響 | IP制限、クライアント証明書、内部トークン検証 |
| リリース担当 | 設定変更やスロットスワップに影響 | ステージングスロット、本番反映手順 |
Health checkを有効化する手順
Azure portalでHealth checkを有効化する基本手順はシンプルです。Azure portalで対象のApp Serviceアプリを開き、左側メニューの「監視」から「正常性チェック」を選択し、有効化したうえで /health や /api/health などの有効なURLパスを指定して保存します。(Microsoft Learn)
ただし、本番環境では「手順どおりに有効化する」だけで終わらせないことが重要です。保存時にアプリが再起動するため、Microsoftは運用アプリへの影響を抑えるためにステージングスロットを構成し、本番へスワップする方法を推奨しています。(Microsoft Learn)
有効化前に確認するチェックリスト
| 項目 | 確認内容 | NG例 |
|---|---|---|
| パスの存在 | 指定したURLがアプリ内に存在する | 存在しない /healthcheck を指定する |
| 応答コード | 正常時に200〜299を返す | 301、302、307、401、500を返す |
| 応答時間 | 1分以内に応答する | DB待ちでタイムアウトする |
| ウォームアップ | 完全に起動後のみ200を返す | 起動途中でも200を返す |
| 依存先 | 重要なDBや外部サービスを確認する | アプリプロセスだけを確認してDB障害を見逃す |
| 認証 | App Service認証または匿名許可の設計ができている | 独自認証でHealth checkがログイン画面へ飛ばされる |
| スケール | 本番は2インスタンス以上か | 1インスタンスのまま可用性向上を期待する |
ヘルスチェック用エンドポイントの設計例
Health checkの品質は、指定するエンドポイントの設計で大きく変わります。トップページを指定するよりも、ヘルスチェック専用のエンドポイントを作るほうが安全です。
たとえば、Web APIであれば次のような判断基準が実用的です。
| チェック対象 | 含めるべきか | 理由 |
|---|---|---|
| アプリプロセスの起動状態 | 含める | 最低限の死活確認になる |
| DB接続 | 多くの場合は含める | DBに接続できないアプリは実質的に利用不能なことが多い |
| メッセージキュー | 業務上必須なら含める | 非同期処理が止まるとサービス品質に影響する |
| 外部決済API | 慎重に判断 | 外部要因で全インスタンス異常扱いになる可能性がある |
| 重い集計処理 | 含めない | Health check自体が負荷源になる |
| キャッシュ接続 | 依存度が高ければ含める | Redisなどの停止でアプリが機能しない場合は重要 |
Microsoftのドキュメントでも、アプリがデータベースやメッセージングシステムに依存している場合、Health checkエンドポイントはそれらの重要コンポーネントに接続し、接続できない場合は500レベルの応答コードを返す例が示されています。また、1分以内に応答しない場合も異常と見なされます。(Microsoft Learn)
実務では、ヘルスチェックを「軽すぎる」または「重すぎる」どちらにも寄せすぎないことが大切です。
軽すぎる例は、常に 200 OK を返すだけのエンドポイントです。この場合、DB障害や依存サービス障害が起きてもApp Serviceは正常と判断し、ユーザーは壊れたインスタンスにアクセスし続ける可能性があります。
重すぎる例は、毎回複雑なSQL、外部API呼び出し、大量データ読み込みを行うエンドポイントです。この場合、Health checkそのものが負荷を増やし、遅延やタイムアウトによって不必要な異常判定を招く可能性があります。
管理者が確認すべきApp Serviceプランとインスタンス数
Health checkの効果を最大化するには、App Serviceプランを2つ以上のインスタンスにスケールアウトする必要があります。1インスタンス構成でも監視には使えますが、異常インスタンスをロードバランサーから外すとアプリ全体が停止するため、ロードバランサーからの除外による可用性向上は得にくくなります。(Microsoft Learn)
FreeやSharedのApp ServiceプランでもHealth checkを有効化してメトリックやアラートを利用できますが、これらのプランではスケールアウトがサポートされないため、異常インスタンスの自動置き換えによるメリットは限定的です。Microsoftは、2インスタンス以上にスケールアウトしてHealth checkの恩恵を受けるにはBasicレベル以上へのスケールアップを案内しています。(Microsoft Learn)
| 環境 | 推奨判断 |
|---|---|
| 開発環境 | 1インスタンスでも監視・検証目的なら利用価値あり |
| 検証環境 | 本番に近いスロット構成・認証設定で確認する |
| 本番小規模サイト | 少なくとも2インスタンスを検討する |
| 本番高負荷サイト | 2インスタンス以上に加え、オートスケールやApplication Insightsも併用する |
| 長いウォームアップがあるアプリ | 最小3インスタンスも検討する |
Azure Advisorでも、本番ワークロードではApp Serviceの最小インスタンス数を2にし、ウォームアップ時間が長いアプリでは3インスタンスを推奨する記述があります。(Microsoft Learn)
開発者が実装時に注意すべきポイント
Health check用エンドポイントは、アプリケーションコードの一部として実装する必要があります。単にルートを追加するだけでなく、「どの状態ならユーザーにリクエストを受け付けてよいか」を明確に定義することが重要です。
正常時だけ200を返す
Health checkでは、200〜299のステータスコードが正常と見なされます。逆に、401、403、500、リダイレクト系のステータスコードは異常判定の原因になります。
たとえば、次のような設計が望ましいです。
| 状態 | 返すステータスコードの考え方 |
|---|---|
| アプリ起動済み、DB接続可能、重要依存先も利用可能 | 200 |
| DBに接続できない | 500 |
| アプリの初期化中 | 503 |
| メンテナンス中 | 503 |
| 認証が必要 | Health check用パスでは避ける |
特に注意したいのは、ログイン画面へのリダイレクトです。Health checkは302リダイレクトに従いません。また、HTTPSリダイレクトを有効にしていても「HTTPS Only」が無効な場合、HTTP 307が原因で Waiting for health check response になる可能性があります。(Microsoft Learn)
認証とセキュリティの注意点
App Serviceの認証・承認機能を利用している場合、Health checkはその機能と統合されるため、追加設定なしで利用できます。一方、独自の認証システムを使っている場合は、Health checkパスで匿名アクセスを許可する必要があります。(Microsoft Learn)
ただし、匿名アクセスを許可するからといって、誰でも内部状態を詳しく見られるエンドポイントにしてはいけません。Health checkエンドポイントは、詳細な環境変数、接続文字列、内部エラー内容、依存サービス名などを返さない設計にします。
セキュリティを高める方法として、MicrosoftのドキュメントではIP制限、クライアント証明書、仮想ネットワークなどでアクセスを制限したうえで、x-ms-auth-internal-token ヘッダーと WEBSITE_AUTH_ENCRYPTION_KEY のSHA256ハッシュを照合する方法が示されています。(Microsoft Learn)
実務では、次のようなレスポンスが扱いやすいです。
{
"status": "Healthy"
}避けたい例は次のようなレスポンスです。
{
"status": "Unhealthy",
"database": "sql-prod-eastasia-01",
"connectionString": "Server=...",
"error": "password authentication failed..."
}後者は障害調査には便利に見えますが、公開された場合の情報漏えいリスクが高すぎます。詳細な診断情報はApplication Insights、ログ、App Service Diagnosticsに集約し、Health checkエンドポイントは最小限の結果だけを返す設計が安全です。
設定できるアプリ設定
Health checkでは、標準の有効化に加えてアプリ設定で動作を調整できます。代表的な設定は次の2つです。
| アプリ設定 | 既定値 | 設定可能な値 | 用途 |
|---|---|---|---|
WEBSITE_HEALTHCHECK_MAXPINGFAILURES | 10 | 2〜10 | 異常と判定するまでの失敗回数 |
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT | 50 | 1〜100 | 一度にロードバランサーから除外できる異常インスタンスの割合 |
WEBSITE_HEALTHCHECK_MAXPINGFAILURES を小さくすると、異常インスタンスを早く切り離せます。ただし、一時的な遅延やウォームアップ中の応答遅れでも切り離しが起きやすくなります。安易に最小値へ下げるのではなく、アプリの起動時間、依存先の応答時間、通常時のレイテンシを見て判断してください。
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT は、残りの正常インスタンスに負荷が集中しすぎないよう制御するための設定です。既定では、一度にロードバランサーから除外されるインスタンスは半分以下です。たとえば4インスタンス中3インスタンスが異常でも、既定では2インスタンスのみが除外され、残りの2インスタンスは要求を受け続けます。(Microsoft Learn)
デプロイ・移行時の注意点
Health checkの導入は、アプリケーションの可用性を高める一方で、設定ミスがあると本番トラフィックに影響します。特にデプロイや移行のタイミングでは、次の点を確認してください。
設定変更でアプリが再起動する
Health checkの構成変更はアプリの再起動を伴います。業務時間中に直接本番環境で変更すると、短時間でもリクエスト失敗やセッション切断が発生する可能性があります。ステージングスロットで設定・検証し、本番へスワップする流れを基本にしましょう。(Microsoft Learn)
スロットスワップでは設定がスロット固有ではない
Health checkの構成はスロット固有ではありません。スワップ後は、スワップされたスロットのHealth check設定が宛先スロットへ適用されます。ステージングだけ別のパスを指定していると、本番反映後に意図しないパスが使われる可能性があります。(Microsoft Learn)
| スロット | Health checkパス | リスク |
|---|---|---|
| Production | /health | 正常 |
| Staging | /staging-health | スワップ後に本番で想定外のパスになる可能性 |
| Production / Staging共通 | /health | 予期しない差分を抑えやすい |
本番と非本番で完全に同じ依存先をチェックできない場合でも、パス名や返却仕様はできるだけ揃え、内部で環境ごとの依存先を見るように設計すると運用しやすくなります。
ウォームアップと組み合わせて考える
スケールアウト時、App Serviceは新しいインスタンスの準備ができていることを確認するため、Health checkパスにpingを行います。(Microsoft Learn)
そのため、ヘルスチェック用エンドポイントが「起動直後でも200を返す」実装だと、実際にはまだDB接続プールやキャッシュが準備できていない状態でトラフィックを受けてしまう可能性があります。逆に、ウォームアップ後にしか200を返さない設計にすれば、未準備のインスタンスへリクエストが流れるリスクを下げられます。
複数アプリを同じApp Serviceプランで動かしている場合
同じApp Serviceプランに複数のアプリを載せている場合は、Health checkの影響範囲を誤解しやすいです。
Microsoftのドキュメントでは、異常なインスタンスは他のアプリの有無に関係なく、指定割合の範囲でロードバランサーのローテーションから除外されると説明されています。一方で、インスタンスの置き換えについては、Health checkが有効な他のアプリも同じインスタンス上で異常な場合に限られます。Health checkが有効でないアプリは、置き換え判定では考慮されません。(Microsoft Learn)
たとえば、同じApp ServiceプランにアプリAとアプリBがあり、どちらもHealth checkを有効にしているとします。アプリAだけが特定インスタンスで異常になった場合、そのインスタンス上のアプリAへのリクエストは止められます。しかし、アプリBが正常であれば、インスタンス自体の置き換えは行われません。
この仕様は、コスト削減のために複数アプリを同一プランに集約している環境で特に重要です。Health checkを導入する前に、次のように整理してください。
| 確認項目 | 理由 |
|---|---|
| 同じApp Serviceプラン上のアプリ一覧 | 置き換え時の影響範囲を把握するため |
| 各アプリのHealth check有効化状況 | 置き換え判定に含まれるか確認するため |
| 本番アプリと検証アプリの混在有無 | 本番可用性に不要な影響を与えないため |
| スロットの有無 | スワップ時の設定差分を防ぐため |
監視とアラートの設定
Health checkパスを指定した後は、Azure Monitorでサイトの正常性を監視できます。Azure portalのHealth checkページからメトリックを開くと、Health check statusの履歴を確認し、アラートルールを作成できます。Health check statusメトリックでは、成功したpingが集計され、設定されたしきい値に基づいてインスタンスが異常と見なされたときにエラーとして反映されます。(Microsoft Learn)
本番環境では、少なくとも次の監視を組み合わせると実用的です。
| 監視項目 | 目的 |
|---|---|
| Health check status | インスタンス単位の異常検知 |
| HTTP 5xx | ユーザー影響の把握 |
| Response Time | 劣化の早期検知 |
| CPU / Memory | リソース逼迫の確認 |
| Application Insights | 例外、依存関係、分散トレースの分析 |
| Activity Log | 設定変更や再起動操作の追跡 |
App Service全体の監視方法として、MicrosoftはAzure Monitor、診断設定、Application Insights、ログストリーム、メトリック、クォータとアラート、アクティビティログなどを用途別に使い分けることを説明しています。特にASP.NET Core、ASP.NET、Java、Node.js、PythonではApplication Insightsによる可観測性の有効化も推奨されています。(Microsoft Learn)
障害時の運用手順
Health checkを有効化したら、障害時の手順も決めておく必要があります。Azure portalの「インスタンス」タブでは、Health check有効化後にインスタンス名と状態を確認でき、異常なインスタンスのワーカープロセスを手動で再起動できます。再起動が失敗する場合は、ワーカーの置き換えを行える場合があります。(Microsoft Learn)
ただし、インスタンス置き換えには制限があります。App Serviceプランでは、異常インスタンスの置き換えは1時間あたり最大1つ、1日あたり最大3つまでです。また、スケールユニットごとの総置き換え数にも構成できない制限があります。(Microsoft Learn)
障害時は、次の順で確認すると原因の切り分けがしやすくなります。
| 順序 | 確認内容 | 判断ポイント |
| -: | ——————– | ——————– |
| 1 | Health check status | どのインスタンスが異常か |
| 2 | HTTPステータス | 500系か、リダイレクトか、認証エラーか |
| 3 | Application Insights | 例外、依存先失敗、遅延の有無 |
| 4 | App Serviceメトリック | CPU、メモリ、接続数の逼迫 |
| 5 | デプロイ履歴 | 直近のリリースや設定変更 |
| 6 | 手動再起動 | 特定インスタンスだけの問題か |
| 7 | スケールアウト | 残りインスタンスの負荷増加に対応できるか |
Windowsアプリケーションでは、Health checkタブから診断情報の収集を有効化し、異常インスタンスのメモリダンプをストレージアカウントに保存する構成も可能です。ただし、この設定は自動修復の構成を変更するため、既存のAuto-Healルールがある場合はApp Service Diagnosticsから設定することが推奨されています。(Microsoft Learn)
よくある失敗例と対策
Health checkは強力ですが、設定ミスをすると逆効果になることがあります。実務で特に多い失敗例をまとめます。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| トップページをHealth checkに指定 | キャッシュで200が返り、障害を見逃す | 専用エンドポイントを作る |
| ログイン必須のパスを指定 | 401やリダイレクトで異常判定される | 匿名アクセスまたはApp Service認証統合を使う |
| カスタムドメインへのリダイレクトがある | 301で異常扱いになる | 既定ドメインのパスで200を返す |
| 依存先をすべて厳密に見る | 外部API障害で全インスタンス異常になる | 業務影響が大きい依存先に絞る |
| 1インスタンスで本番運用 | 切り離しによる可用性向上が限定的 | 2インスタンス以上を検討 |
| スロット間で設定差がある | スワップ後に想定外のHealth checkになる | ProductionとStagingの設定を揃える |
| 設定変更を本番で直接実施 | 再起動で一時影響が出る | ステージングスロットで検証する |
| エンドポイントが重い | Health check自体が負荷になる | 軽量で短時間に応答する実装にする |
管理者・開発者が今すぐ確認すべきこと
Azure App ServiceでHealth checkをすでに使っている場合も、まだ使っていない場合も、次の順番で確認すると無駄がありません。
既存環境の確認
まず、Azure portalで対象App ServiceのHealth checkが有効か、指定パスが何かを確認します。次に、そのパスへアクセスしたときに200〜299を返すか、リダイレクトや認証エラーになっていないかを確認します。
あわせて、App Serviceプランのインスタンス数も確認してください。本番アプリが1インスタンス構成の場合、Health checkの監視価値はありますが、異常インスタンスの切り離しによる可用性向上は限定的です。
アプリ側の実装確認
開発者は、Health checkエンドポイントが次の条件を満たしているかを確認します。
- アプリが完全にウォームアップした後だけ200を返す
- 重要なDBやメッセージング基盤に接続できない場合は500系を返す
- 1分以内に応答する
- 認証リダイレクトを発生させない
- 詳細な内部情報をレスポンスに含めない
デプロイ手順の確認
リリース担当者は、Health check設定の変更を本番で直接行わない手順になっているかを確認します。特にステージングスロットを使っている場合は、スワップ後にHealth check設定がどのスロットへ適用されるかを事前に検証してください。
まとめ：Health checkは「設定」ではなく可用性設計として扱う
Azure App ServiceのHealth checkは、異常なインスタンスを検出し、ロードバランサーから外し、必要に応じて置き換えることで、アプリケーションの可用性を高める機能です。導入自体はAzure portalから簡単に行えますが、本番環境で効果を出すには、ヘルスチェックパスの設計、2インスタンス以上のスケール構成、認証・リダイレクト対策、スロットスワップ時の設定整合性が欠かせません。
まず行うべきことは、対象App ServiceでHealth checkが有効か、指定パスが本当にアプリの利用可能性を表しているかを確認することです。そのうえで、Azure MonitorやApplication Insightsのアラートと組み合わせ、障害時に「どのインスタンスが異常で、どこまで自動復旧し、どこから手動対応するのか」を運用手順として整備してください。
コメント