基于云架构优雅的构建应用可靠性原理及实践

云不是百分之百稳定的，如何基于不是百分之百稳定的云，构建更可靠的应用？这就如同在沙地上搭建一栋摩天大楼，并且要求能够抵御地震、海啸和台风。在架构正确之上，还充满了技巧和最佳实践。

另一方面，云提供了许多服务，方便我们更快速的构建更稳健的应用，充分利用云的这些服务，将获得超越传统方式的巨大优势。所以我们必须熟悉云上相关的服务。

本手册是基于AWS优雅的构建可靠性应用的原理和实践，但是大部分内容在其他云上也都是可行的，新钛云服特意翻译了本手册，希望对基于云构建可靠的应用带来一些帮助。

1. 摘要

本手册的重点是介绍如何基于AWS架构优雅的架构建应用可靠性。本手册是设计，交付和维护Amazon Web Services（AWS）环境的最佳实践。

2. 简介

优雅的AWS架构框架，可帮助你了解在AWS上构建系统时所做的决策的优缺点，通过本框架，将学习在云中运行可靠、安全、高效且经济系统的设计和架构最佳实践。本手册提供了始终如一地衡量架构方法实践，并确定需要改进的领域。我们相信，优雅的架构系统会极大的增加业务成功的可能性。

优雅的AWS的架构框架基于五大支柱：

• 卓越运营

• 安全

• 可靠性

• 性能优化

• 成本优化

本文重点介绍可靠性支柱以及如何将其应用于你的解决方案。在传统的本地环境中，由于单点故障，缺乏自动化和缺乏弹性，实现可靠性可能具有挑战性。通过应用本文中的实践，你将构建具有强大功能的架构基础，一致的变更管理和经证实的故障恢复流程。

本文适用于技术角色，如首席技术官员（CTO），架构师，开发人员和运维团队。阅读本文，你将了解AWS的最佳实践和策略，在设计可靠性云架构时使用。本文包括高级别实现细节和架构模式，以及对可参考的附加资源。

2.1 可靠性

可靠性支柱包括系统从基础架构或服务中断恢复的能力，动态获取计算资源以满足需求，以及缓解诸如错误配置或瞬时网络问题之类的中断。本文提供了在AWS上构建可靠系统的深度最佳实践指南。

2.2 设计原则

在云中，有许多原则可以帮助你增加可靠性：

测试故障恢复过程：在本地环境中，测试经常进行以验证系统在特定情况下的工作，测试通常不用于验证恢复策略。在云中，你可以测试系统故障，并验证恢复过程。你可以使用自动化方法来模拟不同的故障，或重新创建导致失败的场景。这暴露了可以在真正的故障情况之前测试和修复的故障路径，降低在故障前未经过测试的组件的风险。

故障自愈：通过监控系统的关键性能指标（KPI），可以在阀值被突破时触发自动化措施。这些KPI应该是衡量业务的指标，而不是运维服务的技术指标。允许自动通知和跟踪故障，通过自动恢复过程解决或修复故障。更进一步，通过更复杂的自动化，可以预测并在故障发生之前进行修复。

水平扩展以提高聚合系统可用性：用多个小资源替换一个大型资源以减少单个故障对整个系统的影响。分布请求跨越多个较小的资源，以确保它们不共享共同的失败点。

停止猜测容量：内部部署失败的常见原因是系统资源饱和，当需求超过该系统的容量（这通常是拒绝目标服务攻击）。在云中，你可以监控需求和系统利用率，并自动添加或删除要维护的资源，在没有过度供应或供应不足的情况下满足需求的最佳水平。仍然可能会受到一些限制，但是一些限制可以控制，其他限制可以管理。

管理自动化：应通过自动化对基础架构进行变更，变更应通过自动化管理。

我们将通过场景讨论所有这些设计原则。

2.3 定义

服务可用性通常定义为应用程序正常运行的时间百分比。也就是说，它是正确执行预期操作的时间百分比。此百分比是在一段时间内计算的，例如月，年或过去3年。使用最严格的解释，可以在应用程序无法正常运行的任何时候减少可用性，包括计划和非计划中断。我们使用以下标准定义可用性：

• 可用性=正常运行时间/总时间

• 一段时间内（通常是一年）正常运行时间的百分比（例如99.9％）

• 常见简称仅指“9的数量”，例如，“五个九”是指为99.999％

• 有些客户选择从第一项的公式中的总时间中排除计划内服务停机时间（例如，计划维护）。但是，这通常是错误的选择，因为客户实际上可能希望在这些时间使用你的服务。

下面是一个常见的应用程序可用性设计目标表，以及在一年内可能发生但仍能达到目标的可能的中断时间。该表包含我们在每个可用性层通常看到的应用类别的示例。在本文档中，我们将参考这些值。

计算可用性的硬依赖性。许多系统对其他系统具有硬依赖性，其依赖系统的中断直接转换为调用系统的中断。这与软依赖相反，其依赖系统的故障在应用中得到补偿。在发生硬依赖性的情况下，调用系统可用性是从属系统可用性的产物。例如，如果你的系统设计为99.99％可用性，并且对两个其他独立系统具有硬依赖性，每个系统都设计为99.99％的可用性，那么理论上系统可实现99.97％的可用性：

调用系统*依赖1 *依赖2 =

99.99％* 99.99％* 99.99％= 99.97％

因此，在计算自己的依赖关系及其可用性设计目标时，了解它们非常重要。

计算基于冗余组件的可用性。当系统涉及使用独立的冗余组件（例如，冗余可用区）时，理论可用性计算为100％减去组件故障率的乘积（100％减去可用性）。例如，如果系统生成使用两个独立的组件，每个组件的可用性为99.9％，最终系统可用性> 99.999％：

最大可用性-（（依赖1的停机时间）*（依赖2的停机时间））=

100％-（0.1％* 0.1％）= 99.9999％

但是，如果我不知道依赖的可用性怎么办？

计算依赖性可用性。某些依赖项提供有关其可用性的指导，包括许多AWS服务的可用性设计目标（请参阅附录A：为选择AWS服务的可用性而设计）。但是在没有可用性信息的情况下（例如，制造商不公布可用性信息的组件），一种简单的估算方法是确定平均故障间隔时间（MTBF）和平均恢复时间（MTTR）。可用性估算可通过以下方式确定：

可用性估算= MTBF/（MTBF+MTTR）

例如，如果MTBF为150天且MTTR为1小时，则为可用性估计为99.97％。

可用性成本。为更高级别应用程序设计可用性通常会增加成本，因此在开始应用程序设计之前，最好确定真正的可用性需求。高可用性水平对彻底失败场景下的测试和验证提出了更严格的要求。需要通过自动化来从各种各样的故障中恢复，并且要求系统操作的所有方面都按照相同的标准进行类似的构建和测试。例如，必须将添加或删除容量、部署或回滚更新的软件或配置变更，据迁移到所需的可用性目标。在非常高的可用性水平上，软件开发的成本还会增加，创新会受到影响，因为在部署系统时需要更慢的速度。因此，指导方针是在应用标准和考虑整个系统运行生命周期的适当可用性目标时要彻底。

在具有更高可用性设计目标的系统中，成本上升的另一种方式是依赖项的选择。在更高的目标中，可以选择作为依赖项的软件或服务集将会减少，基于这些服务中有我们前面描述的深度投入的那些服务。随着可用性设计目标的增加，通常会发现更少的多用途服务(例如关系数据库)和更多的专门构建的服务。这是因为后者更容易评估、测试和自动化，并且减少了与包含但未使用的功能进行意外交互的可能性。

3. 基础-限制管理

在设计系统架构时，需要考虑物理限制和资源约束。资源约束是常见的故障来源，也是缺乏可用性的原因之一。例如，数据可以进入的速率，或者物理磁盘上的存储量。理解物理约束是设计可靠系统的第一步。其次，对于基于服务的体系结构，常常存在服务限制，这些限制用于保护服务不违反服务水平协议(速率限制)或设计约束(硬限制)。极限管理的最后一个部分是警报和报告，使你能够知道何时达到极限或即将达到极限，然后做出相应的反应。

每项AWS服务都记录了服务创建的云资源的默认限制。每个帐户都会跟踪这些限制，因此如果你使用多个帐户，则需要知道每个帐户的限制。其他限制可能取决于配置。这些限制的示例包括Auto Scaling组中的实例数，预配置IOPS，分配的RDS存储，EBS卷分配，网络IO，子网或VPC中的可用IP地址等。

每个AWS区域和每个AWS账户都实施限制。如果你计划部署到多个区域或AWS账户，则应确保增加所使用的区域和帐户的限制。此外，请确保你有足够的缓冲区，以便在不正确的资源被终止时，在请求其他资源时，可用区不会超出你的限制。

AWS通过AWS Trusted Advisor提供一些服务限制的列表，其他可从AWS管理控制台获得。服务限制文档中提供了默认服务限制；如果你没有跟踪限制增加请求，可以联系AWS支持以提供你正在使用的服务的当前限制。对于受限制的API的速率限制，SDK提供了处理限制响应的机制（重试，指数退避）。你应该评估你的用例，以确定哪种方案更适合你。如果你有一个用例，其中限制会影响你的应用程序的性能，请联系AWS支持以查看是否存在缓解措施或是否可以增加限制。

理想情况下，限制跟踪是自动化的。你可以将当前服务限制存储在Amazon DynamoDB等持久性数据存储中。如果将配置管理数据库（CMDB）或工单系统与AWS 支持API集成，则可以自动跟踪限制增加请求和当前限制。如果你与CMDB集成，那么你可能可以在该系统中存储服务限制。

3.1 关键AWS服务

支持识别当前服务限制的方法的关键AWS功能是AWS Trusted Advisor，它提供了限制的列表。以下服务和功能也很重要：

• Amazon CloudWatch：你可以设置警报以指示何时接近网络IO，预配置IOPS，EBS和临时卷容量（通过自定义指标）等限制。你还可以设置警报，以便在接近最大容量时自动缩放组。

• Amazon CloudWatch-Logs：度量标准过滤器可用于在日志事件中搜索和提取模式。日志条目将转换为数字度量标准，并可应用警报。

4. 基础-网络

在使用基于IP地址的网络构建系统时，你需要规划网络拓扑和寻址，以预期未来的增长以及与其他系统及其网络的集成。如果不规划，可能会发现你的基础架构有限，或者你可能难以集成不兼容的寻址结构。

通过Amazon Virtual Private Cloud（Amazon VPC），可以配置AWS Cloud的私有隔离部分，可以在其中启动虚拟网络中的AWS资源。

在规划网络拓扑时，第一步是定义IP地址空间本身。遵循RFC 1918准则，应为每个VPC分配无类别域间路由（CIDR）块。考虑在此过程中执行以下操作：

• 每个区域允许多个VPC的IP地址空间。

• 考虑跨账户连接。例如，每个业务线可能都有一个唯一的帐户和VPC。这些帐户应该能够连接共享服务。

• 在VPC内，为跨多个可用区的多个子网留出空间。

• 始终将未使用的CIDR块空间留在VPC中。

规划网络拓扑的第二步是确保连接的弹性：

• 如何适应拓扑中的故障？

• 如果错误配置某些内容并删除连接会发生什么？

• 是否能够处理意外增加的服务流量/使用量？

• 是否能够吸收尝试的拒绝服务（DoS）攻击？

AWS有许多功能会影响你的设计。你打算使用多少个VPC？你会在VPC之间使用Amazon VPC peering？你是否将虚拟专用网络（VPN）连接到任何这些VPC？你打算使用AWS Direct Connect还是互联网？

最佳做法是始终为你的VPC CIDR块标识RFC 1918专用地址范围。选择的范围不应与现有的使用或计划使用VPC peering，或VPN共享地址空间的任何内容重叠。通常，你需要确保分配的范围包括足够的地址空间，用于需要部署的子网数量，Elastic Load Balancing（ELB）负载平衡器的潜在大小，VPC中并发Lambda调用的数量，以及服务器（包括机器学习服务器）和部署在子网中的容器。通常，你应该计划部署大型VPC CIDR块。请注意，VPC CIDR块在部署后可以更改，但如果为VPC分配大的CIDR范围，则可以更容易地进行长期管理。子网CIDR无法更改。请记住，部署最大的VPC可能会导致超过65,000个IP地址。基本10.x.x.x地址空间意味着你可以使用超过16,000,000个IP地址。对于所有这些决定，你应该选择偏大而不是偏小。

来自VPC的连接通过路由表条目来管理。Internet网关，NAT网关，虚拟专用网关或VPC对等连接，都通过其路由表中的条目暴露给子网。在规划网络时。考虑你想要的虚拟专用网关和VPC peering。

VPC端点服务是VPC间连接的另一个选择。这使你可以将网络负载均衡器用作另一个VPC的专用入口点。

在VPC之间建立网络的另一个选择是使用VPN设备。AWS Marketplace上提供了常用的设备。

在选择运行设备所需的供应商和实例大小时，应考虑所需的弹性和带宽要求。如果你使用的VPN设备在其实施中没有弹性，那么你应该通过第二个设备进行冗余连接。对于所有这些方案，你需要定义可接受的恢复时间（TTR）并进行测试以确保你满足这些要求。

如果你选择通过AWS Direct Connect连接将VPC连接到数据中心，并且需要此连接具有高可用性，请通过另一个位置的第二个AWS Direct Connect连接进行冗余连接回退。如果你有多个数据中心，请确保连接在不同位置终止。

为了获得最大的弹性，你应该有冗余的到每个数据中心的直接连接。

如果你选择使用AWS Managed VPN通过互联网做的VPN故障转移，请务必了解它支持每个VPN隧道高达1.25 Gbps的吞吐量，但不支持出口等价多路径（ECMP）。多个AWS管理的VPN隧道终止于同一个VGW。

我们不建议客户使用AWS Managed VPN作为速度高于1 Gbps的AWS Direct Connect连接的备份。实际上，即使有多个直接连接，你也需要确保一个网络连接的故障不会使冗余连接崩溃并降低其性能。

你应该使用现有标准来保护此私有地址空间中的资源。应将一个子网或一组子网（每个可用区域一个）用作Internet和应用程序之间的屏障。在本地环境中，你经常使用具有防止常见Web攻击的功能的防火墙，并且你经常使用负载平衡器或边缘路由器来转移DoS攻击，例如SYN flood。AWS提供了许多可以提供此功能的服务，例如AWS Shield和AWS Shield Advanced，部署在Amazon CloudFront和ELB上的集成Web应用程序防火墙（AWS WAF），ELB本身以及AWS虚拟网络的功能，如VPC安全组和网络访问控制列表（ACL）。你可以使用AWS Partners和AWS Marketplace中的虚拟设备来扩充这些功能，以满足你的需求。

4.1 用于网络拓扑的关键AWS服务

支持网络规划的关键AWS服务是Amazon Virtual Private Cloud（Amazon VPC），它允许你分配专用IP地址范围，以提供非Internet可访问资源或扩展数据中心。以下服务和功能也很重要：

• AWS Direct Connect：可用于为AWS提供专用连接，以实现与AWS之间可能的低延迟和一致性能。

• Amazon EC2：如果你选择在网络之间实施VPN，则这是运行VPN设备的服务。

• Amazon Route 53：直接与ELB集成的域名系统（DNS）服务，可以在发生DoS攻击时提供一层防御。

• AWS Global Accelerator：这是一种网络层服务，可用于创建加速器，将流量引导至AWS全球网络上的最佳端点。

• Elastic Load Balancing：提供跨可用区的负载平衡，执行第7层路由，与AWS WAF集成，并与Auto Scaling集成，以帮助创建自我修复基础架构，吸收流量增加，同时在流量减少时释放资源。

• AWS Shield：免费提供针对分布式拒绝服务（DDoS）攻击的自动保护。AWS Shield Advanced可提供你配置的基础架构中的其他保护，并将保护Elastic Load Balancing负载均衡器，Amazon CloudFront分配和Amazon Route 53托管区域。

5. 应用程序高可用性设计

本部分的目的是帮助你设计在AWS上构建和运行应用程序，并提供适当的可用性以满足你的业务需求。可用性目标可以从适用于内部工具的可用性目标（例如，99％的可用性），到关键任务工作负载的目标（例如，99.999％甚至更高）。根据必要的可用性，工程和工作所需的工作量、操作以及适用于交付应用程序的服务会有所不同。为实现最高级别的可用性，成本可能相当高。我们将分享几种应用AWS服务的实用技术，以实现工作负载所需的可用性。

