AppService/Functionsのメンテンスを説明
あまりここまで書いてる情報はないと思います。公式ドキュメントにもここまで整理して書かれてるページがなかったので、攻めて書いてみました。ご参考いただければと思います。
メンテナンスが必要な理由
AppService/Functions などのAzureの各サービスは、たとえば日本のデータセンター(東日本・西日本)の中に、大量のサーバが設置されていて、そのサーバの仮想環境でアプリケーションなどが構築・実行されています。
Azureユーザは、AppService/Functions 上にアプリケーションをデプロイして実行されていますが、その実行されているサーバには他のユーザのアプリケーションもたくさん同時に実行されています。
複数ユーザが共有して利用されているサーバでは、ひっきりなしにリソースが新規作成されたり削除されたりアプリケーションが実行されたり停止されたりするので、サーバを正常状態に保って複数のアプリケーションを正常に動作し続けるためには、日常的なメンテンスが必要不可欠となります。さらに、Azure機能をAppService/Functions にアップグレードなども繁栄していく必要があります。
なので、Azureなどのクラウドサービスがメンテナンスを行うのは当然ということを、まず理解する必要があります。
メンテナンスの種類といつ行われてるか
メンテナンスは大きく２つに分けられます。予定されてるメンテナンスと、予定外のメンテナンスがあり、それぞれ実行されるタイミングが変わります。
予定しているメンテナンス
原則、深夜などのビジネスタイム外の時間帯にメンテナンスが行われます。たとえば、ANTのサーバに関する月１定期メンテナンスのようなものもあります。
予定外のメンテナンス
メンテナンスを行わないとAzure側のサーバが正常に動作できないと判断した際に実施される、予定外のメンテナンスは必要に応じて実施されるので、時間帯に関係なく実施されます。緊急メンテナンスというわけではなく、Azure 側としては想定しているメンテナンスです。
メンテナンスとは具体的に何が行われるのか
メンテナンスとひと言でいっても実際になにをやっているのでしょうか。代表的な例を紹介します。
設定ファイルの入れ替えなど
サーバ内の設定ファイルを入れ替えるだけのようなメンテナンスもあります。
Azure 環境のアップグレード
機能変更や障害改修されて、AppServiceなど自体が新しいバージョンにアップグレードされます。
定期メンテナンス
たとえば、ANTサーバの月１定期メンテナンスのようなものもあります。
実行中インスタンスの負荷が上がりインスタンスを切り替え
アプリケーションが実行中のインスタンスの負荷が上がったり、何かしらの問題が発生して、Azure側がこのままこのインスタンスでアプリ処理を継続することは困難だ！と判断した場合にAzure側の判断で別のインスタンスに切り替えます。
こういった動きも、メンテナンスの一つといえると思います。
メンテナンスが行われるとどうなるのか
場合によってはインスタンスが切り替わる
AppService/Functionsのアプリケーションはずっと同じインスタンス上で実行されているわけではありません。これは、どの料金プランを利用していても共通の話です。
更に、メンテナンス実施＝必ずインスタンスの切り替えが発生するわけではないので覚えておいてください。
アプリケーション実行中にインスタンス切り替えが起こるとどうなるのか？
まず前提としては、インスタンス上でアプリケーションが処理中に割り込んで、処理を中断させてメンテナンスが実施されてしまわないような仕組みになってます。要は、キリのいいところまで処理が終わるまで待ってくれます。
クライアント -> (インターネット) -> FrontEnd -> WebWorker(インスタンス)
という構成でインスタンスの切り替えが発生した際、アプリケーション自体は新しいインスタンスで起動し直されます。
また、原則直前のリクエスト処理が完了した後に新しいインスタンスへの切り替えを行っており、インスタンス切り替え完了後にFrontEndのリクエストキューに溜まっているリクエストをFrontEndから新しいインスタンスに転送されて、引き続きアプリケーションが実行されるという流れになります。
そもそも、なぜインスタンス切り替えが起きるのか？
Azure 側が想定しているケースとしては、以下に記載する『Azure 環境のアップグレード』の際に、アップグレードしようとしたインスタンスがアプリケーション実行中の場合は、"このインスタンスメンテナンスしたいから、別のインスタンスに移動して残りのリクエスト分を処理してね" という感じで、未処理のリクエスト処理がFrontEndに残っていても別のインスタンスに移動させられます。
Azure 側が想定していないケースとしては、実行中のインスタンスで問題が発生したら、Azure が勝手に他の正常なインスタンスに切り替えて、継続してアプリケーションが実行できるようにしてくれています。
どちらにしても、アプリケーションが正常に継続実行できるようにしてくれている仕組みなので、何でインスタンスの切り替えなんて発生するんだ！などと言わないようにしましょう。
アプリケーションの待ち時間（実行されていない時間）が少し発生したのはなぜ？
それはインスタンスの切り替えが発生して、新しいインスタンスで実行するまでの待ち時間が発生していた可能性があります。
そして、プラス料金発生せずに、インスタンス切り替えの待ち時間が発生しない仕組みがあります！
AppServiceプランを使用している場合、「AppService/Functions > 構成 > 全般設定タブ > 常時接続」
こちらの常時接続機能をONにすると、Azure側でインスタンスが常に起動されるようになるため、アプリケーション起動時の待ち時間などは発生しません。デフォルトではOFFになってしまっているので必要なら ON にしましょう。
SQLDatabase/StorageAccount 等がメンテナンス中の場合
(AppService/Functions自体のメンテナンスの話から少しずれますが、)アプリケーション処理からSQLDatabase/StorageAccount等にアクセスした際に、SQLDatabase/StorageAccount側でメンテナンスが発生していると 503 エラー等が発生したりします。AppService/Functions のアプリケーションとしてできることは、SQLDatabase/StorageAccount等にアクセスしている箇所に再送(リトライ)を組み込むことです。
SQLDatabase/StorageAccount等でメンテナンスが発生することも想定した実装していないと、リトライすればSQLDatabase/StorageAccount等へのアクセスが成功していたのに・・・ということになるともったいないことになります。リトライはとても重要なポイントです。
メンテンスが行われていたのか調べる方法
そもそも、メンテナンスの定義ってどう考えてますか？と聞かれたら答えられますでしょうか。
何をもってメンテナンスというのかは少し難しいという前提で、以下を読んでいただければと思います。
ポータル画面で確認
残念ながら「メンテナンスが発生していたかどうか」自体を確認する方法はありません。
どこかを見れば一目瞭然でわかるという情報はないのですが、いくつかの確認ポイントを紹介します。
問題の診断と解決で「Web App Restarted」を利用する
AppService/Functions の [問題の診断と解決] で「Web App Restarted」を検索すると、再起動の発生有無が確認できます。Azure 側がきっかけで再起動が発生していた＝メンテナンスが発生していた可能性が高い、ということがわかります。
問題の診断と解決で「CPU ...」を利用する
この画面で使用されていたインスタンスIDが確認できるので、インスタンス ID が変わっていたら、インスタンスの切り替えが発生していたということが確認できます。
Microsoft の Azure サポートに問い合わせる
有償サポート契約が必要になりますが、MicrosoftのAzureサポートに問い合わせると、該当時間帯にメンテナンスが行われていたかどうか教えてくれます。ただ、ユーザ自身が [問題の診断と解決] で確認できる情報と同じ調査結果がもらえるだけ、という可能性が高いと思っておいた方がいいと思います。
しかし、Azureサポート側もいつメンテナンスが行われていた。という情報をもっているわけではないらしいので、Azure側がきっかけでアプリケーションを再起動した、というログを確認した＝メンテナンスが発生していたのだろう。という推測をもとに答えるしかできないようです。
先述したとおり、AppService/Functionsの[問題の診断と解決]でも「この日時にAzure がきっかけでアプリケーション再起動された」「この日時にユーザきっかけでアプリケーション再起動された」というログが確認できるので、Azure側がきっかけでアプリケーション再起動された場合は、メンテナンスが発生していたのだろう。ということはAzureサポートに問い合わせなくてもユーザ側で確認することができますので、覚えておいてください。
メンテンスの事前通知されないのか・設定できるか
事前通知もされませんし、事前通知できるような設定も用意されてません。
そもそも事前通知がされたら、どうするつもりなのでしょうか。
事前通知を受けたら、一時的にAzure側にリクエストを送信しないように制御でもするのでしょうか。
どのようなメンテナンスが存在するのかの説明にも書いたように、アプリケーション動作に影響がないレベルのメンテナンスもたくさん存在します。じゃあアプリケーション動作に影響があるレベルのメンテナンスのときだけ事前通知してほしいとでも言うのでしょうか・・・。アプリケーション動作に影響があるかどうかの判断をAzure側でできるはずがありません。
メンテナンスの多くは数秒レベルで終わることも多いので、事前通知とかいうことを考えるよりは、Azure側へのリクエスト送信処理にリトライ処理を組み込む。という対策をしたり、クラウド上でアプリケーションの可用性を維持するために必要な考え方を学んで実践した方が、有効だと思います。オンプレのときは考えなくてよかったのに・・・という気持ちはわかりますが、クラウドのメリットは無数にあるのでクラウドの恩恵を受ける代わりに、メンテナンスの発生を受け入れるということは必要なことになります。
Azureが事前通知をしない理由・・・考えても仕方がありませんので書きませんし、上記した内容でわかっていただけたかなと思います。
その代わりに、メンテナンスの影響を軽減させる方法を紹介していきますので、是非ご検討ください。
メンテンスの対策
アプリケーションを継続実行させるための対策
Azure 有償サポートなどでも推奨されている対策を、４つ紹介します。
AppServiceプランのインスタンスを２つ以上で運用する
AppServiceプランを使用している場合の対策になります。
インスタンス数が１だとインスタンスが全く使えなくなる時間が発生する可能性が高まるため、インスタンスに影響するメンテナンスが発生した場合に、アプリケーションが遅延または一時停止してしまうことがあります。
容易な対策としては、スケールアウトしてインスタンス台数を２台以上にします。メンテナンスはスタンプ内のインスタンスを少しづつ順番にメンテナンスしていくので、インスタンスＡはメンテナンスで使えなくなってしまうがインスタンスＢはメンテナンスが行われていないため、メンテナンスによってアプリケーションが一時停止してしまう可能性を下げることができます。
ただ、これはあくまでも「メンテナンスの影響を受ける可能性を容易に下げられる対策」であることを理解いただければと思います。
docs.microsoft.com
アプリケーションを複数リージョンにデプロイして主と副で運用する
具体例でいうと、ひとつのAppServiceを「東日本リージョンにデプロイ」(プライマリリージョン)、もうひとつのAppServiceを「西日本リージョンにデプロイ」(セカンダリリージョン)をそれぞれ構築します。
そして、FrontDoorなどでアクティブなAppServiceをコントロールしてもらう方法です。
TrafficManagerで利用できないインスタンスを避ける
TrafficManagerは定期的にAppService/Functionsのエンドポイントを監視し、問題が発生したリージョンから、別のリージョンへリクエストをルーティングを行うことが可能です。
リトライ処理をアプリケーションに組み込む
これはAzure関係なく、アプリケーションに組み込まれているのが常識だと思います。基礎的で一番大事な対策です。
メンテナンスは短い時間で終わることが多いので、もう一度リトライすれば正常に進んだのに！ということが起きないように、リトライ処理を入れておくのは必須になります。
docs.microsoft.com
セーフティにアプリケーションをダウンさせる対策
アプリケーションが中途半端な状態で強制終了させられないよう、正常にアプリケーションを終了させるための仕組みです。
Graceful Shutdown に対応する
アプリケーションの整合性を維持するための仕組みです。 この仕組みまで入れると、デプロイを実行する際タイミングを意識せずに実行できたりします。
最後に・・・
AppService/Functionsに関するメンテナンスの情報を長々と書きましたがいかがでしたでしょうか。
Azure構成とアプリケーション実装を駆使して、メンテナンスの影響が最小限になるように構成してアプリケーションの可用性の維持を目指していきたいですね。
以上です。