采纳建议并监控预测扩展以获得最佳计算容量

这篇文章由 EC2 高级产品经理 Ankur Sethi 和 亚马逊云科技 Compute 高级专家解决方案架构师 Kinnar Sen 撰写。

Amazon EC2 Auto Scaling 通过动态响应不同的需求来 帮助客户优化其 亚马逊 EC2 容量。根据客户反馈，我们推出 预测性扩展策略，增强了扩展 体验 。预测性扩展会主动将 EC2 实例添加到您的 Auto Scaling 组中，以应对需求激增。这可以提高需求模式可预测且初始化时间较长的应用程序的可用性和性能。我们最近推出了几项旨在帮助您评估预测扩展价值的功能，包括根据预测扩展的潜在可用性和成本影响提供 规范性建议 ，说明是否使用预测扩展，以及 与 Amazon Cloud Watch 的 集成 以持续监控预测的准确性。在这篇文章中，我们将详细讨论这些功能以及您可以轻松采用的步骤，以享受预测性扩展的好处。

回顾：预测扩展

EC2 Auto Scaling 通过管理底层集群的容量和运行状况来帮助客户保持应用程序的可用性。在预测性扩展之前，EC2 Auto Scaling 提供了动态扩展策略，例如 目标跟踪 和 步进扩展 。这些动态扩展策略使用代表应用程序负载的 A mazon CloudWatch 指标进行配置。EC2 Auto Scaling 会持续监控该指标并根据您的策略做出响应，从而触发实例的启动或终止。尽管它非常有效且被广泛使用，但该模型本质上是被动的，对于较大的峰值，可能会在集群扩展时导致容量暂时无法满足。客户通过采用积极的向外扩展和保守的向内扩展来管理额外的实例缓冲区来缓解这种情况。但是，有时应用程序需要很长时间才能初始化，或者出现反复出现的模式，需求突然激增。这些可能会影响系统在向外扩展时的初始响应。客户要求一种主动扩展机制，以便在可预测的峰值出现之前扩展容量，因此我们提供了预测性扩展。

推出预测性扩展是为了使扩展行动具有主动性，因为它可以预测计算需求所需的变化并相应地进行扩展。扩展操作由集合机器学习 (ML) 决定，该机器学习 (ML) 使用来自您的 Auto Scaling 组扩展模式的数据以及来自我们观测结果的数十亿个数据点构建。预测扩展应用于需求变化迅速但具有重复模式、实例需要很长时间才能初始化的应用程序，或者您 为常规需求模式手动调用 计划扩展 的应用程序。预测性扩展不仅可以根据历史使用情况预测容量需求，还可以持续学习，从而使预测随着时间的推移变得更加准确。此外，预测性扩展策略旨在仅在您的 Auto Scaling 组中横向扩展而不进行扩展，从而消除了由于预测不准确而导致容量减少的风险。您必须使用动态扩展策略、定时扩展或自己的自定义机制进行缩容。如果出现异常的需求高峰，新增的动态扩展策略还可以通过弥合需求和预测容量之间的差距来提高您的应用程序性能。

预测扩展的新增功能

可以在非可变的 “仅限预测” 模式下配置预测扩展策略，以评估预测的准确性。当你准备好开始扩展时，你可以切换到 “预测和缩放” 模式。现在，我们规范性地建议，如果您的策略有可能提高可用性和降低成本，是否应将其切换到 “预测和规模” 模式，从而节省手动进行此类评估的时间和精力。您可以通过在 “仅限预测” 模式下创建多个预测扩展策略来测试不同的配置，然后选择在可用性和成本改善方面表现最佳的策略。

监控和可观察性是 亚马逊云科技 架构完善的框架 的关键要素。 现在，我们还为您的预测性扩展策略提供 CloudWatch 指标，以便您可以以编程方式监控预测扩展策略，以了解需求模式变化或长期不准确的预测。这将使您能够监控关键性能指标，并更轻松地采用 亚马逊云科技 架构完善的最佳实践。

在以下部分中，我们将深入探讨这两个功能的细节。

预测性扩展建议

按照这篇预测扩展 简介博客文章所述，在 “仅限预测” 模式下设置了具有预测扩展 策略的 Auto Scaling 组后 ，您可以直观地查看预测结果并调整任何参数以更准确地反映您想要的行为。如果缩放模式不稳定，那么仅仅根据可视化进行评估可能不太直观。此外，如果您保持更高的最低容量，则图表可能会显示实际容量的平线，因为您的 Auto Scaling 组容量是现有扩展策略配置和您配置的最小容量的结果。这使得很难考虑预测性扩展所预测的较低容量是否会使您的 Auto Scaling 组规模不足。

