伸缩组概述

更新时间:
复制 MD 格式

A scaling group is a core component of Auto Scaling. It manages instances that share the same application requirements and instance types. A scaling group lets you quickly scale out instances in your cluster. It can also dynamically adjust the number of instances based on your business needs, helping you reduce costs.

Why use a scaling group

  • Rapidly scale out for high availability

    You can use a scaling group to quickly scale out your service cluster. By adding more instances, you increase your cluster's capacity to handle traffic.

  • Manage costs

    Scaling out adds computing resources and increases costs. However, because traffic is not always at its peak, Auto Scaling aligns resources with actual demand, reducing costs by removing unneeded instances.

Scaling solutions

Solution 1: Maintain a fixed number of instances

  • Use cases: Maintain high availability for a cluster that does not require scaling.

  • How it works: Enable instance health check and configure the Expected Number of Instances for the scaling group.

    When instance health check is enabled, the scaling group automatically removes unhealthy instances. If the number of instances falls below the expected count, Auto Scaling triggers a scale-out to maintain a fixed number of healthy instances.

  • Example

    If you want to maintain a cluster of 10 healthy service instances, set the Expected Number of Instances to 10. The scaling group will automatically trigger scaling activities to maintain 10 healthy instances.

Solution 2: Scheduled scaling

  • Use cases: Handle predictable, recurring changes in business workloads.

  • How it works: Create a Scheduled Tasks for the scaling group to automate scale-out and scale-in events.

    The scheduled task triggers a scale-out when resource demand is high and a scale-in when demand is low. For a complete guide, see Scale ECS instances on a schedule.

  • Example

    For example, if traffic increases at 7:00 PM and decreases at 1:00 AM daily, you can create two scheduled tasks.

    • Handle traffic spikes: Set up a scheduled scale-out task for 7:00 PM. Every day at 7:00 PM, the task adds instances to increase the cluster's capacity.

    • Handle traffic lulls: Set up a scheduled scale-in task for 1:00 AM. Every day at 1:00 AM, the task removes instances to improve resource utilization and reduce costs.

Solution 3: Threshold-based scaling (CPU, memory utilization, etc.)

  • Use cases: Respond to sudden, unpredictable workload changes by triggering scaling when a resource metric crosses a defined threshold.

  • How it works

    Event-triggered task

    You can set up an Event-triggered Tasks for your scaling group. When a resource metric crosses a specified threshold, an alarm triggers a scaling activity.

    Add or remove a fixed number of instances

    You can set up an Event-triggered Tasks and specify a Simple Scaling Rule to execute when the alarm is triggered. This rule scales out or scales in your group in response to the event.

    Effect

    A simple scaling rule adds or removes a specific number of instances or sets the total instance count to a specific value.

    • When average cluster CPU utilization exceeds 80%, add N instances.

    • When average cluster CPU utilization drops below 70%, remove N instances.

    For a complete guide, see Scale ECS instances based on workload.

    Add or remove instances in tiers based on utilization

    You can create a Step Scaling Rule and an associated Event-triggered Tasks. When the alarm is triggered, the system scales out or in based on predefined utilization tiers.

    Important

    Scaling groups for Elastic Container Instance do not support Step Scaling Rule.

    Effect

    When an event-triggered task is triggered, the scaling group scales in or out based on tiers of average cluster CPU utilization.

    • If average CPU utilization is between 60% and 70%, remove 1 instance.

    • If average CPU utilization is between 30% and 60%, remove 3 instances.

    • If average CPU utilization is below 30%, remove 5 instances.

    Target tracking rule

    You can create a Target Tracking Scaling Rule to keep a resource metric for your scaling group at or near a target value.

    Example

    For an ECS scaling group, you can create a target tracking scaling rule that sets the target for average CPU utilization at 80%. Auto Scaling will automatically add or remove instances to keep the group's average CPU utilization at or near 80%.

  • Comparing the two methods

    • Event-triggered tasks offer greater flexibility and customization. You can control exactly how many instances to add or remove when an alarm is triggered, and you can define different scaling responses for various resource utilization tiers.

    • Target tracking scaling rules are simpler to configure. You only need to define the target value for a metric, and Auto Scaling handles the rest.

