Azure App Serviceの502・503を切り分ける方法｜障害・負荷・アプリ原因を確認

Azure App Serviceで「502 Bad Gateway」や「503 Service Unavailable」が発生しても、すぐにAzure全体の障害と判断してはいけません。長時間処理、CPU・メモリ負荷、アプリケーション例外など、アプリ側の問題でも502・503は発生します。

最初に行うべきことは、発生時刻を記録し、Service Healthと同じ時間帯のメトリックを比較することです。その後、Diagnose and solve problemsやKuduで例外や長時間処理を調べます。再起動は復旧のための一時対応として有効ですが、調査に必要な情報を保存してから実施し、再発しないか観察することが重要です。Microsoftも、502・503の調査を「監視」「データ収集」「問題の緩和」の順で進めるよう案内しています。([Microsoft Learn][1])

Azure App Serviceの502・503はAzure全体の障害とは限らない

HTTP 502と503は、利用者から見ると似た障害に見えます。しかし、ステータスコードだけでは原因を特定できません。

Microsoftが挙げている代表的な原因には、次のようなものがあります。

• リクエストの処理に長い時間がかかっている
• アプリが大量のCPUまたはメモリを使用している
• 例外によってアプリが応答できなくなっている

そのため、初動では「502だからネットワーク」「503だからAzureの障害」と決めつけず、発生範囲、負荷、ログ、直前の変更を組み合わせて判断します。([Microsoft Learn][1])

発生状況	主に疑う対象	次に確認すること
Service Healthに該当リージョン・サービスの障害が掲載されている	Azure側のサービス障害	影響対象、開始時刻、復旧状況
同じリージョンの複数アプリが同時にエラーになる	Azure側または共通ネットワーク・依存先	Service Health、共通構成、外部サービス
1つのアプリだけで発生する	アプリ、設定、デプロイ、リソース不足	アプリとApp Serviceプランのメトリック
アクセス増加と同時にCPU・メモリ・キューが上昇する	処理能力不足、長時間処理	スケール、処理時間、負荷集中
デプロイや設定変更の直後から発生する	コードまたは構成変更	変更履歴、例外ログ、ロールバック
再起動すると直るが、しばらくすると再発する	メモリ増加、処理停滞、例外など	再発までのメトリック推移とログ

この表は原因を確定するものではありません。「可能性の高い調査先を選ぶための入口」として使います。

再起動する前に発生時刻と影響範囲を記録する

502・503が続いていると、すぐにアプリを再起動したくなります。しかし、再起動によってプロセス状態や一時的な症状が消えると、原因調査が難しくなることがあります。

最低限、次の情報を記録してください。

1. エラーが発生した日時とタイムゾーン
2. 502または503のどちらだったか
3. エラーになったURLや機能
4. 全利用者に発生したか、一部利用者だけか
5. 発生直前にデプロイや設定変更を行ったか
6. いつまで継続し、いつ復旧したか
7. 再現操作があるか
8. 同じApp Serviceプラン上の別アプリにも影響があるか

時刻は「14時ごろ」ではなく、できるだけ具体的に記録します。

たとえば、次のように残します。

2026年9月19日 14:37 JSTから14:44 JSTまで、注文確定APIで503が発生。トップページは正常。14:20 JSTにアプリ設定を変更。

Azure Monitorやアプリログの表示時刻がUTCになっている場合に備えて、タイムゾーンも必ず併記します。上記の例なら、14:37 JSTは05:37 UTCです。

スクリーンショットを保存する場合は、URLのクエリ文字列、アクセストークン、接続文字列、秘密鍵、回復キー、個人情報が写り込んでいないか確認してください。

Service HealthでAzure側の障害を確認する

最初の切り分け先はAzure Service Healthです。

Azureの正常性情報には、主に次の3種類があります。

機能	確認できる範囲	用途
Azure Status	Azure全体の広域的な状態	広範囲な障害の確認
Service Health	利用中のサービスやリージョンに合わせた情報	自分の環境に関係する障害、メンテナンス、勧告の確認
Resource Health	個別リソースの状態	特定リソースの可用性確認

Microsoftは、Azure Statusだけでなく、利用中のサービスとリージョンに合わせたService Healthを使うことを推奨しています。Service Healthでは、サービス障害、計画メンテナンス、正常性に関する通知を確認できます。([Microsoft Learn][2])

Service Healthで確認する項目

AzureポータルでService Healthを開き、次の点を確認します。

1. App Serviceに関するアクティブな障害があるか
2. アプリを配置しているリージョンが対象か
3. 対象サブスクリプションやリソースが影響を受けているか
4. 障害の開始時刻が502・503の発生時刻と一致するか
5. 計画メンテナンスや正常性に関する勧告が出ていないか

