This topic describes the common terms used in Auto Scaling.
Terms
Term | Description | References |
---|---|---|
Auto Scaling | Auto Scaling is a service that automatically changes the number of instances to adjust the computing power based on the business requirements and policies. Auto Scaling can scale Elastic Compute Service (ECS) instances and elastic container instances. Auto Scaling automatically adds instances of the specified type during peak hours to ensure sufficient computing power. Auto Scaling automatically removes instances of the specified type during off-peak hours to reduce resource costs. | What is Auto Scaling? |
scaling group | A scaling group is a group of instances that can be used for the same scenario. Instances within a scaling group must be of the same type. You can specify the minimum and maximum numbers of instances in a scaling group, and associate Server Load Balancer (SLB) instances and ApsaraDB RDS instances with the scaling group. | Overview |
ECS instance | An ECS instance is a virtual server that includes basic computing components such as vCPU, memory, operating system, bandwidth, and disk. ECS eliminates the need for upfront investments in IT hardware and allows you to scale computing resources on demand. This makes ECS instances more convenient and efficient than physical servers. | What is ECS? |
elastic container instance | Elastic Container Instance is a container service provided by Alibaba Cloud that combines container and serverless technologies. | What is Elastic Container Instance? |
SLB instance | SLB is a service that forwards network traffic to backend servers to increase the throughput of your applications. You can use SLB to prevent service interruptions that are caused by single points of failure (SPOFs) and improve the availability of applications. | SLB overview |
ApsaraDB RDS instance | ApsaraDB RDS is a stable and reliable online database service that supports elastic scaling. ApsaraDB RDS supports mainstream database engines and provides a variety of database solutions, such as disaster recovery, backup, restoration, monitoring, and migration. | What is ApsaraDB RDS? |
scaling mode | A scaling mode specifies when to add or remove a specific number of instances for a scaling group. Scaling modes include scheduled mode, dynamic mode, fixed quantity mode, custom mode, health mode, and multi-mode. | Scaling modes |
instance configuration source | Auto Scaling uses the instance configuration source that you select to create instances. The instance configuration source can be a scaling configuration or a launch template. | Overview of instance configuration sources |
scaling configuration | A scaling configuration is a type of instance configuration source and includes the configuration information of instances. | Create a scaling configuration (Elastic Compute Service) |
scaling rule |
|
Overview |
scaling task | Scaling tasks are categorized into scheduled tasks and event-triggered tasks. A scheduled task can be used to scale instances at a specified time. An event-triggered task can be used to dynamically scale instances based on specified monitoring metrics. | |
scaling activity | A scaling activity records the changes in the number of instances within a scaling group, the boundary values of the scaling group, and the expected number of instances. Scaling activities are triggered when scaling rules are executed, the boundary values of a scaling group are modified, or the expected number of instances is modified. | View the details of a scaling activity |
expected number of instances | After the Expected Number of Instances feature is enabled, Auto Scaling automatically
maintains the number of instances at the expected value.
Note To enable the Expected Number of Instances feature, you must set the Expected Instances
parameter when you create a scaling group. The specified expected number of instances
in the scaling group can be modified.
|
Expected number of instances |
Parallel scaling activity | A scaling activity triggered by using one of the following methods is a parallel scaling
activity:
A parallel scaling activity can be executed if the ongoing scaling activities are
also parallel scaling activities.
Note Parallel scaling activities and non-parallel scaling activities are differentiated
only if the Expected Number of Instances feature is enabled. If the Expected Number
of Instances feature is disabled, no other scaling activities can be executed when
a scaling activity is in progress.
|
Expected number of instances |
Non-parallel scaling activity | Scaling activities other than parallel activities are non-parallel scaling activities.
No other scaling activities can be triggered when a non-parallel scaling activity
is in progress.
Note Parallel scaling activities and non-parallel scaling activities are differentiated
only if the Expected Number of Instances feature is enabled. If the Expected Number
of Instances feature is disabled, no other scaling activities can be executed when
a scaling activity is in progress.
|
Expected number of instances |
stable instance | A stable instance refers to an ECS instance that is in the In Service, Protected, or Standby state in a scaling group. | ECS instance lifecycle |
scaling process | A scaling process refers to a process that you can manually suspend and resume, such as the scale-out, scale-in, health check, scheduled task, and event-triggered task. Scaling processes help you control scaling groups at the process level. | |
ECS instance lifecycle | The lifecycle of an ECS instance in a scaling group refers to the process from the
time when the instance is created to the time when it is released. The lifecycle management
mode of an ECS instance depends on how the instance is created.
|
ECS instance lifecycle |
lifecycle hook | A lifecycle hook allows ECS instances that are being added to or removed from a scaling group to enter the Pending state. After the ECS instances enter the Pending state, you can perform custom operations on them. For example, after an ECS instance is created, you can use a lifecycle hook to allow the instance to enter the Pending state. You can perform tests on the instance to ensure its service availability. Then, Auto Scaling adds the instance as a backend server to an associated SLB instance. | Create a lifecycle hook |
cooldown time | The cooldown time refers to a period during which Auto Scaling cannot execute new scaling activities after one scaling activity is complete in a scaling group. During the cooldown time, Auto Scaling rejects all scaling activity requests of event-triggered tasks from CloudMonitor. This prevents scaling activities from being frequently triggered due to fluctuations in the metric value. | Cooldown time |