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