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