Amazon S3 故障：服务水平协议能带来信任吗？

Amazon Web Services（AWS）中的简单存储服务（Simple Storage Service， S3 ）是一个被很多热门网站使用的云存储平台，其中包括 Twitter 、 G.ho.st 和 37signals 的 Basecamp 。最近 S3 经历了一次严重的故障。故障发生在 S3 分处不同地理位置的三个据点中的一个，持续时间超过两小时。

在 AWS 开发者讨论版上，有些人开始因这次故障而提出 AWS 是否可靠的问题：

S3 服务很出色，但这次事件证明了我们不能依赖它。这次是个大问题，尤其是因为服务停顿了这么长时间。

很快就有人指出 S3 的可靠性一直以来都保持着良好的记录：

在我加入服务的将近一年时间里，这是我经历的第一次故障。

InfoQ 采访了很多 S3 的长期用户，发现他们对于 S3 的可靠性的印象是一致的。在过去的一年里，只出过一两次小毛病，持续时间不过2 分钟。

Amazon 提供了一种 S3 的服务水平协议（Service Level Agreement，SLA），保证“每月 99.9% 的正常运行时间”。Amazon 从去年 10 月开始提供 SLA，而 S3 是 AWS 总共 11 项服务中目前唯一提供 SLA 的。Amazon 的 SLA 对于云存储方案有什么样的意义？

可能意义并不大。S3 SLA 保证一个月里所有以 5 分钟为单位的时间片中，平均有 99.9% 是可用的。SLA 容许的最遭情况等于每月有 40 分钟不可用。这种可靠程度比起金融应用或者医疗设备的要求还差了好几个数量级。不过在半个小时里收不到 Twits 对于大多数人来说只是不足挂齿的小麻烦。

如果达不到 SLA 的承诺，Amazon 会提供服务补偿，但对于收益和声誉全都系于互联网的用户来说，Amazon 的补偿只是聊胜于无。如果达不到 99.9% 的服务水平，那么 Amazon 将减免下个月 10% 的费用。如果可用性下降到 99.0% 以下，换算后相当于一个月内至少有将近 7 个小时无法服务，那么 Amazon 将减免 25% 的费用。为了看得更清楚一点，我们来举个例子。假设一个用户存放了 500G 的数据。把 500G 数据放进 S3 并且在一个月内全部数据都使用 10 次的话，总共的费用大约是 $1000。如果发生 5 小时的故障，那么该用户将得到 $100 的退款。如果故障时间从 7 个小时到一整个月的话，该用户将得到 $250 的补偿。

对于大多数需要利用云计算资源的应用来说，SLA 提供的保障没多大意义。对于决心舍弃其他服务采用 S3 的人来说，Amazon 的声誉和它一直以来的可靠记录比 SLA 更重要。

SLA 的鸡肋性质可能正好说明了为什么 SaaS 计算的金牌代表 Salesforce.com 不提供 SLA。Salesforce 在“ trust.salesforce.com ”网站上提供关于服务健康状况的有意义的实时信息，通过这样来建立起对他们的服务的信任。Salesforce.com 的健康监控网站也是在一次类似的故障之后才建立的。服务提供商如何处理事故也会对满意度产生重大影响，因为人们都知道即使是最完美的系统也避免不了故障。比如Technorati 处理博客数据混乱事件时的做法就受到了表扬。

Amazon 从这次事件吸取了教训。这次故障表现出了 Amazon 的技术服务团队的高效率，大多数客户都认为他们是合格的，但同时也揭露出了他们在系统健康状况信息的沟通上存在严重缺陷。

InfoQ 就这次故障采访了 Amazon 的发言人。Amazon 看起来已经对问题所在有了头绪，而且已经尽早采取了改正措施。

在其中一个据点，我们开始观察到来自多个用户的身份验证请求在上升。虽然我们小心地监控了总请求量，观察到总请求量仍然处在正常范围内，但我们没有注意到身份验证请求所占的比例。这点很重要，因为这些加密请求比其他类型的请求消耗更多的资源。在很短的时间内，我们开始发现其他用户的身份验证请求数量也在显著增长。最后我们还没来得及增加新的服务能力，身份验证服务就被推到了极限。除了处理身份验证请求，Amazon S3 处理的每一个请求都要经过身份验证服务进行帐号验证。因此导致了那个据点的 Amazon S3 没法处理任何请求。

另一方面，有些用户对故障期间缺乏沟通感到很失望。 Viewbook.com 的拥有者 Rien Swagerman 告诉 InfoQ：

我觉得很惊讶……在发生这种事情的时候 Amazon 只给出了很少一点信息。你不得不在论坛里费力发掘才能了解一点状况，而论坛在故障期间又挂掉了没法发贴。

Amazon 的发言人告诉我们 Amazon.com 以及他们的开发者讨论版也一样受到了故障的影响。Amazon 身体力行使用自己的产品，一般来说是件好事，不过云计算可能会颠覆这种思维。

为了平息顾客在沟通水平方面的抱怨，Amazon 希望“很快”推出一个服务水平报告工具。云计算和 SaaS 技术仍然在发展之中，S3 故障显然只是成长中的阵痛。 FocusFriends.net 的 Ivo Beckers 说：

还没有别的厂商能以这样的价格提供这种质量的服务。实际上，我很高兴发生了这件事……它会刺激 Amazon 提供更好的服务。

Amazon 在萌芽中的云计算市场上确实正受到挑战。年初的时候 EMC 启动了 EMC Fortress 服务，这是他们利用对 Mozy 的收购而发展出的一个针对备份的 SaaS 存储平台。最近 EMC 又宣布雇佣微软的前任高管Paul Maritz 来领导一个新的云设施和存储部门。EMC 很可能把目标指向比Amazon 更高端的市场，在价格/ 可靠性上提供更灵活的选择。

架构师怎样才能在保持低成本的同时提高可用性呢？在Amazon 开发者讨论版上，很多人都在为自己的网站的可靠性完全依赖于S3 而感到悲哀。另外一些用户受到的影响较小，因为他们虽然用S3 来存储记录，但在本地保留了一个缓存副本。InfoQ 也用S3 来存储视频，不过在一个EC2 实例上保留了本地缓存，因此InfoQ.com 没有受到这次故障的影响。除了能提高可用性，本地缓存还降低了费用，因为直接从S3 传输的数据量减少了。

你在用S3 吗？你用什么办法来保证可用性呢？

查看英文原文： Amazon S3 Outage : Do SLAs Lead to Trust?