避免云服务失效导致的瘫痪

上周，又一 AWS 服务的失效冲击了几大网站及其服务。如何才能避免瘫痪？仅为伸缩进行架构还不够，还需为灾备进行架构。

根据 AWS 服务健康仪表板，Amazon 东区（北弗吉尼亚区）AZ 的一组云服务——EC2、EMR、RDS 和弹性 Beanstalk 失效，时间大约从六月 29 日下午 7：25 起，至六月 30 日下午 3 时止。该失效影响了许多公司及其服务和网站，其中有 Netflix、Instagram、Pinterest 和 Herokua。据 Amazon 报道，罪魁祸首是“由横扫北弗吉尼亚地区的大面积电暴引起的”电力事件，上周五晚间一场暴风雨袭击了美国东部地区，导致 13 人丧生，三百万人口被停电。

除了电力设施的波动之外，一次巨大的电压脉冲袭击了两大计算中心，迫使它们切换到发电机供电模式，但是其中一个数据中心的发电机未成功运行，导致了相应数据中心在耗尽 UPS 之后停电。电力很快就得到恢复，但是将服务恢复至所有功能完好却需要长得多的时间。 Inmar 的架构副总裁 Mike Kavis解释了需要这么长时间的原因：“事实上，虽然 Amazon 的备份电源切换进来，但是并非所有的计算资源得到成功灾备。其结果是有一组虚拟服务被踢下线，直到 AWS 恢复它们为止。用户（译注：AWS 的用户）对于这一情况的应对措施决定了其应用是瘫痪还是保持弹性。许多网站瘫痪了。”

考虑到这类事件对于理解如何避免瘫痪的重要性。这次 AWS 的电力事故之后，Kavis 在其博文中说，他的公司自 2009 年起经历过 5 次 AWS 失效，但是他们的服务从未宕机过。原因是他们使用了多个 Zone 和 Region。

Amazon 的每个 Region 的 SLA 可达到 99.95%。在同一区域里从未发生过多个 Zone 同时失败，也从未出现过多个 Region 同时失败的情况。本质上，他们提供了计算资源的 100% 正常运行时间（uptime）。只不过这取决于我们如何架构系统以利用 Zone 和 Region 的优势……

我们假设平台中的每个服务器和服务都可能在某个时间点失败，所以设计出多条通路，使之能在多个 Zone 的冗余计算资源上继续处理交易。换言之，我们假定区域内的 Zone 可能会失效，所以将平台设计得不依赖于单个 Zone。

但是，多个 Zone 也不够，Kavis 说：

在这些失效中，我注意到一个模式，即 AWS 的 RDS 服务（将数据库管理过程自动化的服务）似乎在每次 Amzon 出现问题时都会失效……

事实上，我们手动管理我们的 MySQL 数据库才是我们在这些失效中保持弹性的主要原因之一。如果我们依赖于 RDS，我们也不会那么幸运。这是否意味着 AWS 客户不该使用 RDS 呢？不，我们仍然用它实现一些无需极端 SLA 的功能并提供与各销售点系统的实时连接。

Kavis 提到，上次 AWS 失效所袭击的一些公司有着“目前看到的最吸引人、最先进的高可用环境的架构”。但是，他们为了伸缩性牺牲了正常运行时间（uptime）：

无 SLA 要求的免费社交媒体网站就可能会把更多的时间花在支持上百万并发用户的伸缩性上，同时会面临一至两个小时宕机的风险。对于他们而言，把精力花在处理突发访问量比关注不太容易发生的 AWS 失效更有价值。毕竟没有人会因为无法向 Facebook 传照片而死掉。

其结论是：若要实现永远可用，就要为灾备进行架构，而不仅仅为伸缩性架构。正如 Kavis 所言，“我们需要理解的是，弗吉尼亚地区的许多公司自建的数据中心也瘫痪了，而且仍然处于瘫痪中。发生了电力故障。云端和本地的数据中心都瘫痪了。最终一切都瘫痪了。正常运行时间（uptime）的秘密在于你如何在设计时考虑这些失效。”

查看英文原文： Avoiding Downtime When Cloud Services Fail