メンテンスの事前通知されないのか・設定できるか
事前通知もされませんし、事前通知できるような設定・機能も用意されてません。
そもそも事前通知ができたら、どうするつもりなのでしょうか。事前通知を受けたら、一時的に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での活用を始めてみてはいかがでしょうか。
