Twitter為什麼沒有當機?

banq發表於2022-11-25

五年來,我一直是 Twitter 的站點可靠性工程師 (SRE),以後四年裡,我是 Cache 團隊唯一的 SRE,四年來,我負責團隊中的自動化、可靠性和運營。我設計並實現了大部分保持它執行的工具。

快取可以用來使事情變得更快,或者減輕執行成本較高的東西的請求:
如果你有一個伺服器需要1秒鐘的響應,但每次都是同樣的響應,你可以把這個響應儲存在一個快取伺服器中,在那裡可以在幾毫秒內提供響應。或者,
如果你有一個伺服器叢集,每秒服務1000個請求可能會花費1000美元,你可以使用快取來儲存響應,並從該快取伺服器上提供服務。那麼你就會有一個100美元的小型叢集,而一個便宜的大型快取伺服器叢集也許還需要100美元。
這些數字只是為了說明問題的例子。

快取承擔了該網站的大部分流量。推文、所有的時間線、直接資訊、廣告、認證,都是由Cache團隊的伺服器提供的。如果Cache出了問題,作為使用者的你會知道,問題是可見的。

當我加入這個團隊時,我的第一個專案是把正在退役的舊機器換成新機器。當時沒有任何工具或自動化手段來做這件事,我得到的是一個包含伺服器名稱的電子表格。

快取如何保持執行
保持快取執行的第一個要點是,它們是作為Mesos上的Aurora作業執行的。Aurora為應用程式找到執行的伺服器,Mesos將所有的伺服器聚集在一起,所以Aurora知道它們。Aurora也會在應用程式啟動後保持它們的執行。
如果我們說一個快取叢集需要100個伺服器,它將盡力保持100個伺服器的執行。如果一個伺服器由於某種原因完全壞了,Mesos會檢測到這一點,將伺服器從它的聚合池中移除,Aurora現在會被告知只有99個快取在執行,然後知道它需要從Aurora中找到一個新的伺服器來執行。它將自動找到一個,並使總數恢復到100。沒有人需要參與。

在資料中心,伺服器被放置在稱為機架的地方。機架上的伺服器透過一個叫做交換機的裝置與機架上的其他伺服器相連。
從這裡開始,有一個完整的複雜系統,將交換機連線到更多的交換機和路由器,並最終接入網際網路。一個機架上可以容納20到30臺伺服器。一個機架可能會出現故障,交換機可能會損壞,或者電源可能會壞掉,這樣就會導致所有20臺伺服器癱瘓。
Aurora和Mesos為我們做的另一件好事是確保不會有太多的應用程式被放在一個機架上。因此,整個機架可以安全地癱瘓,突然間,Aurora和Mesos會找到新的伺服器,作為執行在那裡的應用程式的家。

之前提到的那個電子表格,也是在跟蹤機架上有多少臺伺服器,電子表格作者試圖確保不會有太多的伺服器。現在有了當前的工具,當我們提供新的伺服器以使其上線時,我們有工具可以跟蹤所有這些。這些工具確保團隊在一個機架上沒有太多的物理伺服器,而且所有的東西都以一種在出現故障時不會造成問題的方式分佈。

不幸的是,Mesos並不能檢測到每一個伺服器的故障,所以我們對硬體問題有額外的監控。我們尋找像壞的磁碟和有問題的記憶體這樣的東西。其中一些問題不會導致整個伺服器癱瘓,但可能只是執行緩慢。我們有一個警報的儀表板,可以掃描到損壞的伺服器。如果發現有一臺伺服器壞了,我們會自動建立一個維修任務,讓資料中心的人去看看。

該團隊還有一個重要的軟體,就是跟蹤快取叢集的啟動時間的服務。如果在很短的時間內有太多的伺服器被視為停機,那麼需要關閉快取的新任務將被拒絕,直到它安全為止。這就是我們如何避免意外地關閉整個快取記憶體叢集,並使受其保護的服務不堪重負。我們有一些阻止措施,比如有太多的伺服器很快被關閉,一次有太多的伺服器需要修復,或者Aurora無法找到新的伺服器來放置舊的任務。要為一個被檢測為故障的伺服器建立一個修復任務,首先我們透過檢查該服務來檢查它是否可以安全地移除作業,然後一旦它是空的,它就被標記為安全的,以便資料中心的技術人員對其進行工作。當資料中心的技術人員將伺服器標記為固定的時候,我們又有工具來尋找這一點,並自動啟用伺服器,以便它可以執行作業。唯一需要的人是資料中心的人,實際上是在修復它。(不過他們還在那裡嗎?)

反覆出現的應用問題也得到了解決。我們有一些錯誤,新的快取伺服器不能被新增回來(啟動時的競賽條件),或者有時需要花費10分鐘來新增一個伺服器(O(n^n)邏輯)。由於所有的自動化工作,我們沒有被人工任務所困擾,我們可以在團隊中形成一種文化,在保持專案進度的同時,我們可以去修復這些問題。我們還有其他的自動修復措施,例如,如果一些應用指標,如延遲是一個異常值,我們會自動重新啟動任務,所以工程師不會被呼喚。團隊可能每週會收到一個頁面,幾乎沒有關鍵的。我們經常有輪流值班的情況,沒有人被呼叫。

容量規劃也是網站沒有癱瘓的重要原因之一。Twitter有兩個資料中心,可以處理整個網站的故障。每個重要的服務都可以從一個資料中心執行。隨時可用的總容量實際上是200%。這只是在災難情況下,大多數時候兩個資料中心都在為流量服務。資料中心的利用率最多隻有50%。即使這樣在實踐中也會很忙。當人們計算他們的容量需求時,他們會計算出一個資料中心為所有流量服務所需的容量,然後通常在此基礎上增加淨空!只要不需要故障,就有大量的伺服器淨空可用於額外的流量。整個資料中心的故障是相當罕見的,在我工作的五年中只發生過一次。

我們還將快取叢集分開。我們沒有一個多租戶叢集,為所有的東西提供服務,並且有應用層面的隔離。這有助於在一個叢集出現問題時,將爆炸半徑保持在只有該叢集和機器上的一些共處的伺服器。同樣,Aurora透過保持快取分佈來幫助這裡,所以不會有很多影響,最終監控會趕上並修復它們。



我做了上面的所有事情我確實與客戶(使用快取服務的團隊)進行了交談。在事情被自動化之後,我又把更多的事情自動化。我還研究了一些有趣的效能問題,試驗了一些可能使事情變得更好的技術,並推動了一些大型的成本節約專案。我做了容量規劃,並決定要訂購多少臺伺服器。我很忙。

這就是為Twitter請求提供服務的快取如何保持執行的原因。這只是日常運作的一部分。為了達到這一點,多年來付出了很多努力。這是一個回過頭來欣賞這個東西仍在實際工作的時刻。

至少現在是這樣,我肯定有一些錯誤潛伏在某個地方......


 

相關文章