Service Healthの開始時刻とアプリのエラー開始時刻が一致し、影響対象にも含まれているなら、Azure側の問題である可能性が高くなります。

一方、Service Healthに何も表示されていないからといって、アプリが正常だと証明されたわけではありません。その場合は、同じ時間帯のアプリとApp Serviceプランのメトリックを調べます。

同じ時間帯のメトリックを比較する

Azureポータルで対象のApp Serviceを開き、通常は「Monitoring」または「監視」にある「Metrics」を選択します。Microsoftのトラブルシューティング手順でも、Average memory working set、CPU time、Memory working set、Requestsなどの確認が案内されています。([Microsoft Learn][1])

時間範囲は、エラー発生時刻の前後15分から30分程度を含めます。可能であれば、1分単位で変化を確認してください。

最初に追加したいメトリック

メトリック	推奨する見方	判断のポイント
Http Server Errors	合計	5xxが増加した時刻を特定する
Requests	合計	アクセス急増とエラーが連動しているか
Response Time	平均	エラー前から応答時間が悪化していないか
CPU Time	合計、必要に応じてインスタンス別	CPU消費が急増していないか
Average Memory Working Set	平均、インスタンス別	メモリ使用量が継続的に増えていないか
Memory Working Set	平均、インスタンス別	特定インスタンスだけ高くないか
Requests In Application Queue	平均	処理待ちが蓄積していないか
Instance Count	平均	発生時にインスタンス数が変化していないか

App Serviceの「Http Server Errors」は、500以上600未満のHTTPステータスコードをまとめて数えるメトリックです。そのため、このグラフだけでは502と503を区別できません。正確なステータスコードは、アプリログ、Webサーバーログ、診断結果などで確認します。

また、CPU Timeは「CPU使用率」ではなく、アプリが消費したCPU時間を秒単位で表すメトリックです。Requests、Http5xx、Memory Working Setなどはインスタンス別に確認できるため、複数インスタンスで動かしている場合は、全体平均だけでなくインスタンスごとの差も確認します。([Microsoft Learn][3])

メトリックの組み合わせから原因を推測する

単一のグラフだけで結論を出さず、複数の指標を同じ時間軸で重ねて判断します。

RequestsとResponse Timeが同時に上昇している

アクセス増加によって処理時間が延びている可能性があります。

さらにCPU、メモリ、アプリケーションキューも上昇している場合は、処理能力不足や長時間処理を疑います。

Http Server Errorsだけが急増している

CPUやメモリが高くないのに5xxだけ増えている場合は、コード例外、設定不備、接続先サービスの障害、タイムアウトなどを調べます。

Application Insightsを有効にしている環境では、例外や依存先へのアクセス失敗を発生時刻と関連付けて確認できます。App Service Diagnosticsも、Application Insightsと連携して例外や依存関係の問題を示せる場合があります。([Microsoft Learn][4])

メモリが徐々に増え、再起動後に下がる

メモリリークや解放されないオブジェクトが疑われますが、グラフだけで確定はできません。

再起動後から再発までの増加傾向を記録し、例外ログ、プロセス情報、メモリダンプなどで裏付けます。

一部のインスタンスだけでエラーが多い

複数インスタンス構成では、特定のインスタンスだけが高負荷や異常状態になることがあります。

インスタンス別にHttp5xx、メモリ、CPU Timeを比較し、問題のあるインスタンスが限定されているか確認します。

App Serviceプラン側の負荷も確認する

アプリのメトリックだけでなく、App Serviceプラン側のメトリックも確認してください。

App Serviceプランでは、次の指標が役立ちます。

• CPU Percentage
• Memory Percentage
• Http Queue Length
• Disk Queue Length
• Data In、Data Out
• ソケット関連のメトリック

App ServiceプランのCPU Percentageは、プラン内の全インスタンスにおける平均CPU使用率です。Memory Percentageは平均メモリ使用率を示します。Http Queue Lengthが高い、または継続的に増えている場合は、プランが高負荷状態にある可能性があります。([Microsoft Learn][5])

同じApp Serviceプランにある別アプリにも注意する

複数のアプリを同じApp Serviceプランに配置している場合、それらのアプリは同じVMインスタンスのCPUやメモリを共有します。診断ログ、バックアップ、WebJobs、デプロイスロットも同じ計算リソースを利用します。([Microsoft Learn][6])

そのため、エラーが出ているアプリ自身のRequestsが増えていなくても、同じプランにある別アプリの処理によってプラン全体が高負荷になることがあります。

