# 设计工作负载来适应需求变化
可扩展**工作负载**提供了自动添加或删除资源的弹性，因此资源在任何给定时间点都非常符合当前需求。
**Topics**
+ [REL07-BP01 在获取或扩展资源时利用自动化](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 在检测到对工作负载的破坏时获取资源](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 在检测到某个工作负载需要更多资源时获取资源](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 对工作负载进行负载测试](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 在获取或扩展资源时利用自动化
云端可靠性的基石是基础设施和资源的程序化定义、预置和管理。自动化有助于您简化资源预置，促进一致和安全的部署，并在整个基础设施中扩展资源。
**期望结果：**管理基础设施即代码（IaC）。您可以在版本控制系统（VCS）中定义和维护基础设施代码。您可以将预置 AWS 资源的过程委托给自动机制，并利用托管式服务，例如应用程序负载均衡器（ALB）、网络负载均衡器（NLB）和自动扩缩组。您可以使用持续集成/持续交付（CI/CD）管道来预置资源，以便代码更改自动启动资源更新，包括对自动扩缩配置的更新。
**常见反模式：**
+ 您使用命令行或在 AWS 管理控制台中（也称为*单击操作*）手动部署资源。
+ 您将应用程序组件或资源紧密耦合，从而创建了不灵活的架构。
+ 您实施的扩展策略不灵活，无法适应不断变化的业务需求、流量规律或新的资源类型。
+ 您手动估算容量来满足预期需求。
**建立这种最佳实践的好处**：基础设施即代码（IaC）支持以编程方式定义基础设施。这有助于您在与应用程序更改相同的软件开发生命周期中管理基础设施更改，从而提高一致性和可重复性，并降低手动、易出错任务的风险。通过使用自动交付管道实施 IaC，可以进一步简化预置和更新资源的流程。您无需手动干预，即可可靠、高效地部署基础设施更新。在扩展资源以满足不断变化的需求时，这种敏捷性尤其重要。
您可以结合使用 IaC 和交付管道来实现动态、自动的资源扩展。通过监控关键指标和应用预定义的扩展策略，自动扩缩可以根据需要自动预置或取消预置资源，从而提高性能和成本效益。这样可以减少因应用程序或工作负载要求发生变化而导致手动错误或延迟的可能性。
IaC、自动交付管道和自动扩缩相结合，有助于组织放心地预置、更新和扩展其环境。这种自动化对于维护响应迅速、富有韧性和高效管理的云基础设施至关重要。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要为 AWS 架构的 CI/CD 管道和基础设施即代码（IaC）设置自动化，请选择版本控制系统（例如 Git）来存储 IaC 模板和配置。这些模板可以使用诸如 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 之类的工具编写。首先，请在这些模板中定义基础设施组件（例如 AWS VPC、Amazon EC2 Auto Scaling 组和 Amazon RDS 数据库）。
接下来，将这些 IaC 模板与 CI/CD 管道集成，以实现部署过程的自动化。[AWS CodePipeline](https://aws.amazon.com/codepipeline/) 提供了无缝的 AWS 原生解决方案，您也可以使用其它第三方 CI/CD 解决方案。创建一个在版本控制存储库发生更改时激活的管道。将管道配置为包括以下各个阶段：整理和验证 IaC 模板、将基础设施部署到暂存环境、运行自动测试以及最终部署到生产环境。必要时纳入审批步骤，以保持对变更的控制。这种自动化的管道不仅加快了部署速度，而且促进了跨环境的一致性和可靠性。
在 IaC 中配置诸如 Amazon EC2 实例、Amazon ECS 任务和数据库副本等资源的自动扩缩，以根据需要提供自动横向扩展和横向缩减。这种方法通过根据需求动态调整资源，来增强应用程序可用性和性能并优化成本。有关支持的资源列表，请参阅 [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 和 [AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html)。
### 实施步骤
1. 创建并使用源代码存储库，来存储控制基础设施配置的代码。提交对此存储库的更改，来反映您要进行的任何持续更改。
1. 选择基础设施即代码解决方案（例如 AWS CloudFormation），以使您的基础设施保持最新状态并检测与预期状态的不一致性（偏差）。
1. 将 IaC 平台与 CI/CD 管道集成来实现部署自动化。
1. 确定并收集用于自动扩缩资源的适当指标。
1. 使用适用于工作负载组件的横向扩展和横向缩减策略，来配置资源的自动扩缩。考虑使用计划的扩展来实现可预测的使用规律。
1. 监控部署来检测故障和回归。在 CI/CD 平台中实施回滚机制，以便在必要时还原更改。
## 资源
**相关文档：**
+ [AWS Auto Scaling: How Scaling Plans Work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: products that can be used with auto scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Using a load balancer with an Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [What Is AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [什么是 AWS Auto Scaling？](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [What is Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [What is Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [什么是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [什么是网络负载均衡器？](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [什么是应用程序负载均衡器？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Integrating Jenkins with AWS CodeBuild and AWS CodeDeploy](https://aws.amazon.com/blogs/devops/setting-up-a-ci-cd-pipeline-by-integrating-jenkins-with-aws-codebuild-and-aws-codedeploy/)
+ [Creating a four stage pipeline with AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-four-stage-pipeline.html)
**相关视频：**
+ [Back to Basics: Deploy Your Code to Amazon EC2](https://www.youtube.com/watch?v=f2wvEQ_sWS8)
+ [AWS Supports You \$1 Starting Your Infrastructure as Code Solution Using AWS CloudFormation Templates](https://www.youtube.com/watch?v=bgfx76jr7tA)
+ [Streamline Your Software Release Process Using AWS CodePipeline](https://www.youtube.com/watch?v=zMa5gTLrzmQ)
+ [Monitor AWS Resources Using Amazon CloudWatch Dashboards](https://www.youtube.com/watch?v=I7EFLChc07M)
+ [Create Cross Account & Cross Region CloudWatch Dashboards \$1 Amazon Web Services](https://www.youtube.com/watch?v=eIUZdaqColg)
# REL07-BP02 在检测到对工作负载的破坏时获取资源
如果可用性受到影响，在必要时被动扩展资源，从而还原工作负载的可用性。
首先，您必须配置运行状况检查和关于此类检查的标准，表示在什么时候可用性会因缺少资源而受到影响。然后，通知适当的人员手动扩展资源，或启动自动化以对其进行自动扩展。
可以根据工作负载手动调整资源规模（例如，通过 AWS 管理控制台 或 AWS CLI 更改自动扩缩组中 EC2 实例的数量，或者修改 DynamoDB 表的吞吐量）。但是，应尽量采用自动化技术（请参阅**在获取或扩展资源时利用自动化**）。
**期望结果：**在检测到故障或客户体验降级时，启动扩缩活动（自动或手动）来恢复可用性。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
对工作负载中的所有组件实施可观测性和监控，以监控客户体验并检测故障。定义用于扩展所需资源的手动或自动程序。有关更多信息，请参阅 [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)。
### 实施步骤
+ 定义扩展所需资源的手动或自动程序。
+ 扩缩程序取决于工作负载中不同组件的设计方式。
+ 扩缩程序还因所使用的底层技术而异。
+ 使用 AWS Auto Scaling 的组件可以使用扩缩计划来配置一组用于扩展资源的指令。如果使用 AWS CloudFormation 或向 AWS 资源添加标签，则可以根据应用程序为不同的资源集设置扩缩计划。Auto Scaling 提供了针对每个资源的定制扩展策略建议。创建扩缩计划后，Auto Scaling 结合了动态扩缩和预测性扩缩方法来支持扩缩策略。有关更多详细信息，请参阅 [How scaling plans work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)。
+ Amazon EC2 Auto Scaling 可验证您具有正确数量的 Amazon EC2 实例来处理应用程序负载。您可创建 EC2 实例的集合，称为自动扩缩组。您可以指定每个自动扩缩组中的最小和最大实例数，Amazon EC2 Auto Scaling 会确保您的组永远不会低于或超过这些限制。有关更多详细信息，请参阅 [What is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Amazon DynamoDB Auto Scaling 会根据实际的流量模式，使用 Application Auto Scaling 服务代表您动态调整预置的吞吐容量。这样表或全局二级索引可以增加预置读取和写入容量处理突增流量，不会受到限制。有关更多详细信息，请参阅[使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)。
## 资源
**相关最佳实践：**
+ [REL07-BP01 在获取或扩展资源时利用自动化](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)
**相关文档：**
+ [AWS Auto Scaling: How Scaling Plans Work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 在检测到某个工作负载需要更多资源时获取资源
云计算最有价值的功能之一是能够动态预置资源。
在传统的本地计算环境中，您必须提前确定和预置足够的容量来满足峰值需求。这的确是个问题，因为很昂贵，如果您低估了工作负载的峰值容量需求，则会对可用性构成风险。
在云中，您不必这样做。相反，您可以根据需要预置计算、数据库和其它资源容量，以满足当前和预测的需求。Amazon EC2 Auto Scaling 和 Application Auto Scaling 等自动化解决方案可以根据您指定的指标在线为您提供资源。这可以使扩展过程变得更加轻松和可预测，还可以通过确保始终有足够的可用资源来显著提高工作负载的可靠性。
**期望结果：**您可以配置计算资源和其它资源的自动扩缩来满足需求。您在扩展策略中提供了充足的余量，可以在额外资源上线时应对流量爆增。
**常见反模式：**
+ 您预置固定数量的可扩展资源。
+ 您选择的扩展指标与实际需求不相关。
+ 您未能在扩展计划中提供足够的余量来应对需求爆增。
+ 您的扩展策略添加容量的时间过晚，这会导致容量耗尽和服务降级，同时使额外的资源上线。
+ 您未能正确地配置最小和最大资源计数，这会导致扩展失败。
**建立此最佳实践的好处：**拥有足够的资源来满足当前需求，对于提供工作负载的高可用性和遵守您定义的服务级别目标（SLO）至关重要。自动扩缩可让您提供工作负载所需的适量计算资源、数据库资源和其它资源，以满足当前和预测的需求。您无需确定峰值容量需求，也无需静态分配资源来满足此需求。相反，随着需求增长，您可以分配更多资源来满足需求，在需求下降后，您可以停用资源以降低成本。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
首先，确定工作负载组件是否适合自动扩缩。这些组件之所以称为*可水平扩展*，是因为它们提供的资源相同，行为也相同。水平可扩展组件的示例包括以类似方式配置的 EC2 实例、[Amazon Elastic Container Service（ECS）](https://aws.amazon.com/ecs/)任务以及在 [Amazon Elastic Kubernetes Service（EKS）](https://aws.amazon.com/eks/)上运行的容器组（pod）。这些计算资源通常位于负载均衡器后面，称为*副本*。
其它复制的资源可能包括数据库只读副本、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 表以及 [Amazon ElastiCache](https://aws.amazon.com/elasticache/)（Redis OSS）集群。有关支持的资源的完整列表，请参阅 [AWS services that you can use with Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/integrated-services-list.html)。
对于基于容器的架构，可能需要通过两种不同的方式进行扩展。首先，您可能需要扩展可提供水平可扩展服务的容器。其次，您可能需要扩展计算资源，以便为新容器腾出空间。每个层都有不同的自动扩缩机制。要扩展 ECS 任务，可以使用 [Application Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)。要扩展 Kubernetes 容器组（pod），可以使用 [Pod 水平自动扩缩控制器（HPA）](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)或 [Kubernetes Event-driven Autoscaling (KEDA)](https://keda.sh/)。要扩展计算资源，对于 ECS，可以使用[容量提供程序](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html)，或者对于 Kubernetes，可以使用 [Karpenter](https://karpenter.sh) 或[集群自动扩缩器](https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/)。
接下来，选择您将如何执行自动扩缩。有三个主要选项：基于指标的扩展、计划扩展和预测式扩展。
**基于指标的扩展**
基于指标的扩展根据一个或多个*扩展指标* 的值来预置资源。扩展指标是与工作负载的需求相对应的指标。确定适当扩展指标的一个好方法是在非生产环境中执行负载测试。在负载测试期间，请将可扩展资源的数量保持为固定，并缓慢增加需求（例如，吞吐量、并发性或模拟用户数）。然后，寻找随着需求增长而增加（或减少）的指标，以及相反，即随着需求下降而减少（或增加）的指标。典型的扩展指标包括 CPU 利用率、工作队列深度（例如 [Amazon SQS](https://aws.amazon.com/sqs/) 队列）、活跃用户数量和网络吞吐量。
**注意**
AWS 观察到，对于大多数应用程序，内存利用率会随着应用程序预热而增加，然后达到稳定的值。当需求减少时，内存利用率通常保持较高水平，而不是并行下降。因为内存利用率与两个方向的需求不符（即随需求而增长和下降），因此在选择此指标进行自动扩缩之前，请慎重考虑。
基于指标的扩展是一种*潜在操作*。利用率指标可能需要几分钟才能传播到自动扩缩机制，而这些机制通常要等到明确的需求增加信号后才会做出反应。然后，当自动扩缩器创建新资源时，这些资源可能需要更多时间才能全面投入使用。因此，重要的是不要将扩展指标目标设置为过于接近完全利用率（例如，90% 的 CPU 利用率）。这样做有可能在额外容量上线之前耗尽现有资源容量。为了获得最佳可用性，典型的资源利用率目标可介于 50-70% 之间，具体取决于需求规律以及预置额外资源所需的时间。
**计划扩展**
计划扩展会根据日历或一天中的时间预置或移除资源。它通常用于需求可预测的工作负载，例如工作日工作时间或销售活动期间的峰值利用率。[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) 和 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) 都支持计划扩展。KEDA 的 [cron scaler](https://keda.sh/docs/latest/scalers/cron/) 支持 Kubernetes 容器组（pod）的计划扩展。
**预测式扩展**
预测式扩展使用机器学习来根据预期的需求自动扩缩资源。预测式扩展分析您提供的利用率指标的历史值，并持续预测其未来值。然后，使用预测值来纵向扩展或缩减资源。[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) 可以执行预测式扩展。
### 实施步骤
1. 确定工作负载组件是否适合自动扩缩。
1. 确定哪种扩展机制最适合工作负载：基于指标的扩展、计划扩展或预测式扩展。
1. 为组件选择适当的自动扩缩机制。对于 Amazon EC2 实例，请使用 Amazon EC2 Auto Scaling。对于其它 AWS 服务，请使用 Application Auto Scaling。对于 Kubernetes 容器组（pod）（例如在 Amazon EKS 集群中运行的容器），可以考虑水平容器组（pod）自动扩缩器（HPA）或 Kubernetes 事件驱动的自动扩缩（KEDA）。对于 Kubernetes 或 EKS 节点，可以考虑 Karpenter 和集群自动扩缩器（CAS）。
1. 对于指标或计划扩展，请进行负载测试，以确定工作负载的相应扩展指标和目标值。对于计划扩展，请确定在您选择的日期和时间所需的资源数量。确定为应对预期的峰值流量所需的最大资源数量。
1. 根据上面收集的信息配置自动扩缩器。有关详细信息，请参阅自动扩缩服务的文档。验证最大和最小扩展限制是否配置正确。
1. 验证扩展配置是否按预期发挥作用。在非生产环境中执行负载测试，观察系统的反应，并根据需要进行调整。在生产环境中启用自动扩缩时，请配置适当的警报来向您通知任何意外行为。
## 资源
**相关文档：**
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Prescriptive Guidance: Load testing applications](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/)
+ [AWS Marketplace: products that can be used with auto scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Scheduled Scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
# REL07-BP04 对工作负载进行负载测试
采用负载测试方法来衡量扩展活动能否满足工作负载要求。
持续开展负载测试，这一点很重要。负载测试用于发现工作负载的断点并测试工作负载的性能。利用 AWS，您可以轻松设置能够模拟生产工作负载规模的临时测试环境。在云中，您可以根据需要创建一套生产规模等级的测试环境，完成测试，然后停用资源。由于测试环境只需在运行时付费，您模拟真实环境的成本仅为本地测试成本的一小部分。
生产中的负载测试还应该被视为 GameDay 活动的一部分，因为在客户使用量降低的那几个小时内，在场的所有员工都忙于解读结果与处理任何出现的问题，生产系统承受着很大的压力。
**常见反模式：**
+ 对与生产采用不同配置的部署执行负载测试。
+ 仅对单个工作负载分段（而非整个工作负载）执行负载测试。
+ 使用请求子集，而不是具有代表性的实际请求集执行负载测试。
+ 对超出预期负载的较小安全系数执行负载测试。
**建立此最佳实践的好处：**您知道架构中哪些组件会在负载下失败，而且能够确定要监控哪些可指示您即将达到该负载的指标，从而及时解决问题，防止故障影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
+ 执行负载测试，确定工作负载的哪些方面表明您必须添加或移除容量。负载测试应具有您在生产中接收的流量类似的代表性流量。增加负载，同时监视所有已检测指标，以便确定哪种指标指示何时必须添加或移除资源。
+ [AWS 上的分布式负载测试：模拟数千个连接的用户](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ 确定请求组合。您可能拥有不同的请求组合，因此应当在确定流量组合时查看不同的时间范围。
+ 实施负载驱动程序。您可以使用自定义代码、开源或商用软件来实施负载驱动程序。
+ 最初使用小容量进行负载测试。通过将负载降低到较小容量（可能小到一个实例或容器），可能会有立竿见影的效果。
+ 针对更大的容量进行负载测试。分布式负载的效果会有所不同，因此您必须对尽量接近生产环境的目标进行测试。
## 资源
**相关文档：**
+ [AWS 上的分布式负载测试：模拟数千个连接的用户](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [加载测试应用程序](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
**相关视频：**
+ [AWS Summit ANZ 2023: Accelerate with confidence through AWS Distributed Load Testing](https://www.youtube.com/watch?v=4J6lVqa6Yh8)