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

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

原文來自《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.

 

 

 


上雲猶如太空探險之旅,iKala Cloud AIOps Services協助企業輕鬆穿梭多雲環境

人類從上個世紀積極探索外太空,為了將太空人送上天際必須克服各式挑戰,而現代企業要從「地端」飛向「雲端」,困難程度有過之而無不及。iKala Cloud AIOps Services 提供多項關鍵服務,幫助 IT 團隊輕鬆悠遊多雲環境。
評論
評論

探索外太空,曾經是國際間的科技競賽,近年 Tesla 創辦人馬斯克更準備把太空旅行當成商業服務,預計 2026 年要帶著人類登陸火星。完成一趟星際旅行,需仰賴嶄新的科技及跨科學精密計算,但你知道嗎?現代企業要從「地端」飛上「雲端」,其實挑戰程度不亞於飛向太空。

對企業資訊管理者來說,有限的 IT 資源無法應付繁重的維運項目,加上同時管理公私有雲架構更顯困難、資安管理複雜,例如需要人工執行過濾警示,各種大大小小挑戰不勝枚舉。換言之,企業想航行雲端,就像打造火箭需要龐大資源及人力。不過,現在有更輕鬆穿梭雲端的方式,就是使用雲端技術服務商 iKala 所提供的 AIOps Services(自動化雲端託管服務)

火箭升空前的全盤規劃:iKala AIOps 擬定系統架構規劃、教育訓練

完成一趟太空之旅,必須做足各種研究,例如精準計算飛行軌道、降落定位點、燃料耗用數、與地球通訊設定…等。

對沒有雲端架構經驗的企業來說,就如同當時的科學家,必須用土法煉鋼的方式檢查數據是否有誤。換言之,企業 IT 在升級之前,就需要有經驗的「雲端顧問」來釐清需求、協助規劃「升雲」之旅。而 iKala 就是企業的最佳雲端顧問,旗下 iKala Cloud AIOps Services 會搭配一位專責的技術客戶經理,協助企業提供即時的技術服務與專業建議。

究竟 IT 升級之前,iKala Cloud AIOps Services 有哪些服務?首先是「系統設計規劃」,涵蓋系統架構規劃書、系統上線/遷移計畫書,可因應客戶產業需求,提供對應的解決方案以及顧問服務。而越來越多企業會使用到 Google 的雲端資源,iKala 也有提供 Google 雲端平台訓練服務。

GCP 教育訓練課程多元,包含 GCP 基礎架構(網路設定規劃、權限控管、計算資源等)、大數據與機器學習(大數據分析 Pipeline、BigQuery、ML 模型訓練與應用)、軟體開發技術與流程(容器化、CI/CD、DevOps)等。因為 iKala 團隊取得 10 多項 Google 專業技術證照,才能在企業規劃雲端轉型的前期就一步到位,規劃出整體藍圖,提供更全面的解決方案建議。

火箭升空中的精密操作:iKala AIOps 輔助即時技術維運、資安管理

當火箭準備就緒、升空倒數之際便是決定這趟太空之旅能否成功的關鍵時刻。從太空人的行前訓練與身體檢查,到火箭的引擎測試完成,如果有靜電或一點火花都可能引發爆炸事故。光是在升空階段,太空總部就要有結構、熱控、姿態控制、資料處理、電能、遙傳指令、推進以及飛行軟體等龐大的系統工程師在旁待命。

換言之,企業 IT 移轉雲端過程就像火箭發射的當下,需要有專業、經驗足夠的工程師,才能即時協助企業順利上雲,甚至快速排除緊急的狀況。對此,iKala Cloud AIOps Services 提供兩大關鍵的幫助:技術維運、資訊安全管理。

iKala Cloud AIOps Services 的技術維運服務內容,提供 7 x 24 的 Help Desk,像是緊急 GCP 問題報修、產品使用技術諮詢;或是事故管理,如搭建監控系統、設定規劃告警政策、規劃日誌收集與留存。每月也會提供企業維運報告,報告書有營運效率檢討、流程優化、新服務項目、營運系統建議等。

至於資訊安全管理方面,除了基本的 GCP 專案權限控管掃描、應用程式 OWASP(Open Web Application Security Project)前 10 大項目資安弱點掃描,同時也針對近年相當受重視的 DDoS 防護,iKala 可協助企業導入 GCP 平台的 DDOS 防禦機制。iKala 掌握多年軟體開發和雲端管理經驗,可分享給客戶 DevOps、AI 第一手實務的作法與經驗。

火箭升空後啟動自動導航:iKala AIOps 提供 AI 自動化監控、帳務管理

當火箭成功升空後,太空人為了執行下一階段任務,這時候火箭就需要轉換成自動駕駛模式,或在探索其他星球時,出動機器人來協助執行人力無法負荷的任務,讓太空人專心處理更關鍵的工作。換言之,上雲後的 IT 架構就像升空後的火箭,應該減少 IT 人員的負擔,甚至不需浪費例行時間,就能夠快速掌握整體資訊系統的運作狀況。

不過要讓 IT 架構像火箭具備自動駕駛功能,勢必需要相當高的技術門檻,而 iKala Cloud AIOps Services 正好有相對應的服務。如此一來,IT 人員的生產力就能投入在更具商業價值的研發專案,讓 IT 部門轉型成可創造產值的單位,而非單純的後勤支援角色。

盤點 iKala Cloud AIOps Services 在此環節共有三大類服務。其中一項是 AI 自動化監控與通報服務,幫助 IT 成員主動監控系統,掌握是否有異常操作狀況。其二是帳務方面的管理,幫助企業產出雲端服務月用量帳務分析報告,針對軟體授權需求,整合出帳至  Marketplace 與第三方服務商,自動化做到 License 採購管理。

第三項則是針對服務級別協定(SLA)iKala Cloud AIOps Services 提供 24 x 7、5 x 8 兩種模式,在重大 GCP 服務異常中斷服務時,提供電話、e-mail 聯繫。而且每月會舉辦 1 次月會(以 on-site 或遠端視訊會議方式)提交書面報告。目前 iKala 的企業客戶服務超過 400 多家、涵蓋數 10 種產業,可說是企業成功上雲,最能安心託付的合作夥伴。 

事實上,雲端託管服務(CMS)是目前最夯的新趨勢,根據市調公司 MarketsandMarkets Research 報告指出,全球雲端託管服務的市場規模,預計從 2020 年的 624 億美元,到 2025 年成長至 1,162 億美元,複合年增長率(CAGR)為 13.3%。代表未來有大量企業採用 CMS,以降低 IT 基礎設施的投資成本及風險,藉此提升企業營運的競爭力。

由此看來,企業的數位轉型,就像上個世紀的太空軍備競賽一樣。「時間就是決勝點」,越晚起步的公司與其他數位能力領先群的企業相比,差距只會越來越大。現在就攜手 iKala 嘗試 iKala Cloud AIOps Services,打造穩定的 IT 系統、邁向數據驅動的商業模式,讓企業在數位世代站穩腳步,輕鬆穿梭多雲之間。

了解更多 iKala Cloud AIOps Services