Auto Scaling 为何扩容快而缩容慢 - 非对称判断逻辑的设计意图
详解 EC2 Auto Scaling 即时执行扩容而对缩容设置冷却期的非对称设计原因、防抖动机制以及目标追踪扩缩容的内部逻辑。
扩容与缩容的非对称性
EC2Auto Scaling 的默认设置中，扩容（添加实例）的冷却期为 0 秒（即时执行），缩容（删除实例）的冷却期为 300 秒（5 分钟）。这种非对称设置有明确的设计意图。扩容延迟会直接影响用户。流量急增时如果不添加实例，响应时间会恶化，最坏情况下服务会宕机。因此扩容应尽可能快速执行。另一方面，缩容过快会导致抖动（频繁的扩容和缩容循环）。流量暂时减少后删除实例，紧接着流量再次增加又添加实例，这种无效循环会反复发生。由于实例启动需要数分钟，抖动会同时导致性能下降和成本增加。
冷却期（Cooldown）的机制
冷却期是在执行扩缩容操作后抑制下一次扩缩容操作的时间。扩容冷却期间会抑制额外扩容，但可以执行缩容。反之，缩容冷却期间会抑制额外缩容，但可以执行扩容。这种设计确保不会出现「需要扩容但因为在缩容冷却期间而无法执行」的情况。冷却期的最优值取决于工作负载特性。如果 EC2 实例从启动到通过 ELB 健康检查需要 3 分钟，则扩容冷却期应设为 3 分钟以上。冷却期过短时，新实例尚未处理流量就被判断为「仍然不够」，导致过度扩容。使用目标追踪扩缩容策略时，冷却期会自动管理，无需手动设置。
目标追踪扩缩容的内部逻辑
目标追踪扩缩容（Target Tracking Scaling）是最推荐的扩缩容策略，通过自动调整实例数来维持指定指标的目标值。例如将 CPU 使用率目标设为 50%，Auto Scaling 会增减实例数以维持 CPU 使用率在 50%。内部采用类似 PID 控制器（比例-积分-微分控制）的算法运行。根据当前指标值与目标值的差（偏差）计算所需实例数。偏差越大，一次添加或删除的实例数越多。目标追踪扩缩容的重要特性是内部为扩容和缩容分别创建不同的告警。扩容告警在 3 分钟评估期内连续 3 次超过阈值时触发，缩容告警在 15 分钟评估期内连续 15 次低于阈值时触发。这种非对称的评估期实现了「快速扩容、谨慎缩容」。
缩容时删除实例的选择逻辑
执行缩容时，按默认终止策略决定删除哪个实例。默认逻辑分 3 步。第一，选择实例数最多的可用区。这样可维持可用区间的实例数平衡。第二，在该可用区内选择使用最旧启动配置（Launch Configuration）或启动模板（Launch Template）的实例。这样优先删除旧配置的实例，促进向新配置迁移。第三，如果有多个使用相同启动配置的实例，选择最接近下一个计费时间的实例。EC2 引入按秒计费后这一标准的实际意义已减弱，但逻辑仍保留。也可设置自定义终止策略。可选择 NewestInstance（删除最新实例）、OldestInstance（删除最旧实例）、ClosestToNextInstanceHour（删除最接近下一计费时间的实例）等策略。
预测性扩缩容 - 从历史模式预测未来
2021 年推出的预测性扩缩容（Predictive Scaling）通过机器学习分析过去 14 天的流量模式，预测未来流量并提前配置实例。例如每天早上 9 点流量急增的模式下，预测性扩缩容会在 8:50 左右开始添加实例，为 9 点的流量高峰做准备。响应式扩缩容（流量增加后才添加实例）由于实例启动和注册到 ELB 需要数分钟，在流量急增初期会出现性能下降。预测性扩缩容填补了这一空白。建议将预测性扩缩容与目标追踪扩缩容配合使用。预测性扩缩容提前配置「预期的基线」，目标追踪扩缩容应对「意外的波动」，形成分工协作。预测性扩缩容的预测精度取决于流量模式的规律性。每天重复相同模式的工作负载可获得高精度，但不规则的流量模式下预测可能偏差。如需系统学习扩缩容设计模式，可参考专业书籍（Amazon）。