次の順番で確認すると判断しやすくなります。

1. エラーが出たアプリのCPU Time、メモリ、Requestsを確認する
2. App Serviceプラン全体のCPU PercentageとMemory Percentageを確認する
3. 同じプランにある他のアプリの負荷を確認する
4. WebJobs、バックアップ、デプロイスロットの処理時刻を確認する

アプリ側の負荷が低く、プラン全体の負荷だけが高い場合は、同じプラン上の別アプリやバックグラウンド処理が影響している可能性があります。

Diagnose and solve problemsで異常を調べる

Azure App Serviceには、設定不要で利用できる診断機能があります。

対象のApp Serviceを開き、「Diagnose and solve problems」を選択します。表示名はポータルの言語や更新状況によって多少異なることがあります。

App Service Diagnosticsでは、次のような観点を確認できます。

• Availability and Performance
• Web App Down
• Web App Slow
• Application Logs
• CPU Usage
• Memory Usage
• Application Changes
• Networking
• TCP Connections
• SNAT Port Exhaustion
• Process List

利用できる診断項目は、Windows、Linux、コンテナなどの構成によって異なります。

特に確認したいのは、502・503の発生直前に何が変わったかです。コードのデプロイ、アプリ設定、接続文字列、ネットワーク設定、スケール設定などの変更時刻とエラー開始時刻を比較します。

App Service Diagnosticsは直近24時間以内の問題を調べる際に特に有効とされているため、障害発生後は早めに確認するのが安全です。([Microsoft Learn][4])

Advanced Tools／Kuduでログとプロセスを確認する

Diagnose and solve problemsだけで原因が分からない場合は、Kuduを使用します。

Microsoftの案内では、Azureポータルの対象アプリから「Development Tools」「Advanced Tools」を開き、「Go」を選択してKuduへ移動します。Kuduでは、ログストリーム、診断ダンプ、環境情報、デバッグコンソールなどを利用できます。([Microsoft Learn][1])

Kuduで確認する内容

確認場所	主な確認内容
Log Stream	発生時刻付近の例外、タイムアウト、起動エラー
Log files	アプリログ、Webサーバーログ、コンテナログ
Process情報	プロセスの異常、ハング、高負荷
Diagnostic dump	例外や停止状態の詳細調査
Debug Console	ファイル配置、ログ更新時刻、設定反映状況
Environment	環境変数や実行環境の差異

Kuduは、アプリ設定、接続文字列、環境変数などの重要情報も扱います。画面共有やスクリーンショットを行う際は、秘密情報を必ず隠してください。

また、デバッグコンソールではファイル削除や設定変更につながる操作も可能です。調査目的で利用する場合は、参照だけにとどめ、意味を理解していないコマンドを本番環境で実行しないようにします。Kuduが提供する情報や機能、必要なアクセス権限は構成によって異なります。([Microsoft Learn][7])

再起動は一時対応として実施する

アプリの再起動は、一時的なプロセス異常から復旧する方法として有効です。Microsoftのトラブルシューティングでも、一時的な問題から回復するための簡単な方法として再起動が案内されています。([Microsoft Learn][1])

ただし、次の順番を守ります。

1. 発生時刻を記録する
2. メトリックの画面を保存する
3. 必要なログを保存する
4. Service Healthと変更履歴を確認する
5. 再起動を実施する
6. 復旧時刻を記録する
7. 同じ条件で再発しないか監視する

再起動後に正常化しても、原因が解消したとは限りません。

たとえば、メモリ使用量が時間とともに増える問題では、再起動によって一時的にメモリが解放されます。しかし、根本原因が残っていれば再発します。

再起動後は、少なくとも次の項目を継続して観察します。

• Http Server Errors
• Response Time
• CPU Time
• Memory Working Set
• Requests In Application Queue
• App ServiceプランのCPU Percentage
• App ServiceプランのMemory Percentage

スケールアップ・スケールアウトは測定結果を見て判断する

502・503が出たからといって、すぐに上位プランへ変更すれば直るとは限りません。

スケールを検討しやすいのは、次のようなケースです。

観測結果	検討する対応
アクセス増加とCPU・メモリ・キュー上昇が連動している	スケールアップまたはスケールアウト
特定時間帯だけ負荷が集中する	オートスケール、処理の分散
同じプランの別アプリがリソースを消費している	App Serviceプランの分離
1インスタンス障害時の影響を減らしたい	複数インスタンス構成
CPU・メモリに余裕があるのに遅い	コードや外部依存先を先に調査
デプロイ直後からエラーになった	スケールより変更内容の修正・ロールバック

