从容应对未知风险----解密亚马逊云科技的韧性之道

从容应对未知风险----解密亚马逊云科技的韧性之道

作者：5G 类别：[ 业界快讯 ] 2024-08-28 16:30:01 来源：5G

北京2024年8月28日 /美通社/ -- 越来越多用户希望企业业务能7×24不间断运行，同时企业却面临越来越多业务中断的风险，如企业系统复杂性的增加，频繁的功能更新和发布等。如何确保业务连续性，提升韧性，成为企业急需解决的问题。

韧性是应用程序抵御中断或从中恢复的能力，包括与基础设施、依赖服务、错误配置、网络问题和负载激增相关的中断。在亚马逊云科技，构建云韧性是一项最基础的工作。亚马逊云科技从一开始并持续在其基础设施、服务设计与部署、运营模式和机制中将韧性考虑其中。在此基础上，亚马逊云科技还提供一套全面的服务、最佳实践等，进一步帮助客户提升自身的韧性。

亚马逊云科技的韧性始于全球基础设施

亚马逊云科技全球基础设施地理位置分散，遍及34个地理区域的108个可用区。为了避免单点故障的影响范围，亚马逊云科技最小化全球基础设施之间的互联性。每个区域都独立于其他区域，区域之间的这种隔离机制确保单个区域发生服务故障时，其他区域不受影响仍正常运营。每个区域由三个或更多个相互独立，且在物理上分隔的可用区组成。每个可用区都有独立的电力、制冷和物理安全设施，同一区域内的可用区之间的物理距离也经过精心计算——通常是100公里以内。可用区的这种隔离机制，既能防止如供电、冷却等常见故障点，也能避免同时受到如地震、洪水等大规模灾害的影响。可用区之间又通过冗余的超低延迟网络连接，可实现可用区间单位毫秒级延迟的数据同步复制。为了获得高可用性的同时可以实现更大的容错能力，客户可以将他们的应用程序设计为在多个可用区中运行。

亚马逊云科技将韧性根植于服务及架构设计中

亚马逊云科技构建的服务均满足极高的可用性目标。在服务/系统设计时，亚马逊云科技使用通过对服务的控制平面和数据平面进行隔离设计，并采用"单元架构"设计模式，减少故障发生的可能，并尽可能降低故障发生时的影响范围。

亚马逊云科技服务分为控制平面和数据平面，并对他们进行分离设计，即数据平面不依赖于控制平面而独立运行，当控制平面发生故障的情况下数据平面仍能继续正常运行。其中，控制平面提供用于创建、读取/描述、更新、删除和列出（CRUDL）资源的管理 API，例如启动新的 Amazon EC2 实例、创建 Amazon S3 存储桶以及描述 Amazon SQS 队列等。数据平面是提供服务的主要功能，例如正在运行的 Amazon EC2 实例本身、读取和写入 Amazon EBS 卷、在 Amazon S3 存储桶中获取和放置对象等。控制平面往往是复杂的协调和聚合系统，会执行多项任务；数据平面则没那么复杂，相比控制平面其发生故障事件的可能性要小。这类似于火车系统，控制平面相当于指挥中心，数据平面则是铁路线路，当指挥中心如通讯系统出现临时故障时，火车仍然能按照既定线路运行。

亚马逊云科技根据区域和可用区的隔离机制以及控制平面和数据平面分离的原则，提供三种服务类型：全局（Global）服务、区域级（Region）服务、可用区级（AZ）服务。全局服务的控制平面和数据平面不是在每个区域中独立存在。全局服务以 Amazon Identity and Access Management（Amazon IAM）为例，该服务是全局服务，它的数据平面独立存在于每个区域（Region），该区域中的每个云服务都直接与 Amazon IAM 数据平面交互。Amazon IAM 有独立的控制平面，客户可以使用它来管理身份和策略等 IAM 资源。当 IAM 控制平面故障的情况下，无需任何更改，每个区域的身份验证和授权（即 IAM 的数据平面）都可以继续正常运行。

