こんにちは、MLBお兄さんこと松村です。
先日アトランタ・ブレーブスの Ronald Acuña Jr 選手が30HR 60盗塁の「30-60」を達成しました。史上初の記録で、ホントにすごい選手です。
私の中で Azure で一番利用しているサービスである「App Service」ですが、内部的なアーキテクチャーについてはマイクロソフトが解説記事を出しています。
この記事のアプリケーションスロットについての部分に、このような記述があります。（日本語訳のほうです）
リソースの競合が負荷テスト実行などのシナリオのみに限定されている場合、スロットを独自のサーバセットを備えた App Service Plan に一時的に移動すると次のようになります：
非本番スロット用に追加の App Service Plan を作成します。注意：各 App Service Plan は、本番スロットの App Service Plan と同じリソースグループおよび同じリージョンである必要がございます。
非本番スロットを異なる App Service Plan へ移動し、コンピューティングを別のプールへ移動します。
別の App Service Plan で実行しながら、リソースを大量に消費する（またはリスクの高い）タスクを実行します。例えば、リソースの競合が発生しないため、本番スロットに悪影響を与えることなく、非本番スロットに対して負荷テストを実行できます。
非本番スロットを本番環境にスワップする準備ができましたら、本番環境スロットを実行している同じ App Service Plan へ戻します。その後、スロットスワップ操作を実行します。
へー、そんなことできるんだ？と思ったので、実際に試してみました。
有効な場面
文章ではイメージしづらかったので、図にしてみました。
通常 Web App のスロットは同じ App Service Plan にいるため、一方のスロットに負荷がかかればもう一方のスロットも負荷の影響を受けるため、スロットの使い分け方にも注意が必要です。
しかし上図の構成を取ることができれば、スロットの負荷が高いとき（負荷テストなど）に予め別の App Service Plan に移しておき、もう一方のスロットに影響を及ぼさないようにすることが可能です。
このような場面において有効な方法であると私は理解しました。
それでは実際に Azure ポータルを使って、スロットごとに使用する App Service Plan を分ける作業をやってみます。
手順
まずは Web App リソースを1つ作成します。今回は東日本リージョン (japaneast) にします。
またスロットを利用するため、App Service Plan の SKU は Standard 1 (S1) にします。
スロットを1つ作成します。今回は「test」という名前にします。
当然ですが App Service Plan は本番スロットと同じものを使用中です。
続いて、スロット用の App Service Plan を作成します。このときの注意点は以下です。
- Web App と同じリソースグループに作成すること
- Web App と同じリージョンに作成すること
- スロットが利用可能な SKU にすること (Standard 以上)
最後に test スロットの App Service Plan を変更します。変更はポータルから行うことができます。
これで本番スロットと非本番スロットの App Service Plan を分けることができました。
注意点
Azure App Service の課金単位は App Service Plan であるため、上記のようにスロット毎に使用する App Service Plan を分けた場合、それぞれの App Service Plan に対して課金が発生します。
そのため常に App Service Plan を分けて運用するというのは現実的ではなく、負荷テストの際など一時的な場面において有効な方法であると思います。
しかしこの方法は私自身も知らなかったので、活用できるように利点を覚えておきたいですね。
知らなかったけど、こういう構成が作れるんだね。 pic.twitter.com/8WwQDiI0E6
— Yuta Matsumura⚾MLBお兄さん (@tsubakimoto_s) 2023年9月2日
