选择您的 Cookie 首选项

我们使用必要 Cookie 和类似工具提供我们的网站和服务。我们使用性能 Cookie 收集匿名统计数据,以便我们可以了解客户如何使用我们的网站并进行改进。必要 Cookie 无法停用,但您可以单击“自定义”或“拒绝”来拒绝性能 Cookie。

如果您同意,AWS 和经批准的第三方还将使用 Cookie 提供有用的网站功能、记住您的首选项并显示相关内容,包括相关广告。要接受或拒绝所有非必要 Cookie,请单击“接受”或“拒绝”。要做出更详细的选择,请单击“自定义”。

REL07-BP03 在检测到某个工作负载需要更多资源时获取资源 - 可靠性支柱

REL07-BP03 在检测到某个工作负载需要更多资源时获取资源

云计算最有价值的功能之一是能够动态预置资源。

在传统的本地计算环境中,您必须提前确定和预置足够的容量来满足峰值需求。这的确是个问题,因为很昂贵,如果您低估了工作负载的峰值容量需求,则会对可用性构成风险。

在云中,您不必这样做。相反,您可以根据需要预置计算、数据库和其它资源容量,以满足当前和预测的需求。Amazon EC2 Auto Scaling 和 Application Auto Scaling 等自动化解决方案可以根据您指定的指标在线为您提供资源。这可以使扩展过程变得更加轻松和可预测,还可以通过确保始终有足够的可用资源来显著提高工作负载的可靠性。

期望结果:您可以配置计算资源和其它资源的自动扩缩来满足需求。您在扩展策略中提供了充足的余量,可以在额外资源上线时应对流量爆增。

常见反模式:

  • 您预置固定数量的可扩展资源。

  • 您选择的扩展指标与实际需求不相关。

  • 您未能在扩展计划中提供足够的余量来应对需求爆增。

  • 您的扩展策略添加容量的时间过晚,这会导致容量耗尽和服务降级,同时使额外的资源上线。

  • 您未能正确地配置最小和最大资源计数,这会导致扩展失败。

建立此最佳实践的好处:拥有足够的资源来满足当前需求,对于提供工作负载的高可用性和遵守您定义的服务级别目标(SLO)至关重要。自动扩缩可让您提供工作负载所需的适量计算资源、数据库资源和其它资源,以满足当前和预测的需求。您无需确定峰值容量需求,也无需静态分配资源来满足此需求。相反,随着需求增长,您可以分配更多资源来满足需求,在需求下降后,您可以停用资源以降低成本。

在未建立这种最佳实践的情况下暴露的风险等级:

实施指导

首先,确定工作负载组件是否适合自动扩缩。这些组件之所以称为可水平扩展,是因为它们提供的资源相同,行为也相同。水平可扩展组件的示例包括以类似方式配置的 EC2 实例、Amazon Elastic Container Service(ECS)任务以及在 Amazon Elastic Kubernetes Service(EKS)上运行的容器组(pod)。这些计算资源通常位于负载均衡器后面,称为副本

其它复制的资源可能包括数据库只读副本、Amazon DynamoDB 表以及 Amazon ElastiCache(Redis OSS)集群。有关支持的资源的完整列表,请参阅 AWS services that you can use with Application Auto Scaling

对于基于容器的架构,可能需要通过两种不同的方式进行扩展。首先,您可能需要扩展可提供水平可扩展服务的容器。其次,您可能需要扩展计算资源,以便为新容器腾出空间。每个层都有不同的自动扩缩机制。要扩展 ECS 任务,可以使用 Application Auto Scaling。要扩展 Kubernetes 容器组(pod),可以使用 Pod 水平自动扩缩控制器(HPA)Kubernetes Event-driven Autoscaling (KEDA)。要扩展计算资源,对于 ECS,可以使用容量提供程序,或者对于 Kubernetes,可以使用 Karpenter集群自动扩缩器

