腦洞大開：將非死book整個托管在AWS上，這可行嗎？

非死book 大約在2004 年成立，隨著逐漸成為美國五大科技巨頭之一，他們的基礎架構也由大學寢室里的一臺服務器發展成為遍布全球的七個定制數據中心。隨著 非死book 預計用戶數將增長至 19.4 億，他們很有可能還在規劃新的數據中心。

最近公布了一則消息：Snap 分別與 Google Cloud Platform 和 AWS（Amazon Web Services）簽署價值 20 億和 10 億美元訂單，這使得我們不禁好奇，以 非死book 如此龐大的規模，能否在 AWS 之上運行。

為了回答這個問題，我們從四個方面來考慮：

1. 服務器容量
2. 服務器硬件性能
3. 軟件
4. 成本

請注意，我們考慮的不是 非死book 是否應該遷移至 AWS，只是在探討這樣做的可行性。

1. 服務器容量

由于 非死book 已經很久沒有公布過準確的服務器數量，很多人根據流傳的假設進一步進行了猜測。不過這里肯定水分不少。

非死book 到底有多少臺服務器？

早在 2012 年，Data Center Knowledge 估計 非死book 共有180,000 臺服務器。這個數值基于 2010 年發布的一組數據，通過這組數據精確計算得知，非死book 在 2010 年共有 60,000 臺服務器。假設 2012 年的估值是準確的，那么 非死book 的服務器數量增速已經遠遠超過了摩爾定律。

非死book 的用戶增長情況，來源：The Next Web

我們想知道 非死book 在五年（2012-2017）后的今天有多少臺服務器。為了獲得盡可能精確的估值，我們進行了三種計算。

計算一：每服務器用戶數

首先通過“每服務器用戶數”來計算 非死book 的服務器數量。

2012 年，非死book 用戶數 10 億，共有 18 萬臺服務器。

• 1,000,000 用戶 / 180,000 服務器 = 5,556 用戶每服務器

2017 年，非死book 用戶數接近 20 億。

• 2,000,000 用戶 / 5,556 用戶每服務器 = 360,000 臺服務器

此外還需要考慮，非死book 不僅用戶數翻倍，每個人生成的數據量也增加了：照片、視頻、直播等。另外現在 非死book 還運營著 Instagram，那么服務器數量再翻一倍吧。

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

按照這個計算方式，非死book 在 2017 年擁有的服務器數量約為 72 萬臺。

計算二：每服務器營收

接下來通過“每服務器營收”來計算他們的服務器容量。

2012 年，非死book 營收為50. 89 億美元。將 2012 年的營收除以 2012 年的服務器總量，那么每服務器營收為 2.8 萬美元。

• 5,089,000,000 美元營收 / 180,000 服務器 = 28,272 美元營收每服務器

2016 年，非死book 營收為 276.38 億美元，將其除以 28,272 美元，那么就是 977,575 臺服務器。

• 27,638,000,000 美元營收 / 28,272 美元營收每服務器 = 977,574.98 臺服務器

按照這個計算方式，非死book 在 2017 年擁有的服務器數量約為 97.8 萬臺。

計算三：每服務器對應的員工數

這個方式將使用員工數來計算服務器容量。

2012 年，非死book 有4,619 名員工，平均每位員工對應約 40 臺服務器。

• 180,000 服務器 / 4619 員工 = 38.96 臺服務器每員工

2016 年，非死book 有 17,048 名員工。按照每位員工 40 臺服務器來計算，約有 681,920 臺服務器。

• 17,048 員工 * 40 服務器每員工 = 681,920 臺服務器

按照這個計算方式，非死book 在 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

所以我們估計 非死book 在 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 規模是 非死book 的 5 倍。

• 非死book 需要 83 萬臺服務器
• AWS 有 410 萬臺服務器
• 4,100,000 / 830,000 = 4.939

