Amazon A EC2 uto Scaling 的目标跟踪扩展政策 - Amazon A EC2 uto Scaling
多个目标跟踪扩缩策略选择指标定义目标值定义实例预热时间注意事项

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

Amazon A EC2 uto Scaling 的目标跟踪扩展政策

目标跟踪扩展策略会根据目标指标值自动扩展 Auto Scaling 组的容量。这使您的应用程序无需人工干预即可保持最佳性能和成本效益。

通过目标跟踪，您可以选择一个指标和一个目标值，目标值用来表示应用程序的理想平均利用率或吞吐量水平。Amazon A EC2 uto Scaling 会创建并管理在指标偏离目标时调用扩展事件的 CloudWatch 警报。举个例子，这类似于恒温器保持目标温度的方式。

例如，假设您当前有一个在两个实例上运行的应用程序，并且您希望当应用程序的负载发生变化时，Auto Scaling 组的CPU利用率保持在 50% 左右。这为您提供额外容量以处理流量高峰，而无需维护过多的空闲资源。

您可以通过创建目标跟踪扩展策略来满足这一需求，该策略的目标是平均CPU利用率为 50%。然后，当容量CPU超过 50% 时，您的 Auto Scaling 组将向外扩展或增加容量，以应对增加的负载。当容量降CPU至低于 50% 时，它将扩大或减少容量，以便在利用率低的时期优化成本。

主题

多个目标跟踪扩缩策略

为帮助优化扩缩性能，您可以将多个目标跟踪扩缩策略组合使用，但前提是其中的每个策略都各自使用不同的指标。例如，利用率和吞吐量可能会相互影响。每当其中一个指标发生变化时，通常意味着其他指标也将受到影响。因此，使用多个指标可以提供有关您的 Auto Scaling 组所承受的负载的更多信息。这可以帮助 Amazon A EC2 uto Scaling 在确定向您的群组添加多少容量时做出更明智的决定。

Amazon A EC2 uto Scaling 的目的是始终优先考虑可用性。如果任何目标跟踪策略已准备好横向扩展，它将扩展 Auto Scaling 组。只有当所有目标跟踪策略（启用部分缩放）都准备好进行缩减时，它才会缩小规模。

选择指标

您可以使用预定义的指标或自定义指标，创建目标跟踪扩展策略。

使用预定义的指标类型创建目标跟踪扩展策略时，您可以从以下预定义指标列表中选择一个指标。

  • ASGAverageCPUUtilization— Auto Scaling 组的平均CPU利用率。

  • ASGAverageNetworkIn – 单个实例在所有网络接口上收到的平均字节数。

  • ASGAverageNetworkOut – 单个实例在所有网络接口上发送的平均字节数。

  • ALBRequestCountPerTarget – 每目标的应用程序负载均衡器请求计数。

重要

有关CPU利用率、网络 I/O 和每个目标的 Application Load Balancer 请求数等 CloudWatch 指标的其他重要信息，分别可在亚马逊EC2用户指南中的列出您的实例的可用CloudWatch 指标主题和应用程序负载均衡器用户指南中的应用程序负载均衡器指标主题中找到。

您可以 CloudWatch 通过指定自定义 CloudWatch 指标来选择其他可用指标或您自己的指标。您必须使用 AWS CLI 或SDK来创建具有自定义指标规范的目标跟踪策略。有关使用为目标跟踪扩展策略指定自定义指标规范的示例 AWS CLI，请参阅的扩展策略示例 AWS CLI。

选择指标时请记住原则：

  • 我们建议您仅使用每隔一分钟可用的指标，以帮助您更快地扩展以响应利用率变化。目标跟踪将评估所有预定义指标和自定义指标的以一分钟为粒度聚合的指标，但底层指标发布数据的频率可能会降低。例如，默认情况下，所有 Amazon EC2 指标均以五分钟为间隔发送，但可配置为一分钟（称为详细监控）。是否选择此配置取决于单个服务。大部分情况下可尝试使用尽可能小的间隔。有关启用详细监控的信息，请参阅 配置 Auto Scaling 实例的监控。

  • 并非所有自定义指标都适用于目标跟踪。指标必须是有效的使用率指标，它用于描述实例的繁忙程度。指标值必须随着 Auto Scaling 组中的实例数按比例增加或减少。这样，指标数据可用于随实例数量按比例扩展或缩减。例如，如果 Auto Scaling 组的负载分布在各个实例上，则 Auto Scaling 组的CPU利用率（即CPUUtilization带有EC2指标维度的亚马逊指标AutoScalingGroupName）起作用。

  • 以下指标不适用于目标跟踪：

    • Auto Scaling 组前面的负载均衡器收到的请求数（即，Elastic Load Balancing 指标 RequestCount）。负载均衡器收到的请求数不会根据 Auto Scaling 组的使用率而发生变化。

    • 负载均衡器请求延迟（即，Elastic Load Balancing 指标 Latency）。请求延迟可能会根据使用率增加而增加，但不一定按比例变化。

    • CloudWatch 亚马逊队SQS列指标ApproximateNumberOfMessagesVisible。队列中的消息数可能不会随着处理队列中的消息的 Auto Scaling 组的大小按比例发生变化。但是，衡量 Auto Scaling 组中每个EC2实例队列中消息数量的自定义指标可以起作用。有关更多信息，请参阅 基于 Amazon 的扩展策略 SQS。

  • 要使用 ALBRequestCountPerTarget 指标，您必须指定 ResourceLabel 参数以标识与该指标关联的负载均衡器目标组。有关使用为目标跟踪扩展策略指定ResourceLabel参数的示例 AWS CLI，请参阅的扩展策略示例 AWS CLI。

  • 当某个指标向 CloudWatch （例如ALBRequestCountPerTarget）发出实数 0 值时，当您的应用程序持续一段时间内没有流量时，Auto Scaling 组可以缩减到 0。要在没有请求路由时将自动扩缩组横向缩减至 0，组的最小容量必须设置为 0。

  • 您可以使用指标数学组合现有指标，而不必发布要在扩缩策略中使用的新指标。有关更多信息，请参阅 使用公制数学创建目标跟踪扩展策略。

