Hulu 技術團隊在過去的一年中，進行了大量系統準備與改進工作，期望提供更穩定，更高質量的大型比賽直播。

文/ Brandon Lonac、Raymond Khalife、Kalyani Narayanan、Travis McCann、Justin Goad

譯/ 元寶

原文 https://medium.com/hulu-tech-blog/streaming-the-super-bowl-preparing-hulus-systems-and-operations-for-the-biggest-game-of-the-year-5ce10e1923f6

大約一年前在博客中，我們曾概述了如何在一些大型活動中擴展我們的實時流服務，如“March Madness”等。

從那時起，Hulu在美國的用戶量已經超過了2500萬，我們幾乎每一次重大活動都在打破自己的并發記錄。進入2019年，我們知道超級碗將再次打破紀錄，所以我們不得不為今年規模最大的體育賽事做好準備 —— 取得了很大的收獲：Hulu今年觀看超級碗比賽現場直播的觀眾人數是2018年的四倍，我們成功地為觀眾在他們喜愛的設備上提供了穩定、高質量的大型比賽直播。

在過去的一年里，Hulu技術團隊專注于三個關鍵領域，我們逐步完善了準備工作的整體方案：

• 改進負載預測：提高我們為任何特定事件準確預測系統負載的能力。

• 快速擴展我們的系統：按需增強關鍵系統，或者在沒有選擇的情況下提供冗余。

• 戰爭游戲和戰術準備：改進為大型電視直播活動做準備的最佳實踐。

利用歷史收視率數據改進并發預測

今年，我們利用上個賽季的數據來預測并發收視率。通過獲取歷史收視率數據，并將其與用戶增長估計相結合，我們能夠對每周的并發性預測進行建模。在整個2018-2019賽季，我們的估計與實際相比有+/- 10％的錯誤率。我們還構建了一個并發收視率矩陣，并將其推斷為關鍵路徑系統的每秒請求數。結合這兩種新功能，我們可以更好地了解什么系統需要擴展、擴展多少以及何時擴展。

該模型給出了預測的最小、最大和平均范圍的置信區間。當我們接近實際日期時，置信區間會變得更小，直到得到這樣的結果：

使用混合云的方法擴展我們的平臺

Hulu的大部分服務都運行在內部PaaS上，我們稱之為Donki，它利用了數據中心的Apache Mesos / Aurora和云中的容器編排系統。Donki將服務打包成容器，相同的容器可以在我們的數據中心和云中運行。雖然我們最近將部分最高流量服務遷移到了云中，但我們能夠在可能的故障轉移方案中利用我們的數據中心。Donki允許我們根據特定服務的需要輕松地將部署協調到任一環境中。我們專注于利用云中的自動擴展功能來更好地處理意外的流量激增，從而保持我們的系統良好運行。

我們利用自動擴展的兩種方式：

• 擴展承載服務的集群。

• 擴展服務本身。

承載服務的集群可以通過添加或刪除計算機來自動擴展。自動擴展必須根據規則進行，它是根據CPU和內存預留閾值來收縮或增長。

服務本身將通過添加或刪除實例來自動擴展，具體取決于每個實例的每分鐘請求數、每個實例的CPU使用率或每個實例的內存使用量等指標。我們的生產工程團隊負責可觀察性和模擬(混亂)，他們運行負載測試來發現每個實例的容量，并與團隊合作設置適當的自動伸縮規則。

我們需要擴展的關鍵服務領域之一是支持用戶發現體驗的堆棧。我們采用了靈活的方法，根據流量預測和自動化的定期性能測試來擴展系統，以逐步加載和加速整個端到端堆棧。為了幫助服務團隊做到這一點，我們的生產準備小組提供了兩個功能：

1. 適用于具有真實測試模擬的團隊的負載測試工具。

2. 在整個服務堆棧中協調端到端的壓力測試。

這是一項巨大的工作，它解放了團隊，使他們能夠專注于特定的擴展需求。

?

我們的系統具有不同的架構域，這些域需要單獨或整體進行擴展。我們從壓力測試開始，找到這些領域和整個系統的弱點。這導致了一個中斷/修復周期，因為我們鞏固了系統的每個域。自動化系統范圍的測試每周運行多次。這允許快速迭代驗證在以前的運行中發現的團隊修復。各個團隊還能夠獨立地對其服務進行壓力測試，以便在運行更大規模測試之前驗證改進。由于域中的所有服務都使用Donki（我們的PaaS），因此很容易對每個應用程序集群的大小進行微調。然后，工作可以集中在應用程序優化和調整應用程序集群和規模參數上。

一旦系統能夠處理預期的負載，我們就開始進行峰值測試，以模擬大量用戶在游戲開始時登錄或模擬播放失敗。

不同的域以不同的方式擴展。探索體驗側重于個性化、元數據豐富的響應。在向數百萬用戶擴展時，這可能會出現問題。目標是在那個時刻為用戶提供最好的響應。我們專注于緩存基線響應，然后在此基礎上進行個性化，以確保查看者找到他們想要的內容。我們從頭開始對系統進行了功能降低。為了實現系統所需的規模，我們做出了這些架構設計決策。

