Amazon EC2 Auto Scaling 的动态扩缩 - Amazon EC2 Auto Scaling
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

Amazon EC2 Auto Scaling 的动态扩缩

动态扩缩会根据流量的变化扩展自动扩缩组的容量。

Amazon EC2 Auto Scaling 支持以下类型的动态扩缩策略:

  • Target tracking scaling(目标跟踪扩缩)– 根据某个 Amazon CloudWatch 指标和目标值增加或减少组的当前容量。这与温控器保持家里温度的方式类似——您只需选择一个温度,剩余的工作将由温控器完成。

  • Step scaling(步进分步)– 通过一系列扩缩调整(也称步进调整)来增加和减少组的当前容量,具体调整因警报严重程度而异。

  • Simple scaling(简单扩缩)– 通过单次扩缩调整来增加和减少组的当前容量,每次扩缩活动之间有一个冷却时间。

如果扩缩活动所基于的指标会按比例增减自动扩缩组中的实例数量,我们建议您使用目标跟踪扩缩策略。否则,我们建议您使用步进扩展策略。

使用目标跟踪扩缩策略时,自动扩缩组会根据应用程序的实际负载按比例扩缩。这意味着,除根据负载变化满足当前容量需求外,目标跟踪策略还可以适应持续的负载变化,例如由于季节性变化而导致的负载变化。

默认情况下,新自动扩缩组在启动时没有任何扩缩策略。如果自动扩缩组不进行任何形式的动态扩缩,除非您设置了计划扩缩或预测性扩缩,否则该组不会自行扩缩。

动态扩缩策略的工作方式

动态扩缩策略指示 Amazon EC2 Auto Scaling 跟踪特定 CloudWatch 指标,并定义当关联的 CloudWatch 警报处于 ALARM 状态时要采取的操作。用于调用警报状态的指标是来自自动扩缩组中所有实例的指标聚合。(例如,假设您有一个 Auto Scaling 组,其中有两个实例,一个实例的 CPU 利用率为 60%,另一个实例的 CPU 利用率为 40%。CPU 平均利用率为 50%。) 策略生效后,在超过警报的阈值时,Amazon EC2 Auto Scaling 向上或向下调整组的所需容量。

如果调用动态扩缩策略,容量计算生成的数字超出了组的最小和最大大小范围,则 Amazon EC2 Auto Scaling 确保新容量永远不会超出最小和最大大小限制。容量通过以下两种方式衡量:使用您在以实例数设置所需容量时选择的相同单位;或者使用容量单位(如果应用了实例权重)。

  • 示例 1:Auto Scaling 组的最大容量为 3,当前容量为 2,并有增加 3 个实例的动态扩缩策略。调用此策略后,Amazon EC2 Auto Scaling 仅向组添加 1 个实例,以防止组超出其最大大小。

  • 示例 2:Auto Scaling 组的最小容量为 2,当前容量为 3,并有移除 2 个实例的动态扩缩策略。调用执行此策略后,Amazon EC2 Auto Scaling 仅从组中移除 1 个实例,以防止组小于其最小大小。

当所需容量达到最大大小限制时,向外扩展停止。如果需求下降并且容量下降,则 Amazon EC2 Auto Scaling 会再次扩展。

但使用实例权重时例外。在这种情况下,Amazon EC2 Auto Scaling 可以扩展超过最大大小限制,但上限为您的最大实例权重。其目的是尽可能接近新的所需容量,但仍然遵循为该组指定的分配战略。分配策略决定要启动的实例类型。权重根据实例类型确定每个实例向所需的组容量贡献的容量单位数。

  • 示例 3:Auto Scaling 组的最大容量为 12,当前容量为 10,并有增加 5 个容量单位的动态扩缩策略。向实例类型分配三个权重之一:1、4 或 6。调用策略后,Amazon EC2 Auto Scaling 根据分配策略,选择启动权重为 6 的实例类型。此横向扩展事件的结果是得到所需容量为 12、当前容量为 16 的组。

多个动态扩缩策略

在大多数情况下,目标跟踪扩缩策略就足以将您的 Auto Scaling 组配置为自动扩展和缩减。目标跟踪扩缩策略允许您选择所需结果,并让 Auto Scaling 组根据需要添加和删除实例以实现该结果。

对于高级扩缩配置,您的 Auto Scaling 组可以有多个扩缩策略。例如,您可以定义一个或多个目标跟踪扩展策略,一个或多个步进扩展策略,或者同时使用两种策略。这样可以更灵活地覆盖多种场景。

为了说明多个扩缩策略如何协同工作,请设想一个应用程序,它使用一个 Auto Scaling 组和 Amazon SQS 队列将请求发送到单个 EC2 实例。为了帮助确保应用程序性能达到最佳级别,有两个策略用于控制何时扩缩 Auto Scaling 组。一个是使用自定义指标、根据队列中的 SQS 消息数增加和移除容量的目标跟踪策略。另一个是步进扩缩策略,它使用 Amazon CloudWatch CPUUtilization 指标,当实例在指定时间长度内的使用率超过 90% 时增加容量。

如果同时实施多个策略,各个策略可能会同时指示 Auto Scaling 组扩展(或缩减)。例如,在 SQS 自定义指标达到峰值并超过自定义指标警报的阈值时,CPUUtilization 指标可能会达到峰值并超过 CloudWatch 警报的阈值。

如果发生上述情况,Amazon EC2 Auto Scaling 会选择在扩展和缩减时都提供最大容量的策略。例如,假定 CPUUtilization 策略启动一个实例,而 SQS 队列的策略启动两个实例。如果同时满足两个策略的扩展条件,Amazon EC2 Auto Scaling 优先选择 SQS 队列策略。这会导致 Auto Scaling 组启动两个实例。

即使策略使用不同的扩展条件,使提供最大容量的策略具有优先级的方法也适用。例如,如果一个策略终止三个实例,另一个策略将实例数量减少 25%,且在缩减时组中有八个实例,则 Amazon EC2 Auto Scaling 会优先考虑为组提供最大数量实例的策略。这会导致 Auto Scaling 组终止两个实例(8 X 25% = 2)。目的是防止 Amazon EC2 Auto Scaling 删除过多实例。

不过,在将目标跟踪扩展策略与步进扩展策略结合使用时,我们建议您务必谨慎,因为这些策略之间的冲突可能会导致意外的行为。例如,如果步进扩展策略在目标跟踪策略准备执行缩减之前启动缩减活动,则不会阻止缩减活动。在缩减活动完成后,目标跟踪策略可能会指示组重新横向扩展。