Azure App Service といえば WebApps を簡単にホストできるPaaSサービスです。特徴としてインスタンスの自動スケールがありますが、今回 Azure App Service の自動スケール方法に新しい方法(トラフィックベースの自動スケール)がGAされたので紹介します。
2024年3月25日リリースのApp Service の新自動スケーリングについて
2024年3月25日にMS公式のAzure更新通知から下記のようなアナウンスがありました。
Azure App Service is pleased to announce general availability of the "Automatic Scaling" feature. We received important feedback about the Automatic Scaling feature during the preview phase and have made following enhancements to the Automatic Scaling feature.
(省略)
The App Service platform will automatically scale out the number of running instances of your application to keep up with the flow of incoming HTTP requests, and automatically scale in your application by reducing the number of running instances when incoming request traffic slows down.
以下、日本語訳。
Azure App Service では、"自動スケーリング" 機能の一般提供が開始されました。プレビュー段階で自動スケーリング機能に関する重要なフィードバックを受け取り、自動スケーリング機能に次の機能強化を行いました。
(省略)
App Service プラットフォームは、受信 HTTP 要求のフローに対応するためにアプリケーションの実行中のインスタンスの数を自動的にスケールアウトし、受信要求トラフィックの速度が低下すると実行中のインスタンスの数を減らすことでアプリケーションを自動的にスケールインします。
General Availability: Automatic Scaling for App Service Web Apps | Azure の更新情報 | Microsoft Azure より引用。
新しいAzure App Service に新しい自動スケールの方法が追加されたようですね。今回はそんな新しい自動スケールを紹介していこうと思います。
Azure App Service のスケーリング方法比較
Azure App Serviceには前からある「マニュアル(手動のスケーリング)」、「スケジュールとメトリックを用いたルールベースの自動スケーリング」と新機能の「トラフィック量に基づいた自動スケーリング(新機能)」があります。それではスケーリング方法を比較していきましょう。
マニュアル(手動のスケーリング)
こちらは自動スケールは設定せず、手動でインスタンス数を変更します。
スケジュールとメトリックを用いたルールベースの自動スケーリング
こちらはApp Service 旧来のオートスケールであるルールベースのオートスケール設定です。
自動スケーリングの画面は見慣れた画面ではないでしょうか？
CPU使用率などのメトリックの値やスケジュールによるスケールアウト/スケールインのルールを作成しておくことでルールに則った自動スケーリングが行われます。
トラフィック量に基づいた自動スケーリング(新機能)
2つ目のルールベースの自動スケーリングの名前が似ていてややこしいので新しい方は「トラフィック量ベース自動スケーリング」と呼びます。
特徴はトラフィック量に応じて、自動的に判断してWebアプリごとにスケールアウト/インが可能な点です。また今まではApp Service Plan ごとインスタンスう数がスケールアウトしていましたが、今回の新オートマチックスケールにより負荷が高いWebアプリのみのインスタンス数のスケールアウトが可能になりました。
そしてこちらが今回新しく追加した自動スケーリングの設定画面です。
「トラフィック量ベース自動スケーリング」に設定すると、下記のような設定項目が現れます。ここの設定項目により自動スケールの設定が可能です。
| 項目名 |
単位 |
説明 |
| Maximum burst(最大バースト) |
プランで共通 |
Number of instances this plan can scale out under load. Value should be greater than or equal to current instances for this plan. (このプランが負荷下でスケールアウトできるインスタンスの数。このプランの現在のインスタンス数以上である必要があります。) |
| Always ready instances(常に準備されたインスタンス) |
Web Apps ごと |
Number of instances that are always ready and warm for this web app.(このWebアプリケーションの常に準備され、ウォームな状態にあるインスタンスの数。) |
| Enforce scale out limit(スケールアウト制限の強制) |
Web Apps ごと |
Limit the number of instances this web app can scale out to.(このWebアプリケーションがスケールアウトできるインスタンスの数を制限します。) |
| Maximum scale limit(最大スケール制限) |
Web Apps ごと |
The maximum number of instances this web app can scale out to.(このWebアプリケーションがスケールアウトできる最大のインスタンス数。) |
少し設定値がわかりづらかったのでまとめてみました。
- 「最大バースト」がApp Service Plan 内での最大インスタンス数。
- 「常に準備されたインスタンス」がWebアプリごとの最小インスタンス数。
- 「スケールアウト制限の強制」によってこのWebアプリがスケールアウトできる最大インスタンス数を設定するかどうか選択。
- 「最大スケール」は「スケールアウト制限の強制」がONの場合のみ指定可能なこのWebアプリがスケールアウトできる最大インスタンス数を設定できます。
つまりWebアプリごとにスケールアウト/インできるようになったトラフィック量ベースの自動スケール設定ができるようになったようですね。
新しいトラフィック量ベースのオートスケールを試してみた
それでは実際に試してみます。
1つのApp Service Plan 上にWeb Apps1とWeb Apps2 を乗せて作ります。
Web Apps1の設定。
Web Apps2の設定。
何も負荷をかけていないこの状態でまずはWebApps1とWebApps2の現在のインスタンス数を確認してみようと思います。
新しいオートスケールによるインスタンス数はWebApps機能一覧の「監視-メトリック」のメトリック「Automatic Scaling Instance Count」から確認できます。↓の画像のように最初のインスタンス数は1のままでした。
この状態でWebApps1にのみ負荷をかけてみましょう。負荷はロードテストが簡単にできるAzure Load Testing でHTTPリクエストを投げてみました。
Azure Load Testing はこちらの記事で紹介してますのでこちらもご参照ください。
onarimon.jp
WebApps1に負荷をかけてみたところ、トラフィックによる負荷を検知して自動的にスケールアウトしていることがわかります。また、ドキュメントにも書かれていましたが、負荷テストが終了するとスケールインに向けてレビューが行われるようで5分ほどして自動的にスケールインされていました。
WebApps2のほうですが、こちらには負荷をかけていないため、こちらのアプリはインスタンス数は1のままキープされていますね。
これが今回のトラフィック量ベースの自動スケールの動きです。
新しいトラフィック量ベースの自動スケールの仕組み
新しい自動スケールは正常性チェックメカニズムに加えて、エンドポイントに向けての正常性プローブを投げることによりスケールの判定をしているようですね。
定期的に投げられている「GET /admin/host/ping」、「GET /」の通信がそれにあたるようです。
新しいトラフィック量ベースの自動スケールの制限事項について
とても便利な新しいトラフィック量ベースの自動スケールですが、下記のような制限事項があるのでご注意ください。
- 価格レベルはPremium V2 (P1V2、P2V2、P3V2) と Premium V3 (P0V3、P1V3、P2V3、P3V3、P1MV3、P2MV3、P3MV3、P4MV3、P5MV3) のみ。
- 最小インスタンス数は1～
- Azure Functions は未対応。Azure Functions が載ったApp Service Plan は新しいトラフィック量ベースの自動スケールは選択不可
App Service Planの価格レベル(SKU)はプレミアムプランのV2,V3でないと利用できないのでご注意ください。Azure Functions が使えないのも注意。
トラフィック量ベースの自動スケールの課金形態について
課金形態はApp Serivce Plan のSKUベースの料金で自動スケーリングされたインスタンス数分が秒単位で課金されるみたいです。
課金に対しては今まで以上に必要なときにのみの課金とできるのでコスト最適化にもつながる気がします。
利用シーン
今回の新しい自動スケールですが、利用シーンを考えてみました。
- Web Apps ごとのトラフィックに応じたスケーリングが可能
- 開発環境などのWeb Apps はそのWebApps のMAXサイズを制限する
- ルールを分析して設定する必要はなく、すべてが自動で行われるスケーリング
メトリックを分析して、閾値を考えての手間が意外と時間がかかって大変なのと、そこまで悩んだメトリックのスケーリングルールが本当にうまく動かない例もたくさんあると思うので今回のオートマチックな自動スケーリングによって、管理工数の削減が期待できますね。
参考情報
learn.microsoft.com
techcommunity.microsoft.com
