スロットとは、異なるアプリのバージョンをサーバー上にホストできて、公開するバージョンを瞬時に切替えて公開できる機能です。各スロットは独立した環境として動作し、異なる設定やアプリコードを持つことができます。これにより、改修後のアプリの新バージョンをデプロイ・テスト・リリースする際に、現在の運用スロットのアプリに影響を与えずに行うことができます。
スロットをスワップとは
例えば、運用スロットからステージングスロットに切り替えることを、スワップといいます。システムによっては、バージョン１スロットからバージョン２スロットにスワップするような運用をしているケースもあります。どういうスロット運用をするかは、プロジェクトによって異なります。
また、スロットを切り替えたらどうなるかというと、アプリURLは変わらずに、アプリの中身が変わります。そしてスワップでアプリの中身が切り替わる際はダウンタウンなしで切り替えることができます。スロットの最大数は、Standardプランだと５個、Premiumプランだと２０個が作成できるスロットの最大数になります。
アプリ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 側のアプリ用リクエストキューにリクエストが溜まっていたら継続して処理させてくれます。ただ・・・例えば、申込み機能を削除する場合、利用者が申込み機能を使用している最中に、申込み機能がない状態のバージョンにスワップしてしまうとさすがにエラーが発生します。これは、わかりやすい極端な例をあげましたが、アプリが大幅に更新された場合はスワップ機能に頼らずに、一度システムを止めてメンテナンス期間中にアプリを入れ替えた方がいいと思います。スワップも魔法の機能ではありませんので、アプリにどういう変更があるのかを理解した上でスワップで即時入れ替えを行うのかメンテナンス期間を設けるのかを判断していただければと思います。
以上です。
