用戶案例 | 騰訊小視頻&轉碼平台雲原生容器化之路

作者

李匯波，騰訊業務運維高級工程師，目前就職於TEG 雲架構平台部 技術運營與質量中心，現負責微信、QQ社交類業務的視頻轉碼運維。

摘要

隨着短視頻興起和快速發展，對於視頻轉碼處理的需求也越來越多。低碼率高清晰，4K、超清、高清、標清適配不同終端和不同網絡環境來提升用戶體驗，以及水印、logo、裁剪、截圖等多樣化的用戶需求。對於資源的多樣化需求和彈性擴縮容也需要快速響應，而隨着公司自研上雲項目的推進，設備的穩定行和多樣性可提供更多選擇，來滿足像朋友圈、視頻號、廣告、公眾號等轉碼業務快速、穩定、抗突發的資源需求。

服務場景

MTS（Media transcoding service）的定位是點播場景准實時（及離線）視頻處理服務。為業務提供分鍾級可完成的高清壓縮、截圖水印、簡單剪輯等基本視頻處理功能，同時具備向下集成定制畫質增加，質量測評等深度功能的能力。

業務開發者定義批量處理模板，當內容生產方上傳數據時，觸發轉碼作業輸出多規格壓縮視頻和視頻封面，即可發表推送。

背景

微信側和小視頻平台承接着非常多視頻文件，而這些視頻基本都在轉碼平台根據業務需求進行處理，為了降低碼率減少成本，降低用戶因網絡而卡頓等功能。最早轉碼平台基本上是各個業務維護一個獨立集群，集群繁多，集群之間資源也不能互相調度使用，並且單集群容量較小，請求量大的業務不得不部署多套集群支撐。

這給運營帶來很大的挑戰，需要一套容量上限更大，資源調度更靈活，運營更便捷的平台。而隨着公司自研上雲項目的推進和 TKE 容器化，轉碼平台需要能快速對接 TKE 資源，利用公司海量計算資源來滿足業務對視頻轉碼的訴求。

建設思路和規划

視頻接入和轉碼過程經常面臨多業務突發，在保障業務質量前提下又需要提升利用率，提高運營的效率。

平台能力建設：單集群能力上限提高，業務頻控隔離互不影響，資源調度靈活調整

資源管理建設：圍繞 TKE 容器平台充分挖掘空閑碎片資源，通過 HPA 錯開高低峰彈性擴縮容，提升 CPU 利用率。與此同時，利用視頻接入服務流量高、CPU 使用率低，轉碼服務流量低、CPU 使用率高特點，通過兩種場景混部充分利用物理機資源，防止純流量集群低負載

運營系統建設：適配業務場景，完善變更上下架流程，進程監控告警剔除，建立穩定保障平台

平台能力建設

架構升級

老轉碼平台架構：

1. 為 master/slave 主從結構，容災能力相對較弱，而且受限 Master 性能，單集群大概管理8000台 worker

2. 資源調度層面不能友好區分不同核數的 worker，導致有些負載高，有些負載低

3. 不能夠基於業務維度做頻控，單業務突發影響整個集群

   

新轉碼平台架構：

1. 合並 Master/Access 模塊為 sched，sched 調度模塊分布式部署，任一節點掛了可自動剔除掉
2. worker 和 sched 建立心跳並且上報自身狀態和 cpu 核數等信息，便於調度根據 worker 負載來分配任務，保障同一個集群部署不同規格 cpu worker 負載均衡
3. 單集群管理能力 3w+ worker，滿足節假日業務突增
4. 業務合並到公共大集群，可對單業務進行頻控，減少業務直接的干擾

架構的升級，平台不再受限單集群能力，日常和節假日高峰可快速滿足需求，並且業務合並大集群錯開高低峰，可資源利用

接入服務 svpapi 升級 DevOps 2.0

借助業務上 tke 東風，小視頻平台接入服務 svpapi 實現標准化升級。重要改進包括：

