看Pinterest如何通过架构变化将EC2成本降低了62%

　　北美，喜欢讲述成功故事，也喜欢分享这些创业神话。

　　**让人兴奋的是，如Pinterest、Instagram、Quora一样，拥有巨大增长、大量用户、大量数据、极少员工、成本控制严格、风投青睐，基于AWS等公有云上的创新型企业(不是单纯技术创新型，而是应用创新)在技术实践方面的经验分享。

　　自2010年3月上线以来，Pinterest从未远离人们视线(透视Pinterest——浅析视觉化社交网站的发展瓶颈)。每个季度的访问/用户数字总是令人咋舌。而其创意故事，也被亚马逊搬上了AWS re:Invent会议。鲜为人知的是，Pinterest喜欢将他们的业务和后台架构做关联，并与诸多创新型企业分享经验(highscalability和techworld都曾有对其技术部门进行了采访)。一周以前，2013年的钟声刚刚敲响，highscalability所发表的《Pinterest Cut Costs From $54 To $20 Per Hour By Automatically Shutting Down Systems》文章在Hacknews引发讨论热潮。Pinterest工程师Ryan Park现身回答许多问题，其所代表的公有云中创新企业技术实践引人思考。

　　为此，特别从数篇highscalability对于Pinterest的关注文章中抽丝拨茧，分析出其在面对**增长的业务需求时，如何进行的架构变迁，**终实现将EC2从54美元/小时降到20美元/小时的“秘密”。

　　300万用户，Pinterest架构简洁易懂

　　2012年2月，Pinterest用户是300万，其联合创始人Paul Sciarra在Quora上分享了一些简短的堆栈信息，从中不难看出Pinterest架构很是简洁易懂。

　　Python+应用程序层重大修改Django

　　web-server中Tornado与(有选择性的)node.js

　　Memcached与membase / redis用于object-与logical-caching

　　RabbitMQ消息队列

　　Nginx, HAproxy和Varnish实现静态交付于负载均衡

　　MySQL实现持久数据存储

　　MrJob on EMR用于MapReduce

　　Git

　　

 

　　这张图更为简洁地展现了当时的Pinterest是面对300万用户时是如何设置架构的。

　　1800万访客，Pinterest在低峰时间关闭部分实例

　　2012年4月，新的数字诞生了。1800万访客，12名员工，410TB数据。这是TechWorld对Pinterest系统工程师Ryan Park的采访中所提到的数字。而与之相对应的是，之前的系统已经无法满足业务**扩展的需要，Pinterest对其架构进行了必要的更新。

　　5月21日，highscalability上刊登了文章《Pinterest Architecture Update》总结了其**架构层面的变化。

　　具体来看，有以下11个方面：

　　8000万对象被存储在S3中，共计410TB的数据存储量。这是去年8月份数据的10倍。EC2实例也已增长了近3倍。总计费用大约为：39000美元/S3，3000美元/EC2;

　　在2011年底，Pinterest大约12名员工，而今，大约有31名(人数还是很少);

　　下午和晚上显然访问量会急剧下滑，所以他们在夜间减少了40%实例的应用。高峰时，EC2上要花费52美元/小时，晚上及其他非高峰时间，仅该项可减少到15美元/小时;

　　Web层用了150 EC2实例;

　　90个实例用于内存缓存，移除/减少数据库负载;

　　35个实例用于内部运行;

　　70个主数据库分布在全球不同区域，以实现数据库的并行备份，实现系统冗余;

　　用Python和Django来写的;

　　使用分片功能，当数据库可用性能达到50%之后会被分割，用以满足增长及I/O需求;

　　ELB被用作实现实例间的复杂均衡服务，ELB API使得实例的移动更容易实现;

　　用于数据分析的，基于Hadoop的Elastic Map Reduce(Amazon EMR)每月支出在几百美元;

　　

 

　　其他一些细节

　　而借助AWS，Pinterest只通过很少的IT基础设施就成功承受了1800万访客(5月份)的访问。

　　更多时，Pinterest设置自动扩展服务降低成本

　　在2012年11月举行的AWS re:Invent会议上，已经升任Pinterest技术负责人的Ryan Park讲述了企业**的改革：设置自动扩展服务降低成本;

　　20%系统被关闭在应对高峰负荷后;

　　正常状态下使用预留实例;

　　不间断的使用on-demand实例和现有Spot实例处理弹性负载。当自动扩展服务需要更多的服务器时，会同时打开on-demand实例和Spot实例请求。大部分的服务都使用一半的on-demand实例和一半的Spot实例。

　　监视进程频繁的检查运行状态，更多实例确保在需要的时候启动，在不需要时终止。如果Spot实例价格较高的话则会被关闭，同时启动按需实例来代替;一旦Spot实例价格回落则会被买入。

　　通过这样的系统改造和很少的维护(2周左右的时间)，目前Pinterest的成本已经从之前54美元/小时降到20美元/小时(EC2)，成本节省非常可观。

　　当这条新闻在1月2日在Hacknews上发表时，引发了热烈的讨论。Ryan Park也现身讨论之中，其中有些观点颇具参考价值。

　　2013，或将实现数据库的自动扩展

　　

 

　　问：是否可以实现数据库扩展的问题?

　　Ryan Park：自动扩展服务(auto-scaling)是特别为一批Web应用服务器(大约80台)而设置的服务。过去几个月中，我们一直根据业务服务需求而扩容架构，已经实现用相同的代码自动扩展内部服务的需求。当然，其不能自动扩展数据库服务器，不过即使这样，也为我们节省了大量成本。(在Ryan Park补充说明中，auto-scaling在全年中都有所应用，越用越能大幅降低成本)。也有其他用户在后面爆料说，他们在2013年将和Netflix一起在实践了基于Cassandra扩展的概念验证工作。

　　问：为什么不考虑如同colo这样的云服务提供商，即使增加一些全职员工来负责维护，成本也要比AWS要低?

　　Ryan Park：Pinterest增长如此迅速，几乎没有办法依靠自身系统来满足。除此以外，Pinterest的团队成员一直很少，不过现在成员有所增加，也许可以考虑如同colo或者其他云服务提供商。确实，在对比colo list和on-demand实例之后，AWS的费用确实比较贵。但我们可以通过auto-scaling来调整on-demand实例和Spot实例的比例，进而实现成本的降低。

　　留在**后的思考：

　　对于很多公有云中的创新企业而言，很早以前就已经被提出的自适应架构是否更为合适?另一方面，管理在云中所积累的大数据，旧有技术手段无法满足需求，这也给如Pinterest和Netfix这样的，“轻”技术创新企业更多技术创新的机会。由此而来的实践经验，比如日前Netflix清理AWS的开源工具Janitor Monkey等，可供所有云上创业的企业使用。或者，这也是AWS在IaaS市场一支独秀的根本原因?(编译/郭雪梅 审核/仲浩)

　　本文为CSDN原创文章，未经允许不得转载。如需转载请联系market@csdn.net。

　　(责任编辑：leonlee07)