AWS上周末崩溃5小时 故障原因大揭秘

ZD至顶网软件频道消息：对于亚马逊而言，9月20日是个糟糕的一天。美国东海岸亚马逊网络服务（AWS）出了故障，5小时后才恢复。本文聊一下故障原因以及AWS恢复服务的过程。

AWS还好不是在周一（9月21日）上午挂掉的，否则网友们少不了吐糟。AWS是周日（9月20日）挂的，周日凌晨太平洋夏令时间3点（北京时间周日下午6点）挂了，几乎没有人注意到。

当然，如果你是诸如亚马逊视频和Reddit的一些流行用户服务和网站的系统管理员的话，你当然会知道这事。有没有被搞了个措手不及？

在AWS的大客户里，似乎只有Netflix公司对AWS数据中心出现大故障做了二手准备，其他人似乎都没有准备。

要知道，这次的故障远非一个“简单的”数据中心问题，并不是诸如美东AWS主干互联网叫推土机不小心碰了一下那么简单，这次的故障要复杂得多。 

一开始是亚马逊在美国弗吉尼亚的DynamoDB服务出问题。DynamoDB是一种快速灵活的NoSQL数据库服务。DynamoDB用于支持应用程序，必须保证在支持大规模的程序时延迟在几毫秒以内。你可能已经猜到了，许多时间敏感度高的AWS云服务都用到 DynamoDB服务。

一位AWS发言人在对此事作出正式回应时表示，“2015年9月20日太平洋夏令时间凌晨02时13分到早上7点10分，美国东部地区的亚马逊DynamoDB服务的读写操作出现错误率非常大的情况，影响了该地区的其他AWS服务，并造成一些AWS客户也受到错误率增大的影响。“ 

DynamoDB一旦出现读/写问题，其性能就会开始崩溃，进而会影响美国东部的其他AWS服务。出现这种情况后，美国东部所有其他AWS服务的应用程序编程接口（API）开始出现超时。尔后，基于AWS的服务就开始失效。

有些客户受到的影响比其他客户大些。在大多数情况下，这些客户会受到错误增多的影响，导致客户无法访问自己的网站和服务。许多这一类的网站其实并没有“挂掉”，但网站的性能下降，无法提供满意的服务。 

根据周日的AWS服务运行状况仪表板上DynamoDB条目的数据，整个故障过程如下： 

凌晨3:00 （所有时间为太平洋夏令时间，缩写为PDT）：我们正在检查美国-东-1区API请求错误率升高的问题。 

凌晨3:26 PDT：美国-东-1区所有DynamoDB API调用误差率继续增加，我们正在全力解决此问题。

凌晨04时05 PDT：已经找到了问题的根源，我们正在努力恢复服务。

凌晨04时41分PDT：我们仍在解决美国-EAST-1区错误率升高的问题，以求恢复DynamoDB API的正常工作。

凌晨04时52分PDT：我们在下面为大家提供目前情况的详细信息。问题的根源是DynamoDB内部的部分元数据服务。它是一个内部子服务，作用是管理表和分区信息。我们的恢复工作重点目前放在恢复元数据操作上。在我们进行恢复工作期间，API的速度将受到限制。

可以看到，亚马逊花了两个小时才找到问题的根源。他们接着就降低了所有AWS API的速度，以便其间他们的系统管理员解决出现的问题。 

早上5:22 PDT：我们现在开始对API限速，以利恢复工作的进行。

早上05:42 PDT：元数据服务开始趋向稳定；我们仍在继续恢复工作，力求尽快取消API限速。 

早上6:19 PDT：元数据服务现在稳定了下来，我们的恢复工作的目标是尽快取消API限速。

早上07:12 PDT：我们仍在努力恢复服务，力求尽早取消API限速及恢复正常API，但会遵循小心谨慎的原则。 

早上07:22 PDT：我们已开始逐步取消API限速，恢复正常流量。

早上7:40 PDT：我们继续取消API限速，可望在短期内恢复正常。

早上7:50 PDT：读写操作开始恢复正常，我们在继续努力恢复其他各种操作。

早上8:16 PDT：读写操作的恢复进展非常顺利，我们仍在继续努力恢复其他各种操作。

至此，AWS用了5个多小时才重新恢复正常服务。

从理论上说，7月16日发布的亚马逊DynamoDB可能有助于缓解该问题，原因是该版本含DynamoDB跨区域复制功能。其客户端解决方案使得AWS客户可以在不同的AWS地区内同时保存相同的DynamoDB表副本，而且是近乎实时的。使用该功能当然是要交钱的，但有了这个功能以后，你就可以利用跨区域复制功能备份DynamoDB表，或是可以对分布在不同地理位置上的数据进行低延迟访问。 

不管怎么说，此次事件表明，即便是全球最大的云服务提供商也会发生重大故障。有些业务要求绝对无中断，那么，在DynamoDB跨区域复制上花点钱则会是明智的一步。