最大個人直播平臺Twitch如何實現99.99%高可用性？

Twitch是世界上最大的個人流媒體直播平臺，客戶端觀看Twitch的方式有很多，包括桌面瀏覽器、移動裝置、遊戲機和電視應用程式。客戶端交付平臺團隊擁有向使用者交付Twitch客戶端的基礎設施。去年，我們為我們的一個關鍵微服務設計了下一代高可用性的防禦措施，將可用性從99.9%（3個9）提高到99.99%（4個9）。

在這篇文章中，我將分享我們的設計、指導原則和結果。

每當你為一個服務設計高可用性時，你都應該考慮到常見的考慮因素（適用於任何雲服務）以及你的服務的特定機會。雲端計算高可用性的基礎知識是眾所周知的，比如使用冗餘來避免單點故障。我們將討論我們在基礎知識之外所做的事情。

指導原則

我們制定了以下高可用性原則。

• 像對待安全一樣對待可用性。
• 實行深度防禦。
• 將你的內容交付網路（CDN）作為一個完整的合作伙伴來保護你的服務。
• 為服務的不可用性設計故障轉移機制。
• 將超額配置作為一項長期防禦措施。
• 準備好在你需要時迅速增加容量。
• 使用比例配置來平衡超額配置和成本。
• 定期分析負載並調整服務分配。
• 考慮可用性決定對其他領域的影響，如延遲。
• 對警報進行投資，並避免錯誤警報和不知情的極端情況。
• 不要依賴常設防禦：對攻擊作出反應。
• 優化你的服務以獲得最大的效率。
• 致力於持續創新和不斷改進。

交付網路平臺

通常一天有3000萬人訪問www.twitch.tv。作為回應，Twitch網路平臺是一個單頁應用程式，由一個名為Sage的微服務與CDN合作向瀏覽器提供。Sage的工作是提供index.html。這聽起來很簡單，但Sage還支援金絲雀釋出、A/B測試、政策執行和搜尋引擎後設資料檢索。如果Sage不能完成它的工作，使用者就不能到達Twitch，也就不能享受Twitch提供的實時視訊、聊天和其他一切。一旦網路平臺被載入，Sage就不在了，其他服務支援觀看體驗。因此，我們關心Sage的高可用性，因為你只有一次機會，給人留下第一印象。

讓我們來定義一些指標。我們正在衡量可用性，即Sage服務負載平衡器的無錯誤率，每週報告一次。一個相關的指標是交付率，即從CDN到瀏覽器的無差錯率。可用性衡量的是服務，而交付能力衡量的是實際的客戶體驗。

Sage在全球十幾個AWS資料中心執行，由數百個CDN存在點支撐。它一直是高度超額配置的，作為對拒絕服務攻擊和活動波動的一種保障。Sage是一個你永遠不必擔心的可靠服務，直到有一天我們擔心了。去年，我們注意到Sage的可用性在3月的一天略低於99.9%。3個9的可用性是對所有關鍵Twitch服務的最低期望。當這種情況第二次發生時，我們採取了短期行動，將受影響地區的伺服器增加了三倍，同時我們進行了深入分析，並決定在長期基礎上做什麼。

威脅建模：像對待安全一樣對待可用性

對Sage的DDOS攻擊是是正常負載的數倍的突發請求，突然爆發通常可以輕鬆處理，但如果超過了容量，一些使用者將開始收到5xx錯誤。分散式拒絕服務（DDOS）攻擊同時襲擊多個地區。它們通常在幾分鐘的時間內就結束了，但有時也會延長。由於一個熱門事件引起的浪湧可能持續數小時甚至數天。

並非所有的可用性威脅都是敵對的。流量的增加可能是出於完全無辜的原因，比如增長，或者是在一個意料之外的、瘋狂的、流行的事件中激增。無論意圖如何，對可用性的挑戰就意味著戰爭 

中世紀的城堡是視覺化可用性防禦的一個很好的比喻，所以我們將把我們的原則與城堡防禦聯絡起來。雖然這似乎更適合於安全討論，但你不能把可用性與安全分開，許多安全設計的工具同樣適用於可用性。其中最主要的是威脅建模。我們首先從服務中斷開始倒推，確定什麼會導致或促成故障的發生。然後，我們為這些漏洞設計緩解措施。

深入防禦；多層防禦

城堡實行縱深防禦，即分層防禦的技術，以削弱和打擊攻擊者的士氣。一些防禦措施是顯而易見的，如高而厚的石牆。其他的則是隱藏的，在需要時才會保密。當攻擊者越過一個可怕的防禦，他們就會遇到另一個。

攻入城堡意味著要克服大量的防禦措施，包括自然特徵、周圍的城鎮、護城河、吊橋、門閂、弓箭手、垛口、謀殺洞、外牆、內牆和守衛塔。

