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

Amazon EC2 Auto Scaling 的预测式扩展

使用预测式扩展可在流量流的每日和每周模式之前增加 Auto Scaling 组中的 EC2 实例数。

预测式扩展非常适合以下情况:

  • 周期性流量,例如正常营业时间内的高资源利用率以及晚上和周末的低资源利用率

  • 重复的打开和关闭工作负载模式,例如批处理、测试或定期数据分析

  • 初始化需要很长时间的应用程序,从而在向外扩展事件期间对应用程序性能造成明显的延迟影响

一般来说,如果您有定期的流量增长模式以及需要很长时间才能初始化的应用程序,则应考虑使用预测式扩展。与仅使用动态扩展相比,预测式扩展可以通过在预测负载之前启动容量来帮助您更快地扩展。预测式扩展还可以帮助您避免需要过度配置容量,从而节省 EC2 账单上的资金。

例如,考虑在营业时间内具有高利用率以及夜间具有低利用率的应用程序。在每个工作日开始时,预测式扩展可以在流量第一次涌入之前增加容量。这有助于您的应用程序在利用率较低的时期内保持高可用性和性能。您不必等待动态扩展来响应不断变化的流量。您也不必花时间查看应用程序的负载模式,并尝试使用计划扩展计划适当的容量。

使用 Amazon Web Services Management Console、Amazon CLI 或其中一个 SDK,将预测式扩展策略添加到任何 Auto Scaling 组。

预测式扩展的工作方式

预测式扩展使用机器学习来根据 CloudWatch 的历史数据预测容量需求。机器学习算法会消耗可用的历史数据并计算最适合历史负载模式的容量,然后根据新数据不断学习,以使未来的预测更加准确。

要使用预测式扩展,首先需要创建包含一对指标和目标利用率的扩展策略。如果至少有 24 小时的历史数据,则在创建策略后立即开始创建预测。预测式扩展查找前 14 天的 CloudWatch 指标数据中的模式,以创建未来 48 小时的每小时预测。根据最新的 CloudWatch 指标数据每天更新预测数据。

您可以在仅预测模式下配置预测式扩展,以便您可以在预测式扩展开始主动扩展容量之前对预测进行评估。然后,您可以从 Amazon EC2 Auto Scaling 控制台以图表形式查看 CloudWatch 中的预测和最近指标数据。您还可以通过使用 Amazon CLI 或其中一个 SDK 来访问预测数据。

当您准备好使用预测式扩展开始扩展时,请将策略从仅预测模式切换到预测和扩展模式。切换到预测和扩展模式时,Auto Scaling 组将根据预测开始扩展。

通过使用预测,Amazon EC2 Auto Scaling 可在每小时开始时扩展实例数:

  • 如果实际容量小于预测容量,Amazon EC2 Auto Scaling 会向外扩展您的 Auto Scaling 组,使其所需容量与预测容量相等。

  • 如果实际容量大于预测容量,则 Amazon EC2 Auto Scaling 不会缩小容量。

  • 如果预测容量超出此范围,则会遵守为 Auto Scaling 组的最小容量和最大容量设置的值。

最佳实践

  • 确认预测式扩展是否适合您的工作负载。如果工作负载显示特定于星期几的什么时间的重复负载模式,则工作负载非常适合预测式扩展。若要检查这一点,请在仅预测模式下配置预测式扩展策略。

  • 在允许预测式扩展主动扩展应用程序之前,请评估预测及其准确性。预测式扩展至少需要 24 小时的历史数据才能开始预测。但是,如果历史数据跨越整整两周,预测会更有效。如果您通过创建新的 Auto Scaling 组并删除旧组来更新应用程序,则新的 Auto Scaling 组需要 24 小时的历史加载数据,然后预测式扩展才能再次开始生成预测。在这种情况下,您可能需要等待几天才能获得更准确的预测。

  • 仅预测模式下创建多个预测式扩展策略以测试不同指标的潜在影响。您可以为每个 Auto Scaling 组创建多个预测式扩展策略,但只能将其中一个策略用于主动扩展。

  • 如果选择自定义指标对,则可以定义负载指标和扩展指标的不同组合。为避免出现问题,请确保您选择的负载指标表示应用程序上的满负载。

  • 使用具有动态扩展功能的预测式扩展。动态扩展用于根据资源利用率的实时变化自动扩展容量。将其与预测式扩展结合使用可帮助您紧密跟踪应用程序的需求曲线,在低流量期间进行扩展并在流量高于预期时向外扩展。当多个扩展策略处于活动状态时,每个策略将独立确定所需容量,并将所需容量设置为其中的最大容量。例如,如果要求 10 个实例保持目标跟踪扩展策略中的目标利用率,并且需要 8 个实例保持在预测式扩展策略中的目标利用率,则组的所需容量设置为 10。