定义目标值

创建目标跟踪扩缩策略时，必须指定一个目标值。目标值表示自动扩缩组的最佳平均利用率或吞吐量。为了经济高效地使用资源，目标值的设置应尽可能高，并为流量的意外增加提供合的理缓冲。当应用程序针对正常流量进行最佳横向扩展时，实际指标值应等于或略低于目标值。

当扩缩策略基于吞吐量（例如，每目标的应用程序负载均衡器请求计数、网络 I/O 或其他计数指标）时，目标值表示单个实例在一分钟内的最佳平均吞吐量。

定义实例预热时间

您可以指定新启动实例的预热时间（单位为秒）。在指定的预热时间到期之前，实例不会计入 Auto Scaling 组的聚合EC2实例指标。

当实例处于预热期时，只有当未预热的实例的指标值大于策略的目标利用率时，您的扩展策略才会横向扩展。

如果组再次横向扩展，则仍在预热的实例将计算为下一横向扩展活动所需容量的一部分。旨在持续 (但不过度) 扩大。

在扩展活动进行期间，所有由扩展策略启动的扩展活动都将被阻止，直到实例完成预热。当实例完成预热后，如果发生缩减事件，则在计算新的所需容量时，当前正在终止的任何实例都将计入该组的当前容量。因此不会从 Auto Scaling 组中删除更多实例。

默认值

如果未设置任何值，则扩展策略将使用默认值，即为组定义的默认实例预热值。如果默认实例预热为空，则它将回退到默认冷却时间值。我们建议使用默认实例预热，以便在预热时间发生变化时更轻松地更新所有扩展策略。

注意事项

使用目标跟踪扩缩策略时，需要注意以下事项：

  • 请勿创建、编辑或删除与目标跟踪扩展策略一起使用的 CloudWatch 警报。Amazon A EC2 uto Scaling 会创建和管理与您的目标跟踪扩展策略关联的 CloudWatch警报，并在不再需要时将其删除。

  • 在流量波动时，目标跟踪扩缩策略会优先考虑可用性，在流量减少时以更缓步的方式横向缩减。如果您希望自动扩缩组在工作负载完成后立即横向缩减，则可以禁用策略的横向缩减部分。这使您能够灵活地使用最适合您需求的横向缩减方法。为确保尽快进行横向缩减，我们建议不要使用简单扩缩策略以防止增加冷却时间。

  • 如果指标缺少数据点，则会导致 CloudWatch 警报状态更改为INSUFFICIENT_DATA。发生这种情况时，在找到新的数据点之前，Amazon A EC2 uto Scaling 无法扩展您的群组。

  • 如果设计为很少报告指标，则指标数学可能会很有帮助。例如，要使用最新的值，则使用 FILL(m1,REPEAT) 函数，其中 m1 是指标。

  • 您可能会看到目标值与实际指标数据点之间存在差距。这是因为我们在确定需要添加或删除多少个实例时通过向上或向下取整来保守地进行操作，以免添加的实例数量不足或删除的实例数量过多。但是，对于实例较少的 Auto Scaling 组，组的使用率可能偏离目标值较远。例如，假设您将CPU利用率的目标值设置为 50%，然后您的 Auto Scaling 组超过了目标。我们可以确定，添加 1.5 个实例会将CPU利用率降低到接近 50%。由于不可能添加 1.5 个实例，我们将该值向上取整，添加两个实例。这可能会将CPU利用率降低到 50% 以下，但它可以确保您的应用程序有足够的资源来支持它。同样，如果我们确定移除 1.5 个实例会将您的CPU利用率提高到 50% 以上，那么我们只会移除一个实例。

    对于包含更多实例的更大 Auto Scaling 组，使用率分布在更多实例上，在这种情况下，添加或删除实例会导致目标值与实际指标数据点之间的差距缩小。

  • 目标跟踪扩缩策略假设它应该在指定指标高于目标值时扩展 Auto Scaling 组。在指定指标低于目标值时，不能使用目标跟踪扩缩策略来横向扩展自动扩缩组。