1. 整合原有多變更系統、多監控系統、多基礎資源管理系統到智研統一入口，具體包括研發測試、日常版本發布、資源彈性擴縮容、業務監控告警、業務日志檢索分析。通過 CICD 流程屏蔽直接對 TKEStack 操作，安全性更好
2. 模塊配置區分使用場景托管於七彩石，並支持1分鍾級業務開關切換，支持節假日期間靈活的流量調度和業務流控頻控
3. 下半年接入服務計划利用智研監控集群流量水平，結合 TKEStack 根據流量 HPA 能力，實踐資源擴容無人值守能力

資源管理建設

具備平台能力后，下一步需要對不同容器規格的資源進行分類並均衡調度，這里主要的難點：

1、業務場景多樣性：TKE 集群涉及很多，性能規格也各不相同，從6核到40核都需要能使用

2、資源管理和運營需要考慮：Dockerfile 鏡像制作，適配 TApp 不同集群配置，容器上下架，運維變更規范等

梳理出 TKE 不同集群下容器配置

# 不同cpu規格適配不同環境變量
- name: MTS_DOCKER_CPU_CORE_NUM
  value: "16"
- name: MTS_DOCKER_MEM_SIZE
  value: "16"

# 算力平台親和性設置，當負載超過70%，則驅逐該pod
affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: max_vm_steal
            operator: Lt
            values:
            - "70"

資源調度均衡

轉碼屬於異步任務，處理的每個任務請求時間是不一樣的，並且有狀態，所以無法基於北極星去均衡調度任務，需要平台側來設計調度策略

1. 基於不同規格 CPU 機器 worker 性能，均衡分配任務
2. 根據不同 worker 版本進行調度，支持小業務快速版本迭代

在對不同規格容器，通過 Score 和版本來均衡調度

基於調度能力的在不同 CPU 規格上的任務均衡，C6 和 C12 利用率較相近，不會導致大規格容器資源浪費

運營系統建設

轉碼集群的 worker 資源怎樣擴容到對應集群，這里增加了一層資源管理層，需要手動調用將指定的 worker 從集群上下架。對應平台側開發專業 OSS 系統，將集群的 sched/worker/任務做成頁面便於運營，並且封裝上下架的 API。而 TKE 跟轉碼平台其實無任何關聯，為了實現解耦，運維側開發對接 TKE 上下架的功能，制定流程，將 TKE 擴縮容的資源調用 OSS API 實現同步，具體邏輯如圖：

TKE 支持北極星服務，將對應的 TApp 關聯到北極星服務名，將北極星服務作為不同轉碼集群擴縮容 IP 的元數據管理，保障 TKE 和轉碼側資源的一致性

進程監控

轉碼平台管理的 worker 有上萬台，在運行過程或者新版本發布中不能及時監控容器進程狀態是怎么樣，通過批量掃描時間太長，不能快速知道進程異常狀態，因此結合組內進程監控平台，建設轉碼容器的進程監控告警，異常 worker 通過機器人企業微信、電話告警及時通知剔除，提升服務質量

資源利用優化

轉碼業務目前基本是社交的自研業務，節假日效應突發比較明顯，而且資源需求較大，大部分還是准實時，對於轉碼耗時也比較敏感。因此平時在保障速度外，會預留30%~50的 buff，而業務凌晨基本上是低峰，因此部分資源在凌晨是浪費的。TKE 支持根據系統指標自動伸縮，並且它計費模式也是根據一天內實際使用量收費，這里我們基於 CPU 利用率指標，來配置彈性伸縮，低峰時縮容，高峰時自動擴容，減少資源的占用，從而減少成本

彈性擴縮容

根據實際負載節點副本數在凌晨低峰縮容

Workloads CPU 實際使用占 request 百分比峰值能夠達到75%以上，在保障業務穩定的情況下，提升 CPU 利用率

成果小結

目前轉碼平台從分散小集群合並的三地大集群，運營能力的提升+資源利用率提升，正在努力提升雲原生成熟度，截止到2021年5月。

1. 業務累計接入微信朋友圈、視頻號、c2c、公眾號、看一看、廣告、QQ 空間等內部視頻業務，每天視頻轉碼處理1億+
2. 日常保持在70%左右 CPU 利用率，根據負載自動彈性擴縮容，業務成熟度顯著提高

關於我們

更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~

福利：

①公眾號后台回復【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

②公眾號后台回復【系列】，可獲得《15個系列100+篇超實用雲原生原創干貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列。

【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！