App Serviceでは、上位の価格レベルへ変更するスケールアップと、インスタンス数を増やすスケールアウトが利用できます。複数インスタンスは処理能力や耐障害性の向上に役立つ場合がありますが、価格や構成に影響します。([Microsoft Learn][1])

データベースの遅延、外部APIの停止、コード上のロック、無制限な再試行、長時間同期処理などが原因なら、インスタンスを増やしても十分な改善が得られない可能性があります。

変更前後で、同じメトリック、同じ集計方法、同程度のアクセス条件を使って効果を測定してください。

よくある切り分けの失敗

エラーを見てすぐ再起動する

証拠が消え、原因が分からないまま再発します。最低限、時刻、メトリック、ログを保存してから再起動します。

Azure Statusだけを見る

Azure Statusは広域的な情報を確認するものです。自分のサブスクリプションやリージョンへの影響は、Service HealthとResource Healthも確認します。

異なる時間帯のグラフを比較する

Requestsは直近1時間、CPUは直近24時間というように時間範囲が違うと、相関関係を判断できません。すべてのグラフを同じ時間範囲、同じタイムゾーンに合わせます。

平均値だけを見て正常と判断する

複数インスタンスの平均値では、1台だけ異常な状態が隠れることがあります。利用可能なメトリックはInstanceで分割して確認します。

Http Server Errorsだけで502・503を判断する

Http Server Errorsは5xx全体の件数です。502と503の内訳はログや診断情報で確認します。

根拠なくプランを上げる

スケール変更には費用が伴います。CPU、メモリ、キュー、Requestsとの相関を確認し、変更後も改善効果を測定します。

Kuduの画面をそのまま共有する

Kuduには接続文字列、環境変数、アプリ設定などが表示される場合があります。秘密鍵、トークン、パスワード、個人情報を含む画像は共有しないでください。

再発に備えて監視を設定する

原因を解消した後は、次の障害で同じ調査を繰り返さないように監視を整備します。

設定候補は次のとおりです。

1. Http Server Errorsの増加を通知する
2. Response Timeの悪化を通知する
3. App ServiceプランのCPU・メモリ・HTTPキューを監視する
4. Service Healthアラートを設定する
5. Application Insightsで例外と依存先の失敗を記録する
6. デプロイ日時とバージョンを追跡できるようにする
7. 障害対応手順書に確認順序を残す

Service Healthでは、自分の環境に影響する障害やメンテナンスを通知するアラートを設定できます。([Microsoft Learn][2])

502・503が出たときの確認順序

Azure App Serviceで502・503が発生したら、次の順番で切り分けます。

1. 発生時刻、URL、影響範囲を記録する
2. Service HealthでAzure側の障害を確認する
3. 同じ時間帯のHttp5xx、Requests、Response Time、CPU Time、メモリを比較する
4. App ServiceプランのCPU、メモリ、HTTPキューを確認する
5. Diagnose and solve problemsで異常や変更履歴を調べる
6. Kuduで例外、ログ、長時間処理、プロセス状態を確認する
7. 必要な証拠を保存してから再起動する
8. 再起動後も同じメトリックを監視し、再発を確認する
9. 測定結果を根拠に、コード修正、設定変更、スケール、プラン分離を選ぶ

重要なのは、502・503という結果だけを見るのではなく、発生時刻を軸に、Service Health、アプリメトリック、プランメトリック、ログを同じ時間帯で関連付けることです。これにより、Azure側の障害、アプリの例外、長時間処理、リソース不足を効率よく切り分けられます。
[1]: https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/troubleshoot-http-502-http-503 “Troubleshoot “HTTP 502” and “HTTP 503″ errors – Azure | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/azure/service-health/service-health-overview “What is Azure Service Health? – Azure Service Health | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/azure/azure-monitor/reference/supported-metrics/microsoft-web-sites-metrics “Supported metrics – Microsoft.Web/sites – Azure Monitor | Microsoft Learn”
[4]: https://learn.microsoft.com/en-us/azure/app-service/overview-diagnostics “Troubleshoot with Diagnostics – Azure App Service | Microsoft Learn”
[5]: https://learn.microsoft.com/en-us/azure/azure-monitor/reference/supported-metrics/microsoft-web-serverfarms-metrics?utm_source=chatgpt.com “Supported metrics – Microsoft.Web/serverfarms”
[6]: https://learn.microsoft.com/en-us/azure/app-service/overview-hosting-plans “Azure App Service Plans – Azure App Service | Microsoft Learn”
[7]: https://learn.microsoft.com/en-us/azure/app-service/resources-kudu “Kudu service overview – Azure App Service | Microsoft Learn”