存储

开端时，Picnik应用了一个开源项目，Mogilefs，用于文件存储。我们的年夜部门办事器都有几个余暇的驱动器插槽，我们在这些插槽上接入年夜容量的SATA驱动器，用于Mogilefs文件存储。年夜部门后台办事都是CPU密集型的，所以与这些I/O密集型的存储合营得相当好。这个策略工作得很好，但存储需求跨越CPU需求之后，就不可了，这时刻，Amazon的S3办事看起来似乎是我们扩大存储的最轻易也最廉价的办法。

在测试S3之前，我们现实上并没有对费用用做若干评估，一方面是其时并没有太多的云盘算可供选择，别的就是一些令人尊重的工程师也死力推举S3，最后，我们从来就没指望会年夜量应用。

因为开辟者的机械没有应用Mogile，所以已经有一个框架用于接口分歧的文件存储体系，如许一来，增长S3的支撑就相对轻易些。事实上，仅用了年夜约一天就实现了S3支撑，又测试了一两天，然后就将其打包到我们的每周例行宣布中了。这种实现的简略单纯性也是我们选择S3的另一个症结身分。

最初，我们筹划只将最早的文件迁徙到S3，这些文件是从2007年12月份开端的，因为这些文件拜访频率比拟低，不消怎么担忧机能和可用性方面的问题。这个模式异常棒，S3看起来机能也很好。

独一的不足，我们从Mogilefs中迁徙文件的速度不敷快，没有跟上文件增加的速度。并且Mogilefs也开端涌现一些机能问题了。我们的解决计划跟其他几家年夜型网站一样:将文件直接存储到S3。开端时，只将一小部门新文件直接存储到S3，然后逐渐增长，一向到绝年夜部门新文件都流向Amazon。如许，工作又搞定了，我们就转去解决其他问题了。

固然S3已经相当靠得住了，仍然涌现了一些值得留意的问题。我们碰到的第一个问题是最终一致性(eventualconsistency)问题，根本上，这意味着不克不及包管立刻读取刚写入的文件，在写入到西雅图的S3集群后，再试图从EC2中读，这个问问题会更严重。经由过程将所有的文件拜访都从我们在西雅图的数据中间署理而使这个问题有所缓和，但如许一来，我们的带宽就增长了。

我们碰到的第二个问题是Amazon?返回HTTP500毛病，我们的代码可以或许对不胜利的要求进行重试，这在年夜多半情形下工作优越。每一两周，我们都邑碰到毛病忽然爆发，以至于重试逻辑都不起感化了。这种爆发会连续一小时阁下。一天，我正在查看产生毛病的症结字(keys)，留意到这些症结字都有雷同的前缀!成果证实，S3是基于症结字的规模对数据进行分区的，这意味着保护(如增减某个分区容量)会导致某个规模内的症结字年夜量失足。Amazon如许做是为了坚持S3的高机能。对我们而言，这种突发性毛病更年夜水平上是种懊恼，因为我们还有Mogilefs在起感化，假如写到S3掉败，将其写到Mogile:就是了。跟着增加率趋于稳固，这个问题如今已经很少涌现了，但Mogile仍然在施展感化。

其实我们碰到的这些问题是构建年夜范围体系必定会产生的，所以Amazon也用不着掩盖什么。人们很轻易忘却，这其实是一个有着许多用户的范围伟大的散布式体系。

跟着流量的增加，我们越来越依附于S3。如果S3宕失落了，一天的年夜部门时光里，我们的Mogl都无法处置宏大的要求。荣幸的是，S3年夜部门问题都不是产生在我我们网站的岑岭时光，所以Mogilev还可以或许敷衍。我也应当提到的是，Mogile在两种情形下会宕机几个小时，种情形是修正MYSQL的表构造，还有就是调试Mogilev的Perl代码。这种时刻，1009%的流量都邑压到S3上，而我们的用户则从来不知道产生了什么。

