Vimeo發布新轉碼基礎設施Falkor——降低成本的同時將速度推向極限。

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

從歷史說起

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

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

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

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

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

為什么選擇Falkor?

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

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

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

實現并行化和分布式轉碼

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

圖一：并行化和分布式轉碼過程。

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

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

邁向云原生

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

盡可能使用競價實例

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

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

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

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

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

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

使用標準工具進行開發和部署

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

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

Falkor宏觀架構解析

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

圖二：Falkor組件。

圖三所示，為Falkor作業的端到端流程。

圖三：Falkor流程圖。

下面是Falkor的具體轉碼步驟。

步驟1

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

步驟2

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

步驟3

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

音頻作業在音頻轉碼工作器上運行，該工作器負責對源音頻進行轉碼，而非在本地下載再將轉碼結果上傳至云端。

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

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

步驟4

以上步驟完成后，Falkor AIP會告知視頻API工作已完成。視頻API將新的音頻或視頻文件添加至視頻管理系統，再將完成消息通知客戶端。

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

技術細節

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

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

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

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

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

發布流程

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

我們首先將一小部分H.264 240p轉碼發送至新基礎設施，原因如下：

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

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

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

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

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

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

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

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

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

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

升級總結

我得說，這項工作推進得相當順利。當然，期間也出現了一些與視頻相關的bug（我們已經向上游發布了相關補丁）和基礎設施問題。

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

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

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

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

升級的回報

簡單來講：成本下降、速度加快。在類似的用例下，Falkor的運營成本遠低于Tron，而且我們還有更進一步的調優空間。

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

審核編輯：劉清