区域级服务是建立在多个可用区域之上的服务，数据平面和控制平面都是区域级别。以 Amazon S3 为例，将请求和数据分布在多个可用区之间，可以自动从可用区故障中恢复。

可用区级服务可在一个区域内的每个可用区中独立运行，不依赖于其他可用区中的组件，可用区服务可以指定将资源部署到哪个可用区，如 Amazon EC2 属于可用区级服务。客户可以通过部署多可用区架构运行具有更高可用性、容错能力和可扩展性的生产级工作负载。当工作负载使用多个可用区架构时，可以更好地隔离和保护客户免受影响单个可用区物理基础设施问题的影响，即使一个可用区出现故障，工作负载也能保持运行。

此外，为了进一步降低故障发生时的影响范围即"爆炸半径"，亚马逊云科技还采用了"单元架构"设计模式。该模式将服务切分为多个部署堆栈，每个部署堆栈称为"单元" ，每个单元之间都是互相独立的，不共享任何内容，包括数据库，每个单元服务于一个或多个客户。采用了单元架构后，以可用区级别的服务为例，服务发生故障的影响范围就限制在单元内，而不是整个可用区。

"经验没有压缩算法"——通过卓越的运营和机制确保云服务的韧性

亚马逊云科技还建立内部运营机制，通过服务责任模型、运营就绪审查、安全/持续部署以及错误流程纠错来确保云服务的韧性。其中，亚马逊云科技的工程和产品管理工作由小型多学科团队领导，他们对所提供的服务拥有强大的所有权——不仅负责设计和发布服务，还负责在生产过程中运营服务，并在出现问题时随时待命。

在一项服务发布之前，亚马逊云科技还会使用"运营就绪审查"流程来审核所有新服务的运营准备情况。当对部署软件进行服务更新或推出新服务时，亚马逊云科技会使用安全、持续的部署管道。为了最大限度地减少错误部署对生产造成的潜在影响，亚马逊云科技通过使用广泛的预生产测试、自动回滚和交错生产部署，将自动化部署安全构建到发布过程中。例如，一项服务的更新会从小处开始，首先部署到可用区内的单个最小单元，并经过指定的等待期以验证没有出现问题，再逐步部署到整个可用区的其余部分、其他可用区、单个区域，最后部署到其余区域。

此外，亚马逊云科技还利用"纠错流程"，对客户事件进行分析、研究，找出根本原因，减少其他服务发生类似问题的可能性，防患于未然。

亚马逊云科技赋能客户利用"云韧性"提升"云中韧性"

构建韧性是一个持续的过程，而不是一次性的努力。为了帮助客户更轻松地提升云中应用的韧性，亚马逊云科技基于自身以及多年服务客户的广泛经验，总结了一套包含了服务、策略和架构最佳实践的"韧性系统建设生命周期框架"。该框架包含五个阶段：设定目标、设计和实施、验证和测试、持续运营以及响应和改进。

亚马逊云科技在每个阶段都为客户提供了适用的工具和服务。例如，客户可以使用 Amazon Resilience Hub 来设置目标，根据这些目标评估韧性状况，并根据Amazon Well-Architected Framework和 Amazon Trusted Advisor 的建议实施改进措施。在 Resilience Hub 中，客户可以创建和运行 Amazon Fault Injection Service 实验，这些实验允许客户测试其应用程序将如何响应某些类型的中断。其他服务，如 Amazon Backup、Amazon Elastic Disaster Recovery (Amazon DRS) 和 Amazon Route53 Application Recovery Controller (Route 53 ARC)，可以帮助客户快速响应和从中断中恢复。

结语

正如亚马逊首席信息官 Werner Vogels 曾说过"Everything fails all the time"（故障总在情理之中、意料之外），这也是亚马逊云科技从开始并始终加强和发展韧性的原因。亚马逊云科技将持续为客户提供广泛、深入的架构及运营最佳实践服务、工具和指导，帮助客户在云中构建和运行韧性的应用程序。

从容应对未知风险----解密亚马逊云科技的韧性之道

相关阅读