创建预测式扩展策略(控制台)

创建 Auto Scaling 组后,您可以在该组上配置预测式扩展策略。

创建预测式扩展策略

  1. 访问 https://console.aws.amazon.com/ec2/,打开 Amazon EC2 控制台,然后从导航窗格中选择 Auto Scaling Groups(Auto Scaling 组)。

  2. 选中您的 Auto Scaling 组旁边的复选框。

    将在 Auto Scaling groups (Auto Scaling 组) 页面底部打开一个拆分窗格,其中显示有关所选组的信息。

  3. 自动扩展选项卡的扩展策略中,选择创建预测式扩展策略

  4. 要定义策略,请执行以下操作:

    1. 输入策略的名称。

    2. 启用根据预测进行扩展,授予 Amazon EC2 Auto Scaling 立即开始扩展的权限。

      若要将策略保持在仅预测模式,请保持根据预测进行扩展关闭状态。

    3. 对于指标,从选项列表中选择指标。选项包括 CPU网络输入网络输出Application Load Balancer 请求计数自定义指标对

      如果您选择每目标的 Application Load Balancer 请求计数,请在目标组中选择目标组。每目标的 Application Load Balancer 请求计数仅在您已将 Application Load Balancer 目标组附加到 Auto Scaling 组时才支持。

      如果您选择自定义指标对,请从负载指标扩展指标的下拉列表中选择单个指标。

  5. 对于目标利用率,请输入 Amazon EC2 Auto Scaling 应维护的目标值。Amazon EC2 Auto Scaling 可向外扩展您的容量直到平均利用率达到目标利用率,或直到达到您指定的最大实例数。

    如果您的扩展指标是... 然后目标利用率表示...
    CPU

    每个实例理想情况下应使用的 CPU 百分比。

    网络输入

    每个实例理想情况下应接收的平均每分钟字节数。

    网络输出

    每个实例理想情况下应发出的平均每分钟字节数。

    每目标的 Application Load Balancer 请求计数

    每个实例理想情况下应接收的平均每分钟请求数。

  6. (可选)对于预启动实例,请选择您希望在预测调用增加负载之前启动实例的距离。

  7. (可选)对于最大容量行为,请选择当预测容量超过定义的最大值时,是否允许 Amazon EC2 Auto Scaling 向外扩展高于组的最大容量。启用此设置允许在预测流量达到最高期间进行横向扩展。

  8. (可选)对于高于预测容量的缓冲区最大容量,选择在预测容量接近或超过最大容量时要使用的附加容量。该值是作为相对于预测容量的百分比指定的。例如,如果缓冲区为 10,这表示 10% 缓冲区,因此如果预测容量为 50 并且最大容量为 40,则实际的最大容量为 55。

    如果设置为 0,Amazon EC2 Auto Scaling 可以将容量扩展到高于最大容量,直至等于但不能超过预测容量。

  9. 选择创建预测式扩展策略

创建预测式扩展策略 (Amazon CLI)

使用以下 Amazon CLI 为 Auto Scaling 组配置预测式扩展策略。有关可以为预测式扩展策略指定 CloudWatch 指标的更多信息,请参阅 Amazon EC2 Auto Scaling API 参考中的 PredictiveScalingMetricSpecification

示例 1:创建预测但不扩展的预测式扩展策略

以下示例策略显示了完整的策略配置,该配置使用 CPU 利用率指标进行预测式扩展,其中目标利用率为 40。默认使用 ForecastOnly 模式,除非您明确指定要使用的模式。将此配置保存在名为 config.json 的文件中。

