Amazon Web Service 服务稳定状况受到质疑,9 月 13 日美国东一区服务宕机

  • Chris Swan
  • 邵思华

2013 年 9 月 23 日

话题:AWSDevOps

在 9 月 13 日周五早晨,Amazon Web Service(AWS)在美国东一区的服务再次出现宕机,由于这一地区是整个 Amazon 最大、时间最长久并且业务最繁忙的地区,这次宕机使包括 Heroku、Github 和 CMSWire 在内的一大批主流应用服务中断,还影响到了其它许多 Amazon 的客户。

就在最近这次宕机事件发生数日前,关注云端服务的评论者 Ben Kepes 还撰文写道:“每次 AWS 的宕机事件,看起来都是由于东区导致了服务故障。”Kepes 还引用了分析师 René Büst 的一段文字,其中将美国东一区的服务描述为“陈旧、廉价并且脆弱的”。

Amazon 目前还没有提供详细的故障报告,但上周五的问题已经基本可以归结为网络故障。在2011 年 4 月的一次故障也是与网络问题相关,但在2012 年 12 月2012 年 10 月发生的最近两次故障都是由弹性负载均衡(Elastic Load Balancer – ELB)和弹性块存储(Elastic Block Storage - EBS)服务出现问题而导致的。网络与 EBS 的故障危害性尤其巨大,因为它们会导致多个可用性区域(Availability Zone)(本应作为故障边界)产生故障,或者使提供容错能力的更高级别服务(例如 ELB)中断。

一般来说,应用程序的提供者只会使用传统的架构方式,而不会为了云端服务以及它固有的不稳定性进行针对性的设计,许多应用程序都不会考虑在一个或多个地区(region)中使用多个可用性区域。但即使针对这些故障进行专门设计,也不见得一定能避免问题的发生。Netflex 使用的那套被戏称为“猿猴军团”和“混沌猴子”的工具一直被遵为云端设计的典范。他们有意持续不断地为自己的平台产生各种错误,并以此证明整个平台良好的自我修复能力,但有些时候(如平安夜宕机事件)这个平台还是不能提供能够承受来自四面八方的负载的能力,使得某些客户所使用到的服务质量下降。

东一区连续不断的宕机,以及那些本应力挽狂澜的服务(例如 ELB)的无所作为,为 Amazon 在“基础架构即服务”(Infrastructure as a service)这一市场上的竞争对手带来了机会。Google 近期就为 Google 计算引擎发布了它自己的负载均衡服务,并且提供了一份关于设计健壮的系统的良好提议

查看英文原文:Amazon Web Services Stability and the September 13th US East 1 Outage

AWSDevOps