Azure App Services currently provides two workflows for scaling: scale up and scale out.
These existing scaling workflows work well, but you may want to instead have the App Service platform automatically scale your web app without the hassle of defining auto-scaling rules & schedules.
We are introducing a new platform-managed automatic scaling feature in Azure App Services. Below is a list of key features provided by App Service’s built-in automatic scaling feature:
Pre-warmed instances are also charged on per second basis using the existing Pv2 and Pv3 billing meters once it's allocated for use by your web app [For additional details about pre-warmed instances refer to AZ Cli section below ]
Suggested scenarios for automatic scaling:
Enable Automatic scaling using Azure CLI:
With latest version of AZ CLI we have simplified configuring automatic scaling (Option 1 described below) :
Option 1:
Step 1:
This step enables automatic scaling for your existing app service plan and web apps within this plan. We also set the value of maximum automatic scale for the app service plan using this step.
az appservice plan update --name <<app service plan name>> --resource-group "resource group name" --elastic-scale true | false --max-elastic-worker-count <<max number of workers for app service plan automatic scale >>
az appservice plan update --name sampleAppServicePlan --resource-group sampleResourceGroup --elastic-scale true --max-elastic-worker-count 10 [This enables automatic scaling for the app service plan and sets the max automatic scale out limit of the app service plan as 10]
*** Value of max-elastic-worker-count should be less than or equal to Maximum instances that a premium SKU app service plan can scale out
*** Value of max-elastic-worker-count should be greater than or equal to current instance count (NumberOfWorkers) for your app service plan
*** In some scenarios while setting the value of "--elastic-scale true" for an existing app service plan for App service Linux you may receive an error message (“Operation returned an invalid status 'Bad Request'”). In such scenarios follow below mentioned steps:
You can now view detailed error message which should be similar to "Message":"Requested feature is not available in resource group <<Your Resource Group Name>>. Please try using a different resource group or create a new one."
Step 2:
This step enables minimum number of instances that your web app will always be available on (per app scaling) and also enables the number of pre-warmed instances readily available for your web app to scale (buffer instances).
az webapp update -g <<resource group name>> -n <<web app name>> --minimum-elastic-instance-count <<number of always available instances for the web app>> --prewarmed-instance-count <<number of buffer instances available for the web app >>
az webapp update -g sampleResourceGroup -n sampleWebApp --minimum-elastic-instance-count 5 --prewarmed-instance-count 1 [This configures 5 as the minimum number of instances that your web app will always be available on (per app scaling) and also configures 1 as the number of pre-warmed instances readily available for your web app to scale (buffer instances).
*** Default value of prewarmed-instance-count is set as 1 and for most scenarios this value should remain as 1
*** Assuming that your web app has five always ready instances (minimum-elastic-instance-count 5) and the default of one pre-warmed instance. When your web app is idle and no HTTP requests are received, the app is provisioned and running with five instances. At this time, you aren't billed for a pre-warmed instance as the always-ready instances aren't used, and no pre-warmed instance is allocated. Once your web app starts receiving HTTP Requests and the five always-ready instances become active, and a pre-warmed instance is allocated and the billing for it starts. If the rate of HTTP Requests received by your web app continues to increase, the five active instances are eventually used and when App services decides to scale beyond five instances, it scales into the pre-warmed instance. When that happens, there are now six active instances, and a seventh instance is instantly provisioned and fill the pre-warmed buffer. This sequence of scaling and pre-warming continues until the maximum instance count for the app is reached. No instances are pre-warmed or activated beyond the maximum.
Step 3:
This step disables automatic scaling for your existing app service plan and web apps within this plan
az appservice plan update --name <<app service plan name>> --resource-group "resource group name" --elastic-scale true | false
az appservice plan update --name sampleAppServicePlan --resource-group sampleResourceGroup --elastic-scale false [This disables automatic scaling for the app service plan]
Option 2:
Step 1:
This step enables automatic scaling for your existing app service plan and web apps within this plan
az resource update -g <<resource group name>> -n <<app service plan name>> --set properties.ElasticScaleEnabled=1 --resource-type Microsoft.Web/serverfarms
az resource update -g sampleResourceGroup -n sampleAppServicePlan --set properties.ElasticScaleEnabled=1 --resource-type Microsoft.Web/serverfarms [This enables automatic scaling for the app service plan named "sampleAppServicePlan"]
*** In some scenarios while setting the value of ElasticScaleEnabled=1 for an existing app service plan for App service Linux you may receive an error message (“Operation returned an invalid status 'Bad Request'”). In such scenarios follow below mentioned steps:
az resource update -g <<resource group name>> -n <<app service plan name>> --set properties.ElasticScaleEnabled=1 --resource-type Microsoft.Web/serverfarms -- debug (You can now view detailed error message which should be similar to "Message":"Requested feature is not available in resource group <<Your Resource Group Name>>. Please try using a different resource group or create a new one.")
Step 2:
This step defines maximum number of instances that your app service plan can scale to
az resource update -g <<resource group name>> -n <<app service plan name>> -- properties.maximumElasticWorkerCount=** --resource-type Microsoft.Web/serverfarms
az resource update -g sampleResourceGroup -n sampleAppServicePlan -- properties.maximumElasticWorkerCount=10 --resource-type Microsoft.Web/serverfarms [This sets the max automatic scale out limit of the app service plan named "sampleAppServicePlan" to 10 instances]
*** Value of maximumElasticWorkerCount should be less than or equal to Maximum instances that a premium SKU app service plan can scale out
*** Value of maximumElasticWorkerCount should be greater than or equal to current instance count (NumberOfWorkers) for your app service plan
Step 3:
This step enables minimum number of instances that your web app will always be available on (per app scaling)
az resource update -g <<resource group name>> -n <<web app name>>/config/web --set properties.minimumElasticInstanceCount=** --resource-type Microsoft.Web/sites
az resource update -g sampleResourceGroup -n sampleWebApp/config/web --set properties.minimumElasticInstanceCount=5 --resource-type Microsoft.Web/sites[This sets the minimum number of instances for the web app named "sampleWebApp" to 5. In this example Web app named "sampleWebApp" is deployed to app service plan named "sampleAppServicePlan "]
Step 4:
This step enables the number of pre-warmed instances readily available for your web app to scale (buffer instances).
*** Default value of “preWarmedInstanceCount” is set as 1 and for most scenarios this value should remain as 1
az resource update -g <<resource group name>> -n <<web app name>>/config/web --set properties.preWarmedInstanceCount=** --resource-type Microsoft.Web/sites
az resource update -g sampleResourceGroup -n sampleWebApp/config/web --set properties.preWarmedInstanceCount=2 --resource-type Microsoft.Web/sites[This sets the number of buffer instances available for automatic scaling for the web app named "sampleWebApp" to 2]
*** Assuming that your web app has five always ready instances (minimumElasticInstanceCount=5) and the default of one pre-warmed instance. When your web app is idle and no HTTP requests are received, the app is provisioned and running with five instances. At this time, you aren't billed for a pre-warmed instance as the always-ready instances aren't used, and no pre-warmed instance is allocated. Once your web app starts receiving HTTP Requests and the five always-ready instances become active, and a pre-warmed instance is allocated and the billing for it starts. If the rate of HTTP Requests received by your web app continues to increase, the five active instances are eventually used and when App services decides to scale beyond five instances, it scales into the pre-warmed instance. When that happens, there are now six active instances, and a seventh instance is instantly provisioned and fill the pre-warmed buffer. This sequence of scaling and pre-warming continues until the maximum instance count for the app is reached. No instances are pre-warmed or activated beyond the maximum.
Step 5:
This step disables automatic scaling for your existing app service plan and web apps within this plan
az resource update -g <<resource group name>> -n <<app service plan name>> --set properties.ElasticScaleEnabled=0 --resource-type Microsoft.Web/serverfarms
az resource update -g sampleResourceGroup -n sampleAppServicePlan --set properties.ElasticScaleEnabled=0 --resource-type Microsoft.Web/serverfarms [This disables automatic scaling for the app service plan named "sampleAppServicePlan"]
FAQ:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.