注意：如果可靠性主题对你来说是新的，或者你是AWS新手，请查看本白皮书后面的自动部署消除影响（变更管理），和面向恢复的计算（故障管理）部分。这些部分将介绍在阅读本节时有用的一些概念。

在设计新应用程序时，通常会假设它必须是“五个九”（99.999％），而不必考虑在该可用性级别构建和运行应用程序的真实成本。这样做要求必须构建和运行从最终客户到服务应用程序，数据存储和所有其他组件的每个网络和基础架构，以达到99.999％。仅举一个例子，大多数互联网服务提供商不是为了实现五个九的可用性而构建的。因此，应用程序需要多个服务提供商（没有共同的故障点），特定最终客户可以使用99.999％。

此外，应用程序及其所有依赖项需要构建并测试到此级别的可用性，同时避免单点故障。这将需要大量的自定义开发，因为许多软件库和系统不能构建为五个九的可用性。整个系统将要求对故障触发器进行详尽的测试。由于99.999％的可用性每年可提供不到5分钟的停机时间，因此在生产中对系统执行的每项操作都需要自动化并进行相同级别的测试。每年5分钟的预期，人的判断和行动完全不能胜任故障恢复。系统必须在任何情况下自动恢复。因此，生产环境必然会缓慢变更，每个变更都在全面复制的预生产环境中进行测试（本身会增加大量成本。）

在AWS上可构建真正需要99.999％可用性的应用程序，如同以下示例说明。

99.999％的可用应用。让我们创建一个ATM网络，为客户分配现金。它由定制的外部设备（ATM）组成，通过网络连接到由拥有ATM的商业银行运营的主处理设备。商家银行维护一个称为主处理设备帐户的机器余额的现金帐户。主处理设备具有到所有银行和银行网络的冗余连接。

设备本身并非始终可用，任何单个设备的网络连接也是，因此你需要部署大量设备以使客户能够轻松使用其他设备（如果设备停机或缺少连接）。在“可用性话术”中，它们是冗余的，并且孤立的故障。

主处理设备实际上是至少两台计算机和存储，它们跨独立的AWS区域部署，并在区域之间进行同步复制。主处理设备具有到商家银行和银行网络的冗余连接，并且主处理设备在独立位置具有备用副本。当需要现金时，主处理设备请求电子资金转账，从客户的账户中取钱并将其存入主处理设备账户。在转移资金后，它会向ATM发送信号以分配资金。然后，它通过与商业银行的冗余连接，启动自动清算（ACH）将这些资金转移到商家银行的账户。这将偿还商家银行所分配的资金。如果在资金转移到主处理设备之后，ATM与主处理设备或ATM机本身之间的连接出现问题，它就不能告诉ATM分配现金。它会将资金转回客户的账户。ATM将使交易超时，然后将自己标记为停止服务。

将从AWS上的主处理设备到商家银行建立多个AWS Direct Connect连接。来自ATM机的连接也将通过冗余直接连接提供商运行到主处理设备。如果与主处理设备断开与商家后台的冗余连接，它们将持续存储ACH传输请求，直到连接恢复，同时标记ATM运行的服务。

此应用程序可以在AWS上构建和运行。然而，如前所述，成本将是相当大的。对于大多数应用程序，我们建议首先提出几个简单的问题：

• 想解决哪些问题？

• 应用程序的哪些特定方面需要特定级别的可用性？

• 这种工作量在一年内实际累积的累积停机时间是多少？

• 从本质上讲，系统不可用的真正影响是什么？

让我们来探索一个例子，你可能最初认为应用程序需要99.999％可用，但实际上即使可用性设计目标较低，它也可以工作。

让我们创建一个智能家居取暖产品。它由移动应用程序和与加热系统电连接的无线恒温器组成。恒温器与互联网上的控制终端连接。你的应用使用互联网上的API将操作发送到恒温器。当然，你的用户会期望开启加热功能始终有效。他们需要五个九的可用性。我们如何提供可用性？考虑该可用性级别所需的体系结构：

如果他们的互联网服务提供商（ISP）中断了怎么办？要真正为你的客户所用，你需要通过移动设备进行冗余互联网连接。这会增加恒温器的成本，生产成本，运行成本以及在其上运行的代码的复杂性。你还必须测试此冗余是否正确切换。然后你需要看看这个设计中的其他失败点。当你需要更新运行“服务”的操作系统时会发生什么？或者，如果你需要部署新版本？如果你需要重新配置数据中心网络怎么办？或者，如果你需要添加更多存储空间？或者，当互联网连接断开时，你可以在恒温器上设置物理覆盖按钮。

这是一个表示可靠性要求而不考虑范围和成本并计算投资回报率（ROI）的示例，可能会导致你走错路。例如，恒温器需要五个可用性，而不是整个架构。在你的分析中，你应该询问有关未说出的假设的问题。如果你有中断，你是否有客户在其他时间不会再回来开展业务？你是否可以使用较低级别的可用性和回退机制来处理故障？

在大多数应用中，需要考虑许多潜在的中断源。在更高的可用性水平下，对这些中断的检测和响应必须完全自动化。

下表列出了常见的中断来源：

实现99.999％的可用性意味着掌握此处列出的所有中断源，并在操作过程中自动完成所有应该人为的干预。它意味着测试应用程序的各个方面，包括预测客户将使用它的方式，这是大多数人难以想象的。它意味着部署和维护金丝雀，不断测试你的应用程序，并经常进行自动故障转移测试，以确保你的网络的每个部分在这些条件下正常运行。它意味着成功和失败的单元级和工作流/事务监控，它意味着警报和日志分析，自动回滚和自动系统恢复功能，包括你和客户之间的每个相关服务，网络连接和基础设施。

经过深入分析，实现和维护高可用性应用程序所涉及的工作似乎令人生畏。这通常会导致更精确的定义和需求的优先级：

• 对你的客户和你的企业来说，最有价值的交易是什么？

• 你能预测某些地区何时有最大的需求？

• 你的高峰时间是一天，一周，一个月，一个季度或一年的几个时间点？

好消息是AWS提供了许多服务，来抽象完成许多这些工作所需的工作，只要选择合适的服务来满足你的可用性设计目标。为可用性定义正确的设计目标，将使你了解如何实施应用程序并确定实现可用性的额外成本。本白皮书的其余部分将帮助你考虑选择正确的设计目标，然后选择AWS服务，构建软件以及构建符合你目标的操作实践。

本节的其余部分分为四部分：

• 了解可用性需求

• 可用性应用程序设计

• 可用性的操作注意事项

• 可用性目标的示例实现

我们将在“了解可用性需求”中探索可用性需求，如何影响你的体系结构。在“应用程序设计可用性”中，我们将介绍应用于提高可用性的常用技术。我们讨论了更新应用程序的方法，这些方法可以最大限度地减少“可用性的操作注意事项”中的可用性影响。最后，在“可用性目标的示例实现”中，我们将说明如何使用不同的方法来提高可用性。

5.1 了解可用性需求

最初将应用程序的可用性视为整个应用程序的单一目标是很常见的。但是，经过仔细检查，我们经常发现应用程序或服务的某些方面具有不同的可用性要求。例如，某些系统可能会优先考虑在检索现有数据之前接收和存储新数据的能力。其他系统优先考虑改变系统配置或环境的操作的实时操作。服务可能在一天中的某些时段具有非常高的可用性要求，但在这些时间之外可以容忍更长时间的中断。这些是你可以将单个应用程序分解为组成部分的几种方法，并评估每个应用程序的可用性要求。这样做的好处是根据具体需求将工作（和费用）集中在可用性上，而不是将整个系统设计为最严格的要求。

建议：严格评估应用程序的独特方面，并在适当情况下区分可用性设计目标以反映业务需求。

在AWS中，我们通常将服务划分为“数据平面”和“控制平面”。数据平面负责提供实时服务，而控制平面用于配置环境。例如，Amazon EC2实例，Amazon RDS数据库和Amazon DynamoDB表读/写操作都是数据平面操作。相反，启动新的EC2实例或RDS数据库，或在DynamoDB中添加或更改表元数据都被视为控制平面操作。虽然高可用性对于所有这些功能都很重要，但数据平面通常具有比控制平面更高的可用性设计目标。

我们的许多客户采用类似的方法，来批判性地评估他们的应用程序，并识别具有不同可用性需求的子组件。有了这些信息，就可以根据子组件定制可用性设计目标，并且完成工作以满足每个子组件的特定设计目标。当然，具有更高可用性设计目标的组件将需要在工程，测试和操作自动化方面进行更深入的投资。