Solution 4: Custom scaling (manual scaling)

If these solutions do not meet your needs, you can create a custom scaling solution.

You can trigger scaling activities by manually executing a scaling rule or by changing the number of instances in a scaling group. For a complete guide, see Manually scale ECS instances with one click.

Note

Manual scaling supports API calls. You can write your own programs to call the API and build a custom scaling solution tailored to your business.

Solution 5: Predictive Scaling

In addition to the solutions above, scaling groups can also forecast future resource demand and scale automatically.

You implement this solution by configuring a prediction rule. You can first run it in a forecast-only mode to assess its accuracy. If the forecast meets your needs, you can enable Predict and Scale for the rule. When enabled, the prediction rule automatically creates scheduled tasks based on the forecast to scale the group. For details, see View the effect of a predictive scaling rule.

Usage notes

Before using a scaling group, ensure your application supports scaling out.

Auto Scaling expands instance capacity by scaling out. Therefore, you must consider whether scaling out your instances will affect your cluster's business operations.

  • Data consistency

    If your databases are deployed on the instances being scaled, scaling out can lead to data inconsistencies. To avoid this, consider adjusting your architecture. For example, deploy your database independently and have all instances share a single database, which makes your services stateless.

  • Data security

    Instances in a scaling group are created and released automatically. If you store data on these instances, back it up properly to ensure its security.

Using a scaling group

Get started

Advanced use cases

Application deployment

  • Use an image with pre-packaged software for automatic deployment

    • ECS scaling groups.

      Build a custom image that includes your application packages and then set this image as the source in the instance configuration.

    • Scaling groups for Elastic Container Instance.

      Build a Docker image for your application and then set this image as the source in the instance configuration.

  • Automatically run deployment scripts when an instance starts

    • Instance User Data solution

      When using an ECS scaling group, you can set user data for instances. In the user data, you can run scripts to deploy application packages. For details, see Use instance user data to automatically configure ECS instances.

    • Lifecycle hook solution

      When using an ECS scaling group, you can set a lifecycle hook. After a scale-out is triggered and before the new instance is added to the group, you can run deployment scripts on the instance. For details, see Automatically run scripts on ECS instances.

Rolling update

You can use the Rolling Update feature to update instance images in a scaling group or run scripts across multiple instances in batches. For details, see Rolling Update.

Associate a cloud database

You can assign the same security group to the scaling group or automatically add new instances to the IP address whitelist of a cloud database. This ensures that new instances can access the database.

References

Associate a load balancer

If the instance cluster in your scaling group uses a load balancer as an access point, you can associate the load balancer with the scaling group. Once associated, new instances are automatically added to the backend server group of the load balancer.

References

Custom operations

You can use a lifecycle hook to perform custom operations, such as mounting a NAS file system, binding an EIP, or running custom scripts, before an instance is added to or removed from a scaling group.

References

Design a scale-in policy

When your business workload decreases, the scaling group triggers a scale-in activity based on your policy, automatically reducing resources to prevent waste. During a scale-in, you might need to control the frequency, perform a graceful scale-in, or choose which instances to remove. For guidance, refer to the following document.

References

Optimize resource costs

After setting up a scaling group, you can further reduce costs by incorporating spot instances and using cost optimization policies.

References

Disaster recovery and availability

When using a scaling group, scale-out activities might fail due to insufficient instance inventory in an availability zone. You can mitigate this risk by configuring multiple availability zones and instance types. You can also implement a Balanced Distribution Policy for multi-zone disaster recovery.

References

Scale Kubernetes nodes

Use Kubernetes to implement elastic scaling of nodes.

References