Vimeo發(fā)布新轉(zhuǎn)碼基礎(chǔ)設(shè)施Falkor——降低成本的同時將速度推向極限。

Vimeo的下一代轉(zhuǎn)碼基礎(chǔ)設(shè)施Falkor現(xiàn)已登場，標志性的形象是充滿上個世紀80年代風格的狗頭龍身。它不僅比前代方案更快、更可靠，也拉開了通往云原生未來的序幕。關(guān)于Falkor的一切，本文將為您一一揭曉。

從歷史說起

Falkor的前任方案是Tron轉(zhuǎn)碼技術(shù)棧，這套技術(shù)棧可以追溯到2013年。Tron具有以下特點：

?能輸出帶有音頻和視頻的漸進式MP4格式。

?會將整個源文件下載到本地，將其轉(zhuǎn)碼為所需的profile，再將結(jié)果上傳至云存儲。

Tron是為前云時代的Vimeo所量身打造，當時我們還在運營自己的數(shù)據(jù)中心（也配合使用一部分競價實例以優(yōu)化運營成本）。但如今，我們已經(jīng)全面轉(zhuǎn)向Google Cloud。

盡管Tron已有10年歷史，但我們并不打算讓它徹底“退休”。某些Falkor無法處理的極端情況，還是要勞Tron的大駕。關(guān)于更多具體情況，我們將在后文中詳細介紹。

為什么選擇Falkor?

這套全新基礎(chǔ)設(shè)施的雛形發(fā)源于2011年，甚至比Tron的誕生還要早。但我們直到2019年底才在這個方向上全面發(fā)力，希望借Falkor項目達成以下幾個目標。

將原始源文件直接作為輸入

這一點屬于對Tron開發(fā)工作的延續(xù)，希望盡可能使用原始源文件作為轉(zhuǎn)碼輸入，從而最大限度提升輸出質(zhì)量。畢竟夾層文件是轉(zhuǎn)碼的產(chǎn)物，而轉(zhuǎn)碼本身是個有損過程。所以跟直接使用原始源文件相比，使用夾層作為后續(xù)轉(zhuǎn)碼源會降低視頻質(zhì)量。

實現(xiàn)并行化和分布式轉(zhuǎn)碼

并行化與分布式轉(zhuǎn)碼的本質(zhì)，就是把視頻拆分成一個個更小的片段，分別在我們的服務器上進行轉(zhuǎn)碼。在完成所有轉(zhuǎn)碼之后，再把各片段組合起來以創(chuàng)建最終輸出（參見圖一）。這樣不僅轉(zhuǎn)碼速度更快，從錯誤中恢復的能力也更強。

圖一：并行化和分布式轉(zhuǎn)碼過程。

我們希望新的基礎(chǔ)設(shè)施能繼續(xù)使用成本低廉的臨時競價實例，延長舊有Tron設(shè)施的使用周期。競價實例不提供容量保證，但成本比按需實例低得多，價格普遍在后者的50%以下，也有助于對可用資源的快速變化做出響應。在Vimeo的用例中，使用競價實例意味著某些轉(zhuǎn)碼作業(yè)會被中途取消；但配合并行化與分布式轉(zhuǎn)碼，只需重新執(zhí)行一小部分即可順利完成視頻轉(zhuǎn)碼。

此外，Google等云服務商大多支持按秒（首分鐘之后）支付實例費用。也就是說，運行單一實例1個小時和運行10個實例各6分鐘，其資源價格基本相當，但并行轉(zhuǎn)碼的總體耗時會短得多。

邁向云原生

之前提到，Tron是專為前云計算時代的Vimeo所設(shè)計，那時候的云環(huán)境還有很多問題，所以立足本地基礎(chǔ)設(shè)施是個非常合乎邏輯的選擇。但現(xiàn)在既然決定上云，我們當然要充分利用云服務商提供的方案。這樣能大大削減需要自主管理的本地基礎(chǔ)設(shè)施，但代價就是我們得提防別陷入供應商鎖定的陷阱。一旦過度依賴當前云服務商的復雜技術(shù)體系，那么我們后續(xù)會很難遷移至其他云服務商。

盡可能使用競價實例

如前所述，使用競價實例有助于降低成本，同時不會顯著影響轉(zhuǎn)碼時間。

將音頻和視頻分別存儲，生成碎片化的MP4輸出

將音頻和視頻分別輸出，讓我們得以輕松訪問音頻和視頻流。

如果音頻只需要被提取和存儲一次（而非與視頻混合或合并），那我們的打包壓力就會小得多，也能節(jié)約存儲成本。（傳統(tǒng)上，音頻和視頻會被存儲在同一文件內(nèi)，導致不同視頻質(zhì)量或還原度版本中都要單獨保存一份音頻。）

