Facebook 直播如何撐起瞬間 80 萬人的流量?

評論
評論

原文來自《How Facebook Live Streams To 800,000 Simultaneous Viewers》,Inside Mia 獲授權編譯。

知道怎麼打造世界級散佈式服務(distributed service)的公司,可能比擁有 核武 的國家還少。Facebook 不僅是其中的佼佼者,而它新推出的直播功能就是一項散佈式服務。

Facebook 執行長 Mark Zuckerberg 就曾經說過:

我們做了重大決定,就是把在影片的努力轉而聚焦到直播上,因為它是接下來的新格式,而非已經存在線上 5 -- 10 年的那種影片。我們正進入影片的新黃金年代,我相信往前快轉 5 年,很有可能 Facebook 上使用者每天分享的內容幾乎都是影片。

如果你在廣告業,還有什麼比沒有盡頭、一直在成長,而且免費產生的內容更適合拿來放廣告呢?這就像 Google 在網路指數成長時,為各網站提供廣告所開拓的市場一樣。

Facebook 的直播技術堅強,就像 BuzzFeed 在 Facebook 直播用橡皮筋爆西瓜,最高達 80 萬人同時在線上收看,共有 30 多萬條留言。這也是在 15 億使用者的社群網路上才看得到的病毒傳播效應。

作為參考, 2015 年的超級盃共有 1.14 億觀眾收看,平均有 236 萬人在看直播;2015 的 E3 電玩展則同時有 84 萬人在 Twitch 上收看;而 9 月 16 日的共和黨辯論最多有 92.1 萬人同時在收看直播。

與此同時, Facebook 上還有其他大量的直播正在發生。那麼 Facebook 到底投注了多少資源在直播上呢?

根據 Facebook 的產品長 Chris Cox 在 Wired 報導上提到:

有超過百人在直播底下工作。一開始在 12 人左右,到現在已經有超過 150 名工程師。

要能同時處理上百萬條直播而不當機。

要能負擔一條直播上的數百萬位觀眾,還要在全球不同的裝置和網路提供商間無縫同步播出。

Cox 也承認「結果基礎架構的問題真的不好解決。」

要是我們能知道這些基礎問題是怎麼解決的,應該會很有趣。

Facebook 流量團隊的 Federico Larumbe,就在 Facebook 技術部落格上發表了《Scaling Facebook Live》,裡面提到了直播運作的細節。

原文相當精彩,重點節錄如下:

起源

  • Facebook 開了一個新功能,讓使用者能分享即時影片。(注意,在這裡直播對 Facebook 來說就是一個功能而已)
  • 2015 年 4 月只能透過 Mention app 直播,而且限定名人專用。
  • 隨後便展開長達一年的改進與協定的變動。
    • 他們從 HLS(HTTP Live Streaming)開始,iPhone 可支援,而且他們也可以使用現有的內容傳遞網路。
    • 同時開始研究 RTMP (Real-Time Messaging Protocol,即時訊息傳送協定) ,這是一種基於 TCP 的協定。分別有一條音訊串流和視訊串流從手機傳送到直播伺服器。
      • 優點:RTMP 在直播主和觀眾間點對點的延遲較低,在互動式的直播上特別有幫助。降低延遲也能提升整體的體驗。
      • 缺點:因為不是基於 HTTP,所以需要全新的架構。要規模化一定要架個新的 RTMP 代理。
    • 另外也研究了 MPEG-DASH(基於 HTTP 的動態與適應性媒體串流)
      • 優點:比 HLS 省 15% 的空間。
      • 優點:自動調整傳輸率,會根據網路狀況改變傳輸品質。
  • 2015 年 12 月在數十個國家展開服務。

直播影片很特別,也帶來許多問題

  • 拿一開始的西瓜影片流量表現為例:
    • 在一開始流量上升得很快,數分鐘內就達到每秒超過 100 個請求,直到影片結束都持續上升。
    • 影片一結束流量就直直落。
    • 簡而言之:瞬間流量很大。
  • 直播影片和一般影片不一樣:它會產生瞬間流量。
    • 直播影片和觀眾的連結更深,所以通常觀看次數比一般影片多 3 倍。
    • 直播影片會被推到資訊牆最上方,所以被看到的機會也比較高。
    • 專頁的所有粉絲都會收到直播通知,又吸引到一批可能會來看影片的觀眾。
  • 瞬間流量會對 cache(暫存)系統和負載平衡系統造成問題。
  • Cache 的問題
    • 很多人同時想要收看你的直播,導致經典的「驚群效應」(Thundering Herd problem),大量等待中的處理程序同時被喚醒,卻只能一次處理一項。
    • 大量瞬間流量會對 cache 系統造成壓力。
    • 一部串流影片被分割成很多一秒的小檔,流量飆高時,暫存這些分割檔的伺服器可能會超載。
  • 全球負載平衡系統的問題
    • Facebook 在全世界都有分布 PoP ,Facebook 的流量是分散到全世界的。
    • 所以挑戰在於避免瞬間流量灌爆其中一個 PoP。

整體架構