1. 使用異步/非阻塞應用程序框架

2. 使用斷路器、限速和減載模式

3. 同時使用本地和分布式緩存

4. 內聚客戶端行為

我們的API網關和邊緣服務使用的是基于JVM的異步事件驅動的應用程序框架和斷路器。這允許一次針對單個應用程序實例打開數千個連接。如果太多的請求保持打開時間太長，就會導致內存壓力。所有應用程序都處于無響應的狀態。我們使用壓力和峰值測試來微調對系統的速率限制請求，以保護系統免受過多流量的影響。這允許系統在極端尖峰期間繼續運行，并為用戶提供自動，而不是在壓力下崩潰并且不為任何人服務。如果用戶流量超出了我們的速率限制，我們的系統將開始減輕負載。如果需要丟棄請求，我們的API層中的斷路器將跳閘并將請求發送到后備集群。這是我們核心客戶端應用程序體驗的高度緩存版本，支持對我們唯一用戶的請求。Discovery Experience的主要目標是返回響應，這種模式組合有助于確保這一點。

為了實現低延遲響應和大規模的Discovery Experience，緩存是非常依賴的。節點既使用基于本地JVM的緩存，也使用分布式緩存。節點緩存響應基于MRU和TTL的元數據。在緩存丟失或刪除的情況下，將從分布式緩存中獲取數據。這種對不同緩存的組合使用有助于使Fallback體驗幾乎與正常響應幾乎沒有區別。

這將我們帶到最后一點，即客戶行為的內聚力。使用定義的和一致的服務器API，客戶端也可以幫助擴展。考慮到HTTP響應代碼和報頭，客戶端可以幫助防止在錯誤情況下進行轟擊，并在錯誤場景中生成更多的負載。在過去，我們已經看到了各種客戶機中不一致的錯誤處理邏輯可以做什么。在調用API時使用指數級后退和可變時間量等策略是客戶端可以幫助擴展的簡單方法。這似乎是一種合理的方法，但它需要與我們擁有的眾多客戶協同努力。它還需要關于API應該多久進行通信的最佳實踐。

準備故障轉移流以實現運營準備和冗余

我們花了很多時間對系統進行壓力測試和擴展，但事情并不總是按照計劃進行。這就是為什么我們總是計劃冗余，特別是在視頻播放等關鍵領域，這也是我們系統的核心，我們的目標是確保源流本身的最高可用性。基于內容合作伙伴，源流路徑的架構可能大不相同，并且每個工作流本身都面臨著不同的挑戰。因此，確保為實時流實現多個故障轉移選項是絕對有必要的。

實施這些額外的信號通路需要與我們的信號提供商和合作伙伴密切合作。我們遵循的一些最佳實踐是為實時流建立多個非交叉信號路徑，確保故障轉移腳本經過了充分的測試，并且可以在幾秒鐘內執行源流之間的切換，并保留實時和DVR體驗為確保用戶在故障轉移時沒有任何問題。

除了為大型活動做好準備所涉及的所有技術之外，為我們的組織做好準備也至關重要。隨著我們的規模不斷擴大，我們采用的一項新舉措是，在壓力測試故障情景下定期進行桌面練習，以幫助團隊更好地準備和從潛在的中斷中恢復。Wargaming已被證明是一個非常有教育意義的過程，可以建立一個持續運營的準備文化，并確保我們的Runbook全部搞定。這種做法還揭示了我們需要為更多的失敗情景制定緩解計劃。我們確定了許多團隊所需的短期和長期工作，我們將繼續跟蹤這些團隊的未來。

超越超級碗——使我們的準備工作自動化

我們一直在提高我們為大型活動提供服務的嚴謹性和紀律性。整個技術組織的團隊花費了無數的時間來準備我們的系統，以供越來越多的觀眾使用。

我們得到的一些關鍵結論是:

• 通過自動化我們的生產負載測試，我們能夠建立始終做好準備的一致性并進一步推動自己。

• 持續改進我們的預測確實有助于推動團隊需要提供的結果。

• 通過為負載測試提供一個中央平臺，我們解放了工程師的精力，讓他們專注于如何更好地架構和重構系統以適應規模。

這些努力的結果讓人們對今年的超級碗更加有信心，但這個過程仍然涉及一些手動元素隨著2019年剩余時間的推進，我們計劃將更多時間用于自動化和這些領域的改進。最終，我們希望我們的預測能夠自動優化容量預測，以考慮更多的變量。我們還計劃將負載測試更多地集成到我們的CI / CD管道中，并在一致的基礎上擴展我們測試的場景，以獲得更好的可靠性。盡管大型活動可能總會有一些疏忽，但我們的目標是盡可能多地準備和自動化，以使得我們的團隊更有效率和過程更加簡化。

點擊【閱讀原文】或掃描圖中二維碼了解更多LiveVideoStackCon 2019 上海 音視頻技術大會 講師信息。

總結

以上是生活随笔為你收集整理的Hulu：如何实现大型比赛直播系统自动扩容的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。