本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Amazon EC2 Auto Scaling 的动态扩缩
动态扩缩会根据流量的变化扩展自动扩缩组的容量。
Amazon EC2 Auto Scaling 支持以下类型的动态扩缩策略:
-
目标跟踪扩展-根据 Amazon CloudWatch 指标和目标值增加和减少群组的当前容量。这与温控器保持家里温度的方式类似——您只需选择一个温度,剩余的工作将由温控器完成。
-
Step scaling(步进分步)– 通过一系列扩缩调整(也称步进调整)来增加和减少组的当前容量,具体调整因警报严重程度而异。
-
Simple scaling(简单扩缩)– 通过单次扩缩调整来增加和减少组的当前容量,每次扩缩活动之间有一个冷却时间。
我们强烈建议您使用目标跟踪扩展策略,并选择与 Auto Scaling 组容量变化成反比变化的指标。因此,如果您将 Auto Scaling 组的规模增加 50%,则该指标将减少 50%。这使指标数据能够准确触发按比例扩缩事件。其中包括平均 CPU 利用率或每个目标的平均请求数等指标。
通过目标跟踪,您的 Auto Scaling 组可以根据应用程序的实际负载成正比进行扩展。这意味着,除根据负载变化满足当前容量需求外,目标跟踪策略还可以适应持续的负载变化,例如由于季节性变化而导致的负载变化。
目标跟踪策略还无需手动定义 CloudWatch 警报和缩放调整。Amazon EC2 Auto Scaling 会根据你设定的目标自动处理这个问题。
内容
动态扩缩策略的工作方式
动态扩展策略指示 Amazon EC2 Auto Scaling 跟踪特定 CloudWatch 指标,并定义当相关 CloudWatch 警报处于警报状态时要采取的操作。用于调用警报状态的指标是来自自动扩缩组中所有实例的指标聚合。(例如,假设您有一个 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 消息数增加和移除容量的目标跟踪策略。另一种是分步扩展策略,当实例在指定时间长 CloudWatch CPUUtilization
度内超过 90% 的使用率时,该策略使用 Amazon 指标来增加容量。
如果同时实施多个策略,各个策略可能会同时指示 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 删除过多实例。
不过,在将目标跟踪扩展策略与步进扩展策略结合使用时,我们建议您务必谨慎,因为这些策略之间的冲突可能会导致意外的行为。例如,如果步进扩展策略在目标跟踪策略准备执行缩减之前启动缩减活动,则不会阻止缩减活动。在缩减活动完成后,目标跟踪策略可能会指示组重新横向扩展。