使用者案例 | 騰訊小視訊&轉碼平臺雲原生容器化之路

騰訊雲原生發表於2021-11-19

作者

李匯波，騰訊業務運維高階工程師，目前就職於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 效能優化實踐、最佳實踐等系列。

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

相關文章