Azure App Service でのアプリのパフォーマンス低下に関する問題のトラブルシューティング

この記事は、Azure App Service でのアプリのパフォーマンス低下に関する問題のトラブルシューティングに役立ちます。

この記事の任意の時点でさらにサポートが必要な場合は、 Azure コミュニティ サポートの Azure エキスパートにお問い合わせください。 または、Azure サポート インシデントを送信できます。 Azure サポートに移動し、[サポート チケットの送信] を選択します。

症状

アプリを参照すると、ページの読み込みが遅くなり、タイムアウトすることがあります。

原因

この症状は多くの場合、アプリケーション レベルの問題が原因で発生します。その例を次に示します。

• ネットワーク要求に時間がかかる
• 非効率的なアプリケーション コードまたはデータベース クエリ
• 高メモリ/CPU を使用するアプリケーション
• 例外が原因でアプリケーションがクラッシュする

トラブルシューティングの手順

トラブルシューティングは、大きく次の 3 つのタスクに分けられます。この 3 つのタスクを上から順に行います。

1. アプリケーションの動作を観察、監視する
2. データを収集する
3. 問題を緩和する

App Service ではステップごとにさまざまなオプションを使用できます。

アプリケーションの動作を観察して監視する

サービスの正常性を追跡する

Azure では、各サービスの中断またはパフォーマンスの低下が公開されます。 サービスの正常性は 、Azure portal で追跡できます。 詳細については、「 Azure portal を使用してサービス正常性通知を表示する」を参照してください。

アプリを監視する

Azure portal の監視ツールを使用して、アプリケーションに問題があるかどうかを確認できます。 サイドバー メニューの [ 監視 ] で、[ メトリック] を選択します。 [ メトリック ] ドロップダウン メニューには、追加できるすべてのメトリックが表示されます。

アプリを監視するメトリックには、次のようなものがあります。

• 平均メモリ ワーキング セット
• CPU 時間
• メモリ ワーキング セット
• リクエスト
• 応答時間

詳細については、次を参照してください。

• Azure App Service のクォータとメトリック
• アラート通知を受け取る

Web エンドポイントの状態を監視する

アプリが Standard 価格レベルで実行されている場合、App Service では、3 つの地理的な場所から 2 つのエンドポイントを監視できます。

エンドポイント監視では、地理的に分散した場所から Web URL の応答時間とアップタイムをテストする Web テストを構成します。 テストでは、Web URL に対して HTTP GET 操作を実行して、各場所からの応答時間とアップタイムを決定します。 構成された各場所では、テストを 5 分ごとに実行します。

アップタイムは HTTP 応答コードを使用して監視され、応答時間はミリ秒単位で測定されます。 HTTP 応答コードが 400 以上である場合、または、応答に 30 秒以上かかる場合、監視テストは失敗します。 すべての指定した場所から監視テストが成功した場合、エンドポイントは利用可能と見なされます。

これを設定するには、 Azure App Service のクォータとメトリックに関するページを参照してください。

拡張機能を使用したアプリケーション パフォーマンスの監視

"サイト拡張機能" を使用して、アプリケーションのパフォーマンスを監視することもできます。

各 App Service アプリには、サイト拡張機能として展開された強力なツール セットを使用できる拡張可能な管理エンドポイントが用意されています。 次のような拡張機能があります。

• GitHub Codespaces などのソース コード エディター。
• アプリに接続されている MySQL データベースのような、接続されたリソース用の管理ツール。

Azure Application Insights というパフォーマンス監視を目的としたサイト拡張機能も使用できます。 Application Insights を使用するには、SDK でコードをリビルドします。 追加データへのアクセスを提供する拡張機能をインストールすることもできます。 SDK では、アプリの使用状況とパフォーマンスをさらに詳細に監視するコードを記述できます。 詳細については、「 Application Insights の概要 - OpenTelemetry の可観測性」を参照してください。

データの収集

App Service は、Web サーバーと Web アプリケーションの両方のログ情報を診断する機能を備えています。 情報は Web サーバー診断とアプリケーション診断に分けられます。

Web サーバー診断を有効にする

次の種類のログを有効または無効にできます。

• 詳細なエラー ログ: エラーを示す HTTP 状態コードの詳細なエラー情報 (状態コード 400 以上)。 これには、サーバーがエラー コードを返した理由を判断するのに役立つ情報が含まれている場合があります。
• 失敗した要求トレース: 要求の処理に使用される IIS コンポーネントのトレースや各コンポーネントにかかった時間など、失敗した要求に関する詳細情報。 これは、アプリのパフォーマンスを向上させたり、特定の HTTP エラーの原因を特定したりする場合に便利です。
• Web サーバー ログ: W3C 拡張ログ ファイル形式を使用した HTTP トランザクションに関する情報。 これは、サイトで処理された要求の数や特定の IP アドレスからの要求の数などのアプリの全体的なメトリックを特定するときに役立ちます。

アプリケーション診断を有効にする

App Service からアプリケーションのパフォーマンス データを収集するためのオプションは、いくつかあります。Visual Studio からライブでアプリケーションをプロファイルしたり、より多くの情報とトレースをログ記録するようにアプリケーション コードを変更したりできます。 アプリケーションへのアクセスの量と、監視ツールでの観察結果に基づいて、オプションを選択できます。

