发展案例：豌豆荚从自建机房迁移至AWS云计算

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