App Service のスロットとは？
App Service には「スロット」と呼ばれる機能があり、運用中のアプリケーションと並行で新しいバージョンのアプリケーションを展開やテストしたり、入れ替えることが出来ます。
ドキュメントとしては以下のドキュメントに記載されていますが、実践的に使用する上でとっつきにくいのも事実なので、簡単ではありますが、動作をまとめます。
スロットはどのように実装されているのか？
ドキュメントには「デプロイ スロットは、固有のホスト名を持つライブ アプリです。」と書かれていますが、実際の配置としてはどのようになっているのでしょうか？
例えば運用スロットに追加して、stg1 という名前でスロットを作ったとします。
Azure Resource Explorer を使用すると確認することが出来ますが、元のアプリケーションの配下に slots という要素があり、その配下にスロットは配置されます。
つまり、リソースとして完全に独立しているわけではないが、元のリソースに依存する、別の構成情報を持った子リソースとして作成されます。
App Service プランの観点から見ると、運用スロットは別に "slot" という種類で登録されていることが分かります。
つまり、App Service におけるスロットは「運用スロットに紐付いて作成された、独立したリソース」として見ることが出来ます。
App Service プランでも独立したリソースとして動作するため、それぞれサンドボックス (Windows の場合) やコンテナ (Linux, コンテナの場合) として動作します。
1 つの App Service プランで 複数のアプリケーションを動作させる場合と同様 に、スロットに配置や動作させるアプリケーションの数やリソース消費には注意が必要です。
スロットについて理解を深める
スロットが、App Service プラン上で独立したアプリケーションとして動作している点はお話ししました。
では、スワップでアプリケーションを入れ替える際、どうやって切り替わるのでしょうか？運用スロットを停止してステージングスロットのアプリケーションをコピーしているのでしょうか？
App Service の アーキテクチャを理解していると 難しくはないですが、裏では個別にスロットの内容を格納する「器」が用意されており、ホスト名 (~~~.azurewebsites.net) が書き換えられているだけです。
「高度なツール」から Environment で環境変数を探すと、"WEBSITE_DEPLOYMENT_ID" という項目がありますが、これが「器」を示す名前で、スロットを作成すると 「"__"+ 4桁の英数字」 という形で作成されます。
例えば App Service 作成時に作られる運用スロットでは以下のようになっています。
追加でステージングスロットを作成すると以下のように "__bbfb" という記号が追加されて作成されます。
この「器」が各スロットで動作させるアプリケーションプールやサンドボックス、コンテナの実体です。
アプリケーション設定や \home\ 配下に配置されるファイルシステムなども全て独立しており、スワップを行うと入れ替えが行われます。
例えば、先の 2 つのスロットでスワップを行うと、器 (DEPLOYMENT_ID) は以下のように入れ替わることになります。
| スワップ回数 | 運用スロット | ステージングスロット |
|---|---|---|
| 0回目 | (無印) | 末尾__bbfb |
| 1回目 | 末尾__bbfb | (無印) |
| 2回目 | (無印) | 末尾__bbfb |
| 3回目 | __bbfb | (無印) |
ステージングスロットが複数あるとジャグリングのように入れ替わりますが、スロットの操作において、どの器の名前 (DEPLOYMENT_ID) を意識する必要はありません。
操作を行う時点で、どのスロットに対して操作を行ったか (あとで調べるなら操作を行った時刻) だけが重要です。
App Service に対してアクセスする場合も、要求先のホスト名に対して、App Service のフロントエンドがどのインスタンスで実行されているどのサンドボックス化を判断してルーティングを行います。
例えば webapps.azurewebsite.net に対する要求であれば、あるインスタンスの "webapps" というアプリケーションプール、サンドボックスに対して要求が転送されます。
スワップを行うと、運用スロットを提供する「器」は "__bbfb" に移行しますが、フロントエンドはスロットが入れ替わったことを認識しており、引き続き運用スロットを提供するサンドボックスに対して要求を転送します。
スロットにおけるアプリケーション設定について
[構成] > [アプリケーション設定] では、「デプロイ スロットの設定」というチェックボックスがありますが、ここにチェックを入れるとどんな動作になるのでしょうか？
「デプロイ スロットの設定」が有効になっている (マークが付いている) 場合、スロットスワップが行われても入れ替えは行わず、そのスロット (運用は運用のまま、ステージングはステージングのまま) 残ります。
表現がイマイチ定まっておらず、スロットに固定、スロットにピン留め等の表現が使用される場合もあります。
実際にスロットスワップを実行してみましょう。
ターゲットとなる、今動いている運用スロットのアプリケーション設定は以下のようになっています。
key1, key2 というアプリケーション設定を追加し、key2 だけ「デプロイ スロットの設定」を有効にしました。
スワップのソースとなるスロット (今のステージングスロット) は以下のような設定になっています。
スワップを実行し、ステージングスロットを運用スロットに移動 (スワップ) しました。すると、アプリケーション設定は以下のようになりました。
- WEBSITE_NODE_DEFAULT_VERSION はステージングスロットの「器」に紐付いており、スワップ時に移動してきた設定
- key2 は「デプロイ スロットの設定」が有効なため、スワップでも移動しない設定 (この場合、運用スロットに固定)
- ApplicationInsightsAgent_EXTENSION_VERSION はスワップで対象外とされている設定 (サフィックス _EXTENSION_VERSION で終わる設定)
使い分けの例としては以下のようになります。
- 「デプロイ スロットの設定」でチェック する : 本番データベースへの接続情報のような、本番環境、開発環境固有の設定
- 「デプロイ スロットの設定」でチェック しない : アプリケーションの動作を決めるパラメータ (アプリの機能を有効化するフラグなど)
アプリケーション設定において、どのように設定するかはアプリケーション次第ですが、スロットに固定する (「デプロイ スロットの設定」でチェックする) ことを禁止しているパラメータもあるので注意が必要です。必ず、同期の動作を踏まえて判断しましょう。
例: Azure Functions の WEBSITE_CONTENTSHARE : 各スロットのコードを格納するファイル共有名の指定なので、固定された場合コードが入れ替わらなくなる (ステージングスロットにデプロイしたコードをスワップしても、参照しているファイル共有が固定なので切替えできない)
スロットの入れ替え
ポータルからスロットのスワップ操作を行うと、スワップでの入れ替えソースとターゲットでの変更点で表示されます。
以下が、新しいバージョンのアプリケーションが展開されたソースと、現行バージョンのアプリケーションが動作しているターゲットの入れ替えの例です。ソーススロットが使用していた NetFrameworkVersion という構成値で古い値 v4.0 から v6.0 に変更される、アプリケーション設定の APPINSIGHTS_INSTRUM や key1 などが新しく設定されることを意味しています(スロット作成時に何もコピーしなかったためスロット間で差分が出てます)。
スワップ中の動作に関しては ドキュメントに記載があります。要点としては、ソースとして指定した (=新しく運用スロットに配置する) アプリケーションを運用スロットの設定で再起動し、HTTP での応答が開始された段階でルーティングが開始されます。
アプリケーションによっては「HTTP ポートは空いたので応答は開始されているが、アプリケーションはロードされていない (HTTP ステータスコード 404/500/502 応答)」という場合もありますが、そこまでは考慮されません (おそらく、これは「アプリケーションが開始された」という判断は実行するアプリケーションにより異なるため、判断する基準がないため)。
必要に応じて プレビューでのスワップ (multi phase slot swap) を使用して、新しい運用スロットでの公開タイミングを調整しましょう。
まとめ
上記で書いた内容をまとめると、一般的な利用範囲においては、おおよそ以下のようになります。
スロットは活用すると非常に便利な機能ですが、一般的なアプリケーションサーバに標準的に搭載されている機能ではなく、若干とっつきにくい側面があります。
スロットでは「外部から確認できるホスト部分と、内部で実行するアプリケーションの部分で分離しており、スワップの度に入れ替わるという」ことを頭に入れておくと、理解しやすいかも知れません。
もっと細かい動作については記載がありますが、そちらは ドキュメントに記載がある のでそちらを確認してみてください。