Application Insights Profiler を使用する

Application Insights Profiler を有効にすると、詳細なパフォーマンス トレースのキャプチャを開始することができます。 問題を調査する必要がある過去 5 日間までキャプチャされたトレースにアクセスできます。 Azure portal でアプリの Application Insights リソースにアクセスできる場合は、このオプションを選択することができます。

Application Insights Profiler では、各 Web 呼び出しの応答時間に関する統計情報と、応答が遅くなる原因となったコード行を示すトレースが提供されます。 一部のコードがパフォーマンスの高い方法で記述されていないため、App Service アプリが遅くなることがあります。 例としては、並列で実行できる順次コードや、予期しないデータベースのロック競合などがあります。 コード内のこれらのボトルネックを削除すると、アプリのパフォーマンスが向上しますが、詳細なトレースとログを設定せずに検出するのは困難です。 Application Insights Profiler によって収集されたトレースは、アプリケーションの速度低下に繋がったコード行を特定し、App Service アプリのこの問題を解決するために役立ちます。

詳細については、「 Windows で Azure App Service アプリの .NET Profiler を有効にする」を参照してください。

診断トレースを手動でセットアップする

Web アプリケーションのソース コードにアクセスできる場合は、アプリケーション診断を使用して、Web アプリケーションによって生成された情報をキャプチャできます。 ASP.NET アプリケーションは、 System.Diagnostics.Trace クラスを使用してアプリケーション診断ログに情報を記録できます。 ただし、コードを変更し、アプリケーションを再デプロイする必要があります。 この方法は、アプリをテスト環境で実行している場合にお勧めします。

ログ記録用にアプリケーションを構成する方法の詳細については、「 Azure App Service でアプリの診断ログを有効にする」を参照してください。

診断ツールの使用

App Service には、アプリのトラブルシューティングに役立つ構成不要のインテリジェントな対話型のエクスペリエンスが用意されています。 アプリで問題が発生した場合、診断ツールは、問題をより簡単かつ迅速にトラブルシューティングして解決するために適切な情報を導くために何が問題であるかを指摘します。

App Service 診断にアクセスするには、Azure Portal の App Service アプリまたは App Service Environment に移動します。 サイドバー メニューで、[問題の 診断と解決] を選択します。

Kudu デバッグ コンソールを使用する

App Service には、ファイルのデバッグ、調査、アップロード用のデバッグ コンソールのほか、ご利用の環境についての情報を入手するための JSON エンドポイントが用意されています。 このコンソールは、アプリの "Kudu コンソール" または "SCM ダッシュボード" と呼ばれます。

このダッシュボードにアクセスするには、Kudu サイトに移動します。

Kudu には次のような機能があります。

• アプリケーションの環境設定
• ログ ストリーム
• 診断ダンプ
• PowerShell コマンドレットと基本的な DOS コマンドを実行できるデバッグ コンソール

Kudu にはもう 1 つ便利な機能があり、アプリケーションからファーストチャンス例外がスローされた場合に、Kudu と SysInternals ツール Procdump を使用してメモリ ダンプを作成することができます。 このメモリ ダンプはプロセスのスナップショットです。アプリに関して、通常より複雑な問題をトラブルシューティングできる場合も少なくありません。

Kudu で使用できる機能の詳細については、 知っておくべき Windows Azure Websites オンライン ツールを参照してください。

問題を軽減する

アプリをスケーリングする

App Service では、パフォーマンスとスループットを向上させるために、アプリケーションを実行するスケールを調整できます。 アプリのスケールアップには、App Service プランをより高い価格レベルに変更し、より高い価格レベルに切り替えた後に特定の設定を構成する 2 つの関連アクションが含まれます。

スケーリングの詳細については、Azure App Service でのアプリのスケーリングに関する記事を参照してください。

さらに、アプリケーションを複数のインスタンスで実行することもできます。 スケールアウトすると、処理能力が向上するだけでなく、ある程度のフォールト トレランスを確保することができます。 1 つのインスタンスでプロセスがダウンしても、他のインスタンスが要求の処理を続行します。

スケーリングは手動または自動に設定できます。

自動修復を使用する

自動修復では、構成の変更、要求、メモリベースの制限、要求の実行に必要な時間など、選択した設定に基づいて、アプリのワーカー プロセスがリサイクルされます。 ほとんどの場合、プロセスをリサイクルすることは、問題から復旧するための最速の方法です。 アプリは常にAzureポータル内から直接再起動できますが、「自動修復」により、自動的にそれが実行されます。 必要な作業は、アプリのルート web.config にいくつかのトリガーを追加することだけです。 これらの設定は、アプリケーションが .NET アプリでない場合でも同じように動作します。

詳細については、 Azure Web Sites の自動復旧に関するページを参照してください。

アプリを再起動する

1 回限りの問題であれば、通常は再起動が最も簡単な復旧方法です。 Azure portal には、アプリを停止または再起動するためのオプションがあります。

アプリの管理には、Azure PowerShell を使用することもできます。 詳細については、「Azure PowerShellを使用した Azure リソースの管理」を参照してください。

関連コンテンツ

• Azure App Service での断続的な送信接続エラーのトラブルシューティング
• チュートリアル: ロード テストを実行して Web アプリのパフォーマンスのボトルネックを特定する