这项新功能为根据可用性和成本节约因素在 “预测和扩展” 模式下开启预测扩展提供了规范性指导。为了确定可用性和节省的成本，我们将预测与实际容量和所需的最佳容量进行比较。此所需容量是根据您的实例的运行值是否高于还是低于您在预测扩展策略配置中定义的扩展指标的目标值来推断的。例如，如果一个 Auto Scaling 组以 20% 的 CPU 利用率运行 10 个实例，而预测扩展策略中定义的目标为 40%，则这些实例的运行未得到充分利用 50%，并且假定所需容量为 5 个实例（当前容量的一半）。对于 Auto Scaling 群组，我们会根据您感兴趣的时间范围（默认为两周）汇总预测性扩展对成本节省和可用性的影响。可用性影响衡量的是实际指标值高于您为每个策略定义的最佳目标值的时间长度。同样，成本节约根据每个已定义策略的基础 Auto Scaling 组的容量利用率来衡量总共节省的费用。最终成本和可用性将引导我们根据以下内容提出建议：

• 如果可用性增加（或保持不变），成本降低（或保持不变），则开启预测和扩展
• 如果可用性降低，则禁用预测扩展
• 如果可用性提高会增加成本，则客户应根据其成本可用性权衡阈值接听电话

图 1：EC2 自动扩展控制台上的预测性扩展建议

上图显示了控制台如何反映预测性扩展策略的建议。您将获得有关该策略是否可以提高可用性和降低成本的信息，因此建议切换到预测和规模。为了节省成本，您可能需要降低最低容量，并以提高动态扩展策略的利用率为目标。

为了从此功能中获得最大价值，我们建议您在仅预测模式下创建多个具有不同配置的预测扩展策略，选择不同的指标和/或不同的目标值。目标值是改变容量预测的激进程度的重要杠杆。较低的目标值会增加容量预测，从而提高应用程序的可用性。但是，这也意味着要在 Amazon EC2 成本上花费更多的钱。同样，较高的目标值可能会使你的规模不足，而反应性扩展可以在短短几分钟内弥合差距。为每种预测性扩展策略分别提供了成本和可用性影响的估算值。如果可用性或成本得到改善，而另一个变量改善或保持不变，我们建议使用保单。只要存在可预测的模式，通过预测扩展增强的 Auto Scaling 即可保持应用程序的高可用性。

持续监控预测性扩展

根据建议在 “预测和扩展” 模式下使用预测扩展策略后，您必须监控预测扩展策略以了解需求模式变化或预测不准确。我们推出了两个新的CloudWatch预测扩展指标，分别是 “PredictiveScalingLoadForecast” 和 “predictiveScalingCapacityForeca使用 CloudWatch 指标数学功能，您可以创建用于衡量预测准确性的自定义指标。例如，要监控您的保单是超额还是预测不足，您可以发布单独的指标来衡量相应的错误。在下图中，我们展示了如何使用度量数学表达式来创建平均绝对误差，从而对负荷预测进行过度预测。由于预测性扩展只能增加容量，因此在策略过度预测时发出警报以防止不必要的成本很有用。 图 2：在 CloudWatch 上使用指标数学绘制准确度指标

在上图中，Auto Scaling 组的总 CPU 利用率由橙色的 m1 指标表示，而策略的预测负载由绿色的 m2 指标表示。我们使用以下表达式来获得过度预测误差与实际值的比率。

IF ((m2-m1) >0，(m2-m1) ,0)) /m1

接下来，我们将设置警报，使用 亚马逊简单通知服务 (Amazon SNS) 自动发送通知。您可以为容量预测创建类似的精度监控，但请记住，一旦策略进入预测和扩展模式，它就已经开始影响实际容量。因此，对负载预测的准确性设置警报可能更直观，因为负载通常与 Auto Scaling 组的容量无关。

图 3：针对准确度指标创建 CloudWatch 警报

在上面的屏幕截图中，我们设置了一个警报，当我们的自定义精度指标在过去 12 个数据点中有 10 个高于 0.02（20%）时触发，这意味着过去 12 个小时中的 10 个小时。我们更喜欢对更多数据点发出警报，这样我们就只有在预测性扩展持续给出不准确的结果时才会收到通知。

结论

借助这些新功能，您可以更明智地决定预测性扩展是否适合您以及哪种配置最合理。我们建议您从 “仅限预测” 模式开始，然后根据建议切换到 “预测和规模”。进入预测和扩展模式后，预测性扩展将开始采取主动扩展操作，以便在预测需求出现之前启动您的实例并准备好为工作负载做出贡献。然后持续监控预测，以保持应用程序的高可用性和成本优化。您还可以使用新的预测扩展指标和 CloudWatch 功能，例如指标数学、警报和通知，在预测长期偏离设定阈值时进行监控并采取行动。