{ "MetricSpecifications": [ { "TargetValue": 40, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ASGCPUUtilization" } } ] }

要创建此策略,请运行指定配置文件的 put-scaling-policy 命令,如下例所示。

aws autoscaling put-scaling-policy --policy-name cpu40-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json

如果成功,此命令将返回策略的 Amazon Resource Name (ARN)。

{ "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/cpu40-predictive-scaling-policy", "Alarms": [] }

示例 2:预测和扩展的预测式扩展策略

对于允许 Amazon EC2 Auto Scaling 预测和扩展的策略,请添加值为 ForecastAndScale 的属性 Mode。以下示例显示了使用 Application Load Balancer 请求计数指标的策略配置。目标利用率是 1000,并且预测式扩展设置为 ForecastAndScale 模式。

{ "MetricSpecifications": [ { "TargetValue": 1000, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ALBRequestCount", "ResourceLabel": "app/my-alb/778d41231b141a0f/targetgroup/my-alb-target-group/943f017f100becff" } } ], "Mode": "ForecastAndScale" }

要创建此策略,请运行指定配置文件的 put-scaling-policy 命令,如下例所示。

aws autoscaling put-scaling-policy --policy-name alb1000-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json

如果成功,此命令将返回策略的 Amazon Resource Name (ARN)。

{ "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:19556d63-7914-4997-8c81-d27ca5241386:autoScalingGroupName/my-asg:policyName/alb1000-predictive-scaling-policy", "Alarms": [] }

示例 3:可扩展大于最大容量的预测式扩展策略

以下示例显示如何创建一个策略,该策略可以在您需要它来处理高于正常负载时扩展高于组的最大大小限制。预设情况下,Amazon EC2 Auto Scaling 的 EC2 扩展容量不会超过您定义的最大容量。但是,如果让它扩展更高,容量稍微增加以避免性能或可用性问题,可能会有所帮助。

要为 Amazon EC2 Auto Scaling 提供空间,以便在容量预计达到或非常接近组的最大大小时配置额外容量,请指定 MaxCapacityBreachBehaviorMaxCapacityBuffer 属性,如以下示例所示。您必须指定值为 IncreaseMaxCapacityMaxCapacityBreachBehavior。您的组可以具有的最大实例数取决于 MaxCapacityBuffer 值。

{ "MetricSpecifications": [ { "TargetValue": 70, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ASGCPUUtilization" } } ], "MaxCapacityBreachBehavior": "IncreaseMaxCapacity", "MaxCapacityBuffer": 10 }

在本示例中,该策略配置为使用 10% 缓冲区 ("MaxCapacityBuffer": 10),因此如果预测容量为 50 并且最大容量为 40,则实际的最大容量为 55。如果策略可以将容量扩展到高于最大容量以等于但不超过预测容量,则缓冲区为 0 ("MaxCapacityBuffer": 0)。

要创建此策略,请运行指定配置文件的 put-scaling-policy 命令,如下例所示。

aws autoscaling put-scaling-policy --policy-name cpu70-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json

如果成功,此命令将返回策略的 Amazon Resource Name (ARN)。

{ "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:d02ef525-8651-4314-bf14-888331ebd04f:autoScalingGroupName/my-asg:policyName/cpu70-predictive-scaling-policy", "Alarms": [] }

限制

  • 预测式扩展需要 24 小时的指标历史记录才能生成预测。

  • 预测性扩展的核心假设是 Auto Scaling 组是同质的,且所有实例的容量相等。如果您的组不是这样,预测的容量可能不准确。因此,在为混合实例组创建预测性扩缩策略时务必谨慎,因为可以调配容量不相等的不同类型的实例。以下是一些预测容量不准确的例子:

    • 您的预测性扩缩策略基于 CPU 利用率,但每个 Auto Scaling 实例上的 vCPU 数量因实例类型而异。

    • 您的预测性扩缩策略基于网络进入或网络外出,但每个 Auto Scaling 实例的网络带宽吞吐量因实例类型而异。例如,M5 和 M5n 实例类型相似,但 M5n 实例类型显著提高了网络吞吐量。

支持的区域

Amazon EC2 Auto Scaling 在下列 Amazon Web Services 区域支持预测性扩缩策略:美国东部(弗吉尼亚州北部)、美国东部(俄亥俄州)、美国西部(俄勒冈州)、美国西部(北加利福尼亚)、非洲(开普敦)、加拿大(中部)、欧洲地区(法兰克福)、欧洲地区(爱尔兰)、欧洲地区(伦敦)、欧洲地区(米兰)、欧洲地区(巴黎)、欧洲地区(斯德哥尔摩)、亚太地区(香港)、亚太地区(孟买)、亚太地区(大阪)、亚太地区(东京)、亚太地区(新加坡)、亚太地区(首尔)、亚太地区(悉尼)、中东(巴林)、南美洲(圣保罗)、中国(北京)、中国(宁夏)和 Amazon GovCloud(美国西部)。