メンテナンスについて
あまりここまで書いてる情報はないと思います。公式ドキュメントにもまとめて書かれてるページがなかったので、間違いを恐れずに攻めて書いてみました。また、SQLDatabaseやStorageAccount等にも通じる内容が多いので、ご参考いただければと思います。
メンテナンスが必要な理由
AppService/FunctionsなどのAzureの各サービスは、たとえば日本のデータセンター(東日本・西日本)の中に、大量のサーバが設置されていて、そのサーバの仮想環境でアプリケーションなどが構築・実行されています。Azureユーザは、AppService/Functions上にアプリケーションをデプロイして実行されていますが、その実行されているサーバには複数ユーザ分のアプリケーションがたくさん同時に実行されています。複数ユーザが共有して利用されているサーバでは、ひっきりなしにリソースが新規作成されたり削除されたりアプリケーションが実行されたり停止されたりするので、サーバを正常状態に保って複数のアプリケーションを正常に動作し続けるためには、日常的なメンテンスが必要不可欠となります。さらに、Azure機能をAppService/Functions にアップグレードなども繁栄していく必要があります。
以上のことからAzureなどのクラウドサービスは、日常的にメンテナンスを行うのは当然ということを理解する必要があります。
メンテナンスの種類といつ行われているか
メンテナンスは大きく２つに分けられます。予定されてるメンテナンスと、予定外のメンテナンスがあり、それぞれ実行されるタイミングが変わります。
[予定しているメンテナンス]: 原則、深夜などのビジネスタイム外の時間帯にメンテナンスが行われます。たとえば、ANTのサーバに関する月１定期メンテナンスのようなイメージです。
[予定外のメンテナンス]: メンテナンスを行わないとAzure側のサーバが正常に動作できないと判断した際に実施される、予定外のメンテナンスは必要に応じて実施されるので、時間帯に関係なく実施されます。緊急メンテナンスというわけではなく、Azure側としては想定しているメンテナンスです。
メンテナンスとは具体的に何が行われるのか
メンテナンスとひと言でいっても実際になにをやっているのでしょうか。代表的な例を紹介します。
[設定ファイルの入れ替えなど]: サーバ内の設定ファイルを入れ替えるだけのようなメンテナンスもあります。
[Azure環境のアップグレード]: 機能変更や障害改修されて、AppServiceなど自体が新しいバージョンにアップグレードされます。
[定期メンテナンス]: たとえば、ANTサーバの月１定期メンテナンスのようなものもあります。
[実行中インスタンスの負荷が上がりインスタンスを切り替え]: アプリケーションが実行中のインスタンスの負荷が上がったり、何かしらの問題が発生して、Azure側がこのままこのインスタンスでアプリ処理を継続することは困難だ！と判断した場合にAzure側の判断で別のインスタンスに切り替えます。こういった動きも、メンテナンスの一つといえると思います。
メンテナンスが行われるとAzure環境はどうなるのか
インスタンスが切り替わる場合がある
AppService/Functionsのアプリケーションはずっと同じインスタンス上で実行されているわけではありません。これは、どの料金プランを利用していても共通の話です。更に、メンテナンス実施＝必ずインスタンスの切り替えが発生するわけではないので覚えておいてください。
[アプリケーション実行中にインスタンス切り替えが起こるとどうなるのか？]: まず前提としては、インスタンス上でアプリケーションが処理中に割り込んで、処理を中断させてメンテナンスが実施されてしまわないような仕組みになってます。要は、キリのいいところまで処理が終わるのを待った上でメンテナンス実施してくれてます。
クライアント -> (インターネット) -> FrontEnd -> WebWorker(インスタンス)
という構成でインスタンスの切り替えが発生した際、アプリケーション自体は新しいインスタンスで起動し直されます。また、原則直前のリクエスト処理が完了した後に新しいインスタンスへの切り替えを行っており、インスタンス切り替え完了後にFrontEndのリクエストキューに溜まっているリクエストをFrontEndから新しいインスタンスに転送されて、引き続きアプリケーションが実行されるという流れになります。[なぜインスタンス切り替えが起きるのか？]: Azure側が想定しているケースの例としては、以下に記載する『Azure環境のアップグレード』の際に、アップグレードしようとしたインスタンスがアプリケーション実行中の場合は、"このインスタンスメンテナンスしたいから、別のインスタンスに移動して残りのリクエスト分を処理してね" という感じで、未処理のリクエスト処理がFrontEndに残っていても別のインスタンスに移動させられます。Azure側が想定していないケースとしては、実行中のインスタンスで問題が発生したら、Azureが勝手に他の正常なインスタンスに切り替えて、継続してアプリケーションが実行できるようにしてくれています。どちらにしても、アプリケーションが正常に継続実行できるようにしてくれている仕組みなので、何でインスタンスの切り替えなんて発生するんだ！などと言わないようにしましょう。
[アプリケーションの待ち時間（実行されていない時間）が発生したのはなぜ？]: それはインスタンスの切り替えが発生して、新しいインスタンスの準備が整うまでの待ち時間が発生していた可能性がありますが、これはメンテナンスでもなんでもなくて日常的なAzure 側の動作です。コールドスタートがわからない方は、説明している記事を用意してますのでサイト内検索してみてください。そして、プラス料金発生せずに、インスタンス切り替えの待ち時間を抑止できる設定があります。AppServiceプランを使用している場合、
「AppService/Functions > 構成 > 全般設定タブ > 常時接続」
こちらの常時接続機能をONにすると、Azure側でインスタンスが常に起動されるようになるため、アプリケーション起動時の待ち時間が抑止されます。設定を確認してOFFであれば必要に応じてONにしましょう。
SQLDatabase/StorageAccount等がメンテナンス中の場合
(AppService/Functions自体のメンテナンスの話から少しずれますが、)アプリケーション処理からSQLDatabase/StorageAccount等にアクセスした際に、SQLDatabase/StorageAccount側でメンテナンスが発生していると５０３エラー等が発生したりします。AppService/Functionsのアプリケーションとしてできることは、SQLDatabase/StorageAccount等にアクセスしている箇所に再送(リトライ)を組み込むことです。
SQLDatabase/StorageAccount等でメンテナンスが発生することも想定した実装していないと、リトライすればSQLDatabase/StorageAccount等へのアクセスが成功していたのに・・・ということになるともったいないことになります。リトライはとても重要なポイントです。
最後に・・・
メンテナンスに関する情報・考え方を長々と書きましたがいかがでしたでしょうか。
Azure構成とアプリケーション実装を駆使して、メンテナンスの影響が最小限になるように構成してアプリケーションの可用性の維持を目指していきたいですね。
以上です。