補充說明：上述計算并未考慮 AWS 目前的容量局限。AWS 的日常運營有多少預留容量？AWS 是否有 20% 的預留容量可以分配給 非死book？我們打算忽略這些問題，直接假設 AWS 可以完全容納 非死book 目前的需求，但可能要犧牲靈活性作為代價。

為了滿足未來對服務器的需求，非死book 和 AWS 都在服務器基礎架構方面進行持續不斷的投入，因此可以認為，未來的 AWS 也足以承載未來的 非死book。

在服務器凈容量方面，非死book 有可能托管在 AWS 上嗎？

很可能是可以的。

2. 服務器硬件性能

不能直接假定 AWS 與 非死book 的服務器性能是相等的，因此還要考慮服務器性能的問題。非死book 在服務器基礎架構方面已經投入了數十億美元，隨著規模逐漸增長，他們經歷了一臺筆記本充當服務器，從第三方租用服務器，再到自建數據中心的過程。當他們開始自行設計并構建數據中心時，拆箱即用的解決方案就不再適合了。

非死book 在建的沃斯堡（Fort Worth）數據中心，來源：DataCenter Knowledge

非死book 七個數據中心在各方面都以最大化性能和效率為設計目標。從數據中心整體設計到各種細節，例如服務器機架和芯片，一切都是定制的。

“為了優化成本，我們淘汰了你能在標準服務器上看到的大部分組件”，非死book 服務器的設計者 Amir Michael 在2009 年這樣說過。

“我們拆掉了所有沒用的東西，只保留最必要的。”

2011 年，非死book 開源了自己有關數據中心和服務器的全部設計，借此表達對高效率設計的熱愛。隨后還有很多人對該項目做出了貢獻，包括 Google。這些舉措也推動了硬件成本的進一步降低，開始有第三方制造商生產相關組件，進一步降低了定制化數據中心的建設成本。你可以訪問 Data Center Knowledge 查看完整的 非死book 服務器硬件清單。

因此 非死book 現有的服務器基礎架構已經得到了大幅優化，可以幫助 非死book 盡可能高效地運營。例如，他們在服務器場中開辟了一塊單獨的“冷存儲”，專門用來保存不再有人查看的照片和視頻（通常都是 10 年前上傳至 非死book 的內容）。只有在有人想要查看這些照片或視頻時，才會“喚醒”這種存儲設備。

這段 油Tube 視頻展示了 非死book 的冷存儲設置。

非死book 多年的專精化運營與 AWS 截然不同，AWS 的存儲在設計上就需要考慮不同用途（高負荷）的使用。但是與 非死book 和 Google 類似，Amazon 也自行設計硬件。

“沒錯，我們會自己制造服務器，”Amazon CTO Werner Vogels 說：“我們會通過自行制造的定制化存儲和服務器滿足這些（重量級）工作負載的需求。我們還與 Intel 合作制造以更高時鐘頻率運行的自用處理器。”

雖然 AWS 可能顯得更加通用化，不過他們服務器的實際表現不可能比 非死book 差。然而關于專用化以及效率，大家有很多不同看法，這些大型科技公司為什么要這樣做？假設真的要遷移，為了能通過 AWS 獲得與自己數據中心類似的性能，非死book 很有可能需要更多服務器。為了體現這種因素，并在缺乏實際數據的情況下進行對比，我們假設 非死book 遷移后需要的服務器數量會比目前增加 10%，因此服務器的數量將增至 91.3 萬臺。

830,000 * 1.1 = 913,000

非死book 的普萊斯維爾（Prineville）數據中心內部，來源：DataCenter Knowledge

另外還要注意，非死book 正打算將 WhatsApp 從 IBM 平臺遷出，轉移至自己的服務器上運行。WhatsApp 目前使用了 700 臺裸機（類似于 非死book 的）高端 IBM SoftLayer 服務器，這些服務器基本上可以提供與 非死book 自有硬件類似的性能。但相比我們之前討論的一切，這個數字（700！）實在是微不足道，那么可以假設這方面未來的增長完全可以包含在他們未來的擴展計劃中。

遷移？

