本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
PERF02-BP05 动态扩展您的计算资源
利用云的弹性根据需求动态增减计算资源，避免为工作负载预置的容量过多或者不足。
常见反模式：
-
通过手动增加容量来对警报做出反应。
-
使用本地所用的规模调整指南（通常是静态基础设施）。
-
在扩展事件之后保留增加的容量，而不是缩减容量。
建立此最佳实践的好处：配置和测试计算资源的弹性将有助于您节省资金、维护性能基准，以及在流量变化时提高可靠性。
在未建立这种最佳实践的情况下暴露的风险等级：高
实施指导
AWS 提供了通过各种扩展机制动态向上或向下扩展资源的灵活性，以满足需求的变化。动态扩展结合计算相关的指标，可使工作负载自动响应变化，并利用一系列最优的计算资源来实现目标。
您可以使用大量不同方法来实现资源的供需匹配。
-
目标跟踪方法：监控您的扩缩指标，并根据需要自动增加或减少容量。
-
预测性扩缩：根据每日和每周的趋势进行扩缩。
-
基于计划的方法：根据可预测的负载变化设置自己的扩缩计划。
-
服务扩缩：选择可根据设计自动扩缩的服务（如无服务器）。
您必须确保工作负载部署可以处理扩展事件和缩减事件。
实施步骤
-
计算实例、容器和函数都能够与自动扩缩服务相结合或作为此服务的一项功能来提供可实现弹性的机制。以下是自动扩缩机制的一些示例：
自动扩缩机制 使用情形 Amazon A EC2 uto Scaling 确保您有正确数量的 Amazon EC2 实例可用于处理应用程序的用户负载。 Application Auto Scaling 自动扩展亚马逊以外的各项 AWS 服务的资源，EC2例如AWS Lambda 功能或亚马逊弹性容器服务 (AmazonECS) 服务。 Kubernetes Cluster Autoscaler/Karpenter 自动扩缩 Kubernetes 集群。 -
人们经常讨论与诸如 Amazon EC2 实例或 AWS Lambda 函数之类的计算服务相关的扩展问题。此外，务必考虑配置非计算服务（如 AWS Glue）来满足需求。
-
验证扩缩指标是否与正在部署的工作负载的特性相匹配。如果您正在部署视频转码应用程序，则预计CPU利用率为 100%，这不应成为您的主要指标。而应使用转码作业队列的深度。如果需要，可以对扩缩策略使用自定义指标
。要选择正确的指标，请考虑以下亚马逊指南EC2： -
指标应该是有效的利用率指标，并描述实例的繁忙程度。
-
指标值必须随着自动扩缩组中的实例数按比例增加或减少。
-
-
确认工作负载部署可以同时处理扩展事件和缩减事件。例如，可以使用活动历史记录来验证自动扩缩组的扩缩活动。
-
评估工作负载，得出可预测的模式，从而在预期需求会发生预测性的计划内变化时主动扩缩。预测性扩缩可以避免过度预置容量。有关更多详细信息，请参阅使用 Amazon A EC2 uto Scaling 进行预测性扩展
。
资源
相关文档：
相关视频：
相关示例：
