Auto Scaling:How Auto Scaling works

Workflow

The following figure shows how Auto Scaling adds ECS instances.

In this example, a web application is used. The web application has a three-layer architecture and uses ECS instances to process requests, as shown in the black dotted line box on the right side of the preceding figure. In the architecture, the Server Load Balancer (SLB) instance at the top layer forwards the client requests to the ECS instances in the scaling group. The ECS instances, which are at the middle layer, process the client requests. ApsaraDB RDS instances at the bottom layer store application data from the ECS instances.

You can use Auto Scaling to adjust the number of ECS instances at the middle layer based on your business requirements. The following procedure describes how Auto Scaling adjusts the number of ECS instances:

1. Auto Scaling triggers scaling activities when the conditions that are specified in the scaling modes are met. The following table describes the scaling modes that are supported by Auto Scaling. For information about how to configure scaling modes, see Configure a scaling mode.

   You can combine the scaling modes that are described in the following table based on your business requirements. For example, if your business loads significantly increase from 12:00:00 every day, you can create a scheduled task to automatically create 20 ECS instances at 12:00:00 every day. To ensure that the number of ECS instances meets your business requirements, you can combine the scheduled mode together with other scaling modes, such as the dynamic mode and the custom mode.

   Scaling mode	Description	User guide	API references
   Fixed-number mode	If you configure the Minimum Number of Instances parameter when you create a scaling group, Auto Scaling automatically adds ECS instances to the scaling group until the total number of ECS instances in the scaling group is equal to the value of the Minimum Number of Instances parameter. If you configure the Maximum Number of Instances parameter when you create a scaling group, Auto Scaling automatically removes ECS instances from the scaling group until the total number of ECS instances in the scaling group is equal to the value of the Maximum Number of Instances parameter. If you configure the Expected Number of Instances parameter when you create a scaling group, Auto Scaling automatically adds ECS instances to or removes ECS instances from the scaling group to maintain the expected number of ECS instances in the scaling group.	Manage scaling groups	CreateScalingGroup
   Health mode	If you enable the health check feature when you create a scaling group, Auto Scaling checks the status of the ECS instances in the scaling group at specified intervals. If Auto Scaling detects that an ECS instance does not run as expected, Auto Scaling considers the instance unhealthy and removes the instance from the scaling group. Note The health check feature is a built-in feature of Auto Scaling. If your scaling group is associated with an SLB instance for which the health check feature is enabled, the health check feature of Auto Scaling and the health check feature of the SLB instance take effect at the same time. The SLB instance may be a Classic Load Balancer (CLB) instance or an Application Load Balancer (ALB) instance.	Manage scaling groups	CreateScalingGroup
   Scheduled mode	You can create a scheduled task to automatically execute a scaling rule at a specified point in time.	Create a scheduled task	CreateScheduledTask
   Custom mode	You can manually perform scaling operations. For example, you can manually execute scaling rules or add, remove, or delete ECS instances.	Manage scaling rules Manually manage instances in a scaling group	ExecuteScalingRule AttachInstances DetachInstances RemoveInstances
   Dynamic mode	You can create an event-triggered task based on a performance metric that is monitored by CloudMonitor, such as the CPU utilization. If the metric value of the scaling group meets the specified alert condition, an alert is triggered and the specified scaling rule is executed. For example, if the average CPU utilization of all ECS instances in a scaling group exceeds 60%, an alert is triggered and the specified scaling rule is executed.	Manage event-triggered tasks	CreateAlarm

2. Auto Scaling calls the ExecuteScalingRule API operation to trigger scaling activities. In this API operation, Auto Scaling specifies the unique identifier of the scaling rule that you want to execute. Example: ari:acs:ess:cn-hangzhou:140692647406****:scalingrule/asr-bp1dvirgwkoowxk7****.

   • If you create a scaling rule in the Auto Scaling console, you can find the scaling rule in the scaling rule list and click the ID of the scaling rule in the Scaling Rule ID/Name column. On the page that appears, you can view the unique identifier of the scaling rule. Example: asr-bp14u7kzh8442w9z****. For information about how to create scaling rules, see Manage scaling rules.

   • If you call an API operation to create a scaling rule, you can call the DescribeScalingRules API operation to query the unique identifier of the scaling rule.

3. Auto Scaling uses the unique identifier to query information about the scaling rule, the scaling group, and the scaling configuration. Then, Auto Scaling triggers scaling activities.

   1. Auto Scaling uses the unique identifier to query information about the scaling rule and the scaling group to which the scaling rule applies. Then, Auto Scaling calculates the number of ECS instances that are required by your business. Auto Scaling also queries information about the SLB instance and the ApsaraDB RDS instances to which you want to attach the required ECS instances.

   2. Auto Scaling queries the information about the scaling configuration in the scaling group. The information includes the vCPUs, memory size, and bandwidth of the ECS instances that must be created.

   3. Auto Scaling triggers a scaling activity based on the following items: the required number of ECS instances, the instance configuration source, and the SLB instance and ApsaraDB RDS instances to which you want to attach the ECS instances.

4. During the scaling activity, Auto Scaling creates the required number of ECS instances, and then attaches the ECS instances to the SLB instance and ApsaraDB RDS instances.

   1. Auto Scaling creates the required number of ECS instances based on the instance configuration source.

   2. Auto Scaling adds the private IP addresses of the ECS instances that are created to the whitelists of the ApsaraDB RDS instances. Then, Auto Scaling adds the ECS instances as the backend servers of the SLB instance.

5. After the scaling activity is complete, Auto Scaling enables the cooldown time feature for the scaling group.

   The scaling group can receive new requests to execute scaling rules only after the cooldown time elapses.

Configure a scaling mode

Auto Scaling can automatically trigger scaling activities to add ECS instances to or remove ECS instances from a scaling group based on your configurations. You can configure scaling modes for Auto Scaling to trigger scaling activities. The following table describes the scaling modes.

The following table describes each configuration method.

Workflow diagrams

Auto Scaling allows you to associate your scaling group with one or more SLB instances and ApsaraDB RDS instances. When a client sends a request from a mobile device or a PC, the associated SLB instance forwards the request to an ECS instance in the scaling group. The ECS instance receives and processes the request. Then, the associated ApsaraDB RDS instances store the application data.

Auto Scaling adjusts the number of ECS instances in your scaling group based on your business requirements and the scaling modes that you configured. The following figures show the scaling processes and elastic recovery (health check) events in Auto Scaling.