現實中，非死book 完全不可能遷移至 AWS。因此這次開腦洞的過程并不考慮有關遷移的具體過程，我們只是想探討一下這樣做的可行性。實際上本文全文都基于這樣的一個假設：非死book 從開始自建基礎架構的第一天開始就選擇托管在 AWS，結果將會怎樣。

權且假設我們在一個平行宇宙中，那么遷移到 AWS 的工作是否順利，需要多久？非死book 在 2013 到 2014 年間將 Instagram 從 AWS 遷移到了自己的服務器上，整個過程用了一年，并且無人察覺。結合這件事來考慮，我們應該也可以在最終用戶毫無察覺的情況下進行反向遷移。

然而…… 我們要遷移的可是整個 非死book，還包括 Instagram，因此整個過程肯定需要更長時間。相比這種理論上的遷移，Instagram 的遷移規模就小太多了，更無須說之前遷移后 Instagram 的規模也擴大了不少。另外別忘了 Netflix，他們花了八年才徹底遷移至 AWS。八年啊！

基于這些假設和猜測，遷移過程應該會很順利，但可能需要多年時間才能完成。

服務器硬件性能

AWS 和 非死book 都在定制數據中心、服務器設計，以及實施方面進行了大量投入。在所有設計均已開源的情況下，這兩家的服務器性能很可能不相上下。

我們認為 AWS 可以很輕松地提供 非死book 所需的計算能力和性能。但因為 AWS 無法滿足 非死book 某些特殊需求，因此還需要保留一些余量。非死book 用 830,000 臺自有服務器可以做到的事情，換成 AWS 的服務器可能需要 913,000 臺。

AWS 能提供 非死book 所需的服務器性能嗎？

極為可能毫無問題。

3. 軟件

非死book 曾經（并且目前依然）使用 OSS（開源軟件）進行開發。與其他公司類似，他們的增長速度飛快，以如此大的規模來說，通常都需要自行開發定制工具，或對現有工具進行大量修改才能滿足自己的需求。

他們依然使用 PHP 開發應用程序代碼，但為了提高性能，非死book 開發了 HipHop Virtual Machine（HHVM），借此通過即時編譯（JIT）的方式編譯 PHP 代碼。這意味著 非死book 的代碼可以通過配合使用 HHVM 和 nginx 的方式來運行。非死book 的整個網站運行在 HHVM 之上（桌面、API、移動），開發和生產環境均是如此。而這恰恰就是定制化的軟件。

感覺上，AWS 與 PHP 和 HHVM 的關系讓人擔憂。但在 非死book 自己的 HHVM GitHub 代碼庫中，有一個鏈接指向了 HHVM for AWS Linux 服務器。因此我們可以假設 非死book 可以成功地在 AWS 上運行 HHVM，進而運行自己的網站。

但是數據庫呢？數據存儲方面，在 SQL 與 NoSQL 對戰中有一個臭名昭著的例子：非死book 對 MySQL 進行了大刀闊斧的改動，用于存儲自己的時間線數據，同時依賴 memcached 實現快速交付。有關 非死book 的伸縮，建議閱讀 High Scalability 的相關文章。非死book 定制版 MySQL 的規范可參閱這里。

Amazon RDS（Relational Database Service）可以滿足要求嗎？有很多科技巨頭都在使用 Amazon RDS，最著名的就是 Netflix。也許可以認為，如果 Netflix 以及他們公司的所有視頻都可以成功地通過 RDS 運行，那么 非死book 也可以？答案無法確定，不過 非死book 的 MySQL 集群是極為龐大的，簡單地遷移很可能根本無法滿足需求。為了處理自己的負載，他們甚至創建了自己的 MySQL 分支！

目前 非死book 也已構造出極為全面的技術棧。他們的 GitHub 代碼庫足以證明這一點。這不免讓人更擔心他們的基礎架構與 AWS 的兼容性問題。

這一過程到底會有多難，Netflix 的例子也許是最好的證明，隨著遷移至分布式云環境，他們需要重建大部分技術組件。