這裡是直播如何從直播源散佈給上百萬觀眾的過程。

  • 直播主從手機開了一條直播。
  • 手機傳了 RTMP 串流到直播伺服器。
  • 直播伺服器解碼影片後轉換成各種傳輸率的影片。
  • 每種傳輸率都創造一組 MPEG-DASH 的連續數個一秒鐘片段。
  • 這些片段都存在資料中心的暫存裡。
  • Cache 暫存從資料中心傳送到各個 PoP 暫存。
  • 觀眾收到直播。
  • 觀眾手機上的播放器以每秒一次的頻率開始從 PoP 接收片段。

要怎麼規模化?

  • 從資料中心到 PoP, 端點數會增加 非常多。使用者會存取 PoP 暫存而非資料中心暫存,而 PoP 是分佈在全世界的。
  • 另外 每個 PoP 內部還會再細分
    • 每個 PoP 內部都 分成兩層 :一層是 HTTP 代理,另一層是暫存。
    • 觀眾從 HTTP 代理請求片段。代理會檢查片段有沒有在暫存裡面,有的話就會回傳片段,沒有的話就會往回向資料中心請求片段。
    • 不同的片段存在不同的暫存, 所以能讓不同的 host 負載平衡。

保護資料中心免於驚群效應

所有觀眾同時要求同一個片段會發生什麼事?

  • 如果片段不在暫存裡,每個觀眾都會向資料中心發出一筆請求。
  • Request Coalescing(回應聯合)。 透過在 PoP 暫存增加 request coalescing 來減少請求的數量。只有第一個請求會傳到資料中心,其他的請求會被攔下,直到第一個請求到了資料中心,然後資料回傳到所有觀眾手上。
  • 代理會加上一層新的暫存,來避免伺服器過熱。
    • 所有的觀眾會被送到一台暫存 host 去等待接收,這可能會導致 host 過熱。
    • 代理加了一層暫存層。 只有第一個到代理的請求會成功要到暫存。其他的請求會直接由代理處理。

PoP 還是身陷險境:靠全球負載平衡來拯救

  • 所以資料中心免於驚群效應的問題,但是 PoP 還是暴露在危險中。問題在於,PoP 的負載衡量結果到達負載平衡器之前,流量可能就已經灌爆 PoP 了。
  • 每個 PoP 都有限制伺服器和連線的數量。瞬間流量要如何不灌爆 PoP?
  • 一個叫做 Cartographer 的系統會描繪網際網路到 PoP 的子網路。它會衡量每個子網路和 PoP 間的延遲。
  • 測量每個 PoP 的負載後,每位使用者就會被傳送到附近能夠負載的 PoP 。代理有計數器會記錄他們收到多少負載。這些計數會累計,所以我們可以知道每個 PoP 的負載。
  • 現在現在出現了一個最佳化問題,我們要在負載限制下同時降低延遲。
  • 用控制系統,可以分為測量的延遲和反應的延遲。
  • 他們把負載測量間隔從 1.5 分鐘縮短到 3 秒鐘,但是這樣仍舊有 3 秒鐘的空窗。
  • 解決辦法是 在發生之前先預測負載
  • 依據先前及當下的負載, 負載估計器 會預測未來的負載量。
    • 如果現在的流量是上升,預測器要怎麼才能預測到流量下降?
    • 在插入函式 使用三次樣條函數(Cubic spline)。
    • 利用一階和二階導數。如果速度是正的,那負載量就會增加,如果加速度是負的,就表示速度下降,最後負載會開始降低。
    • 三次樣條函數能預測比線型函數更複雜的流量模式。
    • 避免波動 。這個插入式也可以解決波動的問題。
    • 測量和反應的延遲,表示會依據不夠及時的數據做決定。插入式函數能減少錯誤,讓預測更準確,並降低波動。所以負載量能更接近目標。
    • 現在是根據過去的三個區間來做預測,每個區間間隔 30 秒。幾乎是等於即時的負載量。

測試

  • 首先你要能讓一個 PoP 過載。
  • 負載測試分散在全球的 PoP 上,好模擬直播的即時流量。
  • 要能模擬目前負載量的 10 倍。
  • 要能模擬一位一次請求一個片段的觀眾。
  • 這個系統能找出並修補負載估計器的問題、調整參數,並驗證暫存層能否克服驚群效應。

上傳的穩定性

  • 即時上傳影片很有挑戰性。
  • 舉一個頻寬介於 100 -- 300 Kbps 的上傳為例。
  • 音訊總共要 64 Kbps。
  • 標準畫質的視訊共要 500 Kbps。
  • 利用手機上的適應性編碼來調整音訊加視訊的不足。影片的傳輸率編碼會根據網路頻寬調整。
  • 手機端會測量 RTMP 上傳位元,來決定上傳的傳輸率,並且根據上個區間的平均來加權。

未來的方向

  • 研究推送機制,而非 request-pull 機制。在請求片段之前就利用 HTTP/2 推送至 PoP。

相關文章

On HackerNews

Scaling Facebook Live

Why Facebook And Mark Zuckerberg Went All In On Live Video

Connecting the World: A look inside Facebook’s Networking Infrastructure

Gamoloco tracks live video stats for 1476093 channels.

 

 

 


精選熱門好工作

營運工讀生 (Part-time Intern)

Wanted
臺北市.台灣

獎勵 NT$4,000

行銷企劃專員 (網站活動)

VeryBuy非常勸敗
臺北市.台灣

獎勵 NT$20,000

整合行銷經理

FunNow
臺北市.台灣

獎勵 NT$20,000

評論