创建高可用工作负载的最佳实践

许多迁移到云端的公共部门组织经常误解亚马逊网络服务 (亚马逊云科技) 区域和可用区的架构从根本上改变了他们对灾难恢复和弹性的看法。在加入 亚马逊云科技 之前，我花了很多年时间帮助组织了解和制定灾难恢复计划。现在在 亚马逊云科技，我与公共部门各种规模的客户合作，构建具有成本效益和弹性的工作负载。在这篇博客文章中，我分享了一些最佳实践，以回答有关构建高可用性工作负载的常见问题，并分享一些考虑 亚马逊云科技 中高可用性、灾难恢复和应用程序灵活性的方法。

我需要在多个区域部署我的工作负载吗？

当组织问 “我需要进入多区域来支持我的灾难恢复需求吗？”我的第一个问题是询问工作负载的恢复时间目标 (RTO)，即你可以容忍的停机时间，以及恢复点目标 (RPO)，即你可以承受丢失多少数据。

我看到许多组织犯的主要错误是在开始讨论灾难恢复之前没有明确定义的 RTO 和 RPO 目标。每个组织都希望零停机时间和零数据丢失，但现实是系统出现故障。甚至亚马逊首席技术官（CTO）沃格尔斯（Werner Vogels）也表示：“ 失败是理所当然的，随着时间的推移，一切最终都会失败 ”。

在本地世界中，跨多个数据中心运行工作负载（大多数组织认为这是 “灾难恢复”）对于许多 RTO/RPO 目标来说是必要的，因为数据中心是单点故障。但是，将工作负载迁移到 亚马逊云科技 时，最佳做法是在多个 可用区 部署工作负载 。在 亚马逊云科技 全球基础设施中，可用区由一个或多个独立的数据中心组成，冗余电源、网络和连接位于不同的设施中。对于大多数迁移到云的组织而言，跨多个可用区部署工作负载已经相当于他们在本地环境中旨在实现的灾难恢复目标。

每个组织和工作负载都不同。一些公共部门组织的工作负载可能可以承受更高的 RTO 目标（例如，更长的恢复时间）。例如，非营利组织的筹款申请可能只需要将RTO/RPO设定为工时目标即可。相反，非营利性医疗保健组织可能面临生命所依赖的关键工作量，因此RTO/RPO目标是几分钟甚至是实时。尽管没有哪个组织希望停机，但请记住，随着 RTO/RPO 目标的降低（例如，更快的恢复速度和更少的数据丢失），成本和复杂性可能会急剧增加（图 1）。

图 1。随着 RTO/RPO 的减少，比如减少停机时间和潜在的数据丢失量，成本可能会大幅增加。

也就是说，亚马逊云科技为许多 灾难恢复选项 提供了设计模式 ，具体取决于组织的 RTO/RPO 目标。组织需要审查其 RTO 和 RPO 目标、这些目标的成本影响，并决定适合其每种工作负载的内容。

如何使我的工作负载尽可能具有弹性？

尽管组织可能不需要在多个区域同时部署工作负载（例如作为多区域主动/主动灾难恢复策略的一部分），但他们仍然希望确保最大限度地减少中断并且工作负载尽可能具有弹性。

亚马逊云科技 在 AW S 构建者库 中发布了许多模式， 以演示 亚马逊云科技 如何思考和构建高度可用的工作负载。但是，一些关键模式可以对大多数公共部门组织产生最大的直接影响。

考虑控制平面和数据平面

在 亚马逊云科技，我们经常谈论 最小化爆炸半径 。尽管这是一个很大的话题，但最小化爆炸半径的要素之一是从 控制平面和数据 平面的角度考虑分布式系统 。数据平面负责执行您的客户请求，控制平面负责管理和出售您的客户配置。例如，对于已创建个性化引擎以提高应用程序参与度的组织而言，向用户提供推荐的机制将被视为数据平面，而采集和清理数据以及训练机器学习模型的后端服务将被视为控制平面。如果由于某种原因控制平面不可用，则数据平面将继续执行客户请求。数据平面通常很简单，而控制平面可能要复杂得多。通过解耦这些系统，使它们相互独立运行，您可以构建具有更高面向客户的可用性的系统。

实现静态稳定性以支持可用性

另一种常见模式是 静态稳定性 。静态稳定性意味着在依赖关系出现故障或不可用期间，系统可以继续正常运行，无需进行更改。静态稳定性最明显的例子可以用亚马逊弹性计算云（Amaz on EC2 ）工作负载来说明。