深度防禦在中世紀是很有效的，今天它仍然是一種受人尊敬的防禦策略。

深度防禦對可用性至關重要，因為我們不能依靠任何一種機制來完全保護我們。我們利用多個冗餘的防禦層來提供卓越的保護。當攻擊者穿透一個防禦層時，後面還有另一個防禦層--削弱攻擊者的決心和資源，使進一步攻擊變得不值得。我們的每一個防禦機制都是深度防禦馬賽克的一部分。

從頭到尾思考：CDN防禦系統

在攻擊者到達城堡之前，他們必須首先越過外圍的防禦設施。城堡利用了周圍地區的自然特徵，如懸崖和河流。位於山丘或山脈上的城堡更容易發現入侵者，而敵人也更難將士兵和武器轉移到位置上。周圍的城鎮是防禦系統的一個組成部分。鎮民們被期望既能保衛城堡，又能對入侵者發出警報。城堡周圍充滿水的護城河阻止了隧道的建設。

CDN是我們認識敵對交通並對其採取行動的第一個機會。對於Sage來說，CDN可以識別和過濾已知的不需要的機器人，同時傳遞友好的機器人，如搜尋引擎爬蟲。在長時間的攻擊中，如果我們能夠識別攻擊者流量的顯著特徵，我們可以配置CDN來攔截它。

當一座城堡被圍攻時，攻擊者會隔離城堡，切斷其食物和水的供應。供應充足的城堡有足夠的儲備來等待漫長的圍困。1226年對凱尼沃斯城堡的圍攻持續了6個月，直到佔領者耗盡了食物而投降。城市可以拖得更久：1648-1669年對坎迪亞的圍攻持續了21年!

服務所有者同樣必須考慮當資源匱乏時該怎麼辦。我們的高階系統工程師James Hartshorn設計了一個設施，我們稱之為Sage Origin Backup。Sage和CDN通常不快取index.html，因為新版本的釋出很頻繁。然而，我們確實快取了最新版本的index.html，用於故障轉移。當Sage不可用並以5xx錯誤響應請求時，CDN會介入並提供一個過時的index.html來代替它。使用者完全沒有意識到服務的中斷，也沒有受到影響。雖然繞過Sage意味著沒有服務的業務邏輯，但這只是短暫的，而且保留了提供index.html這一重要的任務。

為了衡量這種做法的有效性，我們跟蹤了一個名為 "送達率 "的指標，它告訴我們客戶從CDN收到200個響應與5xx個錯誤的頻率。由於這一明顯有效的機制，大多數星期我們都達到了5個9的送達率。

外牆：過度校驗是你的常設防禦

城堡防禦最明顯的一層是其厚厚的石牆，也叫幕牆。每個人都知道城堡牆的重要性。它是你的常備防禦，是保護你的基礎。在視覺上具有威懾力，牆是不斷提醒可能的攻擊者城堡的完整性。

城堡牆的服務相當於我們的供應水平，即每個區域的容量大小。當攻擊突然到來時，在沒有任何警告的情況下，我們的常備防禦需要足夠。我們不是為標準負荷而是為標準攻擊負荷分配容量。

傳統上，Sage一直在全球十幾個AWS資料中心的數百臺伺服器上執行，所有這些伺服器都被高度超額配置，以防範拒絕服務攻擊。每個地區都有相同的容量。雖然這種安排多年來一直執行良好，但隨著時間的推移，有些事情已經發生了變化。Twitch的流量增加了：我們是否仍然有足夠的供應？世界各地的負載差異有多大？我們甚至在正確的地區嗎？

我們試圖更好地瞭解我們的流量和負載。分析顯示，地區負載差異很大：我們最繁忙的地區的流量是最不繁忙的地區的24倍！此外，有些地區更容易出現問題。此外，一些地區比其他地區更容易受到拒絕服務攻擊。這意味著我們的 "厚牆 "保護並不像我們認為的那樣厚。

所有流量的45%只通過兩個資料中心，這也是令人不舒服的：雖然沒有容量的問題，但一個完整的區域中斷可能會影響到我們很大一部分使用者。

我們研究了我們的流量頻率分佈，以瞭解每個區域所承受的峰值負荷。由此產生的各地區每小時請求的堆積圖使我們能夠對每個地區的負載進行分析。我們還研究了每分鐘的請求，以瞭解激增的強度。

有了這些洞察力，我們將Sage從一個固定的供應模式轉移到一個按比例的供應模式。我們根據測量的負載，乘以超額配置係數來調整我們的區域分配。我們還在歐洲增加了更多的區域來分配負載。因此，Sage現在有非常不同的區域分配，但每個區域的保護量是相等的。我們的比例配置方法確保每個地區都得到充分的保護，同時又不浪費。儘管增加了新的地區，但每月的費用只增加了1.5%，因為這種重新分配供應的方式減少了許多地區的分配。

