SUS02-BP01 动态扩缩工作负载基础设施 - AWS Well-Architected Framework

SUS02-BP01 动态扩缩工作负载基础设施

利用云的弹性并动态扩缩基础设施,以使云资源的供应与需求相匹配,避免在工作负载中过度调配容量。

常见反模式:

  • 您没有扩缩基础设施以匹配用户负载。

  • 您一直在手动扩缩基础设施。

  • 在扩展事件之后,您将保留增加的容量,而不是缩减容量。

建立此最佳实践的好处:配置和测试工作负载弹性有助于有效地将云资源的供应与需求相匹配,并避免过度调配容量。您可以利用云中的弹性,在需求高峰期间和之后自动扩缩容量,以确保您只使用满足业务需求所需的适当数量的资源。

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

实施指导

云让您能够通过各种机制灵活地动态扩展或缩减资源,以便满足不断变化的需求。供应与需求的最佳匹配提供了最低的工作负载环境影响。

需求可以是固定的,也可以是变化的,需要指标和自动化来确保管理不会变成沉重负担。应用程序可以通过修改实例大小来纵向扩展或缩减,通过修改实例数量来横向扩展或缩减,或者组合使用这两种方式。

您可以使用大量不同方法来实现资源的供需匹配。

  • 目标跟踪方法:监控您的扩缩指标,并根据需要自动增加或减少容量。

  • 预测性扩缩:根据每日和每周的趋势进行扩缩。

  • 基于计划的方法:根据可预测的负载变化设置自己的扩缩计划。

  • 服务扩缩:选择按设计可以原生扩缩或者将自动扩缩作为一项功能提供的服务(如无服务器)。

确定利用率低或无利用率的时段,缩减资源以消除过剩容量并提高效率。

实施步骤

  • 弹性可根据对您拥有的资源的需求来提供这些资源。实例、容器和函数提供了弹性机制,可以与自动扩缩结合使用,也可以作为服务的一项功能。AWS 提供了一系列自动扩缩机制,以确保工作负载可以在低用户负载期间快速轻松地缩减。以下是自动扩缩机制的一些示例:

    Auto scaling mechanism Where to use

    Amazon EC2 Auto Scaling

    用于验证您拥有适量的 Amazon EC2 实例,可处理您应用程序的用户负载。

    Application Auto Scaling

    用于自动扩缩 Amazon EC2 以外的各项 AWS 服务的资源,比如 Lambda 函数或 Amazon Elastic Container Service (Amazon ECS) 服务。

    Kubernetes Cluster Autoscaler

    用于自动扩缩 AWS 上的 Kubernetes 集群。

  • 扩缩通常与计算服务(如 Amazon EC2 实例或 AWS Lambda 函数)相关。考虑使用非计算服务配置(如 Amazon DynamoDB 读写容量单元或 Amazon Kinesis Data Streams 分片)来满足需求。

  • 验证衡量扩展或缩减的指标已根据所部署的工作负载类型进行了验证。如果您正在部署一个视频转码应用程序,CPU 利用率预计为 100%,并且不应将此作为您的主要指标。如果需要,可以对扩缩策略使用自定义指标(如内存利用率)。要选择正确的指标,请考虑以下关于 Amazon EC2 的指导:

    • 该指标应该是有效的利用率指标,并描述实例的繁忙程度。

    • 该指标值必须随 Auto Scaling 组中的实例数量成比例地增加或减少。

  • 对 Auto Scaling 组使用动态扩缩而不是手动扩缩。我们还建议您在动态扩缩中使用目标跟踪扩缩策略

  • 确认工作负载部署可以处理扩展事件和缩减事件。为缩减事件创建测试场景,以确认工作负载的行为符合预期,并且不会影响用户体验(如丢失粘滞会话)。您可以使用活动历史记录验证 Auto Scaling 组的扩缩活动。

  • 评估您的工作负载以获得可预测的模式,并在您预期需求会发生预测和计划的变化时主动扩缩。借助预测性扩缩,您无需过度调配容量。有关详细信息,请参阅使用 Amazon EC2 Auto Scaling 进行预测性扩缩

资源

相关文档:

相关视频:

相关示例: