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

www.net130.com     日期:2015-9-25    浏览次数:
出处:至顶网

对于亚马逊而言,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跨区域复制上花点钱则会是明智的一步。

分享道
相关新闻