內牆：增加容量

1300年代後，一個防禦良好的城堡有兩道牆。如果入侵者突破了外牆，還有另一道更高的牆要對付。守衛者會把箭和熱焦油射向攻擊者，他們被夾在牆之間的狹窄區域。

如果常設供應是你的外牆，那麼增加的能力就是你的內牆。無論你的配置有多好，超過這個水平所需要的只是一個足夠的流量。你增加的容量可以來自於自動擴充套件，手動增加容量，或者當你預測到負載變化時計劃增加容量。你很容易認為自動擴充套件是你需要的全部，但這有其侷限性。自動擴充套件可以在幾分鐘內建立新的例項，但DDOS攻擊可能在這段時間內完全結束，並擾亂你的可用性。對於長期的負載挑戰，如流量的意外增加或負載的季節性變化，自動擴充套件仍然是非常有用的。

Twitch上的一個熱門活動可以吸引一百萬或更多的觀眾。我們經常會收到關於這類事件的提前擴充套件通知，如果我們認為有必要，可以增加容量。然而，有些流量的增加是意外的，我們必須做好準備。對於Sage來說，我們對我們的供應水平和服務效率有信心，以應對短期的負載激增。在長期的負載挑戰中，一旦達到一定的服務錯誤閾值，我們會臨時增加容量。在新容量上線之前發生的任何服務錯誤都會被CDN的Sage Origin備份功能所覆蓋，不會影響到客戶。

更高的效率意味著更多的能力和更低的成本

效率在中世紀的戰爭中發揮了重要作用。長弓的到來在百年戰爭中發揮了巨大的作用，因為它射得更快，穿得更遠，同時製造起來也更容易，成本更低。

Sage是一個在Linux上執行的C#.NET核心服務，一直被認為是一個高效的服務。

我們的高階軟體工程師Felix Kastner看到了通過消除多餘的軟體層和分塊應用響應壓縮來獲得進一步效率的機會。他推測這些優化將使效能至少提高100%。實際的效能改進是5000%。這種恆定的50倍的效能提高意味著我們可以在降低成本的同時提高Sage的容量：由於每個例項能夠承載更多的負載，因此需要的數量更少。

創新和持續改進是關鍵

中世紀的戰爭比人們所描述的更為複雜，它需要不斷的創新來跟上時代的變化。像長弓和大炮這樣的新武器具有高度的破壞性，必須用新的防禦和戰略來應對。城邦僱傭了最好的人來設計武器和防禦措施。達芬奇被聘為軍事建築師和工程師，他為威尼斯和切薩雷-博爾吉亞發明了戰爭機器和防禦措施。

服務的可用性需要同樣的創新承諾。攻擊者不會停滯不前，你的防禦系統也不能。前面描述的Sage Origin Backup的創新使5個9的交付率成為可能。賽捷的優化創新使我們能夠在降低成本的同時提高容量。我們每週審查運營活動，問自己哪些方面需要改進。當一個破壞性的事件發生時，我們會充分分析錯誤的原因，以及為避免再次發生需要做的事情。

我們在一起：戰略性可用性決策

當Sage最初被配置時，可供選擇的AWS地區少得多。在我們的分析和按比例配置工作中，我們有機會在歐洲增加地區。我們增加新地區的主要動機是減少我們最繁忙地區的負擔，但由於我們有新地區的選擇，我們戰略性地選擇了它們，希望能看到延遲的改善。我們在AWS巴黎增加了Sage的存在，以改善法國的觀眾體驗，眾所周知，法國的內部連線良好，但與其他國家的連線較差。我們在AWS斯德哥爾摩增加了辦事處，以便更接近俄羅斯，一個擁有大量Twitch觀眾的國家。這些變化的延遲影響很大：歐洲的延遲減少了27%，俄羅斯的延遲減少了52%。

這說明了共同考慮可用性、延遲和安全性等領域的價值，而不是把它們當作孤立的主題。

經驗之談

像對待安全一樣對待高可用性，允許你使用威脅建模和其他安全工具來識別漏洞和設計防禦措施。實行深度防禦，以達到卓越的可用性覆蓋。

充分利用你的CDN來過濾惡意流量並建立故障轉移機制。也要準備好一個替代的CDN。測試你的故障轉移機制，以便你知道它們的工作。

超額配置作為一個長期的防禦，並準備在你需要時增加更多的容量。定期分析負載並調整你的分配。使用比例配置來平衡分配水平和成本。優化你的服務，以較低的成本增加容量。

測量可用性指標並投資於警報。調整你的警報，以避免錯誤的警報和不知情的情況。不要依賴你的常設防禦系統：準備好自動和手動反應。

即使有良好的保護措施，也不要對可用性感到自滿。致力於持續的創新和改進。審查操作，在事件發生後發明改進措施，並重復進行。