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

# 预测式扩展的工作方式
<a name="predictive-scaling-policy-overview"></a>

本主题说明预测性扩展的工作原理，并描述创建预测性扩展策略时需要考虑的内容。

**Topics**
+ [

## 工作原理
](#how-predictive-scaling-works)
+ [

## 最大容量限制
](#predictive-scaling-maximum-capacity-limit)
+ [

## 注意事项
](#predictive-scaling-considerations)
+ [

## 支持的区域：
](#predictive-scaling-regions)

## 工作原理
<a name="how-predictive-scaling-works"></a>

要使用预测扩展，请创建预测性扩展策略，指定要监控和分析的 CloudWatch 指标。要使预测性扩展开始预测未来值，此指标必须包含至少 24 小时的数据。

创建策略后，预测性扩展将开始分析最多过去 14 天的指标数据，以确定模式。其使用此分析生成未来 48 小时容量需求的每小时预测。使用最新 CloudWatch 数据，预测每 6 小时更新一次。随着新数据的出现，预测性扩展能够不断提高未来预测的准确性。

首次启用预测性扩展时，该功能将在*仅预测*模式下运行。在此模式下，它会生成容量预测，但不会根据这些预测实际扩展自动扩缩组。这使您可以评估预测的准确性和适用性。您可以使用 `GetPredictiveScalingForecast` API 操作或 AWS 管理控制台查看预测数据。

查看预测数据并决定根据该数据开始扩展后，将扩展策略切换到*预测和扩展*模式。在此模式中：
+ 如果预测预计负载会增加，则 Amazon EC2 Auto Scaling 将通过横向扩展来增加容量。
+ 如果预测预计负载会减少，则不会横向缩减以减少容量。如果要移除不再需要的容量，则必须创建动态扩缩策略。

默认情况下，Amazon EC2 Auto Scaling 会在每个小时开始时根据该小时的预测扩展自动扩缩组。您可以选择使用 `PutScalingPolicy` API 操作中的 `SchedulingBufferTime` 属性或 AWS 管理控制台中的**预启动实例**设置来指定更早的开始时间。这会导致 Amazon EC2 Auto Scaling 在预测的需求之前启动新实例，从而使其有时间启动并准备好处理流量。

为了支持在预测的需求之前启动新实例，强烈建议您为自动扩缩组启用*默认实例预热*。这指定了横向扩展活动结束后的一段时间，在此期间，即使动态扩缩策略指示应减少容量，Amazon EC2 Auto Scaling 也不会横向缩减。这可以帮助您确保新启动的实例在考虑进行横向缩减操作之前，有足够的时间开始为增加的流量提供服务。有关更多信息，请参阅 [为 Auto Scaling 组设置原定设置实例预热](ec2-auto-scaling-default-instance-warmup.md)。

## 最大容量限制
<a name="predictive-scaling-maximum-capacity-limit"></a>

自动扩缩组有最大容量设置，限制了可以为该组启动的 EC2 实例的最大数量。默认情况下，设置扩缩策略后，这些策略无法将容量增加到高于最大容量。

或者，您可以允许在预测容量接近或超过自动扩缩组的最大容量时，自动增加组的最大容量。要启用此行为，请使用 `PutScalingPolicy` API 操作中的 `MaxCapacityBreachBehavior` 和 `MaxCapacityBuffer` 属性或 AWS 管理控制台中的**最大容量行为**设置。

**警告**  
允许自动增加最大容量时应谨慎行事。如果不对增加的最大容量进行监控和管理，则可能导致启动的实例数量超出预期。然后，增加的最大容量将变为自动扩缩组新的正常最大容量，直到您手动对其进行更新。最大容量不会自动降回到原来的最大值。

## 注意事项
<a name="predictive-scaling-considerations"></a>
+ 确认预测式扩展是否适合您的工作负载。如果工作负载显示特定于星期几的什么时间的重复负载模式，则工作负载非常适合预测式扩展。若要检查这一点，请在*仅预测*模式下配置预测性扩展策略，然后参考控制台中的建议。Amazon EC2 Auto Scaling 会根据对潜在策略性能的观察提供建议。在允许预测式扩展主动扩展应用程序之前，请评估预测及建议。
+ 预测式扩展至少需要 24 小时的历史数据才能开始预测。但是，如果历史数据跨越整整两周，预测会更有效。如果您通过创建新的 Auto Scaling 组并删除旧组来更新应用程序，则新的 Auto Scaling 组需要 24 小时的历史加载数据，然后预测式扩展才能再次开始生成预测。您可以使用自定义指标来聚合新旧自动扩缩组之间的指标。否则，您可能需要等待几天才能获得更准确的预测。
+ 选择一个负载指标，该指标应准确代表应用程序的全部负载，并且是应用程序中对扩缩最重要的方面。
+ 将动态扩缩与预测性扩展结合使用可帮助您紧密跟踪应用程序的需求曲线，在低流量期间进行横向缩减并在流量高于预期时横向扩展。当多个扩展策略处于活动状态时，每个策略将独立确定所需容量，并将所需容量设置为其中的最大容量。例如，如果要求 10 个实例保持目标跟踪扩展策略中的目标利用率，并且需要 8 个实例保持在预测式扩展策略中的目标利用率，则组的所需容量设置为 10。如果您不熟悉动态扩缩，则建议您使用目标跟踪扩缩策略。有关更多信息，请参阅 [Amazon EC2 Auto Scaling 的动态扩缩](as-scale-based-on-demand.md)。
+ 预测性扩展的核心假设是 Auto Scaling 组是同质的，且所有实例的容量相等。如果您的组不是这样，预测的容量可能不准确。因此，在为[混合实例组](ec2-auto-scaling-mixed-instances-groups.md)创建预测性扩展策略时务必谨慎，因为可以预置容量不相等的不同类型实例。以下是一些预测容量不准确的例子：
  + 您的预测性扩展策略基于 CPU 利用率，但是每个 Auto Scaling 实例CPUs 上的 v 数因实例类型而异。
  + 您的预测性扩缩策略基于网络进入或网络外出，但每个 Auto Scaling 实例的网络带宽吞吐量因实例类型而异。例如，M5 和 M5n 实例类型相似，但 M5n 实例类型显著提高了网络吞吐量。

## 支持的区域：
<a name="predictive-scaling-regions"></a>
+ 美国东部（弗吉尼亚州北部）
+ 美国东部（俄亥俄州）
+ 美国西部（北加利福尼亚）
+ 美国西部（俄勒冈州）
+ 非洲（开普敦）
+ 亚太地区（香港）
+ 亚太地区（海得拉巴）
+ 亚太地区（雅加达）
+ 亚太地区（墨尔本）
+ 亚太地区（孟买）
+ 亚太地区（大阪）
+ 亚太地区（首尔）
+ 亚太地区（新加坡）
+ 亚太地区（悉尼）
+ 亚太地区（东京）
+ 加拿大（中部）
+ 加拿大西部（卡尔加里）
+ 中国（北京）
+ 中国（宁夏）
+ 欧洲地区（法兰克福）
+ 欧洲地区（爱尔兰）
+ 欧洲地区（伦敦）
+ 欧洲地区（米兰）
+ 欧洲地区（巴黎）
+ 欧洲（西班牙）
+ 欧洲地区（斯德哥尔摩）
+ 欧洲（苏黎世）
+ 以色列（特拉维夫）
+ Middle East (Bahrain)
+ 中东（阿联酋）：
+ 南美洲（圣保罗）
+ AWS GovCloud （美国东部）
+ AWS GovCloud （美国西部）