Amazon A EC2 uto Scaling 的动态扩展 - Amazon A EC2 uto Scaling
动态扩缩策略的工作方式多个动态扩缩策略

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

Amazon A EC2 uto Scaling 的动态扩展

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

Amazon A EC2 uto Scaling 支持以下类型的动态扩展策略：

  • 目标跟踪扩展-根据 Amazon CloudWatch 指标和目标值增加和减少群组的当前容量。这与温控器保持家里温度的方式类似——您只需选择一个温度，剩余的工作将由温控器完成。

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

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

我们强烈建议您使用目标跟踪扩展策略，并选择与 Auto Scaling 组容量变化成反比变化的指标。因此，如果您将 Auto Scaling 组的规模增加一倍，则该指标将减少 50%。这使指标数据能够准确触发按比例扩缩事件。其中包括诸如平均CPU利用率或每个目标的平均请求数之类的指标。

通过目标跟踪，您的 Auto Scaling 组可以根据应用程序的实际负载成正比进行扩展。这意味着，除根据负载变化满足当前容量需求外，目标跟踪策略还可以适应持续的负载变化，例如由于季节性变化而导致的负载变化。

目标跟踪策略还无需手动定义 CloudWatch 警报和缩放调整。Amazon A EC2 uto Scaling 会根据你设定的目标自动处理这个问题。

内容

动态扩缩策略的工作方式

动态扩展策略指示 Amazon A EC2 uto Scaling 跟踪特定 CloudWatch 指标，并定义在ALARM关联 CloudWatch 警报出现时要采取的操作。用于调用警报状态的指标是来自自动扩缩组中所有实例的指标聚合。（例如，假设您有一个 Auto Scaling 组，其中有两个实例，其中一个实例为 60%CPU，另一个实例为 40% CPU。 平均而言，这一比例为50％ CPU。） 策略生效后，当警报阈值被突破时，Amazon A EC2 uto Scaling 会向上或向下调整组的所需容量。

调用动态扩展策略时，如果容量计算得出的数字超出了组的最小和最大大小范围，Amazon A EC2 uto Scaling 将确保新容量永远不会超出最小和最大大小限制。容量通过以下两种方式之一进行测量：使用您在根据实例设置所需容量时选择的相同单位，或者使用容量单位（如果应用了实例权重）。

  • 示例 1：Auto Scaling 组的最大容量为 3，当前容量为 2，并有增加 3 个实例的动态扩缩策略。在调用此策略时，Amazon A EC2 uto Scaling 仅向该组添加 1 个实例，以防止该组超过其最大大小。

  • 示例 2：Auto Scaling 组的最小容量为 2，当前容量为 3，并有移除 2 个实例的动态扩缩策略。在调用此策略时，Amazon A EC2 uto Scaling 仅从该组中移除 1 个实例，以防止该组小于其最小大小。

当所需容量达到最大大小限制时，向外扩展停止。如果需求下降而容量减少，Amazon A EC2 uto Scaling 可以再次进行扩展。

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

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

多个动态扩缩策略

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

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

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

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

发生这些情况时，Amazon A EC2 uto Scaling 会选择为横向扩展和向内扩展提供最大容量的策略。例如，假设的策略CPUUtilization启动一个实例，而SQS队列的策略启动两个实例。如果同时满足两个策略的扩展标准，Amazon A EC2 uto Scaling 将优先考虑SQS队列策略。这会导致 Auto Scaling 组启动两个实例。

即使策略使用不同的扩展条件，使提供最大容量的策略具有优先级的方法也适用。例如，如果一个策略终止了三个实例，另一个策略将实例数量减少了 25%，并且该组在缩小规模时有八个实例，那么 Amazon A EC2 uto Scaling 会优先考虑为该组提供最大实例数量的策略。这会导致 Auto Scaling 组终止两个实例（8 X 25% = 2）。其目的是防止 Amazon A EC2 uto Scaling 删除过多的实例。

不过，在将目标跟踪扩展策略与步进扩展策略结合使用时，我们建议您务必谨慎，因为这些策略之间的冲突可能会导致意外的行为。例如，如果分步扩展策略在目标跟踪策略准备好扩大规模之前启动活动规模，则活动规模不会被阻止。活动规模完成后，目标跟踪策略可以指示该小组再次扩大规模。