Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問

この記事では、 Azure App Service の Web Apps 機能におけるアプリケーションの可用性、パフォーマンス、およびトラブルシューティングに関する一般的な質問に回答します。 このガイドを使用して、問題をすばやく解決し、アプリの信頼性を最適化します。

各種 App Service プランのクォータと制限に関する詳細情報はどこで得られますか?

クォータと制限については、「App Service の制限」を参照してください。

すべての Web アプリが停止した場合でも CPU/メモリ使用量を表示する App Service プラン

Azure アプリ サービスには、セキュリティ更新プログラム、SCM コンソールの可用性、アプリケーションの監視、認証、Web アプリのその他の多くの重要な機能など、いくつかのプラットフォーム操作と機能を処理する継続的なシステム プロセスが必要です。

実行中の Web アプリがない場合や、App Service プランに Web Apps が含まれている場合でも、App Service プランでシステム プロセスが実行されます。

プラットフォーム プロセスは最小限のリソース (CPU、メモリ、ディスク領域など) を消費するため、App Service プランの容量計画、監視、自動スケーリング トリガーの構成時にも同じ内容を考慮する必要があります。

アプリのパフォーマンスが遅い

アプリの低速なパフォーマンスには複数の要因が関与している可能性があります。 詳細なトラブルシューティング手順については、「Troubleshoot slow web app performance (Web アプリの低速なパフォーマンスのトラブルシューティング)」を参照してください。

CPU 使用率が高い場合のトラブルシューティング方法

CPU 使用量が多い一部のシナリオでは、アプリが実際により多くのコンピューティング リソースを必要としている可能性があります。 その場合は、アプリケーションが必要なすべてのリソースを取得できるように、より高いサービス階層へのスケーリングを検討してください。 その他の場合、CPU 使用量の多さは、不適切なループまたはコーディング方法によって発生している可能性があります。 CPU 使用量が増えている原因の調査は 2 つの部分からなるプロセスです。 最初にプロセス ダンプを作成し、次にプロセス ダンプを分析します。 詳細については、「Capture and analyze a dump file for high CPU consumption for Web Apps (Web アプリの増加した CPU 使用量のためのダンプ ファイルの取得と分析)」を参照してください。

メモリ消費量が多い場合のトラブルシューティング方法

メモリ使用量が多い一部のシナリオでは、アプリが実際により多くのコンピューティング リソースを必要としている可能性があります。 その場合は、アプリケーションが必要なすべてのリソースを取得できるように、より高いサービス階層へのスケーリングを検討してください。 その他の場合、コード内のバグがメモリ リークの原因になることがあります。 コーディングの手法では、メモリ消費量が増加する場合もあります。 メモリ使用量が多い原因の調査は 2 つの部分からなるプロセスです。 最初にプロセス ダンプを作成し、次にプロセス ダンプを分析します。 Azure サイト拡張機能ギャラリーのクラッシュ診断は、これらの手順の両方を効率的に実行できます。 詳細については、「Capture and analyze a dump file for intermittent high memory for Web Apps (Web アプリの断続的な増加したメモリ使用量のためのダンプ ファイルの取得と分析)」を参照してください。

PowerShell を使用して App Service Web アプリを自動化するにはどうすればよいですか?

PowerShell コマンドレットを使用すると、App Service Web アプリを管理および維持できます。 ブログの投稿「Automate web apps hosted in Azure App Service by using PowerShell (PowerShell を使用して Azure App Service でホストされた Web アプリを自動化する)」では、Azure Resource Manager ベースの PowerShell コマンドレットを使用して一般的なタスクを自動化する方法について説明しています。

Web アプリのトラブルシューティングを行うために情報を収集する必要がある

Web アプリのイベント ログを表示するには

