使用 EC2 Auto Scaling 调整真实应用容量

简介

应用有时需要更多服务器，之后又需要减少。本实验将定义两个扩缩策略，把真实实例池从两台扩展到三台再回到两台。你会确认实际 HTTP 响应，并观察组的上下限如何阻止继续增加或减少。

你应已理解启动模板、Auto Scaling 组及 ALB 健康检查。本次全新环境独立提供名为 application-fleet 的健康双实例组、模板、网络和负载均衡器，不复用前面实验的资源。

认证考点关联

本实验为 SAA-C03 Domain 2 和 SOA-C03 Domain 2 中 Auto Scaling 容量、扩缩动作和负载均衡集成提供入门实践。

定义扩缩策略

本步骤检查已提供的实例池并创建策略，但不改变容量。

进入工作目录，查看组的初始容量：

cd /home/labex/project

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'

TG_ARN=$(aws elbv2 \
  describe-target-groups \
  --names application-targets \
  --query 'TargetGroups[0].TargetGroupArn' \
  --output text)

LB_DNS=$(aws elbv2 \
  describe-load-balancers \
  --names application-alb \
  --query 'LoadBalancers[0].DNSName' \
  --output text)

aws elbv2 \
  wait target-in-service \
  --target-group-arn "$TG_ARN"

预期最小 2、期望 2、最大 3，且 AWS View 中有两个健康目标。扩缩策略定义容量调整。ChangeInCapacity 增减绝对数量：1 增加一台，-1 减少一台。

创建两个 SimpleScaling 策略。冷却时间通常让简单扩缩动作稳定后，才响应下一次告警触发动作。此处保存为 30 秒：

aws autoscaling \
  put-scaling-policy \
  --auto-scaling-group-name application-fleet \
  --policy-name add-one-server \
  --policy-type SimpleScaling \
  --adjustment-type ChangeInCapacity \
  --scaling-adjustment 1 \
  --cooldown 30

aws autoscaling \
  put-scaling-policy \
  --auto-scaling-group-name application-fleet \
  --policy-name remove-one-server \
  --policy-type SimpleScaling \
  --adjustment-type ChangeInCapacity \
  --scaling-adjustment -1 \
  --cooldown 30

aws autoscaling \
  describe-policies \
  --auto-scaling-group-name application-fleet \
  --query 'ScalingPolicies[].{Name:PolicyName,Type:PolicyType,Adjustment:ScalingAdjustment,Cooldown:Cooldown}'

创建策略不会执行策略。本实验显式使用 --no-honor-cooldown 调用，便于观察受控变化，不演示冷却时间计时或 CloudWatch 告警。生产中指标触发策略通过告警执行，目标跟踪则跟随目标指标值。这里不测试自动指标反馈或 CPU 负载。

扩容到三台服务器

本步骤执行正向策略，并验证新增服务器真正处理请求。

扩容增加实例。执行策略并等待 ALB 就绪：

aws autoscaling \
  execute-policy \
  --auto-scaling-group-name application-fleet \
  --policy-name add-one-server \
  --no-honor-cooldown

aws elbv2 \
  wait target-in-service \
  --target-group-arn "$TG_ARN"

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'

预期期望容量 3 和三个当前 ID。组使用启动模板启动新服务器，并自动注册到目标组。

已达到最大值时，再执行一次相同策略，然后查看容量：

aws autoscaling \
  execute-policy \
  --auto-scaling-group-name application-fleet \
  --policy-name add-one-server \
  --no-honor-cooldown

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'

容量保持 3，策略调整不能超过组的最大值。这限制服务器数量，不限制单台服务器处理的请求数量。

发送九个请求，将响应 ID 与三个当前实例对照：

for request in 1 2 3 4 5 6 7 8 9; do
  curl --config client.conf -sS "http://$LB_DNS/health"
  echo
done

打开 AWS View。确认期望 3、三个健康目标，并通过 Send request 观察三个 ID 的实际 200 响应。仅在 API 响应中增加资源并不能证明它处理流量。

三台服务实例

示例：期望容量为三台，新增服务器返回 HTTP 200。你的实例 ID 会不同。

缩容并保持最小容量

本步骤减少容量，并确认两台应用服务器仍可用。

缩容减少实例。执行负向策略，并等待当前目标健康：

aws autoscaling \
  execute-policy \
  --auto-scaling-group-name application-fleet \
  --policy-name remove-one-server \
  --no-honor-cooldown

aws elbv2 \
  wait target-in-service \
  --target-group-arn "$TG_ARN"

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Instances:Instances[].InstanceId}'

aws ec2 \
  describe-instances \
  --filters "Name=tag:aws:autoscaling:groupName,Values=application-fleet" \
  --query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'

预期两个当前 ID 和一台 terminated 实例。组决定移除哪台，不要假设总会选择最新服务器。已移除实例不应继续属于目标组的服务集合。

已达到最小值时，再执行一次负向策略，然后查看容量：

aws autoscaling \
  execute-policy \
  --auto-scaling-group-name application-fleet \
  --policy-name remove-one-server \
  --no-honor-cooldown

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Instances:Instances[].InstanceId}'

期望容量保持 2，策略不能让组低于最小值。发送六个请求，确认剩余实例池可用：

for request in 1 2 3 4 5 6; do
  curl --config client.conf -sS "http://$LB_DNS/health"
  echo
done

在 AWS View 中确认两个健康目标和两个当前 ID 的 200 响应。终止 ID 不应出现在新响应中。本练习检查生命周期和路由，不测量缩容排空时间或应用会话保留。

删除策略并保留已准备的实例池

本步骤在已提供实例池回到两台后，删除你的策略配置。

删除两个策略，查看剩余策略列表：

aws autoscaling \
  delete-policy \
  --auto-scaling-group-name application-fleet \
  --policy-name add-one-server

aws autoscaling \
  delete-policy \
  --auto-scaling-group-name application-fleet \
  --policy-name remove-one-server

aws autoscaling \
  describe-policies \
  --auto-scaling-group-name application-fleet \
  --query 'ScalingPolicies[].PolicyName'

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize}'

策略列表应为 []，组容量保持最小 2、期望 2、最大 3。删除策略不会终止现有实例池。保留已提供的组、模板、负载均衡器和网络；AWS View 应仍显示两个健康服务器。

总结

你定义了正向和负向简单扩缩策略，观察真实服务器从两台扩到三台再缩回两台，并测试了两个容量边界。你检查实际 HTTP 响应和原生实例终止，最后删除策略并保留恢复后的实例池。

现在你能区分策略配置、显式执行和指标触发。挑战将运用本课程的路由和健康检查诊断技能，处理新服务器收不到流量的问题。

使用扩缩策略改变应用容量

简介

认证考点关联

定义扩缩策略

扩容到三台服务器

缩容并保持最小容量

删除策略并保留已准备的实例池

总结