はじめに
本記事は、Microsoft Azure Tech Advent Calendar 2021 の投稿です。
App Service (Web Apps, Azure Functions) ではアプリケーションがホストされ実行しておりますが、何かしらの問題が発生した場合にはどのような事象であるか大体の検討をつけて調査を行う必要があります。Web サーバのログやアプリケーションのログ、メモリダンプを取得するといった方法をいきなり実施するのは、事象に対しての概要が分からないまま進めてしまい、見当違いで多くの時間を問題解決時間に要してしまう可能性があります。まさに木を見て森を見ずに現象が発生しているかもしれません。
発生した問題に対して、まずは概要をつかむところから始めていき、細部の情報まで見ていこうということで、App Service (Web Apps, Azure Functions) の Azure ポータル画面では、問題の診断と解決 (Diagnose and solve problems) と呼ばれる機能が提供されております。
以下の記事にて、問題の診断と解決のツールは紹介されており、こちらのツールはさらなるアップデートがされておりますため、紹介記事のアップデートとして共有していきます。
問題の診断と解決 (Diagnose and solve problems) とは
公式の公開情報にて、問題の診断と解決のツールの紹介がされております。Web アプリケーションにてある期間にて正常に動作しなくなり、突然 HTTP Status 5xx 系のエラーが発生したりするなど運用をしていくと様々な問題が発生します。なぜそのような事象が発生したのかをアプリケーションログや OS などのサーバのログから追って確認する必要がありますが、サーバなどのアプリケーション以下に存在するリソースの状況を App Service にて確認するのは中々厳しい状況です。App Service は PaaS 製品であり、Web アプリケーション配下の VM (Virtual Machine) は Microsoft によって管理されているため、Web アプリケーションが再起動したというのはログから辿ることは難しいため、問題の診断と解決 を紹介します。
問題の診断と解決 ツールの登場により、App Service のアプリケーション配下に存在するリソースの状態を Azure ポータル画面にて確認することが出来ます。問題の診断と解決 の機能は Windows 版だけではなく Linux 版や App Service Environment, Azure Functions にも対応しています。
2021 年 12 月現在の App Service の Azure Portal にある問題の診断と解決を確認すると大きく分けて 6 種類のトラブルシューティングカテゴリが存在しています。個人的によく利用しているカテゴリをしては、Availability and Performance であり、どのような問題が App Service 側で検知しているのかを眺めるのに使ってます。
- Availability and Performance
- Configuration and Management
- SSL and Domains
- Risk Assessments
- Navigator (Preview)
- Diagnostic Tools
App Service のインフラ観点での確認方法
Web アプリケーションもしくは App Service の VM 配下のどちらに問題が発生しているか切り分けの作業を実施する際は、Availability and Performance
内の以下の 2 つの機能が見極める材料としては有効かと考えてます。
ウェブアプリダウン
正常な App Service の状態のウェブアプリダウンのスクリーンショットとなりますが、App Availability (Web アプリケーションの可用性) と Platform Availability (App Service プラットフォームの可用性) が表示されどちらも 100 % となっていること確認することが出来ます。アプリのパフォーマンスと可用性のトラブルシューティングの下にあるグラフは時系列に 2 つのそれぞれの可用性をグラフが時系列で表しており、詳細に確認したい開始時刻から終了時刻までドラッグアンドドロップをすると、Successful Check の画面にて該当時間帯の状態が各項目にて詳細に表示されます。
例えば、当該の時間帯にてコールドスタート（Web アプリケーションが正常に起動しない）事象が App Service 側で検知された場合は以下のような画面が出力されます。コールドスタートした際に、App Service がハングしたプロセスのスタックトレース（プログラムにて例外処理が発生し直前のメソッドの呼び出しが記録される）が取得され、Azure ポータル画面にて確認することが出来ます。
Web アプリの再起動
App Service 内の Web アプリケーションが突然再起動してしまった場合は、Web アプリの再起動の機能を利用することで App Service のプラットフォーム内にて発生した事象もしくはユーザによる手動での再起動が行われたのかを確認することが出来ます。
上記のスクリーンショットでは、App Service のプラットフォームにて発生した事象が記録されております。こちらの 2 つの事象はどちらも App Service のプラットフォーム側のパフォーマンスやセキュリティ向上などのアップグレード作業が行われ、それに伴い Web アプリケーションの再起動が実施されます。Web アプリケーションが実行している App Service のプラットフォームは複数のコンポーネントが組み合わさって構成されているため、コンポーネントごとにアップグレード作業が行われます。
プラットフォーム（インフラストラクチャーのアップグレード）
Web アプリケーションが実行されているプラットフォームインフラストラクチャーとなり、Web Worker と呼ばれるコンポーネントに対してのアップグレード作業が実行されます。
Web Worker の個数は App Service プランにて定義されており、2 台へスケールアウトすることができますが、同時刻にアップグレード作業が実行される可能性もあるため、Web アプリケーションを複数のリージョンへデプロイすることが問題の診断と解決にて提案されております。
プラットフォーム（ファイルサーバのアップグレード）
HTML、js ファイル、画像、コードファイルなどのコンテンツやアプリケーションが機能するためのコンテンツを保持するためのストレージであるファイルサーバと呼ばれるコンポーネントに対してのアップグレード作業が実行されます。使用していた App Service は Windows 版であったため問題の診断と解決では、ローカルキャッシュを有効にすることで Web アプリケーションの可用性に影響を及ぼす可能性も低くなります。
https://qiita.com/mym/items/1d364c0251daf88d417d#file-servers
ユーザによる再起動
Azure ポータル等でユーザによる再起動が実行されると以下のスクリーンショットな情報として検知され出力されます。
まとめ
Web アプリケーションもしくは App Service で発生した問題はどちらであるか切り分けを確認する作業として、App Service で提供している問題の診断と解決は有効であると考えてます。突然 Web アプリケーションが再起動した際には、ウェブアプリダウンや Web アプリの再起動を利用して App Service のプラットフォームにて問題が発生していないかをセルフチェックすることが可能となります。