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

騰訊雲原生發表於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 效能優化實踐、最佳實踐等系列。

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

相關文章