揭秘 Twitter 背後的基礎設施：效率與優化篇

天空之城：2013 年 8 月 2 日，宮崎駿的《天空之城castle in the sky》在 ntv 迎來其第 14 次電視重播，劇情發展到高潮之時，twitter 的 tps（tweets per second）也被推上了新的高度——143,199 tps，是平均值的 25 倍，這個記錄保持至今。-- lctt 譯注

<a target="_blank"></a>

目前 twitter 硬體和資料中心的規模已經超過大多數公司。但達到這樣的規模不是一蹴而就的，系統是随着軟硬體的更新優化一步步成熟起來的，過程中我們也曾經犯過很多錯誤。

有個一時期我們的系統故障不斷。軟體問題、硬體問題，甚至底層裝置問題不斷爆發，常常導緻系統營運中斷。出現故障的地方存在于各個方面，必須綜合考慮才能确定其風險和受到影響的服務。随着 twitter 在客戶、服務、媒體上的影響力不斷擴大，建構一個高效、可靠的系統來提供服務成為我們的戰略訴求。

twitter系統故障的界面被稱為失敗鲸fail whale，如下圖 -- lctt 譯注

fail whale

一開始，我們的軟體是直接安裝在伺服器，這意味着軟體可靠性依賴硬體，電源、網絡以及其他的環境因素都是威脅。這種情況下，如果要增加容錯能力，就需要統籌考慮這些互不關聯的實體裝置因素及在上面運作的服務。

最早采購資料中心方案的時候，我們都還是菜鳥，對于站點選擇、營運和設計都非常不專業。我們先直接托管主機，業務增長後我們改用租賃機房。早期遇到的問題主要是因為裝置故障、資料中心設計問題、維護問題以及人為操作失誤。我們也在持續疊代我們的硬體設計，進而增強硬體和資料中心的容錯性。

服務中斷的原因有很多，其中硬體故障常發生在伺服器、機架交換機、核心交換機這地方。舉一個我們曾經犯過的錯誤，硬體團隊最初在設計伺服器的時候，認為雙路電源對減少供電問題的意義不大 -- 他們真的就移除了一塊電源。然而資料中心一般給機架提供兩路供電來提高備援性，防止電網故障傳導到伺服器，而這需要兩塊電源。最終我們不得不在機架上增加了一個 ats 單元（交流切換開關ac transfer switch）來接入第二路供電。

提高系統的可靠性靠的就是這樣的改進，給網絡、供電甚至機房增加備援，進而将影響控制到最小範圍。

我們學到的第一個教訓就是要先模組化，将可能出故障的地方（例如建築的供電和冷卻系統、硬體、光纖網絡等）和運作在上面的服務之間的依賴關系弄清楚，這樣才能更好地分析，進而優化設計提升容錯能力。

我們增加了更多的資料中心提升地理容災能力，減少自然災害的影響。而且這種站點隔離也降低了軟體的風險，減少了例如軟體部署更新和系統故障的風險。這種多活的資料中心架構提供了代碼灰階釋出staged code deployment的能力，減少代碼首次上線時候的影響。

我們設計新硬體使之能夠在更高溫度下正常運作，資料中心的能源效率是以有所提升。

随着公司的戰略發展和營運增長，我們在不影響我們的最終使用者的前提下，持續不斷改進我們的資料中心。下一步工作主要是在目前能耗和硬體的基礎上，通過維護和優化來提升效率。

我們的硬體工程師團隊剛成立的時候隻能測試市面上現有硬體，而現在我們能自己定制硬體以節省成本并提升效率。

twitter 是一個很大的公司，它對硬體的要求對任何團隊來說都是一個不小的挑戰。為了滿足整個公司的需求，我們的首要工作是能檢測并保證購買的硬體的品質。團隊重點關注的是性能和可靠性這兩部分。對于硬體我們會做系統性的測試來保證其性能可預測，保證盡量不引入新的問題。

随着我們一些關鍵元件的負荷越來越大（如 mesos、hadoop、manhattan、mysql 等），市面上的産品已經無法滿足我們的需求。同時供應商提供的一些進階伺服器功能，例如 raid 管理或者電源熱切換等，可靠性提升很小，反而會拖累系統性能而且價格高昂，例如一些 raid 控制器價格高達系統總報價的三分之一，還拖累了 ssd 的性能。

那時，我們也是 mysql 資料庫的一個大型使用者。sas（串行連接配接 scsiserial attached scsi）裝置的供應和性能都有很大的問題。我們大量使用 1u 規格的伺服器，它的磁盤和回寫緩存一起也隻能支撐每秒 2000 次的順序 io。為了獲得更好的效果，我們隻得不斷增加 cpu 核心數并加強磁盤能力。我們那時候找不到更節省成本的方案。

後來随着我們對硬體需求越來越大，我們成立了一個硬體團隊，進而自己來設計更便宜更高效的硬體。

我們不斷的優化硬體相關的技術，下面是我們采用的新技術和自研平台的時間軸。

2012 - 采用 ssd 作為我們 mysql 和 key-value 資料庫的主要存儲。

2013 - 我們開發了第一個定制版 hadoop 工作站，它現在是我們主要的大容量存儲方案。

2013 - 我們定制的解決方案應用在 mesos、tfe（ twitter front-end ）以及緩存裝置上。

2014 - 我們定制的 ssd key-value 伺服器完成開發。

2015 - 我們定制的資料庫解決方案完成開發。