使用碎片化視頻，我們可以輕松將視頻文件切割成多個片段，這種存儲方式能降低打包程序的運行難度。

但這里也有新的權(quán)衡，音頻與視頻拆分會提高漸進式文件的交付難度，挑戰(zhàn)我們將音視頻即時合并的能力。

使用標準工具進行開發(fā)和部署

為團隊和公司內(nèi)其他部門提供一組類似的工具（語言、庫、編排等）服務，確保我們的基礎(chǔ)設(shè)施更易于維護、充分發(fā)揮其他服務和團隊的產(chǎn)出成果，從整體上降低設(shè)施復雜性。

Tron仍依賴于Python 2等已被棄用的技術(shù)。

Falkor宏觀架構(gòu)解析

下面，我們用圖文詳解的方式聊聊Falkor的宏觀架構(gòu)。圖二所示，為Falkor各組件與其他服務間的交互關(guān)系。

圖二：Falkor組件。

圖三所示，為Falkor作業(yè)的端到端流程。

圖三：Falkor流程圖。

下面是Falkor的具體轉(zhuǎn)碼步驟。

步驟1

客戶端通知我們的視頻API使用profile集列表，對視頻數(shù)據(jù)進行轉(zhuǎn)碼。Profile集的確切列表視具體用例而定。例如，并非所有視頻都可使用AV1格式。

步驟2

我們的視頻API會執(zhí)行一系列檢查，包括獲取視頻源位置、要求Falkor API運行分析作業(yè)等。檢查會返回元數(shù)據(jù)，包括視頻時長、編解碼器、幀率、視頻是否為HDR等。這些元數(shù)據(jù)將被放入云存儲，以供后續(xù)轉(zhuǎn)碼作業(yè)重復使用。

步驟3

視頻API從分析作業(yè)處接收元數(shù)據(jù)，并確定需要運行哪些轉(zhuǎn)碼音頻和視頻profile：使用哪些分辨率、是否啟用HDR等。這些profile各自擁有對應的新Falkkor API作業(yè)。

音頻作業(yè)在音頻轉(zhuǎn)碼工作器上運行，該工作器負責對源音頻進行轉(zhuǎn)碼，而非在本地下載再將轉(zhuǎn)碼結(jié)果上傳至云端。

視頻作業(yè)稍微復雜一些。根據(jù)用戶所上傳源視頻的索引和其他元數(shù)據(jù)，F(xiàn)alkor API將確定視頻的拆分位置，理想狀態(tài)下是分割成時長約1分鐘的片段。如果無法分割視頻，則回退至Tron對源視頻做整體處理（后文將討論具體細節(jié)）。每個片段均由各視頻轉(zhuǎn)碼工作器做并行轉(zhuǎn)碼，根據(jù)由源文件分配的視頻片段獲取所需的字節(jié)范圍，之后將結(jié)果上傳至云存儲。

當所有片段均處理完成后，F(xiàn)alkor API會創(chuàng)建最終的合并作業(yè)。該作業(yè)會根據(jù)各片段的標題頭生成視頻標題頭，例如moov和SIDX，再將此標題頭與所有片段連接起來，最后將合并完成的視頻存儲在目標位置。在我們的云服務環(huán)境下，只需調(diào)用云存儲API即可完成最后一步（詳見下文）。

步驟4

以上步驟完成后，F(xiàn)alkor AIP會告知視頻API工作已完成。視頻API將新的音頻或視頻文件添加至視頻管理系統(tǒng)，再將完成消息通知客戶端。

每個單獨作業(yè)都有自己的通知過程，可幫助客戶決定如何按業(yè)務邏輯采取行動。例如，客戶端允許在H.264視頻組件之一和AAC音頻組件之一準備就緒后，立即開始播放視頻；或者，客戶端也可以等待所有轉(zhuǎn)碼均完成后再行播放。客戶端還可觸發(fā)其他處理任務，例如為視頻內(nèi)容生成縮略圖。

技術(shù)細節(jié)

從技術(shù)棧的角度看，所有作業(yè)均在Google Cloud三個美國區(qū)域的Kubernetes（GKE）上運行。在隊列方面，我們使用的是PubSub。Falkor本身由Go編寫，轉(zhuǎn)碼器則用C語言編寫。

Falkor還用到了我們的作業(yè)調(diào)度程序Quickset，讓我們能夠通過以下兩種方式降低成本：

?能在可用的CPU和內(nèi)存資源范圍之內(nèi)，有效將任務分配給各工作器，在盡可能減少CPU閑置的同時、仍為突發(fā)事件保留一部分空間。

?能夠自動縮放Kubernetes節(jié)點，并根據(jù)競價實例優(yōu)先級做任務安排，保證只在真正必要時才回退至非競價實例。

但要讓Quickset有效分配任務，必須保證各項任務的時長和所需的資源量大致相同。為了實現(xiàn)這一點，我們將任務排入不同隊列。任務分析主要根據(jù)大小進行，因為我們找不到更好的近似值選項。音頻任務按持續(xù)時間和編解碼器做分析，這是因為我們不會對音頻做片段拆分，所以不同文件的持續(xù)時長會有很大變化。視頻任務則按還原度和編解碼器劃分，因為視頻片段的持續(xù)時間是恒定的，每段大約一分鐘。

發(fā)布流程

我們在整個發(fā)布過程中始終小心謹慎。畢竟在快速迭代的同時，我們也要保證盡量減少對用戶體驗的干擾。

我們首先將一小部分H.264 240p轉(zhuǎn)碼發(fā)送至新基礎(chǔ)設(shè)施，原因如下：

?這種還原度的視頻不會通過UI或API向用戶公開，僅面向內(nèi)部播放器或外部播放列表，所以即使出現(xiàn)問題也不會造成太大影響。

?我們可以借此引導流量并調(diào)整比例，不必擔心突然對用戶造成嚴重影響。

?我們可以在此期間構(gòu)建并集成零散的音頻和視頻數(shù)據(jù)管線，借此重新組合漸進式文件。

我們還做了一些微小調(diào)整，修復了一些bug并解決了縮放問題。當240p視頻全部由新基礎(chǔ)設(shè)施承載之后，我們開始向其發(fā)送AAC和Opus格式的音頻，意味著Falkor開始處理部分實際業(yè)務流量。

之后我們轉(zhuǎn)向H.264 1080p，這種還原度的視頻能讓我們輕松驗證視覺質(zhì)量是否符合預期，也是用戶使用最多的視頻格式。萬一出現(xiàn)問題，我們會很快得到反饋。雖然我們在內(nèi)部做了一遍又一遍測試，但每當實際處理用戶上傳的內(nèi)容時，總會冒出意料之外的有趣極端案例。

在1080p之后，我們對新基礎(chǔ)設(shè)施的規(guī)模伸縮和輸出質(zhì)量已經(jīng)充滿信心，于是決定引入全部其他H.264格式：4K、2K、720p、360p等，后續(xù)還將轉(zhuǎn)移360o視頻和用于HDR10及杜比視界的HEVC視頻。

但在撰寫本文的同時，我們還有不少轉(zhuǎn)碼任務沒有遷往Falkor：

?具有可變幀率源的視頻。我們打算暫時擱置這部分極端案例，等到之后能輕松發(fā)現(xiàn)幀率問題時再遷移比較安全。

?AV1。其實這里沒有任何技術(shù)障礙，我們只是不想過于貪多。除了極少數(shù)內(nèi)部精選的視頻外，我們還沒有遷移AV1。事實也證明，這種格式確實需要投入更多精力來整理。

?在網(wǎng)絡上存量較少的源視頻。對這部分視頻，我們還是采取將源文件下載到磁盤上的老辦法。

升級總結(jié)

我得說，這項工作推進得相當順利。當然，期間也出現(xiàn)了一些與視頻相關(guān)的bug（我們已經(jīng)向上游發(fā)布了相關(guān)補丁）和基礎(chǔ)設(shè)施問題。

首先，我們需要在單獨的Kubernetes集群中運行AIP和工作器。這是因為一旦集群中的節(jié)點超過1000個，GKE Ingress就無法工作。但現(xiàn)在這個限制已經(jīng)解除了。

第二，Google Cloud的VPC原生集群中，每個pod都有自己的IP地址。而且因為我們有很多很多pod，所以不想把這個集群與Vimeo的其余基礎(chǔ)設(shè)施并列部署，畢竟我們已經(jīng)占用了太多的10.x.x.x內(nèi)部IP資源。但我們將Cloud NAT設(shè)置為仍能與基礎(chǔ)設(shè)施的其余部分通信，例如我們的可觀察性服務。

第三，我們的一部分狀態(tài)機無法妥善處理重復消息。Google Cloud的Pub/Sub提供“at-least-once”（至少一次）交付保證，但并非“exactly-once”（嚴格一次）。所以我們被迫重寫了一些代碼塊以使其更具彈性，并會在后續(xù)編寫新代碼時考慮到這個問題。

第四，為了保證可用性，我們在美國三個區(qū)域同時運行，所以拉高了出口成本。

升級的回報

簡單來講：成本下降、速度加快。在類似的用例下，F(xiàn)alkor的運營成本遠低于Tron，而且我們還有更進一步的調(diào)優(yōu)空間。

此外，雖然Falkor并沒有解決所有問題（短視頻的轉(zhuǎn)碼方式和用時仍跟過去一樣），但長視頻的轉(zhuǎn)碼速度確實大大加快。用戶們紛紛給出好評，所以我們的“折騰”也就物有所值了。

審核編輯：劉清