来自SlideShare的教训 - 使用云计算的惨剧和怎么避免其发生

本文翻译自一篇GIGAOM的文章，原帖地址，作者为Jonathan Boutelle，他是著名站点SlideShare的CTO和创始人之一。

对初创公司而言，云计算可谓是利器，因为只要通过鼠标点击就能一下子拥有几乎无限的计算能力，而且通过这些计算能力能够很好地开创新的机遇。通过鼠标点击就能一下子启动或者关闭上千台服务器是一个非常强大的能力，但就好象漫画书所教我们的那样“great power comes great responsibility（能力越大，责任越大）”。

我公司Slideshare在我们几乎所有的事情中都使用到了云计算，这也导致，我们在使用云计算方面也出现一些大错，下面是两个最明显的例子：

在没有试用之前就浪费了五千美元

几个月前，我们开始非常着迷于Hadoop，我们甚至在办公室中组织了一个Hadoop黑客日（Hackday），并非常迅速地编写一些Hadoop原型代码来对SlideShare用户的数据进行分析，

Hadoop分析本身是一个极为适合云计算的任务。虽然你需要一大堆电脑，但却仅需一天就能把所有的数据都给处理了。但当我们开始使用越来越多和越来越真实数据集来测试我们的原型代码时，它开始花费越来越多的时间来完成一个任务。

在那个时刻，我决定将机器的数目翻四倍（从20台升至75台）。这个决定是非常有意义的，如果一个任务需要100个计算时才能完成，那么100台机器就只需1个小时就能将这个任务快速地完成。

在我做这个决定的几小时后，一次大型站点事故引起所有工程团队人员的注意，为了解决处理这个事故和其它相关的事故，我们连续工作一个晚上和一个整天，最终直到周五的下午才全部搞定。在我们心安理得享受了一个周末之后，周一上班的时候我们发现在事故之前运行的Hadoop分析任务还在继续运行着。我们包含Bug的代码以一种我们没有预想到的方式失败了，以至于在这个问题上就算加入再多的硬件也解决不了这个问题，同时，我们收到了一张来自Amazon Web Service的五千美元的账单。

我们的教训是：如果你真正想使用云计算的力量，那么你需要不停地观测支出，并且确保它没有出现乱来的情况或者超出预算，特别当你快速地伸展和缩小使用云计算的规模时。不巧的是，Amazon Web Service并没有提供任何提醒或者图表工具来帮助用户简单地跟踪支出，虽然跟踪支出是一个牵涉到下载CSV文件，将它们导入Excel并进行分析的繁琐流程，但它却是不可或缺的。

使用云存储的麻烦

我们最近发现我们在存储（S3）方面的开支急剧地增大，经过多天的调查，发现我们在使用存储方面没有明确的原则，比如，一些可以被删去的文件还保留着；不同类型的文件被放置在同一个目录；还有些文件我们根本不知道它们的来源和它们还是否需要。

Amazon S3，和其它类似的云存储，都可以被认为是一个大型的文件系统，它们不会对数据的位置进行任何控制，它由使用者来确保这个存储是否被有条理的使用。如果一个人写代码，这是很简单，但是让一个团队来写多个依赖云存储的程序时，是很容易忘记删除某些文件的。你需要确保你们没有浪费存储，唯一的方法是需要非常明确地定义那些数据存放在那些地方。一个最佳实践是将不同类型的资源放置在不同的”bucket（桶，S3的最高层的目录）“，这也是唯一地能让你得到每种类型数据的占有空间的方法。

蜘蛛侠的原则

在上面两个例子中，我们知道了我们并没有很严格地使用云计算的力量，如果让我们之前借用硬件的话，我们也会触及硬件的限制（比如，磁盘空间用完），这是一件麻烦的事情，但去逼迫我们总结一下过去的行为，来更合理地支出。拥有强大的云计算力量是一件好事，但是如果你要使用它，就要有一定的责任心。