This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Azure App Services currently provides two workflows for scaling: scale up and scale out.
- Scale up: Get more CPU, memory, disk space, and extra features. You scale up by changing the pricing tier of the App Service plan that your app belongs to.
- Scale out: Increase the number of VM instances that run your app. You can scale out to as many as 30 instances, depending on your pricing tier. App Service Environments in Isolated tier further increases your scale-out count to 100 instances. You can scale manually or automatically based on predefined rules and schedules.
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:
- 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.
- Developers can define per web app scaling and control the minimum number of running instances per web app.
- Developers can control the maximum number of instances that an underlying app service plan can scale out to. This ensures that connected resources like databases do not become a bottleneck once automatic scaling is triggered.
- Enable or disable automatic scaling for existing app service plans, as well as apps within these plans.
- Address cold start issues for your web apps with pre-warmed instances. These instances act as a buffer when scaling out your web apps.
- Automatic scaling works with the existing Premium Pv2 and Pv3 SKUs.
- Automatic scaling is billed on per second basis and uses the existing Pv2 and Pv3 billing meters.
-
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 ]
- Use Azure CLI or ARM templates to enable automatic scaling.
Suggested scenarios for automatic scaling:
- You want your web app to scale automatically without setting up an auto-scale schedule or set of auto-scale rules based on various resource metrics.
- You want your web apps within the same app service plan to scale differently and independently of each other.
- A web app is connected to backend data sources like databases or legacy systems which may not be able to scale as fast as the web app. Automatic scaling allows you to set the maximum number of instances your app service plan can scale to. This helps avoid scenarios where a backend is a bottleneck to scaling and is overwhelmed by the web app.
Enable Automatic scaling using Azure CLI:
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:
- Execute above step using the -- debug flag to return details about the error
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.")
- You should now create a new resource group and an app service plan (It is recommended to use PV3 SKU for the new app service plan) and then set ElasticScaleEnabled=1
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 scale out limit of app service plan named "sampleAppServicePlan" to 10 instances]
*** Value of maximumElasticWorkerCount should be less than or equal to 30 (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:
- The App Service automatic scaling feature is currently in early preview.
- Automatic scaling is currently supported for Azure App Service for Windows and Linux.(App service for Windows containers and App Service Environments do not support automatic scaling)
- Automatic scaling can be configured via Azure CLI and ARM templates only. Azure Portal (UX) support for this feature will be enabled in a future release.
- Automatic scaling is available only for Azure App Services Premium Pv2 and Pv3 SKUs
- App Service’s automatic scaling feature is different than Azure Autoscale. Automatic scaling is a new built-in feature of the App Service platform that automatically handles web app scaling decisions for you. Azure Autoscale is a pre-existing Azure feature for defining schedule-based and resource-based scaling rules for your app service plans. for your app service plans.
- Once automatic scaling is configured, existing Azure Autoscale rules and schedules (if any) will not be honored. Applications can use either automatic scaling, or Azure Autoscale, but not both. If you disable automatic scaling for your app service plan by setting ElasticScaleEnabled=0; existing Autoscale rules if any, will be applicable once again
- Health check should not be enabled on web apps with this automatic scaling feature turned on. Due to the rapid scaling provided by this feature, the health check requests can cause unnecessary fluctuations in HTTP traffic. Automatic scaling has its own internal health probes that are used to make informed scaling decisions.
- You can only have Azure App Service web apps in the app service plan where you wish to enable automatic scaling. If you have existing Azure Functions apps in the same app service plan, or if you create new Azure Functions apps, then automatic scaling will be disabled. For Functions it is advised to use the Azure Functions Premium plan instead.