Azure App Service での HTTP エラー "502 無効なゲートウェイ" と "503 サービス利用不可" のトラブルシューティングTroubleshoot HTTP errors of "502 bad gateway" and "503 service unavailable" in Azure App Service

"502 無効なゲートウェイ" と "503 サービス利用不可" は、Azure App Service でホストされているアプリで発生する一般的なエラーです。"502 bad gateway" and "503 service unavailable" are common errors in your app hosted in Azure App Service. この記事は、これらのエラーのトラブルシューティングを行うために役立ちます。This article helps you troubleshoot these errors.

この記事についてさらにヘルプが必要な場合は、いつでも MSDN の Azure フォーラムとスタック オーバーフロー フォーラムで Azure エキスパートに問い合わせることができます。If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and the Stack Overflow forums. または、Azure サポート インシデントを送信できます。Alternatively, you can also file an Azure support incident. その場合は、 Azure サポートのサイト に移動して、 [サポートの要求] をクリックします。Go to the Azure Support site and click on Get Support.

症状Symptom

ブラウザーでアプリにアクセスすると、"502 無効なゲートウェイ" または "503 サービス利用不可" という HTTP エラーが返される。When you browse to the app, it returns a HTTP "502 Bad Gateway" error or a HTTP "503 Service Unavailable" error.

原因Cause

この症状は多くの場合、アプリケーション レベルの問題が原因で発生します。その例を次に示します。This problem is often caused by application level issues, such as:

  • 要求に時間がかかっているrequests taking a long time
  • アプリケーションのメモリ/CPU 使用率が高いapplication using high memory/CPU
  • 例外が発生してアプリケーションがクラッシュするapplication crashing due to an exception.

"502 無効なゲートウェイ" エラーと "503 サービス利用不可" エラーを解決するトラブルシューティング手順Troubleshooting steps to solve "502 bad gateway" and "503 service unavailable" errors

トラブルシューティングは、大きく次の 3 つのタスクに分けられます。この 3 つのタスクを上から順に行います。Troubleshooting can be divided into three distinct tasks, in sequential order:

  1. アプリケーションの動作を観察、監視するObserve and monitor application behavior
  2. データを収集するCollect data
  3. 問題を緩和するMitigate the issue

App Service ではステップごとにさまざまなオプションを使用できます。App Service gives you various options at each step.

1.アプリケーションの動作を観察、監視する1. Observe and monitor application behavior

サービス正常性を追跡するTrack Service health

Microsoft Azure は、サービスの中断やパフォーマンスの低下があるたびに、毎回公表します。Microsoft Azure publicizes each time there is a service interruption or performance degradation. サービスの正常性は、Azure Portal で追跡できます。You can track the health of the service on the Azure Portal. 詳細については、サービスの正常性の追跡に関するページを参照してください。For more information, see Track service health.

アプリを監視するMonitor your app

Web アプリに問題が発生しているかどうかは、アプリを監視することによって確認することができます。This option enables you to find out if your application is having any issues. アプリのブレードで [要求とエラー] タイルをクリックします。In your app’s blade, click the Requests and errors tile. [メトリック] ブレードには、追加できるすべてのメトリックが表示されます。The Metric blade will show you all the metrics you can add.

アプリに関しては、次のメトリックを監視するようお勧めします。Some of the metrics that you might want to monitor for your app are

  • 平均メモリ ワーキング セットAverage memory working set
  • 平均応答時間Average response time
  • CPU 時間CPU time
  • メモリ ワーキング セットMemory working set
  • RequestsRequests

HTTP エラー "502 無効なゲートウェイ" と "503 サービス利用不可" の解決に向けてアプリを監視する

詳細については、次を参照してください。For more information, see:

2.データを収集する2. Collect data

診断ツールの使用Use the diagnostics tool

App Service には、アプリのトラブルシューティングに役立つ構成不要のインテリジェントな対話型のエクスペリエンスが用意されています。App Service provides an intelligent and interactive experience to help you troubleshoot your app with no configuration required. アプリに問題が発生した場合、診断ツールは問題点を指摘し、その問題のトラブルシューティングをすばやく簡単に行って解決するための適切な情報へとユーザーをガイドします。When you do run into issues with your app, the diagnostics tool will point out what’s wrong to guide you to the right information to more easily and quickly troubleshoot and resolve the issue.

App Service 診断にアクセスするには、Azure Portal の App Service アプリまたは App Service 環境に移動します。To access App Service diagnostics, navigate to your App Service app or App Service Environment in the Azure portal. 左側のナビゲーションで、 [問題の診断と解決] をクリックします。In the left navigation, click on Diagnose and solve problems.

Kudu デバッグ コンソールを使用するUse the Kudu Debug Console