“无穷”存储的一个危险是很轻易造成糟蹋。对我们来说，我并没怎么留意删除无用文件的后台功课业，对于创立的文件，最终会删除失落近75%，而无用文件增加起来是很快的。

即使我们曾经留意到了这个问题，我们事实上照样决议疏忽它。Picnik的每一小我都很忙，并且这看起来也不是什么年夜不了的问题，再说了，还有更棒的新功效或其他的伸缩性问题须要我们去存眷。有趣的是，S3让我们选择或者招聘和练习更多的人，或者更简略，写张支票就行了。在我们的信誉卡月度额度快用光的时刻，一切都变了。

经由几个月的调剂、剖析和重写代码，我们最后拿出了一份清算无用文件的可伸缩计划。起首是数据库对无用文件记载进行清算，然后在数据库的文件记载和S3上的症结字列表之间做一个年夜型的衔接操作(a largemerge-join)，以履行现实的删除。

在实现更好的清算体系的进程中央，我们开端意识到，S3对我们的工作负荷(workload)来说，现实上长短常昂贵的。先前的成天职析完整没有斟酌PUT操作的成本。许多S3的负荷中，存储成本占了年夜头，因为文件上载今后，在随后的一个很长时段内，只是偶然拜访下。正如前面所提到的，我们的负荷是创立年夜量文件，然后在随后的几天里就删失落了这意味着PUT操作的成本上升了。

意识到这点今后，我们开端尽力优化Mogilefsl的机能，而且研讨高机能的NAS产物。最后，我们实现了一个基于Linux的NFS概念体系作为前端存储，这意味着只须要在S3上存储跨越1周的年夜约25%的文件，这些留下来的文件也有了一个对S3来说加倍友爱的存取模式。

有很长一段时光，我们都不清晰S3是不是仍然适合。尽管更为传统的NAS硬件看起来贵了点，但假如你对历久存储需求有信念的话，可以在一年或两年内分期付款。而另一方面，很多创业公司的CFO(包含我们本身的)都邑告知你，为了坚持灵巧性和必定水平的自由，多花点儿钱也值得一一这种灵巧与自由就是S3供给的。当然，这种灵巧性比将此消费举动当作运维费用照样本钱费用更为主要。至于我们所关怀的，就只是运维费用了，因为这直接与流量和功效有关。

混杂盘算

Picnik重要的办事端组件之一是我们的衬着场(renderfarm)。用户在Picnik上保留图片时，经常须要在办事端重建这个图片。这时，客户端会向办事器发送一年夜段XML文本描写用户的编纂操作。Web办事器收到后，会将所须要的图片连同XML文本一路打包，并将其参加到衬着功课队列中。衬着办事器获取该功课，重建图片，然后将成果图片返回给Web办事器。此时，客户端处于壅塞状况，期待办事器的响应。年夜多半时光，客户只须要期待几秒钟。

固然这是可伸缩体系的典范架构，我们在设计时仍然斟酌到了将来对云盘算的需求。这时的衬着办事器不须要拜访任何内部办事，如数据库或存储办事器。简言之，它们异常合适于运行在EC2上，别的，我们已有了一个本身开辟的设置装备摆设治理和代码安排体系，称为Server manager。

像S3一样，现实实现起来既简略又快速。内部的衬着场已经斟酌到了运行在Xen之上的WM了，所以我须要做的就是一些简略修正，使衬着办事器的VM映像合适于EC2的Xen找，然后将其打包为AMI。在映像启启动时，起首衔接Server manager?获取须要安装和运行的组件列表，个中之一是Renderserver，Renderserver用于衔接衬着队列以获取衬着功课。我要做的第一件事就是激活两个实例运行一下看看怎么样一一棒极了!

