AppService/Functionsのメンテンスを説明
あまりここまで書いてる情報はないと思います。公式ドキュメントにもここまで整理して書かれてるページがなかったので、かなり攻めて書いてみました。ご参考いただければと思います。
メンテナンスとは具体的に何が行われてるのか
インスタンスの切り替え
AppService/Functions のアプリケーションはずっと同じインスタンス上で実行されているわけではありません。
Azure 側が想定しているケース
以下に記載する『Azure 環境のアップグレード』を実行するときに、アップグレードしようとしたインスタンスが誰かにアプリケーション実行中の場合は、"このインスタンスメンテナンスしたいから、別のインスタンスに移動して残りのリクエスト分の処理してね" となって、未処理のリクエスト処理があっても別のインスタンスに移動させられます。
これは Azure としては、想定している動作ということになります。
Azure 側が想定していないケース
実行中のインスタンスに Azure 側も想定していなかった動作・問題が発生したら、Azure が勝手に他の正常なインスタンスに切り替えて、継続してアプリケーションが実行できるようにしています。予定しているメンテナンスによるインスタンスの切り替えではないので、Azure としては想定していないケースということになります。
Azure 環境のアップグレード
機能変更や障害改修されて、新しいバージョンにアップグレードされます。
メンテナンスが必要な理由
AppService/Functions などの Azure の各サービスは、日本のデータセンター（東日本・西日本）の中に、大量のサーバが設置されていて、そのサーバの仮想環境でアプリケーションなどが構築・動作されています。
Azure ユーザは、AppService/Functions 上にアプリケーションをデプロイして実行しますが、そのアプリケーションが動作しているサーバには他のユーザのアプリケーションもたくさん同時に実行されています。
複数ユーザが共有して利用されているサーバでは、ひっきりなしにリソースが新規作成されたり削除されたりアプリケーションが実行されたり停止されたりするので、サーバを正常に保って複数アプリを正常に動作し続けるためには、日常的なメンテンスが必要不可欠となります。さらに、Azure 機能のアップグレードなども繁栄していく必要があります。
なので、Azure などのクラウドサービスがメンテナンスを行うのは当然ということを、理解することが必要となります。
メンテナンスはいつ行われてるか
大きく２種類あります。予定されてるメンテナンスと、予定外のメンテナンスがあり、それぞれ実行されるタイミングが変わります。
予定しているメンテナンス
原則、深夜などのビジネスタイム外の時間帯にメンテナンスが行われます。
予定外のメンテナンス
予定外のメンテナンス（メンテナンスを行わないと Azure 側のサーバが正常に動作できないと判断した際のメンテナンス）なので、時間帯に関係なく実施されます。
メンテナンスが行われるとどうなるか
メンテナンスが発生した際は、基本的に実行中の処理は強制的に中断されたりします。
しかし、Azure 側はユーザのシステム・アプリケーションがリトライ処理などを行い、一時的に使用できない状況を回避してくれてることを期待してます。
ただ、既に Azure にリクエストが届いていてサーバ上で処理中されているものは、処理結果が返却されるまで待ってくれるようです。
まず、Azure 側の動作としては、クライアントからのリクエストを継続して処理してくれます。スワップ操作したタイミングに Azure 側の処理が終わったタイミングでアプリケーションを入れ替えた後に、Azure 側のキューに溜まっているリクエストを継続して処理してくれます。
ただ・・・例えば、申込み機能を削除する場合、利用者が申込み機能を使用している最中に、申込み機能がない状態のバージョンにスワップしてしまうとさすがにエラーが発生します。
スワップも魔法の機能ではありませんので、アプリケーションにどういう変更があるのかを理解した上でスワップで即時入れ替えを行うのかメンテナンス期間を設けるのかを判断していただければと思います。
メンテンスが行われていたか調べる方法
ポータル画面で確認
残念ながら、「メンテナンスが発生していたかどうか」を確認する方法はありません。
代わりの方法としては、
AppService/Functions の [問題の診断と解決] で「Web App Restarted」を検索すると、再起動の発生有無が確認できます。Azure 側がきっかけで再起動が発生していた＝メンテナンスが発生していた可能性が高い、ということがわかります。
Microsoft の Azure サポートに問い合わせる
有償サポート契約が必要になりますが、Microsoft の Azure サポートに問い合わせると、該当時間帯にメンテナンスが行われていたかどうか教えてくれます。
しかし、Azure サポート側もいつメンテナンスが行われていた。という情報をもっているわけではないらしいので、Azure 側がアプリケーションを再起動した」というログを確認した＝メンテナンスが発生していたのだろう。という推測をもとに答えるしかできないようです。
先述したとおり、AppService/Functions の [問題の診断と解決] で「この日時にAzure がきっかけでアプリケーション再起動された」「この日時にユーザきっかけでアプリケーション再起動された」というログが確認できるので、Azure 側がきっかけでアプリケーション再起動された場合は、メンテナンスが発生していたのだろう。ということは Azure サポートに問い合わせなくてもユーザ側で確認することができますので、覚えておいてください。
メンテンスの事前通知はないのか・できないのか
できません。
（理由は今度清書しますが、予定外のメンテナンスもあるので、全てを事前通知なんていうことはまず無理なことはわかると思います。）
メンテンスの対策・影響を受けないためには
Azure 有償サポートでも推奨されている対策が、４つあります。
AppServiceプランのインスタンスを２つ以上で運用する
AppServiceプランを使用している場合の対策になります。
インスタンス数が １ だと、インスタンスに影響するメンテナンスが発生した場合に、アプリケーションが一時停止してしまいます！
容易な対策としては、複数のインスタンスを使うようにします。すると、予定しているメンテナンスであればスタンプ内のインスタンスを少しずつメンテナンスしていくので、インスタンスＡはメンテナンスで使えなくなってしまうがインスタンスＢはメンテナンスが行われていないため、アプリケーションは一時停止しなくて済んだ！という状況になります。
ただ、これはあくまでも「メンテナンスの影響を受ける可能性を容易に下げられる対策」であることを理解いただければと思います。
docs.microsoft.com
アプリケーションを複数リージョンにデプロイして主と副で運用する
具体例でいうと、ひとつのAppServiceを「東日本リージョンにデプロイ」（プライマリリージョン）、もうひとつのAppServiceを「西日本リージョンにデプロイ」（セカンダリリージョン）をそれぞれ構築します。
そして、FrontDoor でアクティブなAppServiceをコントロールしてもらう方法です。
Traffic Manager で利用できないインスタンスを避ける
Traffic Manager は定期的に AppService/Functions のエンドポイントを監視し、問題の発生したリージョンから、別のリージョンへリクエストをルーティングを行うことが可能です。
リトライ処理をアプリケーションに組み込む
これは Azure 関係なく、アプリケーションに組み込まれているのが常識だと思いますので、一番重要な対策です。
メンテナンスは短い時間で終わることが多いので、もう一度リトライすれば正常に進んだのに！ということが起きないように、リトライ処理を入れておくのは必須になります。
docs.microsoft.com
以上です。