1. Kudu の Web サイト (https://*yourwebsitename*.scm.azurewebsites.net) にサインインします。
2. メニューで、[デバッグ コンソール]>[CMD] を選択します。
3. LogFiles フォルダーを選びます。
4. イベント ログを表示するには、eventlog.xml の横にある鉛筆アイコンを選択します。
5. ログをダウンロードするには、PowerShell コマンドレット Save-AzureWebSiteLog -Name webappname を実行します。

Web アプリのユーザー モード メモリ ダンプをキャプチャするには

1. Kudu の Web サイト (https://*yourwebsitename*.scm.azurewebsites.net) にサインインします。
2. [プロセス エクスプローラー] メニューを選択します。
3. [w3wp.exe] プロセスまたは [WebJob] プロセスを右クリックします。
4. [Download Memory Dump] \(メモリ ダンプのダウンロード)>[Full Dump] \(完全ダンプ) を選択します。

Web アプリのプロセス レベルの情報を表示する方法

Web アプリのプロセス レベルの情報を表示するには、次の 2 つのオプションがあります。

• Azure portal で、次の操作を行います。
  1. Web アプリの [プロセス エクスプローラー] を開きます。
  2. 詳細を表示するには、[w3wp.exe] プロセスを選択します。
• Kudu コンソールで次の手順を実行します。
  1. Kudu の Web サイト (https://*yourwebsitename*.scm.azurewebsites.net) にサインインします。
  2. [プロセス エクスプローラー] メニューを選択します。
  3. [w3wp.exe] プロセスの [プロパティ] を選択します。

App Service のローカル キャッシュ機能を使用しているときに、Web アプリのフォルダー構造にログ ファイルが見つからない

App Service のローカル キャッシュ機能を使用する場合は、App Service インスタンスに対する LogFiles および Data フォルダーのフォルダー構造が影響を受けます。 ローカル キャッシュが使用されている場合は、LogFiles および Data フォルダーのストレージ内にサブフォルダが作成されます。 これらのサブフォルダは、"一意識別子" + タイムスタンプという名前付けパターンを使用します。 各サブフォルダは、Web アプリが実行されているか、または実行された VM インスタンスに対応します。

ローカル キャッシュを使用しているかどうかを確認するには、App Service アプリケーション設定 タブを確認します。ローカル キャッシュを使用している場合、アプリ設定 WEBSITE_LOCAL_CACHE_OPTION は Alwaysに設定されます。

失敗した要求トレースを有効にするには

失敗した要求トレースを有効にするには、次の手順に従います。

1. Azure Portal で、Web アプリに移動します。

2. [すべての設定]>[診断ログ] を選択します。

3. [失敗した要求トレース] の [On] \(オン) を選択します。

4. [保存] を選択します。

5. Web アプリ ブレードで [ツール] を選択します。

6. [Visual Studio Online] を選択します。

7. 設定が On でない場合は、 On を選択します。

8. [Go] \(移動) を選択します。

9. Web.config を選択します。

10. system.webServer で、次の構成を追加します (特定の URL をキャプチャするため)。

    <system.webServer>
    <tracing> <traceFailedRequests>
    <remove path="*api*" />
    <add path="*api*">
    <traceAreas>
    <add provider="ASP" verbosity="Verbose" />
    <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
    <add provider="ISAPI Extension" verbosity="Verbose" />
    <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
    </traceAreas>
    <failureDefinitions statusCodes="200-999" />
    </add> </traceFailedRequests>
    </tracing>
    

11. 低速なパフォーマンスの問題をトラブルシューティングするには、この構成を追加します (キャプチャ要求が 30 秒を超える場合)。

    <system.webServer>
    <tracing> <traceFailedRequests>
    <remove path="*" />
    <add path="*">
    <traceAreas> <add provider="ASP" verbosity="Verbose" />
    <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
    <add provider="ISAPI Extension" verbosity="Verbose" />
    <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
    </traceAreas>
    <failureDefinitions timeTaken="00:00:30" statusCodes="200-999" />
    </add> </traceFailedRequests>
    </tracing>
    

12. 失敗した要求トレースをダウンロードするには、ポータルで Web サイトに移動します。

13. [ツール]>[Kudu]>[Go] \(移動) を選択します。

14. メニューで、[デバッグ コンソール]>[CMD] を選択します。

15. LogFiles フォルダーを選択してから、W3SVC で始まる名前を持つフォルダーを選択します。

16. XML ファイルを表示するには、鉛筆アイコンを選択します。

パフォーマンスと回復性に関するその他の推奨事項

• Application Insights と Azure Monitor を使用して、テレメトリ、依存関係トレース、ライブ メトリックなど、App Service アプリの完全なスタック監視を行います。

• 可用性ゾーンをサポートするリージョンにデプロイする場合は、ゾーンの冗長性を有効にして、リージョンの障害時の回復性を強化することを検討してください。 詳細については、「Azure App Service の信頼性」を参照してください。

• App Service では、プラットフォームの信頼性を確保するために定期的なメンテナンスが行われます。 更新の動作 (特に App Service Environment v3) をより詳細に制御するには、アップグレードの優先設定を構成します。 詳細については、 Azure App Service のルーチン (計画済み) メンテナンスに関するページを参照してください。