Implement Autoscaling
Autoscale is an Azure feature that automatically adjusts the number of App Service plan instances based on demand. When resource use crosses certain thresholds, autoscale adds or removes instances to improve availability and minimize costs. This ensures web apps remain responsive during peak times without over-provisioning during low usage.
Azure autoscale supports horizontal scaling but not vertical scaling in web apps. Horizontal scaling changes the instance count by adding or removing copies of your app. Vertical scaling adjusts the CPU, memory, or storage of existing instances and requires changing the pricing tier of the App Service plan. Since vertical scaling has hardware limits and may require restarts, horizontal scaling is more flexible and faster for dynamic web workloads.
To configure autoscale, you define profiles containing rules, capacity, and schedules in the Azure portal or CLI. Metric-based scaling uses signals like percentage CPU, memory usage, HTTP queue length, or custom metrics from Application Insights. You set a low and high threshold, and the system uses OR logic to trigger scale-out and AND logic for scale-in. Each profile specifies a minimum, maximum, and default instance count to keep scaling within safe bounds.
You can also add time-based scaling rules to prepare for known traffic patterns, such as weekends or special events. Schedule-based rules let you scale to a specific instance count for certain days or date ranges. Autoscale can send notifications via email or webhooks when scaling actions occur, which helps in monitoring and auditing changes. Best practices include defining at least one scale-out and one scale-in rule and testing thresholds to avoid rapid scaling cycles.
Autoscale automatically adjusts the number of running resource instances based on current load or demand. This helps maintain application performance during peak usage and reduces costs during low activity periods by scaling resources in or out.
An autoscale configuration uses profiles that contain rules defining when to scale. Each rule is based on a specific metric like CPU usage or a custom application metric, and has a threshold value that triggers the action. The scale action specifies whether to increase or decrease the instance count and by how much. Both scale-out and scale-in rules must be defined to handle fluctuating load efficiently. A cooldown period is set to prevent rapid, unnecessary scaling actions immediately after a previous operation.
Beyond standard platform metrics, you can create scaling rules based on custom metrics generated by your application. For example, you might scale based on active user sessions, message queue length, or a performance counter unique to your app. To use a custom metric, your application must send telemetry data to Application Insights. Once the metric is available there, you can select it as the source for a scaling rule.
When designing rules, set appropriate thresholds and time durations to avoid overly sensitive scaling that could cause instability, known as flapping. A good practice is to scale out when average CPU usage is above 70% for 10 minutes and scale in only when it falls below 30% for a similar period. Always define sensible instance limits: a minimum to ensure availability, a maximum to control costs, and a default number of instances to use if metrics are unavailable.
StudyCerts
StudyCerts