# COST 9. 如何管理需求和供应资源？
为了工作负载的性能与支出实现平衡，请确保您支付过费用的所有资源都得到利用，并避免出现实例利用率过低的情况。无论是从运营成本（由于过度使用导致性能下降）还是从浪费 AWS 支出（由于过度预置）的角度衡量，利用率指标过高或过低都会对组织产生负面影响。
**Topics**
+ [COST09-BP01 对工作负载需求执行分析](cost_manage_demand_resources_cost_analysis.md)
+ [COST09-BP02 实施缓冲区或节流来管理需求](cost_manage_demand_resources_buffer_throttle.md)
+ [COST09-BP03 动态供应资源](cost_manage_demand_resources_dynamic.md)
# COST09-BP01 对工作负载需求执行分析
分析工作负载需求随时间的变化。确认分析涵盖季节性趋势，并准确反映整个工作负载生命周期内的运行条件。分析工作应该体现可能带来的好处，例如花费的时间与工作负载成本成正比。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
分析云计算的工作负载需求涉及了解在云环境中启动的计算任务的模式和特征。这种分析有助于用户优化资源分配、管理成本并验证性能是否达到要求的水平。
了解工作负载的要求。组织要求应指出工作负载对于请求的响应时间。响应时间可用于确定需求是否得到了管理，或者是否应改变资源供应以满足需求。
分析应包括需求的可预测性和可重复性、需求的变化速率以及需求的变化量。对足够长的时间执行分析，以纳入任何季节性变化，例如月末处理或假期高峰。
分析工作应该体现实施扩缩可能带来的好处。查看组件的预期总成本，以及在工作负载生命周期内使用情况和成本的任何增加和减少。
以下是执行云计算的工作负载需求分析时，需要考虑的一些关键方面：
1. **资源利用率和性能指标**：分析 AWS 资源在一段时间内的使用情况。确定高峰期和非高峰期使用模式，以优化资源分配和扩缩策略。监控性能指标，如响应时间、延迟、吞吐量和错误率。这些指标有助于评测云基础设施的整体运行状况和效率。
1. **用户和应用程序扩缩行为**：了解用户行为及其对工作负载需求的影响。检查用户流量模式有助于增强内容的交付和应用程序的响应能力。分析工作负载如何随着需求的增长而扩展。确定自动扩缩参数的配置是否正确有效，以处理负载波动。
1. **工作负载类型：**识别云中运行的不同类型的工作负载，如批处理、实时数据处理、Web 应用程序、数据库或机器学习。每种类型的工作负载都可能有不同的资源需求和性能特征。
1. **服务水平协议（SLA）：**将实际绩效与 SLA 进行比较，确保合规性并确定需要改进的方面。
可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 来收集和跟踪各项指标、监控日志文件、设置警报以及自动应对 AWS 资源的更改。还可以通过使用 Amazon CloudWatch 全面地了解资源利用率、应用程序性能和运行状况。
借助 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)，您可以按照最佳实践预置资源，提高系统性能和可靠性，增强安全性，并寻找节省资金的机会。您也可以关闭非生产实例，并使用 Amazon CloudWatch 和 Auto Scaling 来匹配需求的增加或减少。
最后，可以将 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)或 [Quick](https://aws.amazon.com/quicksight/) 与 AWS 成本和使用情况报告（CUR）文件或应用程序日志一起使用，来对工作负载需求执行高级分析。
总之，通过全面的工作负载需求分析，组织可以就资源预置、扩缩和优化作出明智的决策，从而提高性能、成本效益和用户满意度。
### 实施步骤
+ **分析现有工作负载数据：**分析现有工作负载中的数据、以前工作负载版本中的数据或预测使用模式中的数据。使用 Amazon CloudWatch、日志文件和监控数据来深入了解工作负载的使用情况。分析整个工作负载周期，并收集任何季节性变化数据，如月末或年末活动。分析中反映的工作应该体现出工作负载特征。应将最多的精力放在需求变化最大的高价值工作负载上。应将最少的精力放在需求变化最小的低价值工作负载上。
+ **预测外部影响：**与组织中会影响或更改工作负载需求的团队成员会面。通常涉及的团队包括销售、营销或业务拓展团队。与他们合作，了解其运作周期，以及是否有改变工作负载需求的任何活动。使用这些数据预测工作负载需求。
## 资源
**相关文档：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS 实例调度器](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Getting started with Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [Quick](https://aws.amazon.com/quicksight/)
**相关示例：**
+ [监控、跟踪和分析以实现成本优化](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/monitor-track-and-analyze/)
+ [Searching and analyzing logs in CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-search-analysis.html)
# COST09-BP02 实施缓冲区或节流来管理需求
缓冲区和节流可修改工作负载需求，从而避免出现任何峰值情形。在客户端执行重试时实施节流。实施缓冲以存储请求并将处理任务往后推迟一段时间。确认设计节流和缓冲区时客户端能够在所需的时间内收到响应。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
在云计算领域，实施缓冲区或节流对于管理需求和减少工作负载所需的预置容量至关重要。为了获得最佳性能，必须衡量总需求，包括峰值、请求变化的速度和必需的响应时间。当客户端能够重新发送请求时，应用节流比较切实可行。相反，对于缺乏重试功能的客户端，理想的方法是实施缓冲区解决方案。此类缓冲区可舒缓请求的涌入，并优化具有不同操作速度的应用程序之间的交互。
![\[需求曲线，有两个不同的峰值，需要高预置容量\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/provisioned-capacity-1.png)
假设工作负载的需求曲线如上图所示。此工作负载有两个峰值，为了处理这些峰值，如橙色线所示预置资源容量。因为需要预置容量来处理这两个峰值，所以此工作负载所使用的资源和能源不是由需求曲线下的区域表示，而是由预置容量线下面的区域表示。展平工作负载需求曲线有助于降低工作负载的预置容量和减少对环境的影响。为了平滑峰值，可以考虑实施节流或缓冲解决方案。
为了更好地理解它们，让我们探讨一下节流和缓冲。
**节流：**如果需求源具有重试功能，可以实施节流。节流会告诉需求源，如果当前无法处理请求，则应稍后再试。源将等待一段时间，然后重试请求。实施节流的优势是可限制最大资源量和工作负载成本。在 AWS 中，可以使用 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 实施节流。
**基于缓冲：**基于缓冲的方法使用*产生器*（向队列发送消息的组件）、*使用器*（从队列接收消息的组件）和*队列*（保存消息）来存储消息。然后消息将由使用器读取并处理，这样消息就能够以满足使用器业务要求的速率运行。通过使用以缓冲区为中心的方法，产生器发出的消息被存储在队列或流中，随时可供使用器以符合其运营需求的速度进行访问。
在 AWS 中，您可以从多项服务中进行选择，以便实施缓冲方法。[Amazon Simple Queue Service（Amazon SQS）](https://aws.amazon.com/sqs/)是一项托管服务，提供允许单个使用器读取单个消息的队列。[Amazon Kinesis](https://aws.amazon.com/kinesis/) 提供允许众多使用器读取相同消息的流。
缓冲和节流可以通过修改工作负载需求来平滑任何峰值。在客户端重试操作时使用节流，并使用缓冲来保存请求以供以后处理。使用基于缓冲区的方法时，请构建工作负载以在所需时间内处理请求，并验证您是否能够处理重复的工作请求。分析总体需求、变化率和所需的响应时间，以使所需节流或缓冲的大小适宜。
### 实施步骤
+ **分析客户端要求：**分析客户端请求，确定它们是否能够执行重试。对于无法执行重试的客户端，需要实施缓冲区。分析总体需求、变化率和所需的响应时间，以确定所需的节流或缓冲区大小。
+ **实施缓冲或限制：**在工作负载中实施缓冲或限制。Amazon Simple Queue Service（Amazon SQS）之类的队列可以为工作负载组件提供缓冲区。Amazon API Gateway 可以为工作负载组件提供节流。
## 资源
**相关最佳实践：**
+ [SUS02-BP06 实施缓冲和节流以展平需求曲线](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a7.html)
+ [REL05-BP02 限制请求](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
**相关文档：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS 实例调度器](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)：
+ [Amazon Simple Queue Service](https://aws.amazon.com/sqs/)
+ [Getting started with Amazon SQS](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)
**相关视频：**
+ [Choosing the Right Messaging Service for Your Distributed App](https://www.youtube.com/watch?v=4-JmX6MIDDI)
**相关示例：**
+ [Managing and monitoring API throttling in your workloads](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [Throttling a tiered, multi-tenant REST API at scale using API Gateway](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [Enabling Tiering and Throttling in a Multi-Tenant Amazon EKS SaaS Solution Using Amazon API Gateway](https://aws.amazon.com/blogs/apn/enabling-tiering-and-throttling-in-a-multi-tenant-amazon-eks-saas-solution-using-amazon-api-gateway/)
+ [Application integration Using Queues and Messages](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
# COST09-BP03 动态供应资源
资源按计划预置。这种预置可以基于需求（例如通过自动扩缩来实现），也可以基于时间（需求可以预测，基于时间提供资源）。这些方法可以尽可能减少过度预置或预置不足的情况。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
AWS 客户可以通过多种方式增加可供应用程序使用的资源，并提供资源以满足需求。其中一个选项是使用 AWS 实例调度器，它可以自动启动和停止 Amazon Elastic Compute Cloud（Amazon EC2）及 Amazon Relational Database Service（Amazon RDS）实例。另一个选项是使用 AWS Auto Scaling，该服务让您可以根据应用程序或服务的需求，自动扩缩计算资源。根据需求提供资源，这样您就只需要为使用的资源付费，并且仅在有需要时启动资源，在不需要时终止资源，从而降低成本。
[AWS 实例调度器](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)让您可以将 Amazon EC2 和 Amazon RDS 实例配置为在指定的时间停止和启动，这样您就可以通过一致的时间模式满足对相同资源的需求，例如用户在每天早上八点访问 Amazon EC2 实例，晚上六点后就不再需要访问。该解决方案可停止不使用的资源，并在需要时启动它们，帮助降低运营成本。
![\[图中显示了使用 AWS 实例调度器优化成本。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/instance-scheduler-diagram.png)
您还可以通过简单的用户界面（UI）使用 AWS Systems Manager 快速设置功能，轻松地跨账户和区域来为 Amazon EC2 实例配置计划。您可以使用 AWS 实例调度器来计划 Amazon EC2 或 Amazon RDS 实例，也可以停止和启动现有实例。但是，您无法停止和启动属于自动扩缩组（ASG）或管理 Amazon Redshift 或 Amazon OpenSearch Service 等服务的实例。自动扩缩组对组中的实例和何时创建这些实例有自己的计划。
[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 有助于您调整容量以维持稳定、可预测的性能，并确保成本最低，以满足不断变化的需求。这是一项用来扩缩应用程序容量的完全托管式免费服务，与 Amazon EC2 实例和竞价型实例集、Amazon ECS、Amazon DynamoDB 与 Amazon Aurora 集成。自动扩缩提供自动资源发现功能，帮助在工作负载中找到可以配置的资源，它具有内置的扩缩策略来优化性能、成本或者在两者之间取得平衡，并提供预测性扩展来协助应对定期出现的峰值。
可以通过多种扩缩选项来扩缩自动扩缩组：
+ 始终保持当前实例级别
+ 手动缩放
+ 按计划扩展
+ 根据需求进行扩展
+ 使用预测式扩展
自动扩缩策略各不相同，可以分为动态扩缩策略和计划扩缩策略。动态策略为手动扩缩或动态扩缩，这可以是计划扩缩或者预测性扩缩。您可以针对动态、计划和预测性扩缩使用扩缩策略。还可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 中的指标和警报来触发工作负载的扩缩事件。我们建议您使用[启动模板](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)，确保可以访问最新功能和改进。当您使用启动配置时，并非所有的自动扩缩功能都可用。例如，您无法创建 Auto Scaling 组来同时启动竞价型实例和按需型实例或者指定多个实例类型。您必须使用启动模板来配置这些功能。使用启动模板时，建议您对每个模板进行版本控制。利用启动模板的版本控制，您可以创建全套参数的子集。然后，您可以重复使用它来创建同一启动模板的其他版本。
可以使用 AWS Auto Scaling 或通过 [AWS API 或 SDK](https://aws.amazon.com/developer/tools/) 在代码中加入扩缩。这样省去了手动更改环境的操作成本，因而工作负载的总体成本得以降低，而且可以更快地执行更改。这还使您的工作负载资源配置随时与您的需求相匹配。为了遵循这一最佳实践，并为组织动态供应资源，您应该了解 AWS 云 中的水平和垂直扩缩，以及 Amazon EC2 实例上运行的应用程序的性质。您的云财务管理团队最好与技术团队合作，以遵循这一最佳实践。
[弹性负载均衡（ELB）](https://aws.amazon.com/elasticloadbalancing/)通过在多种资源之间分配需求来帮助您扩缩规模。通过使用 ASG 和弹性负载均衡，可以按照最优方式路由流量来管理传入的请求，以便自动扩缩组中没有一个实例会发生负载过高的情况。请求将以轮询方式，在目标组的所有目标上分配，而不考虑容量或利用率。
典型的指标可以是标准 Amazon 指标，例如 CPU 利用率、网络吞吐量以及弹性负载均衡观察到的请求和响应延迟。如果可能，应该使用指示客户体验的指标，通常是来自工作负载中的应用程序代码的自定义指标。在本文档中，为了详细说明如何动态满足需求，我们将自动扩缩划分为两类：基于需求的供应模型和基于时间的供应模型，并分别深入探讨这两种模型。
**基于需求的供应：**利用云的弹性来提供资源，根据近实时的需求状态来满足不断变化的需求。对于基于需求的供应，请使用 API 或服务功能，以编程方式改变架构中云资源的数量。这让您能够在架构中扩缩组件，并在需求高峰期间增加资源数量以保持性能，也可以在需求量降低时减少容量以降低成本。
![\[图中描述了基于需求的扩缩策略，例如简单/分步扩缩和目标跟踪。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/demand-based-supply.png)
+ **简单/步骤扩缩：**监控指标，按照客户定义的步骤手动添加/删除实例。
+ **目标跟踪：**类似恒温器的控制机制，可自动添加或删除实例，以维护客户定义的目标指标。
当采用基于需求的方法进行构建时，请注意两个重要事项。首先，了解您必须以多快的速度预置新资源。其次，了解供应和需求之间的差额将发生变化。您必须准备好应对需求变化的速度，并准备好应对资源故障。
**基于时间的供应：**基于时间的方法可以协调资源容量，以满足可预测或按时间明确定义的需求。此方法通常不依赖资源的利用水平。基于时间的方法可以确保资源在需要的特定时间可用，并且提供时不会因启动程序和系统或一致性检查而发生延迟。使用基于时间的方法，您可以在繁忙时段提供额外的资源或增加容量。
![\[图中描述了基于时间的扩缩策略，例如计划扩缩和预测性扩缩。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/time-based-supply.png)
您可以使用计划性或预测性自动扩缩，实施基于时间的方法。工作负载可以在规定的时间按计划横向扩展或缩减（例如办公时间开始时），从而确保用户就位或需求增加时资源可用。预测性扩缩使用相关模式进行横向扩展，而计划扩缩在预先规定的时间进行横向扩展。您还可以在自动扩缩组中使用[基于属性的实例类型选择（ABS）策略](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)，该策略允许您将实例要求表示为一组属性，例如 vCPU、内存和存储。这还允许您在新一代实例类型发布时自动使用它们，并通过 Amazon EC2 竞价型实例访问更广泛的容量。Amazon EC2 Fleet 和 Amazon EC2 Auto Scaling 会选择并启动符合指定属性的实例，无需手动选择实例类型。
可以利用 [AWS API 和 SDK](https://aws.amazon.com/developer/tools/) 以及 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)，在需要时自动预置和停用整个环境。此方法非常适合仅在规定的办公时间或时间段运行的开发或测试环境。您可以使用 API 来扩缩环境中的资源大小（垂直扩缩）。例如，可以通过更改实例大小或类纵向扩展生产工作负载。这可以通过停止和启动实例，以及选择不同的实例大小或类来实现。这种技巧也可以应用于其他资源，如 Amazon EBS 弹性卷，您可以在使用时对其进行修改以增加大小、调整性能（IOPS）或更改卷类型。
当采用基于时间的方法进行构建时，请注意两个重要事项。首先，使用模式的一致性如何？ 其次，如果模式发生更改会产生什么影响？ 您可以通过两种方式提高预测的准确性：监控工作负载和使用商业智能。如果您发现使用模式发生重大更改，可以调整时间，以确保提供覆盖范围。
## 实施步骤
+ **配置计划扩缩：**对于可预测的需求变化，基于时间的扩缩可以及时提供正确的资源数量。如果资源创建和配置的速度不够快，无法响应需求变化，也可使用这种方法。根据工作负载分析，使用 AWS Auto Scaling 配置计划扩缩。要配置基于时间的计划，可以使用预测性扩缩而不是计划扩缩，根据预期或可预测的负载变化，提前增加自动扩缩组中的 Amazon EC2 实例数量。
+ **配置预测性扩缩：**使用预测性扩缩，可在流量流的每日和每周模式之前增加自动扩缩组中的 Amazon EC2 实例数量。如果您有定期的流量高峰和需要很长时间才能启动的应用程序，则应该考虑使用预测性扩缩。与本质上属于被动应对的单纯动态扩缩相比，预测性扩缩可帮助您在预计负载到来之前初始化容量，从而更快地扩缩。例如，如果用户在开始上班时开始使用工作负载，而在下班后不再使用，预测性扩缩可以在上班之前增加容量，这就消除了动态扩缩对流量变化作出反应的延迟。
+ **配置动态自动扩缩：**要根据活动工作负载指标配置扩缩，请使用自动扩缩。使用分析并配置自动扩缩以在正确的资源级别启动，并确认工作负载在所需的时间内横向缩减。您可以启动并自动扩展单个 Auto Scaling 组中的一组按需实例和竞价型实例。除了享受使用竞价型实例的折扣外，您还可以使用预留实例或 Savings Plan 获得常规按需实例定价的折扣费率。以上所有因素的综合作用是帮助您进一步节约 Amazon EC2 实例成本，同时帮助您获得应用程序所需的规模和性能。
## 资源
**相关文档：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS 实例调度器](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ 扩展 Auto Scaling 组的大小
+ [Getting Started with Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Getting started with Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Scheduled Scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Predictive scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)
**相关视频：**
+ [Target Tracking Scaling Policies for Auto Scaling](https://www.youtube.com/watch?v=-RumeaoPB2M)
+ [AWS 实例调度器](https://www.youtube.com/watch?v=nTLEyo2NzUs)
**相关示例：**
+ [基于属性选择实例类型用于 Amazon EC2 Fleet 的自动扩缩](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [Optimizing Amazon Elastic Container Service for cost using scheduled scaling](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [Predictive Scaling with Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [如何将实例调度器和 CloudFormation 配合使用来计划 Amazon EC2 实例？](https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-instance-scheduler/)