Facebook 运行在 AWS 上 1 年成本约为 59.7 亿美元！
作者｜SQLizer 官方博客
译者｜大愚若智
infoq旗下：细说云计算公众号编译（ID：CloudNote）
Facebook 大约在 2004 年成立，随着逐渐成为美国五大科技巨头之一，他们的基础架构也由大学寝室里的一台服务器发展成为遍布全球的七个定制数据中心。随着 Facebook 预计用户数将增长至 19.4 亿，他们很有可能还在规划新的数据中心。
最近公布了一则消息：Snap 分别与 Google Cloud Platform 和 AWS（Amazon Web Services）签署价值 20 亿和 10 亿美元订单，这使得我们不禁好奇，以 Facebook 如此庞大的规模，能否在 AWS 之上运行。
为了回答这个问题，我们从四个方面来考虑：
服务器容量
服务器硬件性能
软件
成本
请注意，我们考虑的不是 Facebook 是否应该迁移至 AWS，只是在探讨这样做的可行性。
由于 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 可以按照下列方式分解：
地区 – 一个完整包含的地理区域（如“欧洲”或“美国西部”）。
可用区域（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。
很可能是可以的。
不能直接假定 AWS 与 Facebook 的服务器性能是相等的，因此还要考虑服务器性能的问题。Facebook 在服务器基础架构方面已经投入了数十亿美元，随着规模逐渐增长，他们经历了一台笔记本充当服务器，从第三方租用服务器，再到自建数据中心的过程。当他们开始自行设计并构建数据中心时，拆箱即用的解决方案就不再适合了。
Facebook 在建的沃斯堡（Fort Worth）数据中心，来源：DataCenter
Knowledge
Facebook 七个数据中心在各方面都以最大化性能和效率为设计目标。从数据中心整体设计到各种细节，例如服务器机架和芯片，一切都是定制的。
“为了优化成本，我们淘汰了你能在标准服务器上看到的大部分组件”，Facebook 服务器的设计者 Amir Michael 在 2009 年这样说过。
2011 年，Facebook 开源了自己有关数据中心和服务器的全部设计，借此表达对高效率设计的热爱。随后还有很多人对该项目做出了贡献，包括 Google。这些举措也推动了硬件成本的进一步降低，开始有第三方制造商生产相关组件，进一步降低了定制化数据中心的建设成本。你可以访问 Data Center Knowledge 查看完整的 Facebook 服务器硬件清单。
因此 Facebook 现有的服务器基础架构已经得到了大幅优化，可以帮助 Facebook 尽可能高效地运营。例如，他们在服务器场中开辟了一块单独的“冷存储”，专门用来保存不再有人查看的照片和视频（通常都是 10 年前上传至 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
Faceboo 52 26176 52 13773 0 0 3479 0 0:00:07 0:00:03 0:00:04 3479k 的普莱斯维尔（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 台。
极为可能毫无问题。
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 的例子也许是最好的证明，随着迁移至分布式云环境，他们需要重建大部分技术组件。
也许可以，但几乎可以肯定这样做会让性能大受影响，Facebook 甚至可能需要构建一个新的系统。
注意：这可能是本文准确性最差的内容。虽然 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 实例（用于运行 PHP 代码等内容）
实例：713,000 个
每月 100% 利用率
r3.2xlarge 实例上运行 Linux
3 年全额预付
存储（照片和视频）
标准存储：1256.5PB
PUT/COPY/POST/LIST 请求：2147483647 个
GET 和其他请求：2147483647 个
数据传输
区域间数据传出：314125
数据传出：628250
数据传入：1256500
数据传出至 CloudFront：1256500
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 亿）
年营收超过 280 亿美元，总市值 4340 亿美元，全球用户数超过 19.4 亿的 Facebook 无疑有着庞大而复杂的基础架构。有人预计 Facebook 在 2012 年时的自有服务器基础架构价值已高达 40 亿美元，目前这一数字很可能已经翻了三倍达到 120 亿美元。
然而每年 59.7 亿美元的托管成本已经远远超过 Facebook 在 2017 年时的“营收成本”（3,789,000,000 美元），这个成本已包含数据中心以及其他方面的运营成本。
另外需要注意，假设估算的 AWS 价格可能并非 Facebook 需要支付的。与 Snapchat 和 Netflix 类似，Facebook 也是有很大影响力的重量级用户，因此有能力协商并获得更低的价格。
可以，但这样更贵。
我们永远不可能知道这种开脑洞的假设是否准确，但可以这样看：
在服务器净容量方面，AWS 应该可以满足 Facebook 的需求。
服务器硬件的性能也许并非最优，但只要使用更多服务器获得更强计算能力就可以解决。
软件部分最麻烦。需要考虑 Facebook 能否简单地将现有基础架构直接移植到 AWS。虽然有可行的解决方案，但可能需要在 AWS 现有基础架构的基础上构建新的系统。这样的做法不仅痛苦，而且不太可行。但如果 Facebook 在 2010/2011 年就选择托管到 AWS，那么可能已围绕 AWS 构建了自己的技术，这种情况下软件本身不再是问题，但依然棘手。
Facebook 可以付得起托管费用，但相比目前的成本会高很多。
毫无疑问，这些结论都是错的，因为我们无法获得计算所需的数据。但是……
根据本文进行的计算和得到的结果，理论上可以将 Facebook 托管到 AWS 吗？可以，完全可以。
阅读英文原文：Is it possible to host Facebook on AWS?
相关阅读：