高品质的音视频能力是怎样的? | Qcon 全球软件开发大会·上海站邀请函 了解详情
写点什么

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

  • 2017-07-02
  • 本文字数:6845 字

    阅读完需:约 22 分钟

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

最近公布了一则消息:Snap 分别与 Google Cloud Platform AWS (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 Machine HHVM ),借此通过即时编译(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 )关注我们。

2017-07-02 17:542182
用户头像

发布了 283 篇内容, 共 94.6 次阅读, 收获喜欢 54 次。

关注

评论

发布
暂无评论
发现更多内容

Bzz节点分币系统搭建,Bzz矿机挖矿系统

5分钟速读之Rust权威指南(十八)

码生笔谈

rust 范型 trait

C语言从入门到精通(三)

代码情缘

编程 开发 C语言 编程之路 硬件开发

Python——注释和字符串的拼接

在即

6月日更

Bzz节点挖矿系统搭建,Bzz分币系统源码

2021全球人工智能技术大会开幕 百度王海峰:跨语言沟通正在成为现实

百度大脑

人工智能 沟通 跨语言

架构训练营模块 5 作业 - 江哲

江哲

应用,才是区块链的终极归宿

CECBC

如何使用Tauri和Ember.js创建小型、快速和酷的桌面应用程序

代码先生

tauri ember.js desktop程序

C语言从入门到精通(二)

代码情缘

开发 C语言 编程、

TcaplusDB君 | 行业新闻汇编(6月1日)

tcaplus

数据库 游戏 TcaplusDB

整数划分问题(详解 n > m 情况)

若尘

数据结构 6月日更

备战金九银十,2021年最全999道Java岗高频面试题分享

Java架构师迁哥

TcaplusDB | 祝全世界的大小朋友六一儿童节快乐

tcaplus

数据库 TcaplusDB

区块链能否为应对气候变化 提供解决方案?

CECBC

JavaScript 代码逻辑判断的优化

编程三昧

JavaScript 大前端 代码质量 代码优化 编程思想

理解IM消息“可靠性”和“一致性”问题,以及解决方案探讨

JackJiang

即时通讯 IM 可靠消息最终一致

程序员必知的硬核基础知识

Java架构师迁哥

工厂里三个质检车间缩减为一个,飞桨企业版EasyDL助力降本增效

百度大脑

飞桨

TcaplusDB:祝全世界的大小朋友六一儿童节快乐

TcaplusDB

数据库 nosql 分布式 TcaplusDB

这个 “少年黑客”,用黑科技守护独居老人

阿里云视频云

阿里云 计算机视觉 音视频 养老

网络攻防学习笔记 Day38

穿过生命散发芬芳

网络攻防 6月日更

C语言从入门到精通(四)

代码情缘

编程 C语言 变量 编程之路 6月日更

区块链+数字政务:成都高新区如何创新

CECBC

【TcaplusDB知识库】TcaplusDB限制条件

tcaplus

数据库 TcaplusDB

Redis 缓存的三大问题及其解决方案

xcbeyond

redis 缓存 6月日更

Sprint Review != Demo——《Scrum指南》重读有感(4)

Bruce Talk

Scrum 敏捷 随笔 Agile

平衡计分卡- 战略落地的工具

石云升

创业 战略 职场经验 6月日更

【Redis】概览

awen

redis

轮胎行业遇上AI,百度智能云携手固铂轮胎智能化转型

百度大脑

智能云 轮胎

将Facebook整个托管在AWS上,这可行吗?_Facebook_SQLizer官方博客_InfoQ精选文章