AppService/Functionsのスロット・スワップ機能
スロットとは
デフォルト環境とは別にスロットと呼ばれるもう一つ同じ環境できて、そのサブ環境のことをスロットと呼びます。
スワップとは
デフォルト環境→スロット１に切り替え、スロット１→スロット２に切り替え、スロット２→デフォルト環境に切り替え、などのように切り替えること自体のことをスワップと呼びます。
リリースする環境を切り替えても、アプリケーションURLは変わらずアプリケーションの中身が変わるイメージです。活用例としては、デフォルト環境からスロット１に切り替えることでダウンタウンなしで最新版のアプリケーションをリリースできる機能になります。更に、スロット２・スロット３のように複数作成してどのスロットをリリースするかを選ぶこともできます。
アプリケーションURL・実行されるアプリケーションは、一つだけ存在するので、アプリケーションURLにアクセスすると今リリースされているスロットのアプリケーションが実行されることになります。
Azure内部では何をやっているかというと、クライアント側から受信したアプリケーションへのリクエストデータについて、ロードバランサ(LB)から送る先をアプリAからアプリBに切り替えるだけなので、ダウンタウンなしで切り替えられているという仕組みになっています。
スワップ(切り替え)の実行例
以下２つのバージョンのアプリケーションがあるとします。
（１）本番リリース用のアプリケーションVer.1(本番環境で現在実行中)
（２）本番リリース用のアプリケーションVer.2(開発済みの最新版)
"https: //test-app.com" について、（１）から（２）への切り替えを例に説明します。
本番環境をダウンタイムなしで切り替えられる
本番環境をバージョンアップするときダウンタイムなしで切り替えたい。という要望をよく聞きます。
それは、このスロットのスワップ機能で実現することができて、上記手順 [STEP 3] スワップを実施したタイミングでシステムを止めることなく稼働してくれます。先述したとおりAzure内部の仕組みとしては、ロードバランサ(LB)の向け先を変えているだけだから、ダウンタウンなしにAzure上で実行されるアプリケーションを切り替えられる、ということになります。
「ダウンタイムなし」とは
アプリケーションを入れ替え・更新するときに、昔ながらのオンプレ開発だと、「夜中の１時頃にメンテナンス時間を利用者に通知して、１時間ほどのアプリケーション入れ替え・更新作業をして、システム再開する。」というのが昔ながらのやり方だと思います。
ですが、今の時代はそんなことをする必要ありません。スワップボタンをポチッと押すだけでアプリケーションが最新に入れ替わる上に、システムが停止する時間もありません。ということで「ダウンタイムなし」とは、システムが使えない時間が発生しないということです。
各スロットはAppServiceプランやインスタンスを共有している
例えば、AppServiceプランでインスタンスが１台で稼働させている場合は、切り替え前のアプリケーションと切り替え後のアプリケーションは、そのインスタンスを各スロットのアプリケーションが共有して使用していることを覚えておいてください。
ですので、同じAppServiceプランが使われるのでAppServiceプランに対して設定したものはすべてのスロットに適用されます。メトリックなどを見る場所も変える必要はありません。
利用者がアプリケーションを使っている最中にスワップしたらどうなるのか
まず、Azure側の動作としては、クライアントからのリクエストを継続して処理してくれます。スワップ操作したタイミングにAzure側の処理が終わったタイミングでアプリケーションを入れ替えた後に、Azure 側のキューに溜まっているリクエストを継続して処理してくれます。
ただ・・・例えば、申込み機能を削除する場合、利用者が申込み機能を使用している最中に、申込み機能がない状態のバージョンにスワップしてしまうとさすがにエラーが発生します。
これは、わかりやすい極端な例をあげましたが、アプリケーションが大幅に更新された場合はスワップ機能に頼らずに、一度システムを止めてメンテナンス期間中にアプリケーションを入れ替えた方がいいと思います。スワップも魔法の機能ではありませんので、アプリケーションにどういう変更があるのかを理解した上でスワップで即時入れ替えを行うのかメンテナンス期間を設けるのかを判断していただければと思います。
以上です。