然后针对不同方面定制可用性设计目标，并且执行适当的工作以设计系统。AWS拥有丰富的工程应用经验，具有一系列可用性设计目标，包括具有99.999％或更高可用性的服务。AWS Solution Architects（SA）可以帮助你根据可用性目标进行适当设计。在你的设计过程中尽早参与，AWS可以提高我们帮助你实现可用性目标的能力。规划可用性不仅在你的工作负载启动之前完成。随着你获得操作体验，学习现实世界事件以及忍受不同类型的失败，我们不断完善你的设计。然后，你可以应用适当的工作量来改进你的实施。

5.2 可用性应用程序设计

在我们运营Amazon.com和AWS的这些年里，我们在设计可用性应用程序方面积累了丰富的经验。虽然有许多经验教训，但我们应用于提高可用性的五个最常见的实践如下：

• 故障隔离区

• 冗余组件

• 微服务架构

• 面向恢复的计算

• 分布式系统最佳实践

以下部分深入介绍了每种做法。

5.2.1 故障隔离区

如上所述，除了各个组件的可用性之外，用于增加系统可用性的最知名和广泛使用的技术之一，是并行地使用多个独立组件。（一个常见的例子是使用多个AWS可用区。）在构建依赖冗余组件的系统时，确保组件独立运行非常重要，对于AWS区域，则要自主运行。理论上的可用性计算只有在这种情况下才有效。

AWS具有多个构造，可提供不同级别的独立冗余组件。从最低级别开始，为了增强数据平面可用性，AWS通过某些维度（例如资源ID），对资源和请求进行分区。这些分区（我们称之为“单元”，但其他分区可称为“分片”或“条带”）被设计为独立的，并且还包含单个单元内的故障。为此，确定适当的分区密钥，以最小化跨单元交互，并避免在每个请求中涉及复杂的映射服务是很重要的。需要复杂映射的服务，最终只是将问题转移到映射服务，而需要跨单元交互的服务降低了单元的独立性（因此假设可用性的改进）。例如，Amazon Route53使用shuffle分片的概念将客户请求隔离到单元格中。

AWS还采用了可用区（AZ）的故障隔离结构。AWS区域由两个或多个设计为独立的可用区组成。每个可用区域与其他区域之间的距离较大，以避免由于火灾，洪水和龙卷风等环境危害而导致的相关故障情况。每个可用区域都具有独立的物理基础设施：专用电源连接，独立备用电源，独立机械服务以及可用区内外的独立网络连接。尽管地理位置分离，但可用区位于同一区域。这可以实现同步数据复制（例如，在数据库之间），而不会对应用程序延迟产生不适当的影这允许客户在主动/主动或主动/备用配置中使用可用区。可用区域是独立的，因此当使用多个AZ时，应用程序可用性会增加。某些AWS服务（包括EC2实例数据平面）被部署为严格的区域服务，它们与可用区域作为一个整体共享命运。这些服务用于独立运行特定可用区内的资源（实例，数据库和其他基础结构）。AWS长期以来在我们的Regions中提供了多个可用区。虽然AWS控制平面通常提供管理整个区域（多个可用区）内的资源的能力，但某些控制平面（包括Amazon EC2和Amazon EBS）能够将结果过滤到单一可用区。完成此操作后，仅在指定的可用区中处理请求，从而减少其他可用区中断的风险。

建议：当你的应用程序依赖于一个可用区域中断期间控制平面API的可用性时，请使用API过滤器为每个API请求的单个可用区域请求结果（例如，使用DescribeInstances）。

最普遍的故障隔离结构是AWS Region的架构。区域设计为自治区域，每个区域都部署了专用的服务副本。区域AWS服务在内部使用主动/主动配置中的多个可用区来实现我们建立的可用性设计目标。

虽然我们为客户提供跨区域运营服务的能力（例如，Amazon Simple Storage Service（Amazon S3）的跨区域复制，以及将各种快照和亚马逊机器映像（AMI）复制到其他区域的能力），但我们这样做了以保持地区自治的方式。此方法的例外情况非常少，包括我们提供全球边缘交付的服务（例如Amazon CloudFront和Amazon Route53），以及AWS身份和访问管理（IAM）服务的控制平面。绝大多数服务完全在一个区域内运作。附录A提供了单一可用区和多可用区配置中所选服务可用性的设计目标表。你可以使用此信息来指导应用程序的设计目标。

5.2.2 冗余组件

AWS中服务设计的基本原则之一，是避免底层物理基础架构中的单点故障。这促使我们构建使用多个可用区的软件和系统，并使弹性的Amazon Web Services成为单个区域的故障。类似地，系统被构建为对单个计算节点，单个存储卷或数据库的单个实例的故障具有弹性。

5.2.3 微服务架构

在AWS，我们使用称为微服务的概念构建了我们的系统。虽然微服务具有几个吸引人的特性，但可用性最重要的好处是微服务更小更简单。它们允许你区分不同服务所需的可用性，从而将投资更专注于具有最大可用性需求的微服务。例如，要在Amazon.com（“详细信息页面”）上提供产品信息页面，需要调用数百个微服务来构建页面的不连续部分。虽然有一些服务必须可用于提供价格和产品详细信息，但如果服务不可用，则可以简单地排除页面上的绝大多数内容。甚至诸如照片和评论之类的东西实际上也不需要提供顾客可以购买产品的体验。

微服务将面向服务的体系结构的概念提升到创建具有最小功能集的服务的程度。每项服务都会发布API以及设计目标，限制以及使用该服务的其他注意事项。这与调用应用程序建立了“契约”。这实现了三个主要好处：

• 该服务有一个简明的业务问题和一个拥有业务问题的小团队。这样可以实现更好的组织扩展。

• 只要满足API和其他“合同”要求，团队就可以随时部署

• 只要满足API和其他“合同”要求，团队就可以使用他们想要的任何技术堆栈。

建议：通过“合约”（API和性能期望）将离散功能隔离到服务中。

部署微服务架构时需要考虑一些因素。一个是你现在拥有一个分布式计算架构，可以使实现最终用户延迟要求变得更加困难，并且在调试和跟踪用户交互方面存在额外的复杂性。AWS X-Ray服务可用于帮助你解决此问题。要考虑的另一个影响是，随着你管理的应用程序数量的增加，操作复杂性也会增加。

5.2.4 面向恢复的计算(ROC)

作为AWS专注于构建故障隔离区并避免单点故障的补充，我们还努力将故障发生时的中断时间降至最低。由于影响持续时间是计算可用性的主要输入，因此缩短恢复时间对提高可用性具有直接影响。面向恢复计算（ROC）是应用于改善恢复的系统方法的术语。

ROC确定了增强恢复的系统特征。这些特征包括：隔离和冗余，系统范围内的回滚变更能力，监控和确定健康状况的能力，提供诊断的能力，自动恢复，模块化设计以及重启能力。我们在前面的部分中讨论了隔离和冗余以及模块化设计。在“可用性的操作注意事项”部分中，我们将讨论回滚更改，监视和诊断的能力。在本节中，我们将讨论健康监控，自动恢复和重启能力。

ROC承认系统中会发生许多不同类型的故障。故障可能发生在硬件，软件，通信和操作中。ROC建议专注于使用正确的机制来检测故障（例如Elastic Load Balancing或Route53运行状况检查），而不是构建新的机制来捕获，识别和纠正每种不同类型的故障。发生故障后，ROC将应用少量经过充分测试的恢复路径之一。

在应用面向恢复的方法的系统中，许多不同类别的故障都映射到相同的恢复策略。例如，应用ROC，我们会将相同的恢复方法应用于网络超时和依赖性失败，其中依赖性返回错误。这两个事件对系统都有类似的影响，因此ROC不会试图使任何一个事件成为“特殊情况”，而是应用类似的指数退避重试策略。另一个例子是使用Auto Scaling与Amazon Elastic Compute Cloud（Amazon EC2）来管理队列容量。实例可能由于硬件故障，操作系统错误，内存泄漏或其他原因而失败。不是为每个构建自定义补救，而是将任何实例视为实例失败，终止实例，并允许Auto Scaling替换实例。