App Service には、ファイルのデバッグ、調査、アップロード用のデバッグ コンソールのほか、ご利用の環境についての情報を入手するための JSON エンドポイントが用意されています。App Service comes with a debug console that you can use for debugging, exploring, uploading files, as well as JSON endpoints for getting information about your environment. このコンソールは、アプリの Kudu コンソールまたは SCM ダッシュボードと呼ばれます。This is called the Kudu Console or the SCM Dashboard for your app.

ダッシュボードには、https://<アプリ名>.scm.azurewebsites.net/ リンクからアクセスできます。You can access this dashboard by going to the link https://<Your app name>.scm.azurewebsites.net/.

Kudu には次のような機能があります。Some of the things that Kudu provides are:

  • アプリケーションの環境設定environment settings for your application
  • ログ ストリームlog stream
  • 診断ダンプdiagnostic dump
  • デバッグ コンソール (Powershell のコマンドレットや基本的な DOS コマンドを実行可能)debug console in which you can run Powershell cmdlets and basic DOS commands.

Kudu にはもう 1 つ便利な機能があり、アプリケーションからファーストチャンス例外がスローされた場合に、Kudu と SysInternals ツール Procdump を使用してメモリ ダンプを作成することができます。Another useful feature of Kudu is that, in case your application is throwing first-chance exceptions, you can use Kudu and the SysInternals tool Procdump to create memory dumps. このメモリ ダンプはプロセスのスナップショットです。アプリに関して、通常より複雑な問題をトラブルシューティングできる場合も少なくありません。These memory dumps are snapshots of the process and can often help you troubleshoot more complicated issues with your app.

Kudu で利用できる機能の詳細については、 知っておくべき Azure Websites のオンライン ツールに関するページを参照してください。For more information on features available in Kudu, see Azure Websites online tools you should know about.

3.問題を緩和する3. Mitigate the issue

アプリをスケーリングするScale the app

Azure App Service では、アプリケーションが実行されるスケールを調整することによって、パフォーマンスとスループットを高めることができます。In Azure App Service, for increased performance and throughput, you can adjust the scale at which you are running your application. アプリのスケール アップには、2 つの関連する措置が伴います。1 つは、App Service プランの価格レベルを引き上げること、もう 1 つは、価格レベルを引き上げた後に特定の設定を構成することです。Scaling up an app involves two related actions: changing your App Service plan to a higher pricing tier, and configuring certain settings after you have switched to the higher pricing tier.

スケーリングの詳細については、Azure App Service でのアプリのスケーリングに関する記事を参照してください。For more information on scaling, see Scale an app in Azure App Service.

加えて、アプリケーションを複数のインスタンスで実行することもできます。Additionally, you can choose to run your application on more than one instance . 処理能力がアップするだけでなく、ある程度の耐障害性を確保することができます。This not only provides you with more processing capability, but also gives you some amount of fault tolerance. この場合、1 つのインスタンスでプロセスがダウンしても、他のインスタンスが要求の処理を続行します。If the process goes down on one instance, the other instance will still continue serving requests.

スケーリングは、[手動] または [自動] に設定することができます。You can set the scaling to be Manual or Automatic.

AutoHeal を使用するUse AutoHeal

AutoHeal は、選択された設定 (構成の変更、要求、メモリに基づく制限、要求の実行に必要な時間など) に従って、アプリのワーカー プロセスをリサイクルします。AutoHeal recycles the worker process for your app based on settings you choose (like configuration changes, requests, memory-based limits, or the time needed to execute a request). ほとんどの場合、問題を回復するための一番の近道は、プロセスをリサイクルすることです。Most of the time, recycle the process is the fastest way to recover from a problem. アプリはいつでも、Azure Portal 内から直接、再起動できますが、AutoHeal はユーザーの介入なしでそれを自動的に実行します。Though you can always restart the app from directly within the Azure Portal, AutoHeal will do it automatically for you. 必要な作業は、アプリのルート web.config にいくつかのトリガーを追加することだけです。All you need to do is add some triggers in the root web.config for your app. アプリケーションが .NET アプリ以外でも、これらの設定は同じように作用します。Note that these settings would work in the same way even if your application is not a .NET one.

詳細については、 Azure Web Sites の自動復旧に関するページを参照してください。For more information, see Auto-Healing Azure Web Sites.

アプリを再起動するRestart the app

1 回限りの問題であれば、通常これが最も簡単な復旧方法です。This is often the simplest way to recover from one-time issues. アプリを停止または再起動するためのオプションは、Azure Portal のアプリ ブレードにあります。On the Azure Portal, on your app’s blade, you have the options to stop or restart your app.

HTTP エラー "502 無効なゲートウェイ" と "503 サービス利用不可" を解決するためにアプリを再起動する

アプリの管理には、Azure PowerShell を使用することもできます。You can also manage your app using Azure Powershell. 詳細については、 リソース マネージャーでの Azure PowerShell の使用をご覧ください。For more information, see Using Azure PowerShell with Azure Resource Manager.