第二阶段就是去实现云操作的最终目的(lolyGrail)了:主动伸缩(auto-scaling)。我们的主动伸缩实现起来照样很轻易的，因为所有处置都是经由过程队列实现的。因为用户在期待衬着成果，所以主动伸缩代码的目的是保护一个空队列5。每分钟都邑叫醒Server manager的一个线程，轮询队列的统计信息(上一分钟已做过均衡)，然落后行盘算，看为了保持闲者和忙者的比例须要做些什么。当然，因为流量和收集延迟会有小幅波动，为避免不需要的振荡而对闲忙比例的修改会涌现迟滞现象，如EC2实例有的时刻须要几分钟能力启动，我们的代码也斟酌到了这些问题。所有这些经验性的调剂阅历了一两周的时光，体系运行起来今后，就异常简略啦。

主动伸缩并不仅仅是典范的容量需求问题，我们也碰到了诸如到EC2的收集延迟加年夜了，或宣布了一个代码修改而使得衬着速度变慢了。碰到这些情形时，我们先停滞主动伸缩，直到找出背后真正的原因并加以纠正为止。我们还修改了一个毛病，这个毛病使一小部门用户的保留操作掉败，这一修改使衬着负载増加了20%正好在圣诞节之前。

这种设置也很合适批处置功课。一段时光以前，我们要重建一批缩略图，我就写了一些代码，将功课提交给衬着队列，然后用新的缩略图文件更新数据库记载。我不须要做任何特殊的工作来分派空间或将功课设置在晚上负载较轻的时刻处置，Server manager只是增长新的实例以顺应新的负载需求。

从财政方面来说，应用EC2比应用S3更清晰。我们试图扩建内部衬着以知足平均的容量需求，同时，将做衬着的CPU转换到做Web办事的CPU也轻易。这意味着将云作为衬着办事器给Web办事器带来了一些动态特征，这让我们易于顺应负载模式的变更，并且，经由过程逐渐购置硬件的方法，这也让我们更有用地应用现有的硬件。例如，可以在数据中间订购个新的机柜，然后把办事器上架，而不消担忧糟蹋年夜部门的机柜电力。

一般与EC2有关的问题重要集中在衔接性上。固然互联网作为一个整体是靠得住的，但任何两点之间的衔接却并非如斯。平日，假如问题涌现在收集和数据中间之间，只有一小部门用户受影响，然则，假如收集正好是云盘算供给者，则所有效户都邑受影响。这种类型的宕机可能异常严重，因为问题可能出在如许的区域，就是岂论是你照样云盘算供给者都没有为之付费，即双不管的区域。

在产生严重问题时(并且是在忙碌时段)，独一的选择就是甩失落负载。曩昔，我们只有种方法掌握让若干用户进来，如今我们按优先级将用户分类(旅客、免费用户、合作伙伴、金牌用户)。可情的是，年夜多半情形下，你不得不期待宕机恢复。岂论哪种情形，我们做的第一件工作就是更新Twitter信息(fecd)，这些新闻也显示在我们的It'srainingonourPicnik”页面上。我们并不责备任何人一个用户才不关怀这些呢。

我们并不像对内部办事器那样监控EC2实例。Nagiosi经由过程Servermanager主动获取EC2实例的信息，Nagiost也监控队列深度，因为这是许多问题的预警器(earlyindicator)。

Caci以图示方法显示运行实例数(经由过程EC2API)及集群层层面上的机能数据。我们不须要在Cacti上增长单个实例的信息，因为它并不现实处置集群，况且实例照样动态变更的。

事实上，我们并不关怀单个实例的机能，已经知道这些实例比当地机械上的要慢一点。没紧要的，因为主动伸缩体系总能在现有资本的前提下找到均衡。

因为实例是从队列中获取功课的，EC2实例稍微慢一点，只是少干点活儿罢了，不会躺倒不干。这使我可以或许集中精神存眷高层的机能数据，如一天中应用EC2实例的比例是若干。在一天停止时，只须要针对web办事器做容量计划，从而决议硬件购置决议计划，而衬着办事器只是从未应用的容量中获益。

要想有用应用网站扶植云盘算资本，须要对运用架构和设置装备摆设治理/主动化有一个合理的“增加”立场。我们将衬着办事器设计为可分化的，以及我们手边已经具备设置装备摆设治理体系等，这些事实使得主动伸缩实现起来既轻易又靠得住。