要避免的模式是开发很少执行的恢复路径。例如，你可能具有用于只读查询的辅助数据存储。当你写入数据存储并且主服务器出现故障时，你可能希望故障转移到辅助数据存储。如果你不经常测试此故障转移，你可能会发现你对辅助功能的假设不正确。辅助数据存储的容量（在上次测试时可能已足够）可能无法再承受此方案下的负载。我们的经验表明，唯一有效的错误恢复是你经常测试的路径。这就是为什么拥有少量恢复路径是最好的。你可以建立恢复模式并定期测试它们。如果你有复杂或关键的恢复路径，则仍需要定期在生产中执行该故障，以说服自己恢复路径有效。在我们刚刚讨论的示例中，你应该定期故障转移到备用数据库，无论是否需要。

AWS在设计我们的服务时考虑了故障恢复。我们设计服务以最大限度地缩短从故障中恢复的时间并对数据产生影响。我们的服务主要使用数据存储，这些数据存储仅在将请求持久存储在多个副本之后才会确认。这些服务和资源包括Amazon Aurora，Amazon Relational Database Service（Amazon RDS）多可用区数据库实例，Amazon S3，Amazon DynamoDB，Amazon Simple Queue Service（Amazon SQS）和Amazon Elastic File System（Amazon EFS）。它们构建为使用基于单元的隔离并使用可用区的独立性。我们在操作程序中广泛使用自动化。我们还优化了更换和重启功能，以便从中断中快速恢复。

5.2.5 分布式系统最佳实践

当我们应用我们在这些部分中讨论的方法，包括微服务架构和故障隔离区的使用时，我们认识到当今构建的许多系统都是分布式系统。他们依靠通信网络来互连组件。特别是当穿越较长距离或中间网络时，这些系统可能具有高延迟或丢失。个别服务可能会看到暂时压倒其响应能力的请求峰值。有许多最佳实践可用于允许这些服务在出现这些“正常”问题时继续正常运行。

这些最佳实践模式包括以下内容：

限制：这是一种防御模式，可以响应需求的意外增长，通常是在Web服务上。一些请求将被接受，但被拒绝的请求将返回一条消息，表明它们已被限制，期望它们将以较慢的速率再次尝试。你的服务应设计为每个节点或单元可以处理的已知容量的请求。这可以通过负载测试来建立。然后，你需要跟踪请求的到达率，如果临时到达率超过此限制，则相应的响应将表示请求已被限制。这允许用户可能重试可能具有可用容量的不同节点/单元。Amazon API Gateway提供限制请求的方法。

使用指数回退重试：这是我们刚才讨论的限制模式的调用方。AWS SDK默认实现此功能，并且可以进行配置。模式是暂停，然后稍后重试。如果再次失败，请暂停更长时间并重试。暂停时间的增加通常称为“后退”。经过一定的尝试次数或经过的时间后，它将退出重试并返回失败。

快速失败：只需尽快返回错误。这将允许释放与请求相关联的资源，并且通常允许服务在资源不足时进行恢复。最好是快速失败而不是允许请求排队。队列可以在系统的多个级别创建，并且可能严重阻碍快速恢复的能力。要非常注意队列存在的地方（它们经常隐藏在工作流程或记录到数据库中的工作中）。

幂等性标记的使用：在分布式系统中，最多一次或至少一次执行操作很容易。但很难保证一次只执行一次动作。这样做的常用方法是在API中使用幂等标记。这样做，服务可以一次或多次接收变异请求，而不会产生重复记录或副作用。调用者使用幂等性令牌发出API请求; 每当请求重复时都会使用相同的标记（例如，由于超时和重试。）当接收到已经处理的请求时，幂等API使用该标记来确定工作已经完成，然后返回 响应与第一次完成工作时返回的响应相同。构建具有幂等性的系统比构建假定动作必须恰好发生一次的系统更具弹性。

持续工作：当负载快速变化时，系统可能会失败。如果你知道你的服务需要在峰值时每秒处理100个单位的工作，那么你应该为100个单位的工作设计和调整你的系统。如果有工作要做，则需要其中一个插槽。但如果没有，你就把“填充物”放在插槽中，这样你就知道你总是每秒做100个单位。一个例子是在缓冲区中播放数据的视频播放器。如果你没有工作，因为没有新数据进入，你可以处理上次收到的相同数据，并有效地渲染相同的视频帧，执行相同的工作。

断路器：在某些情况下，服务需要尽最大努力制作远程请求，但不希望采用硬依赖关系，这将包括依赖关系在计算调用服务的可用性设计目标时的可用性。在这些情况下，一种解决方案是为每个远程请求使用监控回路和断路器。当正常处理请求时，断路器闭合并请求流过。当远程系统开始返回错误或表现出高延迟时，断路器打开以避免进一步的延迟影响或可用性影响。打开时，将忽略依赖关系或将结果替换为本地可用数据（可能只是响应缓存）。系统会定期尝试调用依赖关系以确定它是否已恢复。当发生这种情况时，断路器闭合。

双模态行为和静态稳定性：分布式系统可能受到由一个故障触发的负反馈回路的影响。例如，网络超时可能导致系统尝试刷新整个系统的配置状态。这会给另一个组件增加意外负载，这可能会导致其失败，从而引发其他意外后果。我们将此称为“双模态”行为，因为系统在正常模式和失败模式下具有不同的行为。为了抵消这种行为，我们更喜欢构建静态稳定且仅在一种模式下运行的系统。它们保持足够的内部状态，以便在故障之前继续运行，而不会给系统增加额外的负载。这些系统最终可能在某些故障期间执行较少的工作（这是合乎需要的）。此类系统的另一个示例是使用Amazon EC2作为实例容量的系统。系统通常假设如果实例或可用区失败，它们将通过简单地启动新实例来响应。但是，这种方法意味着在故障期间，系统将执行与往常不同的工作。相反，我们建议使用Elastic Load Balancing或Amazon Route53运行状况检查将负载从失败的实例转移，并使用Auto Scaling异步替换它们。

5.3 可用性的运维注意事项

许多IT工作负载的经验和数据突出了运维和流程对应用程序可用性的重要性。尽管在软件和硬件方面进行了所有投资，但过程中的错误配置或失误可能会频繁地撤消这些努力。在设计满足可用性设计目标的软件时，规划应用程序整个生命周期中使用的自动化或人工流程非常重要。这包括部署新版本，服务操作，刷新底层基础架构以及更换故障基础架构。

测试是交付流水线的重要组成部分。除了在组件级别执行的常见单元测试和功能测试之外，执行持续负载测试也很重要。负载测试应该发现工作负载的断点，测试性能以及执行故障注入测试。此外，你的监视服务必须能够添加或删除对已添加或已弃用的功能的监视。AWS发现执行运营准备情况审核非常有用，这些审核评估测试的完整性，监控能力，以及重要的是，审核应用程序性能到其SLA的能力，以及在发生中断或其他操作异常时提供数据的能力。

5.3.1 自动部署以消除影响

对生产系统进行更改是许多组织面临的最大风险领域之一。我们认为部署是一个需要解决的一流问题，以及我们的软件解决的业务问题。今天，这意味着在任何可行的操作中使用自动化，包括测试和部署更改，添加或删除容量以及迁移数据。

建议虽然传统观点认为你让人在最困难的操作程序中处于循环中，但我们建议你出于这个原因自动化最困难的程序。

这些是最小化风险的部署模式：

• 金丝雀部署

• 蓝绿部署

• 功能切换

• 故障隔离区部署

金丝雀部署是指将少数客户引导到新版本并仔细检查所生成的任何行为更改或错误的做法。如果你遇到严重问题，可以从金丝雀中删除流量并将用户发送到之前的版本。如果部署成功，你可以继续以所需的速度进行部署，同时监视相同的更改和错误，直到完全部署为止。可以使用可启用金丝雀部署的配置来配置AWS Code Deploy。

蓝绿部署类似于金丝雀部署，除了并行部署应用程序的完整队列。你可以跨两个堆栈（蓝色和绿色）交替部署。再一次，你可以将流量发送到新版本，如果你发现部署问题，则可以故障回复到旧版本。你还可以将流量的一小部分用于每个版本，以拨号采用新版本。可以使用部署配置配置AWS Code Deploy，以实现蓝绿部署。

功能切换是应用程序上的配置选项。你可以在关闭功能的情况下部署软件，以便客户看不到该功能。然后，你可以像打开金丝雀部署一样打开此功能，也可以将更改速度设置为100％以查看效果。如果部署有问题，你可以简单地关闭该功能而不回滚。