接下来,选择您将如何执行自动扩缩。有三个主要选项:基于指标的扩展、计划扩展和预测式扩展。

基于指标的扩展

基于指标的扩展根据一个或多个扩展指标 的值来预置资源。扩展指标是与工作负载的需求相对应的指标。确定适当扩展指标的一个好方法是在非生产环境中执行负载测试。在负载测试期间,请将可扩展资源的数量保持为固定,并缓慢增加需求(例如,吞吐量、并发性或模拟用户数)。然后,寻找随着需求增长而增加(或减少)的指标,以及相反,即随着需求下降而减少(或增加)的指标。典型的扩展指标包括 CPU 利用率、工作队列深度(例如 Amazon SQS 队列)、活跃用户数量和网络吞吐量。

注意

AWS 观察到,对于大多数应用程序,内存利用率会随着应用程序预热而增加,然后达到稳定的值。当需求减少时,内存利用率通常保持较高水平,而不是并行下降。因为内存利用率与两个方向的需求不符(即随需求而增长和下降),因此在选择此指标进行自动扩缩之前,请慎重考虑。

基于指标的扩展是一种潜在操作。利用率指标可能需要几分钟才能传播到自动扩缩机制,而这些机制通常要等到明确的需求增加信号后才会做出反应。然后,当自动扩缩器创建新资源时,这些资源可能需要更多时间才能全面投入使用。因此,重要的是不要将扩展指标目标设置为过于接近完全利用率(例如,90% 的 CPU 利用率)。这样做有可能在额外容量上线之前耗尽现有资源容量。为了获得最佳可用性,典型的资源利用率目标可介于 50-70% 之间,具体取决于需求规律以及预置额外资源所需的时间。

计划扩展

计划扩展会根据日历或一天中的时间预置或移除资源。它通常用于需求可预测的工作负载,例如工作日工作时间或销售活动期间的峰值利用率。Amazon EC2 Auto ScalingApplication Auto Scaling 都支持计划扩展。KEDA 的 cron scaler 支持 Kubernetes 容器组(pod)的计划扩展。

预测式扩展

预测式扩展使用机器学习来根据预期的需求自动扩缩资源。预测式扩展分析您提供的利用率指标的历史值,并持续预测其未来值。然后,使用预测值来纵向扩展或缩减资源。Amazon EC2 Auto Scaling 可以执行预测式扩展。

实施步骤

  1. 确定工作负载组件是否适合自动扩缩。

  2. 确定哪种扩展机制最适合工作负载:基于指标的扩展、计划扩展或预测式扩展。

  3. 为组件选择适当的自动扩缩机制。对于 Amazon EC2 实例,请使用 Amazon EC2 Auto Scaling。对于其它 AWS 服务,请使用 Application Auto Scaling。对于 Kubernetes 容器组(pod)(例如在 Amazon EKS 集群中运行的容器),可以考虑水平容器组(pod)自动扩缩器(HPA)或 Kubernetes 事件驱动的自动扩缩(KEDA)。对于 Kubernetes 或 EKS 节点,可以考虑 Karpenter 和集群自动扩缩器(CAS)。

  4. 对于指标或计划扩展,请进行负载测试,以确定工作负载的相应扩展指标和目标值。对于计划扩展,请确定在您选择的日期和时间所需的资源数量。确定为应对预期的峰值流量所需的最大资源数量。

  5. 根据上面收集的信息配置自动扩缩器。有关详细信息,请参阅自动扩缩服务的文档。验证最大和最小扩展限制是否配置正确。

  6. 验证扩展配置是否按预期发挥作用。在非生产环境中执行负载测试,观察系统的反应,并根据需要进行调整。在生产环境中启用自动扩缩时,请配置适当的警报来向您通知任何意外行为。

资源

相关文档:

隐私网站条款Cookie 首选项
© 2025, Amazon Web Services, Inc. 或其附属公司。保留所有权利。