結論は、事前通知されませんし、事前通知できるような設定・機能も用意されていません。その理由とかを具体的に説明しますのてお付き合い下さい。
なぜ事前通知されないのか・設定できないのか
そもそも事前通知ができたら、どうするつもりなのでしょうか。 事前通知を受けたら、一時的にAzure側にリクエストを送信しないように制御でもするのでしょうか。
どのようなメンテナンスが存在するのかの説明にも書いたように、アプリ動作に影響がないレベルのメンテナンスもたくさん存在します。じゃあアプリ動作に影響があるレベルのメンテナンスのときだけ事前通知してほしいのでしょうか。しかし各ユーザーのアプリ動作に影響があるかの判断をAzure側でできるはずがありません。
以上のことから、事前通知を考えるよりは、Azure側へのリクエスト送信処理にリトライ処理を組み込む対策をしたり、クラウド上でアプリの可用性を維持するために必要な考え方を実践した方が有効だと思います。オンプレのときは考えなくてよかったのに・・・という気持ちはわかりますが、クラウド利用の恩恵を受ける代わりに、メンテナンスの発生を受け入れるということはクラウドサービスと付き合う上で必要になります。
Azureが事前通知をしない（できない）理由・・・考えても仕方がありませんので書きませんし、上記でわかっていただけたかなと思います。
その代わりに、メンテナンスの影響を軽減させる方法を紹介しますので、ご検討ください。
メンテナンスの対策
アプリを継続実行させるための対策
Azure有償サポートなどでも推奨されている対策を、４つ紹介します。
◎ AppServiceプランのインスタンス２以上で運用 ▽
AppServiceプランを使用している場合の対策になります。インスタンス数が１だとインスタンスが全く使えなくなる時間が発生する可能性が高まるため、インスタンスに影響するメンテナンスが発生した場合に、アプリが遅延または一時停止してしまうことがあります。容易な対策としては、スケールアウトしてインスタンス台数を２台以上にします。メンテナンスはスタンプ内のインスタンスを少しづつ順番にメンテナンスしていくので、インスタンスＡはメンテナンスで使えなくなってしまうがインスタンスＢはメンテナンスが行われていないため、メンテナンスによってアプリが一時停止してしまう可能性を下げることができます。
ただ、これはあくまでも「メンテナンスの影響を受ける可能性を容易に下げられる対策」であることを理解いただければと思います。
◎ アプリを複数リージョンにデプロイして主と副で運用 ▽
具体例でいうと、ひとつのAppServiceを「東日本リージョンにデプロイ」(プライマリリージョン)、もうひとつのAppServiceを「西日本リージョンにデプロイ」(セカンダリリージョン)をそれぞれ構築します。そして、FrontDoorなどでアクティブなAppServiceをコントロールしてもらう方法です。
◎ TrafficManagerで利用できないリージョン・インスタンスを避ける ▽
TrafficManagerは定期的にAppService/Functionsのエンドポイントを監視し、問題が発生したリージョンから、別のリージョンへリクエストをルーティングを行うことが可能です。
◎ アプリにリトライ処理を組込む ▽
これはAzure関係なく、アプリに組み込まれているのが常識だと思います。基礎的で一番大事な対策です。メンテナンスは短い時間で終わることが多いので、もう一度リトライすれば正常に進んだのに！ということが起きないように、リトライ処理を入れておくのは必須になります。
セーフティにアプリを終了させる対策
メンテナンス発生時に、アプリが中途半端な状態で強制終了させられないよう、正常にアプリを終了させるための仕組みです。
◎ GracefulShutdownに対応する ▽
AppServiceの機能であるGracefulShutdownは、なんらかの理由でアプリをシャットダウンする必要が出たとき、リクエストの処理を途中で切り捨てることなく、適切に終了処理を行うことを目指した仕組みです。特に、メンテナンス時やアプリの更新が行われた時に有用な機能となります。
GracefulShutdownの具体的な動作とメリットについて
このGracefulShutdownは、あらかじめ設定したタイムアウト期間をもとに、アプリの終了処理をコントロールします。このタイムアウト期間、例えば10分等を設けることで、アプリはその10分間で受信済みのリクエストの処理を完了させる時間を確保します。さらに、この間にデータベースや他の外部サービスとの接続も適切に切断します。
このGracefulShutdownにより、アプリが突然終了し、途中で切断されたリクエストや終了処理が未実行のデータベース接続が生じる、という事態を防ぐことができます。その結果、アプリの不整合や想定外のエラーの発生を大幅に抑えることが可能となります。
（もう少し別の言い方で説明すると、）受信済みのリクエストを完了するためのタイムアウト期間を設けて、その間に安全にアプリを終了させる仕組みです。タイムアウト期間のあいだにアプリの後処理・DBや外部サービスとの接続を終了させて、それらが完了したらシャットダウンを行うことで、強制終了が防げてアプリ不整合や余計なエラー
を防ぐことができます。デプロイがタイミングを意識せずに実行できるという、副産物もあります。
さらに、このシャットダウン処理の仕組みにより、アプリのデプロイ（更新）を気にすることなく、適宜行うことができます。これは、新たなデプロイがリクエストに影響を与えず、まずは受信済みのリクエストの処理が保証されるからです。これはGracefulShutdownの大きな利点といえるでしょう。
以上のように、GracefulShutdownはAppServiceで運用するアプリケーションの安定性と信頼性を高める重要な機能です。初心者の方でも簡単に設定できますので、AppServiceでの活用を始めてみてはいかがでしょうか。
以上です。