AWS为其自己的部署建立的最重要规则之一，是避免同时触及区域内的多个可用区。这对于确保可用区域是否可用于我们的可用性计算至关重要。我们建议你在部署中使用类似的注意事项。

5.3.2 测试

测试工作应与你的可用性目标相称。应该测试应用程序对依赖性的瞬时故障的弹性，持续时间可能持续不到一秒到几小时。通过测试确保你可以实现可用性目标是你确信自己能够实现这些目标的唯一方法。我们的经验是，可以持续运行并模拟客户行为的金丝雀测试是最重要的测试过程之一。在这些测试中，你应该进行单元测试，负载测试，性能测试以及模拟故障模式。不要忘记测试外部依赖性不可用性和部署失败。实现非常高的可用性需要实现容错软件模式，并测试它们是否有效。

其他降级模式可能会导致功能降低和响应缓慢，通常会导致服务质量下降。这种降级的常见原因是关键服务的延迟增加和网络通信不可靠（丢包）。你可能希望使用向系统注入随机故障的功能，包括组件故障，网络效应（如延迟和丢弃的消息）以及DNS故障，例如无法解析名称或无法建立与依赖服务的连接。

Netflix提供了一些示例开源软件，可以作为此类测试的基础。你可以使用他们的软件或开发自己的软件来模拟故障模式。为了模拟可能产生掉电的条件，你可以使用常见代理的扩展来引入延迟，丢弃消息等，或者你可以创建自己的。

5.3.3 监测和报警

监控对于确保满足可用性要求至关重要。你的监控需要有效地检测故障。最糟糕的故障模式是“静默”故障，其中功能不再起作用，但除了间接地没有办法检测它。你的客户在你做之前就知道了。遇到问题时发出警报是你监控的主要原因之一。你的警报应尽可能与你的系统分离。如果你的服务中断消除了警报的能力，你将有更长的中断时间。

在AWS，我们在多个级别上检测应用程序。我们记录每个请求的延迟，错误率和可用性，所有依赖关系以及流程中的关键操作。我们还记录了成功运营的指标。这使我们能够在问题发生之前就看到它们。我们还寻找外围数据点，因为这可能是即将发生问题的另一个迹象。这通常称为百分位数监测。如果你的平均值是可以接受的，但是你的100个请求中有一个会导致极端延迟，当你的流量增长时，它最终会成为一个问题。

此外，从远程位置监视所有外部端点，以确保它们独立于基本实现。我们已经看到使用“用户金丝雀”应用程序检测问题的时间有所改善，这些应用程序执行应用程序的消费者执行的一些常见任务。它们可以在图形用户界面和Web服务中实现。它们都必须在很短的时间内完成，目标是1秒。必须仔细选择这些，以便他们在测试期间不会加载应用程序。只有短期任务的原因是每分钟运行一次，这使你可以在用户看到问题之前检测到问题。

虽然很好地理解了操作系统内的监控，但云中的监控提供了新的机会。云提供商不是使用像SNMP那样的旧的事实上的标准方法，而是开发了可定制的钩子和洞察力，从实例性能到网络层，再到请求API本身。

AWS的监控包括五个不同的阶段：

• 采集

• 聚合

• 实时处理和报警

• 储存

• 分析

采集

首先，确定哪些服务和/或应用程序需要监控，定义重要指标以及如何在必要时从日志条目中提取它们，最后创建阈值和相应的警报事件。AWS提供了大量可供使用的监控和日志信息，可用于定义按需更改流程。以下是生成日志和指标数据的部分服务和功能列表。

• Amazon ECS，Amazon EC2，经典负载均衡器，应用程序负载Balancer，Auto Scaling和Amazon EMR发布CPU，网络I / O和磁盘I / O平均值的指标。

• 可以为Amazon Simple Storage Service（Amazon S3），Classic Load Balancers和Application Load Balancers启用Amazon CloudWatch Logs。

• 可以在VPC内的任何或所有弹性网络接口（ENI）上启用VPC流日志。

• AWS CloudTrail以逐个帐户为基础记录所有API事件。

• Amazon CloudWatch Events提供描述AWS服务更改的实时系统事件流。

• AWS提供工具来收集操作系统级日志并将其流式传输到CloudWatch Logs。

• 自定义Amazon CloudWatch指标可用于任何指标尺寸。

• Amazon ECS和AWS Lambda将日志数据流式传输到CloudWatch Logs。

• 亚马逊机器学习（Amazon ML），Amazon Rekognition，Amazon Lex和Amazon Polly提供成功和成功的指标不成功的请求。

• AWS IoT提供规则执行数量的指标以及规则周围的特定成功和失败指标。

• Amazon API Gateway提供API请求数量，错误请求和延迟的指标。

聚合

Amazon CloudWatch和Amazon S3充当主要聚合和存储层。对于某些服务，例如Auto Scaling和ELB，默认度量标准是“开箱即用”的，用于CPU负载或群集或实例上的平均请求延迟。对于流式服务（如VPC Flow Logs或AWS CloudTrail），事件数据将转发到CloudWatch Logs，你需要定义和应用过滤器以从事件数据中提取度量标准。这为你提供了时间序列数据，你可以定义一组CloudWatch警报以触发警报。

实时处理和报警

警报可以触发Auto Scaling事件，以便集群对需求变化做出反应。警报也可以发送到Amazon Simple Notification Service（Amazon SNS）主题，然后推送到任意数量的订阅者。例如，Amazon SNS可以将警报转发到电子邮件别名，以便技术人员可以响应。警报可以发送到Amazon Simple Queue Service（Amazon SQS），该服务可以作为第三方票证系统的集成点。最后，AWS Lambda还可以订阅警报，为用户提供异步无服务器模型，以响应动态变化。

存储和分析

Amazon CloudWatch Logs还支持允许数据无缝流向Amazon S3的订阅。当CloudWatch日志和其他访问日志到达Amazon S3时，你应该考虑使用Amazon EMR从数据本身获得进一步的洞察力和价值。如果你的数据以受支持的方式编写，则可以使用Amazon S3 Select或Amazon Athena查询数据。Amazon S3 Select支持使用或不使用GZIP压缩的逗号分隔值（CSV）或JavaScript对象表示法（JSON）文档。Amazon Athena支持大量格式。

合作伙伴和第三方提供了许多工具，可以进行汇总，处理，存储和分析。其中一些工具是New Relic，Splunk，Loggly，Logstash，CloudHealth和Nagios。但是，系统和应用程序日志之外的生成对于每个云提供商都是唯一的，并且通常对每个服务都是唯一的。

监控过程中经常被忽视的部分是数据管理。你需要确定监视数据的保留要求，然后相应地应用生命周期策略。Amazon S3支持S3存储桶级别的生命周期管理。此生命周期管理可以不同方式应用于存储桶中的不同路径。在生命周期结束时，你可以将数据转移到Amazon Glacier进行长期存储，然后在达到保留期结束后过期。

关键AWS服务

支持监控的关键AWS服务是Amazon CloudWatch，可轻松创建触发扩展操作的警报。此外，AWS X-Ray可与你的应用程序集成，以提供对你的应用程序的请求的分布式交互的可视性。

以下服务和功能也很重要：

• Amazon S3：充当存储层，允许生命周期策略和数据管理。

• Amazon EMR：使用此服务可以进一步了解日志和指标数据。

• Amazon Athena：使用此服务可以进一步了解支持格式的数据。

5.4 运营准备评估

运营准备评估（ORR）是确认应用程序为生产操作做好准备的重要练习。在应用程序开发的早期阶段，团队通常从ORR核对表开始。这使他们能够在请求生产部署之前牢记其操作环境的要求。在初始生产部署之前进行正式的ORR。AWS将定期（每年一次，或在关键绩效期之前）重复ORR，以确保没有“偏离”运营预期。一个应用程序的ORR应包含从其他应用程序中学到的经验教训和最佳实践。

建议：在初始生产使用之前对应用程序进行操作准备审核（ORR），之后定期进行。

5.5 审计

审核你的监控将确保你知道应用程序何时满足其可用性目标。根本原因分析需要能够发现故障发生时发生的事情。AWS提供的服务允许你在事件期间跟踪服务的状态：

• Amazon CloudWatch Logs：你可以将日志存储在此服务中并检查其内容。

