服务依赖惹的祸:亚马逊云计算又双叒叕宕机了,一半互联网中断 -The Verge


Amazon Web Services(AWS)是Amazon的互联网基础设施服务,它是许多网站和应用程序的骨干,已经经历了数小时的中断,这影响了很大一部分Internet。亚马逊表示,截至周三美国东部时间下午5:25,全面恢复可能还需要几个小时。
许多应用程序,服务和网站已在Twitter上发布了有关AWS中断如何影响它们的信息,包括1PasswordAcornsAdobe SparkAnchorAutodeskCapital GazetteCoinbaseDataCampGetaroundGlassdoorFlickriRobotPhiladelphia询问者PocketRadioLabRokuRSS播客坦帕湾时报Vonage华盛顿邮报WNYCDowndetector.com全天在用户报告中指出许多Amazon服务存在问题。
 
AWS已发布11月25日事件的事后报告。从那里的信息中,我们了解到一些内部服务依赖关系,这些依赖关系导致了跨服务失败的级联:
https://aws.amazon.com/cn/message/11201/
我们想为您提供有关2020年11月25日在北弗吉尼亚(US-EAST-1)地区发生的服务中断的其他信息。
Amazon Kinesis可以实时处理流数据。除了由客户直接使用之外,Kinesis还被其他几种AWS服务使用。这些服务在活动期间也产生了影响。尽管不是根本原因,但触发的原因是容量的相对较小的增加,该容量在太平洋标准时间下午2:44开始添加到服务中,并在太平洋标准时间下午3:47完成。Kinesis具有大量处理流的“后端”细胞簇。这些是Kinesis的主要功能,可为流处理提供分发,访问和可伸缩性。流通过“前端”服务器机群拥有的分片机制分布在后端。后端群集拥有许多分片,并提供一致的缩放单位和故障隔离。前端的工作很小但是很重要。它处理身份验证,限制。
太平洋标准时间(PST)凌晨5:15,第一个警报开始发出有关放置和获取Kinesis记录的错误的信息。团队参与并开始审查日志。尽管怀疑是新容量,但存在许多与新容量无关的错误,即使删除了该容量,这些错误也可能会持续存在。尽管如此,作为预防措施,我们在研究其他错误的同时开始删除新容量。由于观察到的各种错误,诊断工作变慢了。我们发现前端机队的现有成员和新成员在进行各种调用时在各个方面均存在错误,从而加剧了我们从根本原因中分离副作用的能力。太平洋标准时间上午7:51,我们已将根本原因缩小为几个候选对象,并确定问题的任何最可能根源都需要完全重启前端机队,Kinesis团队知道这将是一个漫长而谨慎的过程。
太平洋标准时间上午9:39,我们能够确定根本原因,事实证明这并不是由内存压力引起的。而是,新容量导致了舰队中的所有服务器超过了操作系统配置所允许的最大线程数。
对于Kinesis,在短期内,我们将转移到更大的CPU和内存服务器,以减少服务器的总数,从而减少每台服务器在整个机群之间进行通信所需的线程。
有许多使用Kinesis的服务也受到了影响。Amazon Cognito使用Kinesis Data Streams收集和分析API访问模式。
从PST 5:15 AM开始,CloudWatch Events和EventBridge遇到了API错误增加和事件处理延迟的问题。随着Kinesis可用性的提高,EventBridge开始提供新事件并缓慢处理较旧事件的积压。Elastic Container Service(ECS)和Elastic Kubernetes Service(EKS)都使用EventBridge来驱动用于管理客户集群和任务的内部工作流程。这影响了新集群的置备,现有集群的延迟扩展以及任务取消置备。
最后,对于此次事件对客户造成的影响,我们深表歉意。尽管我们为我们在Amazon Kinesis方面的长期可用性感到自豪,但我们知道此服务以及其他受影响的AWS服务对于我们的客户,他们的应用程序和最终用户以及他们的业务有多么重要。我们将竭尽所能,从这次活动中学习并使用它来进一步提高可用性。