SUS02-BP01 动态扩展工作负载基础架构 - 可持续性支柱

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

SUS02-BP01 动态扩展工作负载基础架构

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

常见反模式:

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

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

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

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

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

实施指导

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

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

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

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

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

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

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

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

实施步骤

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

    自动扩缩机制 使用情形

    Amazon A EC2 uto Scaling

    用于验证您是否有正确数量的 Amazon EC2 实例可用于处理应用程序的用户负载。

    Application Auto Scaling

    用于自动扩展亚马逊以外的各项 AWS 服务的资源EC2,例如 Lambda 函数或亚马逊弹性容器服务 (AmazonECS) 服务。

    Kubernetes Cluster Autoscaler

    用于自动扩展 Kubernetes 集群。 AWS

  • 人们经常讨论与诸如 Amazon EC2 实例或 AWS Lambda 函数之类的计算服务相关的扩展问题。考虑使用非计算服务配置(如 Amazon DynamoDB 读写容量单元或 Amazon Kinesis Data Streams 分片)来满足需求。

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

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

    • 指标值必须随着自动扩缩组中的实例数按比例增加或减少。

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

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

  • 评估工作负载,得出可预测的模式,从而在预期需求会发生预测性的计划内变化时主动扩缩。预测性扩缩可以避免过度预置容量。有关更多详细信息,请参阅使用 Amazon A EC2 uto Scaling 进行预测性扩展

资源

相关文档:

相关视频:

相关示例: