BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

将Facebook整个托管在AWS上,这可行吗?

| 作者 SQLizer官方博客 关注 1 他的粉丝 ,译者 大愚若智 关注 9 他的粉丝 发布于 2017年7月3日. 估计阅读时间: 24 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

Facebook大约在2004年成立,随着逐渐成为美国五大科技巨头之一,他们的基础架构也由大学寝室里的一台服务器发展成为遍布全球的七个定制数据中心。随着Facebook预计用户数将增长至19.4亿,他们很有可能还在规划新的数据中心。

最近公布了一则消息:Snap分别与Google Cloud PlatformAWS(Amazon Web Services)签署价值20亿和10亿美元订单,这使得我们不禁好奇,以Facebook如此庞大的规模,能否在AWS之上运行。

为了回答这个问题,我们从四个方面来考虑:

  • 服务器容量
  • 服务器硬件性能
  • 软件
  • 成本

请注意,我们考虑的不是Facebook是否应该迁移至AWS,只是在探讨这样做的可行性。

1. 服务器容量

由于Facebook已经很久没有公布过准确的服务器数量,很多人根据流传的假设进一步进行了猜测。不过这里肯定水分不少。

Facebook到底有多少台服务器?

早在2012年,Data Center Knowledge估计Facebook共有180,000台服务器。这个数值基于2010年发布的一组数据,通过这组数据精确计算得知,Facebook在2010年共有60,000台服务器。假设2012年的估值是准确的,那么Facebook的服务器数量增速已经远远超过了摩尔定律

Facebook的用户增长情况,来源:The Next Web

我们想知道Facebook在五年(2012-2017)后的今天有多少台服务器。为了获得尽可能精确的估值,我们进行了三种计算。

计算一:每服务器用户数

首先通过“每服务器用户数”来计算Facebook的服务器数量。

  • 2012年,Facebook用户数10亿,共有18万台服务器。
    • 1,000,000用户 / 180,000服务器 = 5,556用户每服务器
  • 2017年,Facebook用户数接近20亿。
    • 2,000,000用户 / 5,556用户每服务器 = 360,000台服务器

此外还需要考虑,Facebook不仅用户数翻倍,每个人生成的数据量也增加了:照片、视频、直播等。另外现在Facebook还运营着Instagram,那么服务器数量再翻一倍吧。

360,000 * 2 = 720,000 服务器

按照这个计算方式,Facebook在2017年拥有的服务器数量约为72万台。

计算二:每服务器营收

接下来通过“每服务器营收”来计算他们的服务器容量。

  • 2012年,Facebook营收为50.89亿美元。将2012年的营收除以2012年的服务器总量,那么每服务器营收为2.8万美元。
    • 5,089,000,000美元营收 / 180,000服务器 = 28,272美元营收每服务器
  • 2016年,Facebook营收为276.38亿美元,将其除以28,272美元,那么就是977,575台服务器。
    • 27,638,000,000美元营收 / 28,272美元营收每服务器 = 977,574.98台服务器

按照这个计算方式,Facebook在2017年拥有的服务器数量约为97.8万台。

计算三:每服务器对应的员工数

这个方式将使用员工数来计算服务器容量。

  • 2012年,Facebook有4,619名员工,平均每位员工对应约40台服务器。
    • 180,000服务器 / 4619 员工 = 38.96台服务器每员工
  • 2016年,Facebook有17,048名员工。按照每位员工40台服务器来计算,约有681,920台服务器。
    • 17,048员工 * 40服务器每员工 = 681,920台服务器

      按照这个计算方式,Facebook在2017年拥有的服务器数量约为68.2万台。

不同数量之间的差异

三种计算方式的区间为296,000。

978,000 - 682,000 = 296,000

取中间值并将其作为我们最终的数量。

296,000 / 2 = 148,000

682,000 + 148,000 = 830,000 978,000 - 148,000 = 830,000

所以我们估计Facebook在2017年共有830,000台服务器

AWS又有多少台服务器?

AWS的全球基础架构,来源:AWS

AWS可以按照下列方式分解:

  • 地区 – 一个完整包含的地理区域(如“欧洲”或“美国西部”)。
  • 可用区域(AZ) - 地区内由一个或多个数据中心组成的不同区域(如“伦敦”或“俄勒冈”)。
  • 数据中心 – 基本上就是一种大面积,造价高昂的仓库,每个数据中心承载5万至8万台服务器

截止2017年,AWS共有:

  • 16个地区(还有3个在建)。
  • 42个AZ(新地区上线后还将增加8个)。

相关信息可参阅AWS全球基础架构介绍。

假设平均每个数据中心有6.5万台服务器,平均每个AZ有1.5个数据中心,那么服务器的总数为409.5万台。四舍五入一下,假设AWS共有410万台服务器。

(42 AZ * 1.5个数据中心) * 65,000台服务器 = 4,095,000

2014年,Enterprise Tech进行过类似的计算(不过是基于28个AZ,但道理是相通的),最终估计的服务器数量介于280万到560万台之间。他们的估算中,每个AZ包含三个数据中心,如果这个假设是准确的,那么AWS在全球范围内可能会有超过800万台服务器。

服务器净容量

在服务器净容量方面,根据上文(可能不准确的)计算,AWS规模是Facebook的5倍。

  • Facebook需要83万台服务器
  • AWS有410万台服务器
  • 4,100,000 / 830,000 = 4.939

补充说明:上述计算并未考虑AWS目前的容量局限。AWS的日常运营有多少预留容量?AWS是否有20%的预留容量可以分配给Facebook?我们打算忽略这些问题,直接假设AWS可以完全容纳Facebook目前的需求,但可能要牺牲灵活性作为代价。

为了满足未来对服务器的需求,Facebook和AWS都在服务器基础架构方面进行持续不断的投入,因此可以认为,未来的AWS也足以承载未来的Facebook。

在服务器净容量方面,Facebook有可能托管在AWS上吗?

很可能是可以的。

2. 服务器硬件性能

不能直接假定AWS与Facebook的服务器性能是相等的,因此还要考虑服务器性能的问题。Facebook在服务器基础架构方面已经投入了数十亿美元,随着规模逐渐增长,他们经历了一台笔记本充当服务器,从第三方租用服务器,再到自建数据中心的过程。当他们开始自行设计并构建数据中心时,拆箱即用的解决方案就不再适合了。

Facebook在建的沃斯堡(Fort Worth)数据中心,来源:DataCenter Knowledge

Facebook七个数据中心在各方面都以最大化性能和效率为设计目标。从数据中心整体设计到各种细节,例如服务器机架和芯片,一切都是定制的。

“为了优化成本,我们淘汰了你能在标准服务器上看到的大部分组件”,Facebook服务器的设计者Amir Michael在2009年这样说过。

“我们拆掉了所有没用的东西,只保留最必要的。”

2011年,Facebook开源了自己有关数据中心和服务器的全部设计,借此表达对高效率设计的热爱。随后还有很多人对该项目做出了贡献,包括Google。这些举措也推动了硬件成本的进一步降低,开始有第三方制造商生产相关组件,进一步降低了定制化数据中心的建设成本。你可以访问Data Center Knowledge查看完整的Facebook服务器硬件清单。

因此Facebook现有的服务器基础架构已经得到了大幅优化,可以帮助Facebook尽可能高效地运营。例如,他们在服务器场中开辟了一块单独的“冷存储”,专门用来保存不再有人查看的照片和视频(通常都是10年前上传至Facebook的内容)。只有在有人想要查看这些照片或视频时,才会“唤醒”这种存储设备。

这段YouTube视频展示了Facebook的冷存储设置。

Facebook多年的专精化运营与AWS截然不同,AWS的存储在设计上就需要考虑不同用途(高负荷)的使用。但是与Facebook和Google类似,Amazon也自行设计硬件

“没错,我们会自己制造服务器,”Amazon CTO Werner Vogels说:“我们会通过自行制造的定制化存储和服务器满足这些(重量级)工作负载的需求。我们还与Intel合作制造以更高时钟频率运行的自用处理器。”

虽然AWS可能显得更加通用化,不过他们服务器的实际表现不可能比Facebook差。然而关于专用化以及效率,大家有很多不同看法,这些大型科技公司为什么要这样做?假设真的要迁移,为了能通过AWS获得与自己数据中心类似的性能,Facebook很有可能需要更多服务器。为了体现这种因素,并在缺乏实际数据的情况下进行对比,我们假设Facebook迁移后需要的服务器数量会比目前增加10%,因此服务器的数量将增至91.3万台。

830,000 * 1.1 = 913,000

Facebook的普莱斯维尔(Prineville)数据中心内部,来源:DataCenter Knowledge

另外还要注意,Facebook正打算将WhatsApp从IBM平台迁出,转移至自己的服务器上运行。WhatsApp目前使用了700台裸机(类似于Facebook的)高端IBM SoftLayer服务器,这些服务器基本上可以提供与Facebook自有硬件类似的性能。但相比我们之前讨论的一切,这个数字(700!)实在是微不足道,那么可以假设这方面未来的增长完全可以包含在他们未来的扩展计划中。

迁移?

现实中,Facebook完全不可能迁移至AWS。因此这次开脑洞的过程并不考虑有关迁移的具体过程,我们只是想探讨一下这样做的可行性。实际上本文全文都基于这样的一个假设:Facebook从开始自建基础架构的第一天开始就选择托管在AWS,结果将会怎样。

权且假设我们在一个平行宇宙中,那么迁移到AWS的工作是否顺利,需要多久?Facebook在2013到2014年间将Instagram从AWS迁移到了自己的服务器上,整个过程用了一年,并且无人察觉。结合这件事来考虑,我们应该也可以在最终用户毫无察觉的情况下进行反向迁移。

然而…… 我们要迁移的可是整个Facebook,还包括Instagram,因此整个过程肯定需要更长时间。相比这种理论上的迁移,Instagram的迁移规模就小太多了,更无须说之前迁移后Instagram的规模也扩大了不少。另外别忘了Netflix,他们花了八年才彻底迁移至AWS。八年啊!

基于这些假设和猜测,迁移过程应该会很顺利,但可能需要多年时间才能完成。

服务器硬件性能

AWS和Facebook都在定制数据中心、服务器设计,以及实施方面进行了大量投入。在所有设计均已开源的情况下,这两家的服务器性能很可能不相上下。

我们认为AWS可以很轻松地提供Facebook所需的计算能力和性能。但因为AWS无法满足Facebook某些特殊需求,因此还需要保留一些余量。Facebook用830,000台自有服务器可以做到的事情,换成AWS的服务器可能需要913,000台。

AWS能提供Facebook所需的服务器性能吗?

极为可能毫无问题。

3. 软件

Facebook曾经(并且目前依然)使用OSS(开源软件)进行开发。与其他公司类似,他们的增长速度飞快,以如此大的规模来说,通常都需要自行开发定制工具,或对现有工具进行大量修改才能满足自己的需求。

他们依然使用PHP开发应用程序代码,但为了提高性能,Facebook开发了HipHop Virtual MachineHHVM),借此通过即时编译(JIT)的方式编译PHP代码。这意味着Facebook的代码可以通过配合使用HHVM和nginx的方式来运行。Facebook的整个网站运行在HHVM之上(桌面、API、移动),开发和生产环境均是如此。而这恰恰就是定制化的软件。

感觉上,AWS与PHP和HHVM的关系让人担忧。但在Facebook自己的HHVM GitHub代码库中,有一个链接指向了HHVM for AWS Linux服务器。因此我们可以假设Facebook可以成功地在AWS上运行HHVM,进而运行自己的网站。

但是数据库呢?数据存储方面,在SQL与NoSQL对战中有一个臭名昭著的例子:Facebook对MySQL进行了大刀阔斧的改动,用于存储自己的时间线数据,同时依赖memcached实现快速交付。有关Facebook的伸缩,建议阅读High Scalability的相关文章。Facebook定制版MySQL的规范可参阅这里

Amazon RDS(Relational Database Service)可以满足要求吗?有很多科技巨头都在使用Amazon RDS,最著名的就是Netflix。也许可以认为,如果Netflix以及他们公司的所有视频都可以成功地通过RDS运行,那么Facebook也可以?答案无法确定,不过Facebook的MySQL集群是极为庞大的,简单地迁移很可能根本无法满足需求。为了处理自己的负载,他们甚至创建了自己的MySQL分支!

目前Facebook也已构造出极为全面的技术栈。他们的GitHub代码库足以证明这一点。这不免让人更担心他们的基础架构与AWS的兼容性问题。

这一过程到底会有多难,Netflix的例子也许是最好的证明,随着迁移至分布式云环境,他们需要重建大部分技术组件。

AWS能够支持Facebook庞大的软件环境和复杂的数据需求吗?

也许可以,但几乎可以肯定这样做会让性能大受影响,Facebook甚至可能需要构建一个新的系统。

4. 将Facebook托管到AWS,成本会有多高?

注意:这可能是本文准确性最差的内容。虽然AWS提供了丰富的成本计算方法,但我们无法获知Facebook对数据存储和计算的实际需求。再次提醒,这些数据完全基于猜测。

我们好奇的最后一个问题:成本。虽然AWS已经帮助无数公司快速低成本地缩放,但他们中的绝大部分永远无法达到Facebook的规模。以Facebook的规模来说,自建基础架构可能更便宜(他们也正是这样做的,但我们就是想开个脑洞 ^.^)。

在使用AWS自己的成本计算器进行计算前,先来看看一些全球化产品在云计算方面的成本。

Snapchat的IPO文件中提到,Snap公司计划在5年里向Google支付20亿美元,同时向AWS支付10亿美元。也就是说,每月5千万美元。如此巨大的数字让技术界有些吃惊,甚至有人编出了“支付高额费用存储并处理很快会被销毁的内容”这样的段子(译注:Snapchat是一种“阅后即焚”应用,用户发送的文字和图片等内容会在收件人查看之后立刻销毁)。

上文曾经提到,WhatsApp依然托管在IBM的公有云服务器上,但Facebook计划尽快进行迁移。然而目前WhatsApp的托管成本依然高达每月2百万美元。对于一个只使用了700台服务器的应用来说,这个成本实在是有点高。

我们可以假设Facebook的用量需求远高于WhatsApp和Snapchat的总合。

成本计算

下列计算较为简单,基于1,000,000台服务器,这些服务器分别运行EC2计算、Amazon S3、Amazon RDS,以及照片和视频等数据的存储和传输任务,每月传输的数据流量为1,256.5PB(1,256,500TB)。

计算中假设:

  • 每天上传3亿张照片,平均每张照片4MB。
  • 每天上传1亿小时的视频,平均每个视频200MB。

这些计算即不精确也不严谨。如果你有更好的计算方法,欢迎自己试一试!原始的AWS成本计算结果可参阅这里

随后开始计算:

Amazon EC2

计算:Amazon EC2实例(用于运行PHP代码等内容)

  • 实例:713,000个
  • 每月100%利用率
  • r3.2xlarge实例上运行Linux
  • 3年全额预付

Amazon S3

存储(照片和视频)

  • 标准存储:1256.5PB
  • PUT/COPY/POST/LIST请求:2147483647个
  • GET和其他请求:2147483647个

数据传输

  • 区域间数据传出:314125
  • 数据传出:628250
  • 数据传入:1256500
  • 数据传出至CloudFront:1256500

Amazon RDS

Amazon RDS On-Demand DB实例(用于运行Facebook的时间线)

  • 数据库实例:200,000个
  • 每月100%利用率
  • 数据库引擎和许可:MySQL
  • 实例类型:db.r3.2xlarge
  • 部署:多AZ
  • 存储:常规用途,1TB

数据传输

  • 区域间数据传出:500TB
  • 数据传出:500TB
  • 数据传入:500TB
  • 区域内数据传输:500TB

总额

  • 一次性全额支付(3年期预付):3,933,846,000.00美元(39亿)
  • 一次性全额支付分摊至36个月:每月109,273,500.00美元(1.09亿)
  • 排除一次性支付,额外的月成本:389,020,939.96美元(3.89亿)
  • 月总成本:109,273,500.000美元(1.08亿)+ 389,020,939.96美元(3.89亿) = 498,293,439.96美元(4.98亿)
  • 年总成本:5,979,521,279.52美元(59.7亿)

理论上,如果托管在AWS上,Facebook每年的成本高达59.7亿美元。

巨头Facebook

营收超过280亿美元,总市值4340亿美元,全球用户数超过19.4亿的Facebook无疑有着庞大而复杂的基础架构。有人预计Facebook在2012年时的自有服务器基础架构价值已高达40亿美元,目前这一数字很可能已经翻了三倍达到120亿美元。

然而每年59.7亿美元的托管成本已经远远超过Facebook在2017年时的“营收成本”(3,789,000,000美元),这个成本已包含数据中心以及其他方面的运营成本。

另外需要注意,假设估算的AWS价格可能并非Facebook需要支付的。与Snapchat和Netflix类似,Facebook也是有很大影响力的重量级用户,因此有能力协商并获得更低的价格。

Facebook能够支付AWS托管费用吗?

可以,但这样更贵。

Facebook有可能托管在AWS上吗?

我们永远不可能知道这种开脑洞的假设是否准确,但可以这样看:

  1. 在服务器净容量方面,AWS应该可以满足Facebook的需求。
  2. 服务器硬件的性能也许并非最优,但只要使用更多服务器获得更强计算能力就可以解决。
  3. 软件部分最麻烦。需要考虑Facebook能否简单地将现有基础架构直接移植到AWS。虽然有可行的解决方案,但可能需要在AWS现有基础架构的基础上构建新的系统。这样的做法不仅痛苦,而且不太可行。但如果Facebook在2010/2011年就选择托管到AWS,那么可能已围绕AWS构建了自己的技术,这种情况下软件本身不再是问题,但依然棘手。
  4. Facebook可以付得起托管费用,但相比目前的成本会高很多。

毫无疑问,这些结论都是错的,因为我们无法获得计算所需的数据。但是……

根据本文进行的计算和得到的结果,理论上可以将Facebook托管到AWS吗?可以,完全可以。

作者SQLizer官方博客阅读英文原文Is it possible to host Facebook on AWS?


感谢冬雨对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT