輕鬆構建基於 Serverless 架構的彈性高可用音視頻處理系統

前言

隨着計算機技術和 Internet 的突飛猛進,視頻點播技術因其良好的人機交互性和流媒體傳輸技術倍受教育、娛樂等行業青睞,而在當前, 雲計算平臺廠商的產品線不斷成熟完善, 若是想要搭建視頻點播類應用,告別刀耕火種, 直接上雲會掃清硬件採購、 技術等各類障礙,以阿里云爲例:html

1.png

這是一個很是典型的解決方案, 對象存儲 OSS 能夠支持海量視頻存儲,採集上傳的視頻被轉碼以適配各類終端,CDN 加速終端設備播放視頻的速度。此外還有一些內容安全審查需求, 好比鑑黃、鑑恐等。git

而在視頻點播解決方案中, 視頻轉碼是最消耗計算力的一個子系統,雖然您可使用雲上專門的轉碼服務,但在不少狀況下,您會選擇本身搭建轉碼服務。好比:github

  • 您已經在虛擬機/容器平臺上基於 FFmpeg 部署了一套視頻處理服務,可否在此基礎上讓它有更彈性、更高的可用性?
  • 您的需求只是簡單的轉碼需求,或是一些極其輕量的需求,好比獲取 OSS 上視頻前幾幀的 GIF、獲取視頻或者音頻的時長,本身搭建成本更低;
  • 各類格式的音頻轉換或者各類採樣率自定義、音頻降噪等功能;
  • 您有更高級的自定義處理需求,好比視頻轉碼完成後, 須要記錄轉碼詳情到數據庫, 或者在轉碼完成後, 自動將熱度很高的視頻預熱到 CDN 上, 從而緩解源站壓力;
  • 您有併發處理大量視頻的需求;
  • 您有不少超大的視頻須要批量快速處理完, 好比每週五按期產生幾百個 4G 以上的大視頻, 可是但願當天幾個小時後所有處理完;
  • 自定義視頻處理流程中可能會有多種操做組合, 好比轉碼、加水印和生成視頻首頁 GIF。後續爲視頻處理系統增長新需求,好比調整轉碼參數,但願新功能發佈上線對在線服務無影響;
  • 您的視頻源文件存放在 NAS 或者 ECS 雲盤上,自建服務能夠直接讀取源文件處理,而不須要將它們再遷移到 OSS 上。

若是您的視頻處理系統有上述需求,或者您指望實現一個彈性高可用低成本免運維靈活支持任意處理邏輯的視頻處理系統,那麼本文則是您期待的最佳實踐方案。
2.png數據庫

Serverless 自定義音視頻處理

在介紹具體方案以前, 先介紹兩款產品:編程

  • 函數計算:阿里雲函數計算是事件驅動的全託管計算服務。經過函數計算,您無需管理服務器等基礎設施,只需編寫代碼並上傳。函數計算會爲您準備好計算資源,以彈性、可靠的方式運行您的代碼,並提供日誌查詢、性能監控、報警等功能;
  • 函數工做流:函數工做流(Function Flow,如下簡稱 FnF)是一個用來協調多個分佈式任務執行的全託管雲服務。您能夠用順序,分支,並行等方式來編排分佈式任務,FnF 會按照設定好的步驟可靠地協調任務執行,跟蹤每一個任務的狀態轉換,並在必要時執行用戶定義的重試邏輯,以確保工做流順利完成。

免費開通函數計算,按量付費,函數計算有很大的免費額度。安全

免費開通函數工做流,按量付費,函數工做流有很大的免費額度。服務器

函數計算可靠的執行任意邏輯, 邏輯能夠是利用 FFmpeg 對視頻任何處理操做, 也能夠更新視頻 meta 數據到數據庫等。架構

函數工做流對相應的函數進行編排, 好比第一步的函數是轉碼, 第二步的函數是轉碼成功後,將相應 meta 數據庫寫入數據庫等。併發

至此,您應該初步理解了函數計算的自定義處理能力 + 函數工做流編排能力幾乎知足您任何自定義處理的需求,接下來,本文以一個具體的示例展現基於函數計算和函數工做流打造的一個彈性高可用的 Serverless 視頻處理系統,並與傳統方案進行性能、成本和工程效率的對比。負載均衡

簡單視頻處理系統

假設您是對短視頻進行簡單的處理, 架構方案圖以下:
3.png

如上圖所示, 用戶上傳一個視頻到 OSS, OSS 觸發器自動觸發函數執行, 函數調用 FFmpeg 進行視頻轉碼, 而且將轉碼後的視頻保存回 OSS。

OSS 事件觸發器, 阿里雲對象存儲和函數計算無縫集成。您能夠爲各類類型的事件設置處理函數,當 OSS 系統捕獲到指定類型的事件後,會自動調用函數處理。例如,您能夠設置函數來處理 PutObject 事件,當您調用 OSS PutObject API 上傳視頻到 OSS 後,相關聯的函數會自動觸發來處理該視頻。

附:簡單視頻處理系統示例工程地址

您能夠直接基於示例工程部署您的簡單音視頻處理系統服務,由於音視頻是強 CPU 密集型計算,強烈建議直接函數內存設置爲 3G(2vCPU),可是當您想要處理大視頻(好比test_huge.mov) 或者對小視頻進行多種組合操做的時候, 您會發現函數仍是大機率會執行失敗,緣由是函數計算的執行環境有最大執行時間爲 10 分鐘的限制,若是最大的 10 分鐘不能知足您的需求, 您能夠選擇:

  • 對視頻進行分片 -> 轉碼 -> 合成處理, 詳情參考:fc-fnf-video-processing, 下文會詳細介紹。
  • 聯繫函數計算團隊(釘釘羣號: 11721331) 或者提工單

    • 適當放寬執行時長限制
    • 申請使用更高的函數內存 12G(8vCPU)

爲了突破函數計算執行環境的限制(或者說加快大視頻的轉碼速度),引入函數工做流 FnF 去編排函數實現一個功能強大的全功能視頻處理系統是一個很好的方案。

全功能視頻處理系統-Example

4.gif

如上圖所示, 假設用戶上傳一個 mov 格式的視頻到 OSS,OSS 觸發器自動觸發函數執行, 函數調用 FnF,並行進行提取音頻文件,同時進行 avi,mp4,flv 格式的轉碼。 因此您能夠實現以下需求:

  • 一個視頻文件能夠同時被轉碼成各類格式以及其餘各類自定義處理,好比增長水印處理或者在 after-process 更新信息到數據庫等;
  • 當有多個文件同時上傳到 OSS,函數計算會自動伸縮, 並行處理多個文件;
  • 對於每個視頻,先進行切片處理,而後並行轉碼切片,最後合成,經過設置合理的切片時間,能夠大大加速較大視頻的轉碼速度;
所謂的視頻切片,是將視頻流按指定的時間間隔,切分紅一系列分片文件,並生成一個索引文件記錄分片文件的信息。
  • 結合 NAS + 視頻切片, 能夠解決超大視頻(大於 3G )的轉碼。

附:全功能視頻處理系統示例工程地址

固然, 具體的處理流程是能夠根據您的需求修改 fnf 工做流流程, 上面的只是一個示例。

示例效果:

5.gif

函數計算 + 函數工做流 Serverless 方案 VS 傳統方案

卓越的工程效率

自建服務

函數計算 + 函數工做流 Serverless

基礎設施

須要用戶採購和管理

開發效率

除了必要的業務邏輯開發,須要本身創建相同線上運行環境, 包括相關軟件的安裝、服務配置、安全更新等一系列問題

只須要專一業務邏輯的開發, 配合 FUN 工具一鍵資源編排和部署

並行&分佈式視頻處理

須要很強的開發能力和完善的監控系統來保證穩定性

經過 FnF 資源編排便可實現多個視頻的並行處理以及單個大視頻的分佈式處理,穩定性和監控交由雲平臺

學習上手成本

除了編程語言開發能力和熟悉 FFmpeg 之外,可能使用 K8S 或彈性伸縮( ESS ),須要瞭解更多的產品、名詞和參數的意義

會編寫對應的語言的函數代碼和熟悉 FFmpeg 使用便可

項目上線週期

在具體業務邏輯外耗費大量的時間和人力成本,保守估計大約 30 人天,包括硬件採購、軟件和環境配置、系統開發、測試、監控報警、灰度發佈系統等

預計 3 人天, 開發調試(2人天)+ 壓測觀察(1 人天)

彈性伸縮免運維,性能優異

自建服務

函數計算 + 函數工做流 Serverless

彈性高可用

須要自建負載均衡 (SLB),彈性伸縮,擴容縮容速度較 FC 慢

FC系統固有毫秒級別彈性伸縮,快速實現底層擴容以應對峯值壓力,免運維,全功能視頻處理系統 (FnF + FC) 壓測;性能優異, 詳情見下面的轉碼性能表

監控報警查詢

ECS 或者容器級別的 metrics

提供更細粒度的 FnF 流程執行以及函數執行狀況, 同時能夠查詢每次函數執行的 latency 和日誌等, 更加完善的報警監控機制

好比短視頻處理系統的監控的一個 Example:

5.gif

函數計算 + 函數工做流 Serverless 方案轉碼性能表

實驗視頻爲是 89s 的 mov 文件 4K 視頻:4K.mov,雲服務進行 mov -> mp4 普通轉碼須要消耗的時間爲 188s, 將這個參考時間記爲 T。

視頻切片時間

FC 轉碼耗時

性能加速百分比

45s

160s

117.5%

25s

100s

188%

15s

70s

268.6%

10s

45s

417.8%

5s

35s

537.1%

性能加速百分比 = T / FC轉碼耗時

從上表能夠看出,設置的視頻切片時間越短, 視頻轉碼時間越短, 函數計算能夠自動瞬時調度出更多的計算資源來一塊兒完成這個視頻的轉碼, 轉碼性能優異。

更低的成本

  • 具備明顯波峯波谷的視頻處理場景(好比只有部分時間段有視頻處理請求,其餘時間不多甚至沒有視頻處理請求),選擇按需付費,只需爲實際使用的計算資源付費;
  • 沒有明顯波峯波谷的視頻處理場景,可使用預付費(包年包月),成本仍然極具競爭力;
函數計算成本優化最佳實踐文檔
  • 假設有一個基於 ECS 搭建的視頻轉碼服務,因爲是 CPU 密集型計算, 所以在這裏將平均 CPU 利用率做爲核心參考指標對評估成本,以一個月爲週期,10 臺 C5 ECS 的總計算力爲例, 總的計算量約爲 30% 場景下, 兩個解決方案 CPU 資源利用率使用狀況示意圖大體以下:

6.png

由上圖預估出以下計費模型:

  • 函數計算預付費 3CU 一個月: 246.27 元, 計算能力等價於 ECS 計算型 C5;
  • ECS 計算型 C5 (2vCPU,4GB)+雲盤: 包月219 元;
  • 函數計算按量付費佔整個計算量的佔比 <= 10%,費用約爲 3×864×10% = 259.2 元,(3G 規格的函數滿負載跑滿一個月費用爲:0.00011108×3×30×24×3600 = 863.8,詳情查看計費)。

ITEM

平均CPU利用率

計算費用

總計

函數計算組合付費

>=80%

998(246.27×3+259.2)

<= 998

按峯值預留ECS

<=30%

2190(10*219)

>=2190

  • 在這個模型預估裏面,能夠看出 FC 方案具備很強的成本競爭力,在實際場景中, 基於 ECS 自建的視頻轉碼服務 CPU 利用甚至很難達到 20%, 理由以下:可能只有部分時間段有視頻轉碼請求;爲了用戶體驗,視頻轉碼速度有必定的要求,可能一個視頻轉碼就須要 10 臺 ECS 並行處理來轉碼, 所以只能預備不少 ECS;
  • 所以,在實際場景中, FC 在視頻處理上的成本競爭力遠強於上述模型;
  • 即便和雲廠商視頻轉碼服務單價 PK, 該方案仍有很強的成本競爭力

經實驗驗證, 函數內存設置爲3G,基於該方案從 mov 轉碼爲 mp4 的費用概覽表:

實驗視頻爲是 89s 的 mov 文件視頻, 測試視頻地址:
480P.mov 720P.mov 1080P.mov 4K.mov
測試命令: ffmpeg -i test.mov -preset superfast test.mp4
  • 格式轉換

分辨率

bitrate

幀率

FC 轉碼耗費時間

FC 轉碼費用

騰訊雲視頻處理費用

成本降低百分比

標清 640*480

618 kb/s

24

11s

0.00366564

0.032

88.5%

高清 1280*720

1120 kb/s

24

31s

0.01033044

0.065

84.1%

超清 1920*1080

1942 kb/s

24

66s

0.02199384

0.126

82.5%

4K 3840*2160

5250 kb/s

24

260s

0.0866424

0.556

84.4%

成本降低百分比 = (騰訊雲視頻處理費用 - FC 轉碼費用)/ 騰訊雲視頻處理費用

騰訊雲視頻處理,計費使用普通轉碼,轉碼時長不足一分鐘,按照一分鐘計算,這裏計費採用的是 2 min,即便採用 1.5 min 計算, 成本降低百分比也在 80% 左右。

從上表能夠看出, 基於函數計算 + 函數工做流的方案在計算資源成本上具備顯著優點。

操做部署

詳情見各自示例工程的 README:

總結

基於函數計算 FC 和函數工做流 FnF 的彈性高可用視頻處理系統自然繼承了這兩個產品的優勢:

  • 無需採購和管理服務器等基礎設施,只需專一視頻處理業務邏輯的開發,大幅縮短項目交付時間和人力成本
  • 提供日誌查詢、性能監控、報警等功能快速排查故障
  • 以事件驅動的方式觸發應用響應用戶請求
  • 免運維,毫秒級別彈性伸縮,快速實現底層擴容以應對峯值壓力,性能優異
  • 成本極具競爭力

Q & A

最後一一回答一下以前列出的問題:

Q1: 您已經在虛擬機/容器平臺上基於 FFmpeg 部署了一套視頻處理服務,可否在此基礎上讓它更彈性,更高的可用性?

A: 如工程示例所示,在虛擬機/容器平臺上基於 FFmpeg 的服務能夠輕鬆切換到函數計算, FFmpeg 相關命令能夠直接移值到函數計算,改形成本較低, 同時自然繼承了函數計算彈性高可用性特性。

Q2:您的需求只是簡單的轉碼需求,或是一些極其輕量的需求,好比獲取 OSS 上視頻前幾幀的 GIF 等。 本身搭建成本更低。

A: 函數計算天生就是解決這些自定義問題, 你的代碼你作主, 代碼中快速執行幾個 FFmpeg 的命令便可完成需求。
典型示例:fc-oss-ffmpeg

Q3: 您有更高級的自定義處理需求,好比視頻轉碼完成後, 須要記錄轉碼詳情到數據庫, 或者在轉碼完成後, 自動將熱度很高的視頻預熱到 CDN 上, 從而緩解源站壓力。

A: 詳情見全功能視頻處理系統(函數計算 + 函數工做流方案),after-process 中能夠作一些自定義的操做, 您還能夠基於此流程再作一些額外處理等, 好比:再增長後續流程;最開始增長 pre-process。

Q4: 您有併發同時處理大量視頻的需求。

A: 詳情見全功能視頻處理系統(函數計算 + 函數工做流方案), 當有多個文件同時上傳到 OSS, 函數計算會自動伸縮, 並行處理多個文件。詳情能夠參考全功能視頻處理系統 (FnF + FC) 壓測

Q5: 您有不少超大的視頻須要批量快速處理完, 好比每週五按期產生幾百個 4G 以上的大視頻, 可是但願當天幾個小時後所有處理完。

A: 詳情能夠參考全功能視頻處理系統 (FnF + FC) 壓測,  能夠經過控制分片的大小, 可使得每一個大視頻都有足夠多的計算資源參與轉碼計算, 大大提升轉碼速度。

Q6: 自定義視頻處理流程中可能會有多種操做組合, 好比轉碼、加水印和生成視頻首頁 GIF,後續爲視頻處理系統增長新需求,好比調整轉碼參數,但願新功能發佈上線對在線服務無影響。

A: 詳情見全功能視頻處理系統(函數計算 + 函數工做流方案), FnF 只負責編排調用函數, 所以只須要更新相應的處理函數便可,同時函數有 version 和 alias 功能, 更好地控制灰度上線,函數計算版本管理

Q7: 您的視頻源文件存放在 NAS 或者 ECS 雲盤上,自建服務能夠直接讀取源文件處理,而不須要將他們再遷移到 OSS 上。

A:函數計算能夠掛載 NAS, 直接對 NAS 中的文件進行處理。

相關文章
相關標籤/搜索