分析豌豆荚从自建机房迁移至AWS云计算的发展案例
豌豆荚作为创新工场的首批孵化项目之一，从2009年12月发展至今，用户量已经增长至4.1亿。豌豆荚的主要业务在国内，帮助用户在手机上发现、获取和消费应用、游戏、视频、电子书、壁纸等娱乐内容，在东南亚地区等海外市场也做了类似的业务探索。
这样一个快速增长的系统，对IT的底层支持也是一个相当大的挑战。本文将介绍豌豆荚在IT基础架构、工具、流程方面做过的一些事，在不同需求之间如何平衡，团队职责的划分，以及遇到的一些挑战。
挑战
豌豆荚创立初期国内还没有可靠的公有云服务，所以从2010年开始，豌豆荚通过自购服务器的方式，伴随着豌豆荚在中国市场发展规模逐渐扩大，豌豆荚已经在国内建成了规模较大的数据中心。2014年豌豆荚开始国际化布局，但自建数据中心的方式却很难在国外复制。“不同国家的采购流程和管理政策都不一样，在一些东南亚国家，甚至基础网络提供商都千差万别，自建机房不仅速度缓慢而且无法控制进度。”豌豆荚工程生产力部门质量总监高磊表示，“而业务部门又对迅速提供IT资源支持有着非常紧迫的要求，最终我们发现只用采用云服务才能真正解决我们的问题。”
为什么使用AWS
在决定采用云服务后，豌豆荚便确定了使用AWS，“我们的工程师团队和运维人员对AWS比较熟悉，如果采用其他公有云产品势必需要一个适应和学习的过程，但我们使用AWS的学习成本很低，因此使用AWS可以说是顺理成章。”质量总监高磊说。
除了减少团队的学习成本，AWS服务与自身业务的高度契合也是促使豌豆荚决定采用AWS的重要原因。通过Amazon Elastic Compute Cloud (Amazon EC2)，豌豆荚提升了新产品在海外的发布速度，还可以根据实际使用量确定服务器计算资源，既提升了工作效率还显著降低了成本，而且由于Amazon EC2的高可用性架构，也大大提升了应用的稳定性和可用性。此外，豌豆荚还使用Amazon ElastiCache自动检测并调换运行不畅的缓存节点，降低了基础设备日常管理的费用，同时豌豆荚也使用Amazon ElasticCache集成的Amazon CloudWatch功能对设备进行监控，从而更加准确和清楚的了解与Redis等节点相关的性能指标，保证服务和产品稳定。
收益
如果豌豆荚采用传统自建数据中心的形式，保守估计每个机房需要3-4个月才能完成，而在AWS上只需要几分钟便可以完成一切基础设施的调试。更重要的一点，豌豆荚并没有因为开始拓展海外业务增加任何运维人员，并且与负责传统数据中心的人员投入相比，管理AWS日常运行所需要的人力几乎可以忽略不计。在固定资本投入上，使用AWS与自建数据中心相比较，也能有一定程度的节约。不仅如此，通过对AWS收费政策的理解不断加深，豌豆荚也发现了更多降低使用成本的方法。
豌豆荚与AWS的合作处于起步阶段，随着对AWS各项业务的了解不断加深，豌豆荚还将继续将更多业务迁移至AWS上。
基础设施的建设与增长
豌豆荚诞生于2009年12月，机房部署是从2010年年初开始。那时候因为还没有成熟的云服务可用，所以选择了自建机房的方案。到目前为止，豌豆荚已经在全国各地尤其是北京、天津地区建立了多个节点。
从对基础设施资源使用的情况来看，豌豆荚的主要业务对带宽和 CDN 资源用量会比较高；而从单一业务来看，各类数据挖掘和分析对服务器资源的占用是最大的。豌豆荚从创建一开始就是数据驱动的业务，有很强的用户行为导向，因此数据挖掘的工作量非常多。
数据挖掘主要是基于Hadoop集群。豌豆荚有一个数据挖掘团队专门做产品研发（主要是面向内部），而豌豆荚这个团队则提供硬件资源和底层的Hive、HBase等基础设施的支撑和维护。整体的数据量、计算量一直都在增长，一开始的几年增长极快，最近几年稍微慢一些，也有每年几倍的增长。
差不多在2011年左右，豌豆荚开始尝试做海外版的豌豆荚Snappea。当时评估过在海外自建机房的可行性，在考察过各个地方不同位置、不同IDC、不同运营商的选项之后，豌豆荚发现即使在进展顺利的情况下，也至少需要两三个月才能建成，这个时间成本太高。如果不自建，那就只有公有云这一个选择，正好当时豌豆荚很多工程师都自己用过亚马逊的AWS，出于时间、知识门槛、成本的考量，就决定在海外使用AWS作为豌豆荚的基础支撑。
团队
EP团队的目标很明确：在主要产品的完整生命周期内，实现一流的效率、质量和服务稳定性；至于具体用什么技术或者方法，则并不做限制。一开始豌豆荚团队比较关注流程、开发工具等方面，现在豌豆荚对CI、代码库、自动化测试、运维、基础设施建设等各个方面都做了很多工作，有时候工程师要引入一些新的基础设施相关的技术或框架，豌豆荚也会进行review它们是不是靠谱，总的目标就是让产品从开始开发到线上生产环境运行这整条路径下，其稳定性和质量都有所保证。
现在整个团队的全职工程师有不到三十人，其中运维团队有十个人，而且他们也都会承担开发任务（豌豆荚叫做SRE，网站可靠性工程师），运维过程中需要什么工具、支持系统，都是由他们自己开发。运维团队的主要工作都在维护豌豆荚自建的机房系统上，AWS上面现在平均投入的维护人力差不多只有三分之一个人。这一方面是因为AWS的维护成本确实低，另一方面也是因为豌豆荚在AWS上面的规模还不是太大。
从代码库到生产环境
豌豆荚的产品发布流程还是相对成形的。不同的产品线有不同的发布频率，比较稳定的在一周两次，有些比较早期的项目可能一天一次，没有太大的压力。
产品下一个release要发布哪些feature、发布周期设置成多久间隔，主要是由产品经理和设计师来决定，工程师实现需求。到了发布日期截止之前，从代码库的主干拉一支发布分支出来做feature freeze和最后的验收测试，到发布分支上只能做bug修复，不再接受新的feature。
有的产品线有统一的测试机制，有的产品线则主要靠工程师自己做测试。无论是哪种测试模式，在进入CI做集成之前和之后都会统一进行静态检查和已有的单元测试用例，然后才上到staging环境。从staging环境开始就属于运维负责的领域了，豌豆荚的staging没有真实的流量，但是环境跟线上是一模一样的，可以说是一直处在最新版本的服务，然后staging再跟线上环境同步代码。
这一套自动发布、部署的流程虽然也不是很完善，比如持续集成的检查点还不够多，单元测试率还比较低，不过还算跑的不错。现在AWS上也是同样的一套部署过程，当时适配起来也很快，大概做了一个星期就跑上去了。
监控
豌豆荚的监控系统要实现的目的无非是两个：实时的报警，以及可以追溯的历史数据，其他都是衍生的功能。跟大部分互联网公司一样，豌豆荚一开始做监控也都是用开源软件搭起来的，不过开源的监控软件现在越来越不能满足豌豆荚的需求。
这里面有两个挑战：
性能问题
数据采集的定制化问题
数据采集的定制化主要是涉及到一些业务数据的采集，通用的开源软件也还是要做适配，需要自己去写实现，这个其实还好。性能问题是一个更加严重的问题，这个问题来自于三个方面：越来越多的机器、越来越多的采集项、越来越高的采集频率。
以前豌豆荚监控，可能5分钟抓一次数据就行；现在豌豆荚希望做到秒级的采集。监控系统需要有实时分析日志的能力，而到机器数量增长到千台以上之后，要做秒级的采集和分析，无论是数据收集的速度还是数据分析的速度都会遇到瓶颈。
所以现在豌豆荚正在自己重写一套监控的系统，专门针对豌豆荚自建的机房体系，包括对多机房架构的支持、与资产系统的对接等等。而AWS上豌豆荚直接使用了其CloudWatch监控功能，目前来讲完全够用了。
新的挑战
因为业务跟数据密切相关，而豌豆荚部门承担了给数据分析团队提供基础设施的责任。
业务对数据报告的需求一般有两类：
1、定制化的、定期的数据指标报告
此类报告有按天的、按周的、按月的或者按小时的，一般都是比较常规的监测指标，持续监控、持续分析，中间数据保留完整，需要的计算量和存储量容易预测。这种报告需求比较容易满足。
2、按需出报告
此类需求经常是针对之前没有中间数据的监测值，之前并不知道需要针对此类数值做分析，现在忽然发现需要了，业务部门会要求一次性分析过去半年到一年跟该数据相关的趋势。此类报告往往很耗时，有时候豌豆荚做估算，一年的数据分析完毕需要用多长时间，结果可能是用豌豆荚现在的计算资源，可能要分析一个月才能产出他想要的报告，但这是无法满足业务需求的。
要提高分析速度，最直接的做法就是投入更多的计算资源——放在豌豆荚自建的机房就是扩容，如果用公有云就是起更多的实例。一方面扩容是要做的，另一方面现在AWS进入国内，豌豆荚也在考察使用AWS来做这种任务的可能性。
实际上豌豆荚用了AWS以来，也逐渐发现豌豆荚之前系统设计的并不是那么好。比如豌豆荚在海外的数据分析，原本是想用EMR的，但是发现豌豆荚现在这套东西搬过去不好直接用，只好基于EC2来做这个事情。为什么呢？因为AWS的理念是让不同的组件做不同的事，比如EC2只做计算，数据持久化存储最好都放在S3；但是豌豆荚的系统一开始设计并没有考虑这些，数据都存在本地计算节点上，如果要重构，需要投入的时间还是挺多的。
包括scaling这件事也是，现在豌豆荚基本没有用到scaling，因为豌豆荚的应用上下游之间的依赖关系太重，所以对scaling机制支持的不好。这些都是需要努力的方向。一个比较好的事情是，豌豆荚豌豆荚的工程师都是比较有情怀的，对重构这件事情比较支持。当然，这里面有投入成本和产出的考量，豌豆荚首先要满足的还是业务需求，解决业务问题，至于重构的工作，会随着豌豆荚在AWS上的业务规模更大而变得优先级更高。
最后想分享的是，EC2的reserved instance如果用好了，能够比on demand模式节省很多。豌豆荚一开始不知道AWS除了on demand之外还有reserved instance、spot instance这些玩法，最近才刚知道。Reserved instance非常适合Web Service使用，临时性数据分析用spot instance则比较合适。
- 上一篇：局外人看圈里:沟通，运营者与用户沟通过程的距离
- 下一篇：运维人学习的3条路线图