例如，如果工作负载在 Amazon EC2 上运行 Amazon EC 2 Auto Scaling 组内的三个可用区，则每个可用区包含一个 Amazon EC2 实例。如果工作负载要求所有三个 Amazon EC2 实例同时运行才能提供所需的性能目标，那么这不是静态稳定性。如果可用区因任何原因出现故障，Amazon EC2 Auto Scaling 组将需要为工作负载预置更多实例以满足其性能标准。如果对实例扩展产生影响，则工作负载可能无法及时扩展 Amazon EC2 实例（图 2）。

图 2。未表现出静态稳定性的工作负载。该工作负载需要三个 Amazon EC2 实例，但在可用区 2 经历停机后只有两个。

即使在服务中断期间，静态稳定性也意味着工作负载仍然可以满足性能标准。为了在本示例中实现静态稳定性，工作负载应在每个可用区运行两个 Amazon EC2 实例。即使失去可用区并影响自动扩展服务，工作负载仍可以继续达到性能目标（图 3）。

图 3。表现出静态稳定性的工作负载。此工作负载需要三个 Amazon EC2 实例，并且有四个，即使可用区 2 出现停机也是如此。

静态稳定性是 亚马逊云科技 努力实现的工作负载属性。保持此属性可能意味着您的工作负载略有超额配置，但它更能抵御意外故障。

使用自动化进行构建以节省时间并支持可扩展性

最后一种模式是自动化。与我合作的许多组织都没有足够的人力或资金，无法按照他们想要的方式推进使命。自动化是技术支持任务的一种方式，而不是阻碍任务或分散注意力。

组织通常使用源代码控制工具来保护和版本源代码。为什么云基础设施应该有所不同？ 有许多不同的基础设施 即代码 (IaC) 工具可用，例如 亚马逊云科技 CloudFormation、亚马逊云科技 云开发套件 (亚马逊云科技 CDK ) 或 Terraform。 找到你喜欢的工具并持续使用它。切勿手动更改生产环境。

楼宇自动化确实需要更多的前期时间，这就是为什么一些组织决定跳过它的原因——短期内牺牲了长期收益。但是，成功的组织花时间来自动化部署，并将其基础架构视为代码。这种做法可以在未来获得回报，当您的组织决定扩展时，您可以轻松地将架构和工作负载重新部署到多个 亚马逊云科技 账户。自动化还可以帮助在多个 亚马逊云科技 区域之间简单地部署工作负载，从而支持灾难恢复目标。由于实现了自动化，与我合作的一位公共部门客户每周能够对其工作负载进行超过 6,000 次的更改。

结论和创建高可用工作负载的后续步骤

在这篇博客文章中，我讨论了制定灾难恢复计划的注意事项。组织的灾难恢复计划应基于每个相关工作负载的恢复时间和恢复点目标。考虑到成本和其他资源方面的考虑，这些目标将帮助组织确定哪种类型的灾难恢复解决方案最合适。

关键工作负载模式可以帮助组织实施更具弹性的工作负载。这些模式包括缩小工作负载的爆炸半径，因此如果出现故障，影响是有限的，不会对整个工作负载产生负面影响；静态稳定性，即使面临负面影响，也能让工作负载继续为面向客户的请求提供服务；以及自动化，它可以帮助任何规模的团队扩展到原本无法做到的范围。

下一步，检查您的工作负载并确定 RTO/RPO 目标是什么。查看您的现有架构，确定能否消除瓶颈或其他单点故障。您是否将控制平面功能与数据平面功能混合在一起？你能重构这段代码以提供更好的弹性吗？团队成员是否将时间花在 无差别的活动 或其他不能直接推动任务向前发展的活动上？如果是这样，请寻求自动化。

在 亚马逊建筑商库 中详细了解 亚马逊云科技 用于构建系统的工程模式。阅读 亚马逊云科技 故障隔离边界 白皮书，了解 亚马逊云科技 是如何构建的，以及如何在 亚马逊云科技 上构建工作负载以支持您的弹性目标。

阅读有关 亚马逊云科技 在公共部门实现弹性的更多信息：

• 用于灾难恢复、业务连续性规划和灾难准备的 Goldilocks 区域
• 使用新的《亚马逊云科技 上的政府 IT 连续性》解决方案指南保护关键服务
• 建立数字能力以抵御未来的挑战，从网络攻击到恶劣天气事件
• 利文斯顿教区如何通过提高云端弹性来为自然灾害做准备
• 罗克代尔县如何利用云改善运营和安全性

订阅 亚马逊云科技 公共部门博客时事通讯 ， 将来自公共部门的 亚马逊云科技 工具、解决方案和创新的最新信息发送到您的收件箱，或者 联系我们 。

请花几分钟时间在本次调查中分享您对 亚马逊云科技 公共部门博客的体验的见解 ，我们将使用调查的反馈来创建更多符合读者偏好的内容。