Azure App Service は非常に便利なのですが、アプリケーションに何らかの問題があった場合には VM などと比べると調査方法が若干特殊です。今は公式の診断機能がかなり強化されていますが、逆に多すぎて困ることもあるのでまとめました。
恐らく歴史的経緯によって機能がダブっている部分もあるので、その辺りについても書きました。
用意されているツール
Diagnose and solve problems を使う
何が起こっているのかわかっていない場合は、とりあえずこの自動診断機能を使えば大体の理由は判別できます。おおよその見当がついている場合は、該当するボタンを押せば確認出来ます。
帝国兵殿が Qiita に詳しい使い方を書いてくださっているので、こっちを読めば完璧です。
自動診断は非常に優秀ですが、CPU やメモリを大量に消費していることはわかっても、何故かという部分まではサポートしてくれないので、これから先は別のツールを使うことになります。
ASP.NET アプリケーションに関しては、診断系が他のプラットフォームよりも強化されています。App Service Team のブログにて紹介されています。
UI が用意されているのと、ブラウザで完結するのでお手軽に利用できます。
Support Tools を使う
Diagnose and solve problems のサイドバーに Support Tools が用意されているので、そこから個別にメトリクスを確認したり、アプリケーションのイベントログを表示できます。
Diagnostics as a Service の操作も行えます。ちなみに Diagnose and solve problems のダンプ取得などは DaaS を使っているので、Always On が必要になります。
Basic 以上のインスタンスが必要になるので、その点だけは注意なのと DaaS は WebJob として動き続けるので、プロセスを落としたりしないようにしましょう。
他にも、スケールアウトしているインスタンスのうち 1 台だけ異常な状態になった場合は、Advanced Application restart を使って特定のインスタンスだけを再起動することが出来ます。
根本的な解決ではないですが、問題を軽減することが可能です。他にも Mitigate から Auto Heal の設定が行えますが、それは後で紹介します。
Kudu を使う
最後の砦として、サンドボックス環境で許されている操作なら大体行えるインターフェースとして Kudu があります。もはや説明は不要感ありますが、改めて簡単に紹介を。
Debug Console を使うと、App Service にプリインストールされている診断用ツールを使えます。
ツールを直接使うと、用意されている全てのオプションが扱えるので、他のツールを使った場合には不可能なオプションの設定が出来ます。当然ながらコンソールで動くものに限ります。
Application Insights を使う
継続的にアプリケーションの問題を収集するためには Application Insights を使います。
通常ならメトリクスとエラー周りのみですが、Profiler と Snapshot Debugger をインストールするとパフォーマンスデータとクラッシュ時のメモリダンプを自動で取得してくれます。
https://azure.microsoft.com/en-us/blog/application-insights-profiler/
両方ともダウンロードすれば Visual Studio で表示できるので、デプロイしたコードとバージョンを合わせておけば便利に使えます。
問題が発生すれば自動で収集してくれるので、特に考えることなく使えます。
パフォーマンス問題の場合
プロファイリングを実行する
Kudu を使うと IIS の ETW 付きのプロファイリングを実行出来ます。取得したデータはダウンロードして PerfView で確認出来るようになっています。
警告にもあるように、パフォーマンスへの影響が大きいのでカジュアルに実行は難しいでしょう。
実際にプロファイリングを実行して、原因を特定する例が去年のアドベントカレンダーで紹介されています。例では PHP ですが、ASP.NET でも同様にトレースできるはずです。
[Advent Calendar 2017 Day18] Azure Web Apps パフォーマンスチューニング | Microsoft Docs
面倒な場合は Visual Studio からリモートでプロファイリングを実行出来るので、こっちを使ってみるのも良いかもしれません。
https://azure.microsoft.com/en-us/blog/remote-profiling-support-in-azure-app-service/
結果は Visual Studio で確認出来るので、使い慣れている場合はこっちの方が分かりやすそうです。
メモリダンプを取得する
Diagnose and solve problems を使うと、DaaS 経由でダンプを取得し Debug Diag で解析した結果をダウンロード出来るので、誰でも簡単に解析できるようになっています。
これだけでは不足する場合には、Kudu からミニダンプとフルダンプの両方を取得可能です。
分かりにくいですが、Process Explorer を右クリックするとメニューが表示されるので、そこからダンプを取りつつダウンロードまで行えます。
ダウンロードしたダンプは Visual Studio や dotMemory に突っ込むもよし、WinDbg を使ってハードに扱っても良しなので、根本的な問題解決に役立つかと。
少し手間がかかる方法ではありますが、ProcDump を直接使うと例外フィルターを設定できるので、特定の例外が発生したタイミングでダンプを取るという方法も行えます。
Azure App Service: Generating memory dumps on first chance exception using Procdump | Microsoft Docs
ちなみに ProcDump を使って手動でダンプを取る場合には、SMB でマウントされていない場所にダンプを書き出した方が、遥かに高速で取得できるのでお勧めです。
特に Premium V2 などを使っていると、ローカルが SSD になるのでさらに顕著でしょう。
Auto Heal を有効にする
根本解決に時間がかかりそうなので、一時的に問題の発生を抑えたいという場合には、大体は再起動が有効です。そんな場合には Auto Heal を有効化して、一定の条件で自動的に再起動するように設定します。
リクエスト数や CPU、メモリ使用量を条件に指定出来るので、適切に設定すれば問題の発生を上手く抑えられるでしょう。とはいえ、あくまでも緩和策でしかありません。
最近は Proactive Auto Heal がデフォルトで有効になっているので、逆に予期せぬタイミングで再起動が発生して障害になることもあるかも知れません。
その場合は設定を追加すればオプトアウトが行えるので、必要に応じて設定を追加しましょう。
これで App Service で使える診断周りの機能について大体まとめた気がします。後から足りないと気が付いたら足すかも知れません。