2016 - 我們開發了一個 gpu 系統來做模糊推理和訓練機器學習。

硬體團隊的工作本質是通過做取舍來優化 tco（總體擁有成本），最終達到達到降低 capex（資本支出）和 opex（營運支出）的目的。概括來說，伺服器降成本就是：

删除無用的功能群組件

提升使用率

twitter 的裝置總體來說有這四大類：儲存設備、計算裝置、資料庫和 gpu 。 twitter 對每一類都定義了詳細的需求，讓硬體工程師更針對性地設計産品，進而優化掉那些用不到或者極少用的備援部分。例如，我們的儲存設備就專門為 hadoop 優化過，裝置的購買和營運成本相比于 oem 産品降低了 20% 。同時，這樣做減法還提高了裝置的性能和可靠性。同樣的，對于計算裝置，硬體工程師們也通過移除無用的特性獲得了效率提升。

一個伺服器可以移除的元件總是有限的，我們很快就把能移除的都扔掉了。于是我們想出了其他辦法，例如在儲存設備裡，我們認為降低成本最好的辦法是用一個節點替換多個節點，并通過 aurora/mesos 來管理任務負載。這就是我們現在正在做的東西。

對于這個我們自己新設計的伺服器，首先要通過一系列的标準測試，然後會再做一系列負載測試，我們的目标是一台新裝置至少能替換兩台舊裝置。最大的性能提升來自增加 cpu 的線程數，我們的測試結果表示新 cpu 的 單線程能力提高了 20~50% 。同時由于整個伺服器的線程數增加，我們看到單線程能效提升了 25%。

這個新裝置首次部署的時候，監控發現新裝置隻能替換 1.5 台舊裝置，這比我們的目标低了很多。對性能資料檢查後發現，我們之前對負載特性的一些假定是有問題的，而這正是我們在做性能測試需要發現的問題。

對此我們硬體團隊開發了一個模型，用來預測在不同的硬體配置下目前 aurora 任務的填充效率。這個模型正确的預測了新舊硬體的性能比例。模型還指出了我們一開始沒有考慮到的存儲需求，并是以建議我們增加 cpu 核心數。另外，它還預測，如果我們修改記憶體的配置，那系統的性能還會有較大提高。

硬體配置的改變都需要花時間去操作，是以我們的硬體工程師們就首先找出幾個關鍵痛點。例如我們和 sre（網站可靠性工程師site reliability engineer）團隊一起調整任務順序來降低存儲需求，這種修改很簡單也很有效，新裝置可以代替 1.85 個舊裝置了。

為了更好的優化效率，我們對新硬體的配置做了修改，隻是擴大了記憶體和磁盤容量就将 cpu 使用率提高了20% ，而這隻增加了非常小的成本。同時我們的硬體工程師也和合作生産廠商一起為那些伺服器的最初出貨調整了物料清單。後續的觀察發現我們的自己的新裝置實際上可以代替 2.4 台舊裝置，這個超出了預定的目标。

直到 2012 年為止，軟體團隊在 twitter 開通一個新服務還需要自己操心硬體：配置硬體的規格需求，研究機架尺寸，開發部署腳本以及處理硬體故障。同時，系統中沒有所謂的“服務發現”機制，當一個服務需要調用一個另一個服務時候，需要讀取一個 yaml 配置檔案，這個配置檔案中有目标服務對應的主機 ip 和端口資訊（預留的端口資訊是由一個公共 wiki 頁面維護的）。随着硬體的替換和更新，yaml 配置檔案裡的内容也會不斷的編輯更新。在緩存層做修改意味着我們可以按小時或按天做很多次部署，每次添加少量主機并按階段部署。我們經常遇到在部署過程中 cache 不一緻導緻的問題，因為有的主機在使用舊的配置有的主機在用新的。有時候一台主機的異常（例如在部署過程中它臨時當機了）會導緻整個站點都無法正常工作。

服務發現功能意味着不需要再維護一個靜态 yaml 主機清單了。服務或者在啟動後主動注冊，或者自動被 mesos 接入到一個“服務集”（就是一個 zookeeper 中的 znode 清單，包含角色、環境和服務名資訊）中。任何想要通路這個服務的元件都隻需要監控這個路徑就可以實時擷取到一個正在工作的服務清單。

mesos/aurora 和服務發現這兩個功能給我們帶了革命性的變化。雖然在接下來幾年裡，我們碰到了無數 bug ，傷透了無數腦筋，學到了分布式系統裡的無數教訓，但是這套架還是非常贊的。以前大家一直忙于處理硬體搭配和管理，而現在，大家隻需要考慮如何優化業務以及需要多少系統能力就可以了。同時，我們也從根本上解決了 twitter 之前經曆過的 cpu 使用率低的問題，以前服務直接安裝在伺服器上，這種方式無法充分利用伺服器資源，任務協調能力也很差。現在 mesos 允許我們把多個服務打包成一個服務包，增加一個新服務隻需要修改配額，再改一行配置就可以了。

在兩年時間裡，多數“無狀态”服務遷移到了 mesos 平台。一些大型且重要的服務（包括我們的使用者服務和廣告服務系統）是最先遷移上去的。因為它們的體量巨大，是以它們從這些服務裡獲得的好處也最多，這也降低了它們的服務壓力。

原文釋出時間為：2016-10-08

本文來自雲栖社群合作夥伴“linux中國”