• AWS Config：你可以查看在时间点使用的AWS基础架构。

• AWS CloudTrail：你可以查看在哪些AWS API上调用了哪些AWS API时间和原则。

在AWS，我们每周召开一次会议，审核运营绩效并分享团队之间的学习经验。为运营绩效评估和知识共享建立定期的节奏将增强你从运营团队获得更高绩效的能力。

6. 实现可用性目标的示例

在本节中，我们将使用典型Web应用程序部署来审查系统设计，该应用程序由反向代理，Amazon S3上的静态内容，应用程序服务器和用于持久存储数据的SQL数据库组成。对于每个可用性目标，我们将提供示例实现。以上可以使用容器或虚拟机进行部署，方法是相同的。在本节中，我们将讨论可靠性支柱的其余主题。具体而言，在每个方案中，我们将演示如何：

• 适应需求变化

• 使用监控

• 部署变更

• 资料备份

• 实施弹性

• 测试弹性

• 从灾难中恢复

6.1 依赖选择

我们已选择将Amazon EC2用于我们的应用程序。我们将展示如何使用Amazon RDS和多个可用区来提高应用程序的可用性。我们将使用Amazon Route 53进行DNS。当我们使用多个可用区时，我们将使用Elastic Load Balancing。Amazon S3用于备份和静态内容。当我们设计更高的可靠性时，我们自己只能采用具有更高可用性的服务。有关相应服务的设计目标，请参阅附录。

6.2 单区域方案

6.2.1 2个9可用性（99％）场景

我们将使用对业务有帮助的应用程序，启动可用性和可靠性示例，但如果应用程序不可用，则只会带来不便。这种类型的应用程序可以是内部工具系统，内部知识管理系统和项目跟踪系统，到实验服务提供的实际面向客户的功能，以及可以在需要时隐藏服务的功能开关。

可以使用一个区域和一个可用区部署这些应用程序。我们将软件（包括数据库）部署到单个实例。我们将使用供应商或专用的备份解决方案，使用Runbook将加密的备份数据发送到Amazon S3。我们将通过恢复并确保使用Runbook定期使用它们来测试备份是否有效。我们将在Amazon S3对象上配置版本控制并删除备份的权限。我们将根据要求使用Amazon S3存储桶生命周期策略进行存档或永久删除。

我们将使用AWS CloudFormation将我们的基础架构定义为代码，特别是在发生故障时加速重建。在故障期间，我们将等待失败恢复，可选择通过Runbook将请求路由到静态网站。此恢复时间将取决于可以部署基础架构的速度，并且可以将数据库还原到最新的备份。如果使用Runbook发生可用区故障，则此部署可以位于同一可用区中，也可以位于不同的可用区中。新软件的部署流水线已安排，有一些单元测试，但主要是组装系统的白盒/黑盒测试。软件更新将使用Runbook手动执行，安装和重新启动所需的停机时间服务。如果在部署期间发生问题，则Runbook将介绍如何回滚到以前的版本。我们将提供常见硬件故障，紧急软件更新和其他破坏性更改的剧本。我们将进行简单的监视，指示服务主页是否返回HTTP 200 OK状态。当问题发生时，我们的playbook将指示从实例进行日志记录将用于确定根本原因。将使用运维和开发团队的分析来纠正错误，并且在确定优先级并完成修复时将部署错误的更正。

让我们看看恢复时间对可用性的影响。我们花30分钟来理解并决定执行恢复，在10分钟内在AWS CloudFormation中部署整个堆栈，假设我们部署到新的可用区，并假设数据库可以在30分钟内恢复。这意味着从故障中恢复大约需要70分钟。假设每季度一次失败，我们估计一年的影响时间为280分钟，或者四小时四十分钟。

这意味着可用性的上限为99.9％。实际可用性还取决于实际故障率，故障持续时间以及每个因素实际恢复的速度。对于这种架构，我们要求应用程序脱机更新（每年24小时计算：每次变4小时，每年6次），以及实际事件。因此，参考白皮书早期的应用程序可用性表，我们发现我们的可用性设计目标是99％。

以下是我们解决可靠性支柱主题的方法：

6.2.2 3个9可用性（99.9％）场景

下一个可用性目标适用于高度可用的应用程序，但它们可以容忍短时间的不可用。此类应用程序通常用于内部操作系统，这些系统在关闭时会对员工产生影响。此类应用程序还可用于面向客户的系统，这些系统对业务收入不高，并且可以容忍更长的恢复时间或恢复点。这些应用程序包括帐户或信息管理的管理系统。

我们可以通过为部署使用两个可用区，并将应用程序分离到单独的层来提高应用程序的可用性。我们将使用跨多个可用区域的服务，例如Elastic Load Balancing，Auto Scaling和Amazon RDS Multi-AZ以及通过AWS Key Management Service的加密存储。这将确保在资源级别和可用区级别上容忍故障。可以使用Amazon RDS完成备份和还原。它将使用Runbook定期执行，以确保我们能够满足恢复要求。

基础架构部署技术保持不变。负载均衡器仅将流量路由到健康的应用程序实例。运行状况检查需要位于数据平面/应用程序层，以指示应用程序在实例上的功能。此检查不应针对控制平面。将显示并配置Web应用程序的运行状况检查URL以供负载均衡器和Auto Scaling使用，以便删除并替换失败的实例。如果实例在主可用区中出现故障，Amazon RDS将管理活动数据库引擎在第二个可用区中可用，然后修复以恢复到相同的弹性。

在我们分离了层之后，我们可以使用软件/应用程序弹性模式来提高应用程序的可靠性，以便即使在可用区故障切换期间，数据库暂时不可用时它仍然可用。软件更新将自动进行，而不是使用金丝雀或蓝/绿部署模式，而是使用替换，回滚的方式，使用Runbook进行。

新软件的交付按固定时间表每两到四周进行一次。通过在主页上检查HTTP 200 OK状态，监控将被扩展为通过所有网站提供网站可用性的警报。此外，每次更换Web服务器以及数据库故障转移时都会发出警报。我们还将监控Amazon S3上的静态内容以获取可用性，并在其不可用时发出警报。记录将被汇总，以便于管理和帮助进行根本原因分析。

存在用于整个系统恢复和通用报告的Runbook。我们将提供常见数据库问题，安全相关事件，部署失败以及确定问题根本原因的手册。确定根本原因后，将通过操作和开发团队的组合来识别错误的更正。在修复开发时将部署更正。

让我们看看恢复时间对可用性的影响。我们假设至少有一些失败需要手动决定执行恢复。但是，在这种情况下自动化程度更高，我们假设每年只有两个事件需要做出此决定。我们需要30分钟来决定执行恢复，并假设恢复在30分钟内完成。这意味着从失败中恢复60分钟。假设每年发生两起事故，我们估计当年的影响时间为120分钟。

这意味着可用性的上限为99.95％。实际可用性还取决于实际故障率，故障持续时间以及每个因素实际恢复的速度。对于此体系结构，我们要求应用程序暂时脱机以进行更新，但这些更新是自动进行的。我们估计每年150分钟：每次更换15分钟，每年10次。当服务不可用时，每年最多可增加270分钟，因此我们的可用性设计目标是99.9％。

以下是我们解决可靠性支柱主题的方法：

6.2.3 4个9可用性（99.99％）场景

应用程序的此可用性目标要求应用程序具有高可用性并能够容忍组件故障。应用程序必须能够容忍故障而无需获取额外资源。此可用性目标适用于关键任务应用程序，这些应用程序是公司的主要或重要收入驱动因素，例如电子商务站点，企业对企业Web服务或高流量内容/媒体站点。

我们可以通过使用在区域内静态稳定的架构来进一步提高可用性。此可用性目标不要求控制平面改变工作负载的行为以容忍故障。例如，应该有足够的容量来承受一个可用区的丢失。我们不应要求更新Amazon Route53 DNS。我们不需要创建任何新的基础架构，无论是创建/修改S3存储桶，创建新的IAM策略（或修改策略），还是修改AmazonECS任务配置。

我们建议使用此方法的三个可用区。使用三个可用区部署，每个可用区的静态容量为峰值的50％。可以使用两个AZ，但静态稳定容量的成本更高，因为两个可用区域必须具有100％的峰值容量。我们将添加Amazon CloudFront以提供地理缓存，以及减少应用程序数据平面的请求。

