网站甚么处所适合云计较(以及为甚么!)

存储
起头时，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已经至关靠得住了，依然泛起了一些值得注重的问题。咱们遇到的第一个问题是最终一致性(eventual consistency)问题，根本上，这象征着不克不及包管当即读取刚写入的文件，在写入到西雅图的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 large merge-join)，以执行理论的删除。
在实现更好的清算零碎的过程当中央，咱们起头意想到，s3对咱们的事情负荷(workload)来讲，理论上是十分高贵的。先前的整天职析彻底没有思索put操纵的本钱。不少s3的负荷中，存储本钱占了大头，由于文件上载以后，在随后的一个很永劫段内，只是偶然访问下。正如前面所提到的，咱们的负荷是创立大量文件，而后在随后的几天里就删掉了这象征着put操纵的本钱回升了。
意想到这点以后，咱们起头勤奋优化mogilefsl的机能，而且研讨高机能的nas商品。末了，咱们实现了一个基于linux的nfs观点零碎作为前端存储，这象征着只需求在s3上存储跨越1周的约莫25%的文件，这些留下来的文件也有了一个对s3来讲愈加友爱的存取形式。
有很长一段时间，咱们都不分明s3是否是依然适宜。虽然更为传统的nas硬件看起来贵了点，但如果是你对恒久存储需求有决心信念的话，可以在一年或两年内分期付款。而另外一方面，许多创业公司的cfo(包括咱们本身的)城市通知你，为了连结灵活性和一定水平的自由，多花点儿钱也值得逐个这类灵活与自由就是s3提供的。当然，这类灵活性比将此破费举动当作运维价格仍是资源价格更为首要。至于咱们所关怀的，就只是运维价格了，由于这直接与流量和功用有关。
混淆计较
picnik主要的服务端组件之一是咱们的衬着场(render farm)。用户在picnik上保留图片时，常常需求在服务端重修这个图片。这时候，客户端会向服务器发送一大段xml文本形容用户的编纂操纵。web服务器收到后，会将所需求的图片连同xml文本一块儿打包，并将其插手到衬着功课队列中。衬着服务器获取该功课，重修图片，而后将后果图片返回给web服务器。此时，客户端处于梗阻状况，等候服务器的相应。大大都时间，客户只需求等候几秒钟。
虽然这是可伸缩零碎的典型架构，咱们在设计时依然思索到了将来对云计较的需求。这时候的衬着服务器不需求访问任何内部服务，如数据库或存储服务器。简言之，它们十分适合于运转在ec2上，另外，咱们已有了一个本身开发的设置管理和代码部署零碎，称为server manager。
像s3同样，理论实现起来既简略又疾速。内部的衬着场已经思索到了运转在xen之上的wm了，以是我需求做的就是一些简略修改，使衬着服务器的vm映像适合于ec2的xen找，而后将其打包为ami。在映像启启动时，起首连贯server manager?获取需求装置和运转的组件列表，此中之一是renderserver，renderserver用于连贯衬着队列以获取衬着功课。我要做的第一件事就是激活两个实例运转一下看看怎么样逐个棒极了!
只知其一，不知其二阶段就是去实现云操纵的最终方针(loly grail)了:自动伸缩(auto-scaling)。咱们的自动伸缩实现起来仍是很容易的，由于一切处置都是经由过程队列实现的。由于用户在等候衬着后果，以是自动伸缩代码的方针是维护一个空队列5。每分钟城市叫醒server manager的一个线程，轮询队列的统计信息(上一分钟已做过均衡)，而落后行计较，看为了维持闲者和忙者的比例需求做些甚么。当然，由于流量和网络延迟会有小幅颠簸，为制止不须要的振荡而对闲忙比例的修正会泛起迟滞景象，如ec2实例有的时辰需求几分钟才气启动，咱们的代码也思索到了这些问题。一切这些教训性的调整阅历了一两周的时间，零碎运转起来以后，就十分简略啦。
自动伸缩其实不只仅是典型的容量需求问题，咱们也遇到了诸如到ec2的网络延迟加大了，或发布了一个代码修正而使得衬着速率变慢了。遇到这些情况时，咱们先遏制自动伸缩，直到找出暗地里真实的起因并加以改过为止。咱们还修正了一个毛病，这个毛病使一小部分用户的保留操纵失败，这一修正使衬着负载増加了20%正幸亏圣诞节之前。

这类设置也很适合批处置功课。一段时间之前，咱们要重修一批缩略图，我就写了一些代码，将功课提交给衬着队列，而后用新的缩略图文件更新数据库记载。我不需求做任何特此外事情来分配空间或将功课设置在晚上负载较轻的时辰处置，server manager只是添加新的实例以顺应新的负载需求。
从财政方面来讲，运用ec2比运用s3更分明。咱们试图扩建内部衬着以知足均匀的容量需求，同时，将做衬着的cpu转换到做web服务的cpu也容易。这象征着将云作为衬着服务器给web服务器带来了一些动态特点，这让咱们易于顺应负载形式的变革，而且，经由过程逐渐购置硬件的体式格局，这也让咱们更有用地运用现有的硬件。比方，可以在数据中心订购个新的机柜，而后把服务器上架，而不消担忧挥霍大部分的机柜电力。
普通与ec2有关的问题主要集中在连贯性上。虽然互联网作为一个总体是靠得住的，但任何两点之间的连贯却并不是云云。常规，若是问题泛起在网络和数据中心之间，只要一小部分用户受影响，可是，假设网络刚好是云计较提供者，则一切用户城市受影响。这品种型的宕机能够十分严重，由于问题能够出在如许的区域，就是不论是你仍是云计较提供者都没有为之付费，即双不管的区域。
在产生严重问题时(而且是在忙碌时段)，独一的选择就是甩掉负载。已往，咱们只要种法子控制让几个用户进来，此刻咱们按优先级将用户分类(旅客、免价格户、搭档、金牌用户)。可情的是，大大都情况下，你不克不及不等候宕机恢复。不管哪一种情况，咱们做的第一件事情就是更新 twitter信息(fecd)，这些消息也显示在咱们的it's raining onour picnik”页面上。咱们其实不指义务何人一个用户才不关怀这些呢。
咱们其实不像对内部服务器那样监控ec2实例。nagiosi经由过程 servermanager自动获取ec2实例的信息，nagiost也监控队列深度，由于这是不少问题的预警器(early indicator)。
caci以图示体式格局显示运转实例数(经由过程ec2api)及集群层层面上的机能数据。咱们不需求在 cacti上添加单个实例的信息，由于它其实不理论处置集群，况且实例仍是动态变革的。
事实上，咱们其实不关怀单个实例的机能，已经知道这些实例比当地机械上的要慢一点。不要紧的，由于自动伸缩零碎总能在现有的前提下找到均衡。
由于实例是从队列中获取功课的，ec2实例略微慢一点，只是少干点活儿罢了，不会躺倒不干。这使我能够集中精神存眷高层的机能数据，如一天中运用ec2实例的比例是几个。在一天完毕时，只需求针对web服务器做容量布局，从而决议硬件购置决议计划，而衬着服务器只是从未运用的容量中获益。
要想有用运用网站制作云计较，需求对应用架构和设置管理/自动化有一个合理的“增进”立场。咱们将衬着服务器设计为可分解的，以及咱们手边已经具有设置管理零碎等，这些事实使得自动伸缩实现起来既容易又靠得住。