AWS 能夠支持 非死book 龐大的軟件環境和復雜的數據需求嗎？

也許可以，但幾乎可以肯定這樣做會讓性能大受影響，非死book 甚至可能需要構建一個新的系統。

4. 將 非死book 托管到 AWS，成本會有多高？

注意：這可能是本文準確性最差的內容。雖然 AWS 提供了豐富的成本計算方法，但我們無法獲知 非死book 對數據存儲和計算的實際需求。再次提醒，這些數據完全基于猜測。

我們好奇的最后一個問題：成本。雖然 AWS 已經幫助無數公司快速低成本地縮放，但他們中的絕大部分永遠無法達到 非死book 的規模。以 非死book 的規模來說，自建基礎架構可能更便宜（他們也正是這樣做的，但我們就是想開個腦洞 ^.^）。

在使用 AWS 自己的成本計算器進行計算前，先來看看一些全球化產品在云計算方面的成本。

Snapchat 的 IPO 文件中提到，Snap 公司計劃在 5 年里向 Google 支付 20 億美元，同時向 AWS 支付 10 億美元。也就是說，每月 5 千萬美元。如此巨大的數字讓技術界有些吃驚，甚至有人編出了“支付高額費用存儲并處理很快會被銷毀的內容”這樣的段子（譯注：Snapchat 是一種“閱后即焚”應用，用戶發送的文字和圖片等內容會在收件人查看之后立刻銷毀）。

上文曾經提到，WhatsApp 依然托管在 IBM 的公有云服務器上，但 非死book 計劃盡快進行遷移。然而目前 WhatsApp 的托管成本依然高達每月 2 百萬美元。對于一個只使用了 700 臺服務器的應用來說，這個成本實在是有點高。

我們可以假設 非死book 的用量需求遠高于 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 實例（用于運行 非死book 的時間線）

• 數據庫實例：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 上，非死book 每年的成本高達 59.7 億美元。

巨頭 非死book

年營收超過 280 億美元，總市值 4340 億美元，全球用戶數超過 19.4 億的 非死book 無疑有著龐大而復雜的基礎架構。有人預計 非死book 在 2012 年時的自有服務器基礎架構價值已高達 40 億美元，目前這一數字很可能已經翻了三倍達到 120 億美元。

然而每年 59.7 億美元的托管成本已經遠遠超過 非死book 在 2017 年時的“營收成本”（3,789,000,000 美元），這個成本已包含數據中心以及其他方面的運營成本。

另外需要注意，假設估算的 AWS 價格可能并非 非死book 需要支付的。與 Snapchat 和 Netflix 類似，非死book 也是有很大影響力的重量級用戶，因此有能力協商并獲得更低的價格。

非死book 能夠支付 AWS 托管費用嗎？

可以，但這樣更貴。

非死book 有可能托管在 AWS 上嗎？

我們永遠不可能知道這種開腦洞的假設是否準確，但可以這樣看：

1. 在服務器凈容量方面，AWS 應該可以滿足 非死book 的需求。
2. 服務器硬件的性能也許并非最優，但只要使用更多服務器獲得更強計算能力就可以解決。
3. 軟件部分最麻煩。需要考慮 非死book 能否簡單地將現有基礎架構直接移植到 AWS。雖然有可行的解決方案，但可能需要在 AWS 現有基礎架構的基礎上構建新的系統。這樣的做法不僅痛苦，而且不太可行。但如果 非死book 在 2010/2011 年就選擇托管到 AWS，那么可能已圍繞 AWS 構建了自己的技術，這種情況下軟件本身不再是問題，但依然棘手。
4. 非死book 可以付得起托管費用，但相比目前的成本會高很多。

毫無疑問，這些結論都是錯的，因為我們無法獲得計算所需的數據。但是……

根據本文進行的計算和得到的結果，理論上可以將 非死book 托管到 AWS 嗎？可以，完全可以。

作者：SQLizer 官方博客，閱讀英文原文：Is it possible to host 非死book on AWS?

來自: InfoQ