# 使用历史模式通过预测式扩缩来扩展 Amazon ECS 服务
预测式扩缩可查看流量中过去的负载数据，以分析每日或每周的模式。然后，它会使用此分析来预测未来的需求，并根据需要主动增加服务中的任务。
预测式自动扩缩在以下情况中最有用。
+ 周期性流量：正常营业时间内的高资源利用率以及晚上和周末的低资源利用率。
+ 重复的打开和关闭工作负载模式：例如批处理、测试或定期数据分析。
+ 初始化需要很长时间的应用程序：会造成明显延迟的横向扩展事件期间，这可能会影响应用程序性能。
如果应用程序需要很长时间才能初始化并且存在流量定期增长的情况，则应考虑使用预测式扩缩。这将通过主动增加任务数以应对预测的负载，从而帮助您更快地扩展，而不是仅使用目标跟踪或步进扩缩等动态扩缩策略。预测式扩缩还可帮助您避免过度预置任务数的风险，从而节省成本。
例如，考虑在营业时间内具有高利用率以及夜间具有低利用率的应用程序。在每个工作日开始时，预测式扩缩可以在流量第一次涌入之前横向扩展任务。这有助于您的应用程序在利用率较低的时期内保持高可用性和性能。您不必等待动态扩展来响应不断变化的流量。您也不必花时间查看应用程序的负载模式，并尝试使用计划的扩展计划适当的任务。
预测式扩展是一种服务级别功能，它可独立于底层计算容量（例如 EC2 或 Fargate）的扩展来扩展服务任务。对于 Fargate，AWS 会根据任务要求管理和自动扩展底层容量。对于 EC2 容量，您可以使用自动扩缩组容量提供程序，根据任务的扩展要求来自动扩展底层 EC2 实例。
**Topics**
+ [预测式扩缩概览](#predictive-auto-scaling-overview)
+ [创建预测性扩展策略](predictive-scaling-create-policy.md)
+ [评估预测性扩展策略](predictive-scaling-graphs.md)
+ [覆盖预测](predictive-scaling-overriding-forecast-capacity.md)
+ [使用自定义指标](predictive-scaling-custom-metrics.md)
## 预测式扩展在 Amazon ECS 中的工作原理
您可以在本页了解使用预测式扩缩的注意事项、预测式扩缩的工作原理以及相关使用限制。
### 使用预测式扩缩的注意事项
+ 您需要确保预测式扩缩适合您的工作负载。您可以通过在**仅预测**模式下配置扩缩策略来确认这一点，并查看控制台有何建议。在开始使用预测式扩缩之前，您应该评估预测和建议。
+ 预测式扩缩至少需要 24 小时的历史数据才能开始预测。可用的历史数据越多，预测就越有效，最理想的时间范围是两周。当您删除 Amazon ECS 服务并创建新服务时，还需要等待 24 小时，预测式扩缩才能生成新预测。加快此过程的方法之一是使用自定义指标来聚合新旧 Amazon ECS 服务的指标。
+ 选择一个负载指标，该指标应准确代表应用程序的全部负载，并且是应用程序中对扩缩最重要的方面。
+ 借助采用预测式扩缩的动态扩缩，您可以紧密跟踪应用程序的需求，进而可以在平缓期间进行横向缩减并在流量意外增加时横向扩展。当多个扩缩策略处于活动状态时，每个策略将独立确定所需任务数，而所需任务数将设置为其中最大的任务数。
+ 您可以将预测式扩缩与动态扩缩策略（例如目标跟踪或步进扩缩）一起使用，以便应用程序就可以根据实时和历史模式进行扩展。预测式扩缩本身并不能横向缩减您的任务。
+ 如果您在调用 `register-scalable-target` API 时使用自定义角色，则可能会收到一条错误消息，提示预测式扩缩策略只能在启用 SLR 的情况下生效。在这种情况下，您应该再次调用 `register-scalable-target`，但不要使用 role-arn。注册可扩展目标时使用 SLR 并调用 `put-scaling-policy` API。
### 预测式扩展的工作方式
要使用预测式扩缩，请创建预测式扩缩策略，指定要监控和分析的 CloudWatch 指标。预测式扩缩至少需要 24 小时的数据才能开始预测未来值。
创建策略后，预测性扩展将开始分析最多过去 14 天的指标数据，以确定模式。此分析可用于生成未来 48 小时的每小时需求预测。最新的 CloudWatch 数据将用于每 6 小时更新一次预测。随着新数据的出现，预测式扩缩会不断提高未来预测的准确性。
首次启用预测性扩展时，该功能将在*仅预测*模式下运行。它以这种模式生成预测，但它不会根据这些预测扩展 Amazon ECS 服务。这使您可以评估预测的准确性和适用性。您可以使用 `GetPredictiveScalingForecast` API 操作或 AWS 管理控制台 查看预测数据。
当您决定开始使用预测式扩缩时，请将扩缩策略切换到*预测和扩展*模式。在此模式下会发生以下情况。
Amazon ECS 服务默认会根据该小时的预测进行扩展。您可以在 `PutScalingPolicy` API 操作中使用 `SchedulingBufferTime` 属性选择提前启动。这会使新任务在预测的需求之前启动，并使其有时间启动并准备好处理流量。
### 最大任务数限制
注册 Amazon ECS 服务以进行扩缩时，您会定义每项服务可启动的最大任务数。默认情况下，设置扩缩策略后，这些策略无法将任务数增加到高于最大限制。
或者，您可以允许在预测接近或超过 Amazon ECS 服务的最大任务数时，自动增加服务的最大任务数。
**警告**
允许自动增加最大任务数时应谨慎行事。如果不对增加的最大任务数进行监控和管理，则可能导致启动的任务数超出预期。然后，增加的最大任务数将变为 Amazon ECS 服务新的正常最大任务数，直到您手动对其进行更新。最大任务数不会自动降回到原来的最大值。
### 支持的区域
+ 美国东部（弗吉尼亚州北部）
+ 美国东部（俄亥俄州）
+ 美国西部（北加利福尼亚）
+ 美国西部（俄勒冈州）
+ 非洲（开普敦）
+ 亚太地区（香港）
+ 亚太地区（雅加达）
+ 亚太地区（孟买）
+ 亚太地区（大阪）
+ 亚太地区（首尔）
+ 亚太地区（新加坡）
+ 亚太地区（悉尼）
+ 亚太地区（东京）
+ 加拿大（中部）
+ 中国（北京）
+ 中国（宁夏）
+ 欧洲地区（法兰克福）
+ 欧洲地区（爱尔兰）
+ 欧洲地区（伦敦）
+ 欧洲地区（米兰）
+ 欧洲地区（巴黎）
+ 欧洲地区（斯德哥尔摩）
+ 中东（巴林）
+ 南美洲（圣保罗）
+ AWS GovCloud（美国东部）
+ AWS GovCloud（美国西部）
# 为 Amazon ECS 服务自动扩缩创建预测式扩缩策略
创建预测性扩缩策略，以便 Amazon ECS 根据历史数据自动增加或减少服务运行的任务数。
**注意**
一项新服务需要提供至少 24 小时的数据，然后才能生成预测。
## 控制台
1. 除了用于创建和更新服务的标准 IAM 权限之外，您还需要额外权限。有关更多信息，请参阅 [Amazon ECS 服务自动扩缩所需的 IAM 权限](auto-scaling-IAM.md)。
1. 请确定要用于策略的指标。可供使用的指标如下：
+ **ECSServiceAverageCPUUtilization**：服务应使用的平均 CPU 使用率。
+ **ECSServiceAverageMemoryUtilization**：服务应使用的平均内存使用率。
+ **ALBRequestCountPerTarget**：任务理想情况下应接收的平均每分钟请求数。
您也可以使用自定义指标。您需要定义以下值：
+ 负载：该指标应准确代表应用程序的全部负载，并且是应用程序中对扩展最重要的方面。
+ 扩缩指标：衡量应用程序理想利用率的最佳预测指标。
1. 在 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) 打开控制台。
1. 在 **Clusters**（集群）页面上，选择集群。
1. 在“集群详细信息”页面，找到**服务**部分，然后选择服务。
此时系统会显示服务详细信息页面。
1. 选择**服务自动扩缩**，然后选择**设置任务数**。
1. 在 **Amazon ECS 服务任务计数**下，选择**使用自动扩缩**。
此时将显示**任务计数部分**。
1. 对于**最小任务数**，输入供服务自动扩缩使用的任务数的下限。所需计数不会低于此计数。
1. 对于**最大值**，输入供服务自动扩缩使用的任务数的上限。所需计数不会高于此计数。
1. 选择**保存**。
此时将显示策略页面。
1. 选择**创建扩缩策略**。
此时将显示**创建策略**页面。
1. 对于**扩缩策略类型**，选择**预测式扩缩**。
1. 对于 **Policy name**（策略名称），请输入策略的名称。
1. 对于**指标对**，从选项列表中选择指标。
如果您选择了**每目标的应用程序负载均衡器请求计数**，请在**目标组**中选择目标组。**每目标的应用程序负载均衡器请求计数**仅在您已为服务附加应用程序负载均衡器目标组时才支持。
如果您选择**自定义指标对**，请从**负载指标**和**扩缩指标**的列表中选择单个指标。
1. 在**目标利用率**中，输入 Amazon ECS 应保留的任务百分比的目标值。服务自动扩缩可横向扩展您的容量直到平均利用率达到目标利用率，或直到达到您指定的最大任务数。
1. 选择**创建扩缩策略**。
## AWS CLI
使用 AWS CLI 按如下方式为 Amazon ECS 服务配置预测式扩缩策略。将每个*用户输入占位符*替换为您自己的信息。
有关您可以指定的 CloudWatch 指标的更多信息，请参阅《Amazon EC2 Auto Scaling API 参考》**中的 [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)。
### 示例 1：具有预定义内存的预测式扩缩策略。
以下是具有预定义内存配置的策略的示例。
```
cat policy.json
{
"MetricSpecifications": [
{
"TargetValue": 40,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ECSServiceMemoryUtilization"
}
}
],
"SchedulingBufferTime": 3600,
"MaxCapacityBreachBehavior": "HonorMaxCapacity",
"Mode": "ForecastOnly"
}
```
以下示例演示了如何通过运行指定配置文件的 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 命令来创建策略。
```
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```
如果成功，该命令会返回策略的 ARN。
```
{
"PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
"Alarms": []
}
```
### 示例 2：具有预定义 CPU 的预测式扩缩策略。
以下是具有预定义 CPU 配置的策略的示例。
```
cat policy.json
{
"MetricSpecifications": [
{
"TargetValue": 0.00000004,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ECSServiceCPUUtilization"
}
}
],
"SchedulingBufferTime": 3600,
"MaxCapacityBreachBehavior": "HonorMaxCapacity",
"Mode": "ForecastOnly"
}
```
以下示例演示了如何通过运行指定配置文件的 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 命令来创建策略。
```
aws aas put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```
如果成功，该命令会返回策略的 ARN。
```
{
"PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
"Alarms": []
}
```
# 评估 Amazon ECS 的预测式扩缩策略
在使用预测式扩缩策略扩展服务之前，请在 Amazon ECS 控制台中查看您策略的建议和其他数据。这很重要，因为在确定预测准确之前，您不希望使用预测扩展策略来扩展实际容量。
如果服务是新的，则需要留出 24 小时让服务创建第一次预测。
当 AWS 创建预测时，会使用历史数据。如果服务还没有太多最近的历史数据，预测式扩缩可能会使用从当前可用的历史聚合中创建的聚合数据临时回填预测。预测会在策略创建日期前最多回填两周。
## 查看您的预测性扩展建议
为了进行有效的分析，服务自动扩缩应至少有两个预测式扩缩策略可供比较。（但您仍可以查看单个策略的调查结果。） 创建多个策略时，您可以对使用一个指标的策略和使用另一个指标的策略进行评估。您还可以评估不同目标值和指标组合的影响。创建预测式扩缩策略后，Amazon ECS 会立即开始评估哪种策略可以更好地扩缩您的组。
**在 Amazon ECS 控制台中查看建议**
1. 在 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) 打开控制台。
1. 在 **Clusters**（集群）页面上，选择集群。
1. 在“集群详细信息”页面，找到**服务**部分，然后选择服务。
此时系统会显示服务详细信息页面。
1. 选择**服务自动扩缩**。
1. 选择预测式扩缩策略，然后依次选择**操作**、**预测式扩缩**、**查看建议**。
您可以查看有关策略的详细信息以及我们的建议。该建议告诉您预测性扩展策略是否比不使用预测性扩展策略做得更好。
如果您不确定预测性扩展策略是否适合您的组，请查看**可用性影响**和**成本影响**列以选择正确的策略。每列的信息告诉您该策略的影响。
+ **可用性影响**：描述与不使用策略相比，该策略是否可以通过预置足够的任务来处理工作负载，从而避免对可用性的负面影响。
+ **成本影响**：描述与不使用策略相比，该策略是否可以通过不过度预置任务而避免对您的成本产生负面影响。过度预置会导致您的任务未得到充分利用或处于闲置状态，这只会增加对成本的影响。
如果您有多个策略，则在以较低成本提供最大可用性优势的策略名称旁边显示**最佳预测**标签。对可用性的影响给予了更多的重视。
1. （可选）要选择所需的建议结果时间段，请从**评估期**下拉列表中选择您需要的值：**2 天**、**1 周**或**2 周**。默认情况下，评估期为过去两周。更长的评估期可为建议结果提供更多的数据点。但是，如果您的负载模式发生了变化，例如在需求异常之后，添加更多数据点可能不会改善结果。在这种情况下，您可以通过查看最新数据来获得更有针对性的建议。
**注意**
仅为处于**仅预测**模式的策略生成建议。当策略在整个评估期内处于**仅预测**模式时，建议功能的效果会更好。如果您在**预测和扩展**模式下启动策略，稍后将其切换为**仅预测**模式，则该策略的调查结果可能会有偏差。这是因为该策略已经为实际容量做出了贡献。
## 查看预测性扩展监控图表
在控制台中，您可以查看前几天、几周或几个月的预测，以便可视化策略在一段时间内的表现如何。在决定是否让策略扩展实际任务数时，您还可以使用这些信息来评估预测的准确性。
**在 Amazon ECS 控制台中查看预测式扩缩监控图表**
1. 在 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) 打开控制台。
1. 在 **Clusters**（集群）页面上，选择集群。
1. 在“集群详细信息”页面，找到**服务**部分，然后选择服务。
此时系统会显示服务详细信息页面。
1. 选择**服务自动扩缩**。
1. 选择预测式扩缩策略，然后依次选择**操作**、**预测式扩缩**、**查看图表**。
1. 在**监控**部分中，您可以根据实际值查看策略对过去和未来负载和容量的预测。**负载**图表显示所选负载指标的负载预测和实际值。**容量**图表显示策略预测的任务数。它还包括启动任务的实际数量。垂直线将历史值与未来预测分开。创建策略后不久，这些图表可用。
1. （可选）要更改图表中显示的历史数据量，请从页面顶部的**评估期**下拉列表中选择您的首选值。评估期不会以任何方式转换此页面上的数据。它只会更改显示的历史数据量。
**比较**负载**图表中的数据**
每条水平线代表一小时间隔内报告的一组不同的数据点：
1. **实际观测负载**使用所选负载指标的 SUM 统计数据来显示过去每小时的总负载。
1. **策略预测的负载**显示每小时的负载预测。该预测基于前两周的实际负载观测结果。
**比较**容量**图表中的数据**
每条水平线代表一小时间隔内报告的一组不同的数据点：
1. **实际观测任务数**显示 Amazon ECS 服务过去的实际容量，这取决于您的其他扩缩策略和所选时间段内有效的最小组大小。
1. **策略预测的容量**显示当策略处于**预测和扩展**模式时，您在每个小时开始时期望拥有的基准容量。
1. **推断的所需任务数**显示将扩缩指标维持在所选择目标值的理想任务数。
1. **最小任务数**显示服务中的最小任务数。
1. **最大容量**显示服务中的最大任务数。
为了计算推断的所需容量，我们首先假设每个任务在指定目标值下的利用率相等。实际上，任务数的利用并不均等。但是，通过假设任务之间的利用率分布均匀，我们可以对所需的容量进行可能的估计。然后计算任务数需求，与您在预测式扩缩策略中使用的扩缩指标成反比。换句话说，随着任务数的增加，扩缩指标会以相同的速率减少。例如，如果任务数翻倍，则扩缩指标必定会减少一半。
推断的所需容量的公式：
`sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)`
例如，我们在给定一小时内使用 `actualServiceUnits`（`10`）和 `scalingMetricValue`（`30`）。然后，我们采用您在预测扩展策略（`60`）中指定的 `targetUtilization`，计算同一小时的推断所需容量。这会返回值 `5`。这意味着 5 是推断出的维持容量所需的容量，与扩展指标的目标值成反比。
**注意**
您可以使用各种杠杆来调整和提高应用程序的成本节约和可用性。
您可以使用预测性扩展来计算基准容量，使用动态扩展来处理额外的容量。动态扩展独立于预测性扩展，会根据当前的利用率横向缩减和横向扩展。首先，Amazon ECS 会计算每个非计划的扩展策略的建议任务数。然后，它会根据提供最多任务的策略进行扩展。
要允许在负载减少时进行横向缩减，服务应始终至少有一个启用了横向缩减部分的动态扩缩策略。
您可以通过确保最小和最大容量不太严格来提高扩展性能。如果策略中包含的推荐任务数不在最小和最大容量范围内，则将阻止横向缩减和横向扩展。
# 使用 CloudWatch 监控 Amazon ECS 的预测式扩缩指标
您可以使用 Amazon CloudWatch 监控预测式扩缩相关数据。预测式扩缩策略将收集用于预测未来负载的数据。收集的数据会定期自动存储在 CloudWatch 中，并可用于直观地显示策略在一段时间内的表现。您还可以创建 CloudWatch 警报，以便在性能指标的变化超出所定义的限制时通知您。
## 可视化显示历史预测数据
预测式扩缩策略的负载预测数据可以在 CloudWatch 中查看，并且在单个图表中直观地显示与其他 CloudWatch 指标对比的预测时，这些数据非常有用。您还可以查看更大的时间范围的情况，以了解长期的趋势。您可以访问长达 15 个月的历史指标，以更好地了解您的策略性能。
**使用 CloudWatch 控制台查看历史预测数据**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择 **Metrics**（指标），然后选择 **All metrics**（所有指标）。
1. 选择**应用程序自动扩缩**指标命名空间。
1. 选择**预测式扩缩负载预测**。
1. 在搜索字段中，输入预测式扩缩策略的名称或 Amazon ECS 服务组的名称，然后按 Enter 键以筛选结果。
1. 要为指标绘制图表，请选中该指标旁的复选框。要更改图表的名称，请选择铅笔图标。要更改时间范围，请选择某个预定义的值或选择 **custom**。有关更多信息，请参阅《Amazon CloudWatch 用户指南》**中的[绘制指标图表](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html)。
1. 要更改统计数据，请选择 **Graphed metrics**（已绘制图表指标）选项卡。选择列标题或单个值，然后选择其他统计数据。尽管您可以为每个指标选择任何统计数据，但并非所有的统计数据都对 **PredictiveScalingLoadForecast** 指标有用。例如，**平均**、**最小**和**最大**统计数据非常有用，但**总和**统计数据用处不大。
1. 要在图表中添加其他指标，请在 **All**（全部）下选择 **Browse**（浏览），找到特定的指标，然后选中它旁边的复选框。您最多可以添加 10 个指标。
1. （可选）要将此图表添加到 CloudWatch 控制面板，请选择 **Actions**（操作），然后选择 **Add to dashboard**（添加到控制面板）。
## 使用指标数学创建准确度指标
借助指标数学，您可以查询多个 CloudWatch 指标并使用数学表达式来创建基于这些指标的新时间序列。您可以在 CloudWatch 控制台上直观显示生成的时间序列，并将其添加到控制面板中。有关指标数学的更多信息，请参阅《Amazon CloudWatch 用户指南》**中的[使用指标数学](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。
借助指标数学，您能够以不同方式绘制服务自动扩缩为预测式横向缩减而生成的数据。这可帮助您监控随时间变化的策略性能，并帮助您了解是否可以改进指标组合。
例如，您可以使用指标数学表达式来监控[平均绝对百分比误差](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error)（MAPE）。MAPE 指标可帮助监控在给定预测时段内预测值与实际观测值之间的差异。MAPE 值的变化可能表明随着应用性质的变化，策略的性能是否会随着时间的推移而下降。MAPE 增加说明着预测值和实际值之间的差异加大。
**示例：指标数学表达式**
要开始使用此类图表，您可以创建一个与下例中类似的指标数学表达式。
这不是单个指标，而是一组针对 `MetricDataQueries` 的指标数据查询结构。`MetricDataQueries` 中的每一项都会获取一个指标或执行一个数学表达式。第一项 `e1` 是一个数学表达式。指定的表达式将 `ReturnData` 参数设置为 `true`，这最终会生成单个时间序列。对于所有其他指标，`ReturnData` 值为 `false`。
在此例中，指定的表达式使用实际值和预测值作为输入，并返回新指标（MAPE）。`m1` 是包含实际负载值的 CloudWatch 指标（假设 CPU 利用率是最初为名为 `my-predictive-scaling-policy` 的策略指定的负载指标）。`m2` 是包含预测负载值的 CloudWatch 指标。MAPE 指标的数学语法如下所示：
*（（实际值：预测值）/（实际值）的绝对值）的平均值*
### 可视化显示准确度指标并设置警报
要可视化显示准确度指标数据，请在 CloudWatch 控制台中选择 **Metrics**（指标）选项卡。您可以在此处绘制数据图表。有关更多信息，请参阅《Amazon CloudWatch 用户指南》**中的[将数学表达式添加到 CloudWatch 图表](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console)。
您还可以在 **Metrics**（指标）部分为您监控的指标设置警报。在 **Graphed metrics**（绘制的指标）选项卡中，选择 **Actions**（操作）列下的 **Create alarm**（创建警报）。**Create alarm**（创建警报）图标用一个小铃铛表示。有关通知选项的更多信息，请参阅《Amazon CloudWatch 用户指南》**中的[根据指标数学表达式创建 CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)和[将警报更改通知用户](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html)。
您也可以使用 [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) 和 [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) 以使用指标数学执行计算，并基于输出创建警报。
# 使用计划操作来覆盖 Amazon ECS 的预测值
有时，您可能会获得有关未来应用程序需求的其他信息，预测计算无法考虑这些信息。例如，预测计算值可能会低估即将开展的市场营销活动所需的容量。您可以使用计划操作在未来时段内临时覆盖预测。计划操作可以循环运行，也可以在出现一次性需求波动的特定日期和时间运行。
例如，您可以创建一个任务数高于预测值的计划操作。在运行时，Amazon ECS 会更新服务中的最小任务数。由于预测性扩缩是针对任务数进行优化的，因此最小任务数高于预测值的计划操作将会被执行。这样可以防止任务数低于预期数量。要停止覆盖预测值，请使用第二个计划操作将最小任务数恢复为原始设置。
以下过程概述了在将来期间覆盖预测的步骤。
**Topics**
+ [步骤 1：（可选）分析时间序列数据](#analyzing-time-series-data)
+ [步骤 2：创建两个计划操作](#scheduling-capacity)
**重要**
本主题假设您尝试覆盖预测，以扩展到比预测更高的容量。如果需要在不受预测性扩缩策略干扰的情况下暂时减少任务数，则请改用*仅预测*模式。使用“仅预测”模式时，预测性扩缩将会继续生成预测，但不会自动增加任务数。然后，您可以监控资源利用率，并根据需要手动减少所需任务数。
## 步骤 1：（可选）分析时间序列数据
首先分析预测时间序列数据。这是一个可选步骤，但如果您想了解预测的详细信息，它会很有帮助。
1. **检索预测**
创建预测后，您可以查询预测中的特定时间段。查询的目的是获得特定时间段的时间序列数据的完整视图。
您的查询最多可以包含两天的未来预测数据。如果您已经使用了一段时间预测式扩展，您还可以访问过去的预测数据。但是，开始和结束时间之间的最长持续时间为 30 天。
若要使用 [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI 命令获取预测，请在命令中提供以下参数：
+ 在 `resource-id` 参数中输入集群的名称。
+ 在 `--policy-name` 参数中输入策略的名称。
+ 在 `--start-time` 参数中输入开始时间以仅返回在指定时间或之后的预测数据。
+ 在 `--end-time` 参数中输入结束时间以仅返回在指定时间之前的预测数据。
```
aws application-autoscaling get-predictive-scaling-forecast \
--service-namespace ecs \
--resource-id service/MyCluster/test \
--policy-name cpu40-predictive-scaling-policy \
--scalable-dimension ecs:service:DesiredCount \
--start-time "2021-05-19T17:00:00Z" \
--end-time "2021-05-19T23:00:00Z"
```
如果成功，该命令将返回类似于以下示例的数据。
```
{
"LoadForecast": [
{
"Timestamps": [
"2021-05-19T17:00:00+00:00",
"2021-05-19T18:00:00+00:00",
"2021-05-19T19:00:00+00:00",
"2021-05-19T20:00:00+00:00",
"2021-05-19T21:00:00+00:00",
"2021-05-19T22:00:00+00:00",
"2021-05-19T23:00:00+00:00"
],
"Values": [
153.0655799339254,
128.8288551285919,
107.1179447150675,
197.3601844551528,
626.4039934516954,
596.9441277518481,
677.9675713779869
],
"MetricSpecification": {
"TargetValue": 40.0,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
}
],
"CapacityForecast": {
"Timestamps": [
"2021-05-19T17:00:00+00:00",
"2021-05-19T18:00:00+00:00",
"2021-05-19T19:00:00+00:00",
"2021-05-19T20:00:00+00:00",
"2021-05-19T21:00:00+00:00",
"2021-05-19T22:00:00+00:00",
"2021-05-19T23:00:00+00:00"
],
"Values": [
2.0,
2.0,
2.0,
2.0,
4.0,
4.0,
4.0
]
},
"UpdateTime": "2021-05-19T01:52:50.118000+00:00"
}
```
此响应包括两个预测：`LoadForecast` 和 `CapacityForecast`。`LoadForecast` 显示每小时负载预测。`CapacityForecast` 显示每小时处理预测负载所需的容量的预测值，同时保持 `TargetValue` 为 40.0（平均 CPU 利用率为 40%）。
1. **确定目标时间段**
确定应发生一次性需求波动的小时数。请记住，预测中显示的日期和时间以 UTC 为单位。
## 步骤 2：创建两个计划操作
接下来，在应用程序的负载高于预测负载的特定时间段内创建两个计划操作。例如，如果您的营销活动会在有限时间段内使网站的流量增加，则可计划一个一次性操作以在其启动时更新最小容量。然后，安排另一个操作，以便在事件结束时将最小容量返回到原始设置。
1. 在 [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) 打开控制台。
1. 在 **Clusters**（集群）页面上，选择集群。
1. 在“集群详细信息”页面，找到**服务**部分，然后选择服务。
此时系统会显示服务详细信息页面。
1. 选择**服务自动扩缩**。
此时将显示策略页面。
1. 选择**计划操作**，然后选择**创建**。
此时将显示**“创建计划”操作**页面。
1. 对于 **操作名称**，输入唯一的名称。
1. 对于**时区**，请选择时区。
列出的所有时区均来自 IANA 时区数据库。有关详细信息，请参阅 [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。
1. 对于**启动时间**，输入操作启动的**日期**和**时间**。
1. 对于**循环**，选择**一次**。
1. 对于**任务调整**下的“最小值”，输入一个小于或等于最大任务数的值。
1. 选择**创建计划操作**。
此时将显示策略页面。
1. 配置第二个计划操作，以在事件结束时将最小任务数恢复为原始设置。预测性扩缩只能在设置的**最小值**小于预测值时扩缩任务数。
**为一次性事件创建两个计划操作（AWS CLI）**
要使用 AWS CLI 创建计划操作，请使用 [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) 命令。
例如，让我们定义一个时间表，在 5 月 19 日下午 5:00 时保持最少三个实例的容量，持续 8 小时。以下命令显示如何实现此方案。
第一个 [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) 命令指示 Amazon EC2 Auto Scaling 在 2021 年 5 月 19 日 UTC 下午 5:00 更新指定自动扩缩组的最小容量。
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
--auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```
第二个命令指示 Amazon EC2 Auto Scaling 将该组的最小容量设置为 2021 年 5 月 20 日 UTC 上午 1:00。
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
--auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```
将这些计划操作添加到自动扩缩组后，Amazon EC2 Auto Scaling 将执行以下操作：
+ 2021 年 5 月 19 日下午 5:00，第一个计划的操作将运行。如果组中当前已少于三个实例，则该组会扩展到三个实例。在此期间和接下来的八小时内，如果预测容量高于实际容量，或者如果有动态扩展策略生效，Amazon EC2 Auto Scaling 可以继续横向扩展。
+ 2021 年 5 月 20 日上午 1:00，将运行第二个计划的操作。这将在事件结束时将最小容量恢复为其原始设置。
### 根据重复性计划进行扩展
要覆盖每周相同时间段的预测，请创建两个计划操作，并使用 cron 表达式提供时间和日期逻辑。
此 cron 表达式格式包含五个空格分隔的字段：[Minute] [Hour] [Day\$1of\$1Month] [Month\$1of\$1Year] [Day\$1of\$1Week]。字段可以包含任何允许的值，包括特殊字符。
例如，下面的 cron 表达式在每周二上午 6:30 运行操作。星号用作通配符，以匹配字段的所有值。
```
30 6 * * 2
```
### 另请参阅
有关如何管理计划操作的更多信息，请参阅[使用计划操作扩展 Amazon ECS 服务](service-autoscaling-schedulescaling.md)。
# 面向 Amazon ECS 的使用自定义指标的高级预测式扩缩策略
在预测式扩缩策略中，您可以使用预定义指标或自定义指标。当预定义指标（例如 CPU、内存等）不足以充分描述应用程序负载时，自定义指标非常有用。
使用自定义指标创建预测式扩缩策略时，您可以指定由 AWS 提供的其他 CloudWatch 指标。或者，您可以指定自己定义和发布的指标。您还可以使用指标数学来聚合现有的指标并将其转换为 AWS 会不自动跟踪的新时间序列。例如，通过计算新的总和或平均值来组合数据中的值时，该操作称为*执行聚合*。生成的数据称为*聚合*。
以下部分包含了有关如何为构造策略的 JSON 结构的最佳实践和示例。
## 先决条件
要将自定义指标添加到预测性扩缩策略，您必须具有 `cloudwatch:GetMetricData` 权限。
要指定自己的指标而不是 AWS 提供的指标，您必须首先将您的指标发布到 CloudWatch。有关更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。
如果发布自己的指标，请确保以至少五分钟的频率发布数据点。根据所需的时间长度从 CloudWatch 中检索数据点。例如，负载指标规范以每小时为指标来衡量应用程序的负载。CloudWatch 使用您已发布的指标数据在任意一小时期间提供单个数据值，其方法是将所有数据点与每个一小时内的时间戳聚合起来。
## 最佳实践
以下最佳实践可帮助您更有效地使用自定义指标：
+ 对于负载指标规范，最有用的指标是作为一个整体表示自动扩缩组负载的指标。
+ 对于扩缩指标规范，要扩展的最有用指标是每个任务指标的平均吞吐量或利用率。
+ 目标利用率必须与扩展指标的类型匹配。例如，对于使用 CPU 利用率的策略配置，这是目标百分比。
+ 如果未遵循这些建议，那么时间序列的预测未来值可能会不正确。要验证数据是否正确，您可以在控制台中查看预测值。或者，在创建预测式扩缩策略之后，请检查对 [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html) API 的调用返回的 `LoadForecast` 对象。
+ 我们强烈建议您在仅预测模式下配置预测式横向缩减，以便在预测式扩展启动主动扩展之前对预测进行评估。
## 限制
+ 您可以在一个指标规范中查询最多 10 个指标的数据点。
+ 为满足此限制，一个表达式算作一个指标。
## 排查使用自定义指标的预测式扩缩策略的问题
如果在使用自定义指标时出现问题，建议您执行以下操作：
+ 如果您在使用搜索表达式时在蓝绿部署中遇到问题，请确保您创建的搜索表达式是在寻找部分匹配项而不是完全匹配项。此外，请检查您的查询是否只查找在特定应用程序中运行的自动扩缩组。有关搜索表达式语法的更多信息，请参阅 *Amazon CloudWatch 用户指南*中的 [CloudWatch 搜索表达式语法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)。
+ [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 命令会在您创建扩缩策略时对表达式进行验证。但是，此命令有可能无法识别所检测错误的确切原因。要修复这些问题，请解决您在 [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) 命令请求的回应中收到的错误。您还可以通过 CloudWatch 控制台对表达式进行问题排查。
+ 如果 `MetricDataQueries` 自行指定 SEARCH() 函数，而没有像 SUM() 这样的数学函数，则必须为 `ReturnData` 指定 `false`。原因在于搜索表达式可能返回多个时间序列，而基于表达式的指标规范仅可以返回一个时间序列。
+ 搜索表达式中涉及的所有指标均应该具有相同的分辨率。
# 使用 Amazon ECS 为预测式扩缩自定义指标构建 JSON
以下部分包含了有关如何配置预测行扩缩以从 CloudWatch 查询数据的示例。配置此选项有两种不同的方法，您选择的方法会影响您为预测性扩缩策略构造 JSON 时使用的格式。使用指标数学时，JSON 格式会根据所执行的指标数学进一步变化。
1. 要创建直接从 AWS 提供的其他 CloudWatch 指标或您发布到 CloudWatch 的指标中获取数据的策略，请参阅 [包含自定义负载和扩缩指标的预测式扩缩策略示例（使用 AWS CLI）](#predictive-scaling-custom-metrics-example1)。
## 包含自定义负载和扩缩指标的预测式扩缩策略示例（使用 AWS CLI）
要通过 AWS CLI 使用自定义负载和扩缩指标创建预测性扩缩策略，请将 `--predictive-scaling-configuration` 的参数存储在名为 `config.json` 的 JSON 文件中。
您可以将以下示例中的可替换值替换为您的指标和目标利用率值，从而开始添加自定义指标。
```
{
"MetricSpecifications": [
{
"TargetValue": 50,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Id": "scaling_metric",
"MetricStat": {
"Metric": {
"MetricName": "MyUtilizationMetric",
"Namespace": "MyNameSpace",
"Dimensions": [
{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
]
},
"Stat": "Average"
}
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_metric",
"MetricStat": {
"Metric": {
"MetricName": "MyLoadMetric",
"Namespace": "MyNameSpace",
"Dimensions": [
{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
]
},
"Stat": "Sum"
}
}
]
}
}
]
}
```
有关更多信息，请参阅《Amazon EC2 Auto Scaling API 参考》**中的 [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)。
**注意**
以下是一些可以帮助您查找 CloudWatch 指标的指标名称、命名空间、维度和统计数据的其他资源：
有关 AWS 服务可用指标的更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[发布 CloudWatch 指标的 AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)。
要获取带有 AWS CLI 的 CloudWatch 指标的确切指标名称、命名空间和维度（如果适用），请参阅[列出指标](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html)。
要创建此策略，请运行 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 命令并将此 JSON 文件作为输入，如下例所示。
```
aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
如果成功，此命令将返回策略的 Amazon 资源名称（ARN）。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
"Alarms": []
}
```
# 使用指标数学表达式
以下部分提供有关在策略中如何针对预测式扩缩策略使用指标数学的信息。
## 了解指标数学
如果您想要做的只是聚合现有指标数据，那么 CloudWatch 指标数学可以节省向 CloudWatch 发布另一个指标的精力和成本。您可以使用 AWS 提供的任何指标，还可以使用定义为应用程序一部分的指标。
有关更多信息，请参阅《Amazon CloudWatch 用户指南》**中的[使用指标数学](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。
如果您选择在预测性扩展策略中使用指标数学表达式，请考虑以下几点：
+ 指标数学运算使用指标名称、命名空间和维度键/值对指标的唯一组合的数据点。
+ 您可以使用任意算术运算符（\$1 - \$1 / ^）、统计函数（例如 AVG 或 SUM）或 CloudWatch 支持的其他函数。
+ 您可以在数学表达式的公式中同时使用指标和其他数学表达式的结果。
+ 指标数学表达式可以由不同的聚合组成。但是，得到最终聚合结果的最佳实践是针对扩展指标使用 `Average` 以及针对负载指标使用 `Sum`。
+ 指标规范中使用的任何表达式最终都必须返回一个单个时间序列。
要使用指标数学，请执行以下操作：
+ 选择一个或多个 CloudWatch 指标。然后，创建表达式。有关更多信息，请参阅《Amazon CloudWatch 用户指南》**中的[使用指标数学](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。
+ 使用 CloudWatch 控制台或 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API 验证指标数学表达式是否有效。
## 使用指标数学组合指标的预测性扩缩策略示例（AWS CLI）
有时，您可能需要首先以某种方式处理其数据，而不是直接指定指标。例如，您可能有一个从 Amazon SQS 队列中提取工作的应用程序，并且可能希望使用队列中的项目数作为预测性扩展的标准。队列中的消息数不仅仅定义您需要的实例数。因此，需要执行更多工作来创建可用于计算每个实例的积压的指标。
以下示例是适用于此场景的预测扩展策略示例。它指定了基于 Amazon SQS `ApproximateNumberOfMessagesVisible` 指标的扩展和负载指标，即可从队列中获取的用于检索的消息数量。它还使用 Amazon EC2 Auto Scaling `GroupInServiceInstances` 指标和数学表达式，计算扩展指标的每个实例的积压。
```
aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
--policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
--service-namespace ecs \
--resource-id service/MyCluster/test \
"MetricSpecifications": [
{
"TargetValue": 100,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Label": "Get the queue size (the number of messages waiting to be processed)",
"Id": "queue_size",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Get the group size (the number of running instances)",
"Id": "running_capacity",
"MetricStat": {
"Metric": {
"MetricName": "GroupInServiceInstances",
"Namespace": "AWS/AutoScaling",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Calculate the backlog per instance",
"Id": "scaling_metric",
"Expression": "queue_size / running_capacity",
"ReturnData": true
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_metric",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
],
},
"Stat": "Sum"
},
"ReturnData": true
}
]
}
}
]
}
```
该示例返回策略的 ARN。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
"Alarms": []
}
```