使用所有层中的软件/应用程序弹性模式构建应用程序。对于这些应用程序，主要内容的写入可用性，读取可用性也是关键的架构决策。该应用程序也在部署故障隔离区域中实现。部署流水线将具有完整的测试套件，包括性能，负载和故障注入测试。我们将使用金丝雀或蓝/绿部署将更新部署到每个隔离区中。部署是完全自动化的，包括在KPI指示问题时回滚。监控将包括成功指标以及发生问题时的警报。此外，当数据库故障转移以及AZ发生故障时，每次更换故障Web服务器时都会发出警报。

Runbooks将用于严格的报告要求和性能跟踪。如果成功的操作趋向于未能满足性能或可用性目标，则将使用Playbook来确定导致趋势的原因。Playbook将存在未发现的故障模式和安全事件。还将存在用于确定故障根本原因的手册。我们将在演练日不断地练习我们的故障恢复程序，使用Runbook确保我们可以执行任务而不会偏离程序。构建网站的团队也运营该网站。该团队将确定任何意外故障的错误更正，并确定在实施后部署的修复程序的优先级。我们还将参与AWS支持基础架构事件管理产品。

让我们看看恢复时间对可用性的影响。我们假设至少有一些故障需要手动决定执行恢复，但是在这种情况下自动化程度更高，我们假设每年只有两个事件需要这个决策，恢复操作将很快。我们需要10分钟来决定执行恢复，并假设恢复在五分钟内完成。这意味着从失败中恢复15分钟。假设每年两个，我们估计的一年的影响时间是30分钟。

这意味着可用性的上限为99.99％。实际可用性还取决于实际故障率，故障持续时间以及每个因素实际恢复的速度。对于这种架构，我们假设应用程序通过更新不断在线。基于此，我们的可用性设计目标是99.99％。

以下是我们解决可靠性支柱主题的方法：

6.3 多区域情景

在多个AWS区域中实施我们的应用程序将增加运营成本，部分原因是我们隔离区域以保持其独立性。追求这条道路应该是一个非常周到的决定。也就是说，区域提供了非常强大的隔离边界，我们非常努力避免跨区域的相关故障。在区域AWS服务发生硬件依赖性故障时，使用多个区域可以更好地控制恢复时间。在本节中，我们将讨论各种实现模式及其典型可用性。

6.3.1 3½个9可用性（99.95％），恢复时间在1到30之间分钟

应用程序的这种可用性目标，需要极短的停机时间和特定时间内的极少数据丢失。具有此可用性目标的应用程序包括以下领域的应用程序：银行，投资，紧急服务和数据捕获。这些应用程序具有非常短的恢复时间和恢复点。

通过跨两个AWS区域使用“热备”方法，我们可以进一步缩短恢复时间。我们将工作负载部署到两个区域，我们的被动站点按比例缩放（并保持最终一致），以接收与我们的活动站点相同的流量负载。两个地区都将是静态稳定的。应使用软件/应用程序弹性模式构建应用程序。我们需要创建一个轻量级路由组件，来监视我们的应用程序运行状况，以及我们拥有的任何区域硬依赖关系。此组件还将处理故障转移的自动化，并从前一个活动区域停止复制。在故障转移期间，我们将使用DNS故障转移将请求路由到静态网站，直到在第二个区域中恢复。故障转移将通过检查主页上的HTTP 200 OK状态来使用网站的运行状况检查。

软件更新将使用金丝雀或蓝/绿部署模式自动完成。

新软件的交付按固定时间表每两到四周进行一次。此外，当数据库故障转移以及Region故障转移时，每次更换Web服务器时都会发出警报。我们还将监控Amazon S3上的静态内容以获取可用性，并在其不可用时发出警报。记录将被汇总以便于管理并帮助在每个区域进行根本原因分析。存在用于发生区域故障转移的Runbook，用于在这些事件期间发生的常见客户问题以及用于常见报告的Runbook。我们将提供常见数据库问题，安全相关事件，部署失败，区域故障转移意外客户问题以及确定问题根本原因的手册。确定根本原因后，将通过操作和开发团队的组合来识别错误更正，并在修复开发时进行部署。我们将使用Runbook通过游戏日验证体系结构。我们还将参与AWS支持基础架构事件管理。

让我们看看恢复时间对可用性的影响。我们假设至少有一些故障需要手动决定执行恢复，但是在这种情况下，如果具有良好的自动化，我们假设每年只有2个事件需要这个决定。我们花20分钟决定执行恢复，并假设恢复在10分钟内完成。这意味着从失败中恢复30分钟。假设每年2个，我们估计的一年的影响时间是60分钟。

这意味着可用性的上限为99.95％。实际可用性还取决于实际故障率，故障持续时间以及每个因素实际恢复的速度。对于这种架构，我们假设应用程序通过更新不断在线。基于此，我们的可用性设计目标是99.95％。

以下是我们解决可靠性支柱主题的方法：

6.3.2 5个9可用性（99.999％）或更高的场景

应用程序的此可用性目标几乎不需要特定时间的停机或数据丢失。可以具有此可用性目标的应用程序包括，例如某些银行，投资，财务，政府和关键业务应用程序，它们是极其庞大的创收业务的核心业务。希望在所有层上具有几乎强一致的数据存储和完全冗余。我们选择了一个基于SQL的数据存储。但是，在某些情况下，我们会发现很难实现非常小的RPO。如果你可以对数据进行分区，则可能没有数据丢失。这可能需要你添加应用程序逻辑和延迟，以确保在地理位置之间拥有一致的数据，以及在分区之间移动或复制数据的功能。如果使用NoSQL数据库，则执行此分区可能会更容易。

我们可以通过跨多个AWS区域使用“主动/主动”或“多主”方法来进一步提高可用性。工作负载将部署在所有需要静态稳定的区域中，路由层将流量定向到健康的地理位置，并在位置不健康时自动更改目标，以及临时停止数据复制层。Amazon Route53提供10秒间隔健康检查，并且还可以在你的记录集上提供低至1秒的TTL。

应使用软件/应用程序弹性模式构建应用程序。可能需要许多其他路由层来实现所需的可用性。不应低估这种额外实施的复杂性。该应用程序将在部署故障隔离区域中实施，并进行分区和部署，以便即使是Region wide-event也不会影响所有客户。

部署流水线将具有完整的测试套件，包括性能，负载和故障注入测试。我们将在一个区域中使用金丝雀或蓝/绿部署，一次部署到一个隔离区域，然后再从另一个区域开始。在部署期间，旧版本仍将保持运行实例以便更快地回滚。这些是完全自动化的，包括如果KPI指示问题则回滚。监控将包括成功指标以及发生问题时的警报。

Runbooks将用于严格的报告要求和性能跟踪。如果成功的操作趋向于未能达到性能或可用性目标，则将使用Playbook来确定导致趋势的原因。Playbook将存在未发现的故障模式和安全事件。还将存在用于确定故障根本原因的手册。必须以可以解决潜在冲突的方式在区域之间复制数据存储。出于延迟原因，需要创建工具和自动化流程以在分区之间复制或移动数据，并平衡每个分区中的请求或数据量。解决数据冲突的补救还需要额外的业务手册。我们将使用Runbook在游戏日期间验证架构，以确保我们可以执行任务而不会偏离程序。构建网站的团队也运维该网站。该团队将确定任何意外故障的错误更正，并确定在实施后部署的修复程序的优先级。我们还将参与AWS支持基础架构事件管理。

让我们看看恢复时间对可用性的影响。我们假设进行了大量投入以实现所有恢复的自动化，并且可以在一分钟内完成恢复。我们假设没有手动触发的恢复，但每季度最多一次自动恢复操作。这意味着每年需要四分钟才能恢复。我们假设应用程序通过更新持续在线。基于此，我们的可用性设计目标是99.999％

以下是我们解决可靠性支柱主题的方法：

7. 结论

无论你是初次了解可用性和可靠性的主题，还是经验丰富的老手寻求洞察力，以最大限度地提高关键任务服务的可用性，我们希望本节能够引发思考，提出新想法或引入新的质疑。我们希望可以根据你的业务需求，更深入地了解正确的可用性级别。我们鼓励你利用此处提供的设计，运营和面向恢复的建议，以及AWS解决方案架构师的知识和经验。我们很乐意听取你的意见，尤其是你在AWS上实现高水平可用性的成功案例。请联系你的客户团队或通过我们的网站联系我们。