本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Amazon A EC2 uto Scaling 的目标跟踪扩展政策
目标跟踪扩缩策略根据目标指标值自动扩缩自动扩缩组的容量。它会自动适应您各个应用程序的独特使用模式。这使您的应用程序能够保持EC2实例的最佳性能和高利用率,从而提高成本效益,而无需人工干预。
通过目标跟踪,您可以选择一个指标和一个目标值,目标值用来表示应用程序的理想平均利用率或吞吐量水平。Amazon A EC2 uto Scaling 创建并管理在指标偏离目标时调用扩展事件的 CloudWatch 警报。举例来说,这与恒温器保持目标温度的方式类似。
例如,假设您当前有一个在两个实例上运行的应用程序,并且您希望当应用程序的负载发生变化时,Auto Scaling 组的CPU利用率保持在 50% 左右。这为您提供额外容量以处理流量高峰,而无需维护过多的空闲资源。
您可以通过创建目标跟踪扩展策略来满足这一需求,该策略的目标是平均CPU利用率为 50%。然后,当容量CPU超过 50% 时,您的 Auto Scaling 组将向外扩展或增加容量,以应对增加的负载。当容量降CPU至低于 50% 时,它将扩大或减少容量,以便在利用率低的时期优化成本。
多个目标跟踪扩缩策略
为帮助优化扩缩性能,您可以将多个目标跟踪扩缩策略组合使用,但前提是其中的每个策略都各自使用不同的指标。例如,利用率和吞吐量可能会相互影响。每当其中一个指标发生变化时,通常意味着其他指标也将受到影响。因此,使用多个指标可以提供有关自动扩缩组所承担负载的额外信息。这可以帮助 Amazon A EC2 uto Scaling 在确定向您的群组添加多少容量时做出更明智的决定。
Amazon A EC2 uto Scaling 的目的是始终优先考虑可用性。如果任何目标跟踪策略已准备好横向扩展,则它将横向扩展自动扩缩组。仅在所有目标跟踪策略(已启用横向缩减部分)都准备好横向缩减时,才会进行横向缩减。
选择指标
您可以使用预定义的指标或自定义指标,创建目标跟踪扩展策略。预定义指标可让您更轻松地访问最常用的扩展指标。自定义指标允许您根据其他可用 CloudWatch 指标进行扩展,包括以更精细的间隔发布的高分辨率指标,这些指标在几秒钟左右的时间间隔内发布。您可以发布自己的高分辨率指标或其他 Amazon 服务发布的指标。
注意
美国东部(弗吉尼亚北部)、美国西部(俄勒冈)、亚太地区(新加坡)和欧洲(爱尔兰)都可以使用高分辨率指标进行目标跟踪 Amazon Web Services 区域。
目标跟踪支持以下预定义指标:
-
ASGAverageCPUUtilization
— Auto Scaling 组的平均CPU利用率。 -
ASGAverageNetworkIn
– 单个实例在所有网络接口上收到的平均字节数。 -
ASGAverageNetworkOut
– 单个实例在所有网络接口上发送的平均字节数。 -
ALBRequestCountPerTarget
– 每目标的应用程序负载均衡器请求计数。
重要
有关CPU利用率、网络 I/O 和每个目标的 Application Load Balancer 请求数等 CloudWatch 指标的其他重要信息,分别可在亚马逊EC2用户指南中的列出您的实例的可用CloudWatch 指标主题和应用程序负载均衡器用户指南中的应用程序负载均衡器指标主题中找到。
您可以 CloudWatch 通过指定自定义 CloudWatch 指标来选择其他可用指标或您自己的指标。有关使用为目标跟踪扩展策略指定自定义指标规范的示例 Amazon CLI,请参阅Amazon CLI的扩缩策略示例。
选择指标时请记住原则:
-
我们建议您仅使用间隔为一分钟或更短的指标,以帮助您更快地扩展以应对利用率的变化。以较低间隔发布的指标允许目标跟踪策略检测并更快地响应 Auto Scaling 组利用率的变化。
-
如果您选择由 Amazon 发布的预定义指标EC2,例如CPU利用率,我们建议您启用详细监控。默认情况下,所有 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
参数的示例 Amazon CLI,请参阅Amazon 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 组。在指定指标低于目标值时,不能使用目标跟踪扩缩策略来横向扩展自动扩缩组。