OPPO實時計算平臺基於雲原生的作業彈性伸縮設計與實踐

語言: CN / TW / HK

文章大綱:

一、背景

二、技術方案

  • 2.1 整體架構
  • 2.2 方案詳述:

1.縱向伸縮:

2.橫向伸縮

3.雲原生獨立部署模式
4.資源伸縮協調器

三、方案實踐及效果

  • 3.1 彈性伸縮

  • 3.2 自動診斷

四、後續規劃


一、背景
Flink目前是業界主流的流批一體的計算引擎。OPPO基於Flink構建的實時計算平臺總共執行5000+作業,服務於公司二十幾條業務線。我們從2021年開始著手計算上雲的工作,目前已經有1/5的作業穩定執行在k8s上。

實時計算任務有以下特點:
  • 資源初始固定。任務需要在提交之前明確資源用量且作業執行過程中不會自動調整
  • 任務常駐。由於資料來源多為無界流式資料。一旦有新的流資料進入任務,它會立刻發起並進行一次計算任務,因此整個過程是持續進行的;
  • 負載呈週期性變化。實時作業流量和負載會隨著時間的變化出現明顯的波峰波谷

由於以上特點帶來了以下問題:
  1. 調優困難。通常,使用者需要花費大量的時間進行作業調優。例如,新上線一個作業,需要考慮如何配置該作業的資源、併發數、TaskManager個數及大小等
  2. 資源用量無法匹配負載的變化。由於實時作業的負載往往隨著流量的變化而變化,初始設定的資源量容易過多或太少,從而造成資源浪費或者資源不足而導致作業延時。而解決這個問題使用者往往需要手動重啟作業再次設定資源用量,而這種操作繁瑣的同時也是滯後的

下圖展示的是某作業流量和資源使用情況:

由圖中看出作業呈明顯的波峰波谷的情況。

二、技術方案
2.1 整體架構
為了解決上述問題,我們設計實現了一種基於雲原生的Flink自動擴縮容的方案。整體方案以kubernete為基座,自研的"自動診斷 + 彈性伸縮"為核心。其中自動診斷模組由 SmartResource 負責,彈性伸縮的能力承接由 Flink 計算框架負責。
  • SmartResource負責根據作業上報的指標、使用者自定義的監控規則、全鏈路診斷規則來判斷當前作業的執行的健康度,作業是否需要伸縮均源於此。
  • Flink 計算框架使用自研自適應排程器RescaleMonitor,自動感知資源的變化,動態改變運算元的並行度,並重新排程作業。

架構圖如下:


整體流程如下:

  1. 使用者配置自定義的伸縮策略到 SmartResource

  2. SmartResource 將相關的策略轉化為告警規則並配置到雲監控上

  3. 雲監控的資料來自 Flink 叢集上報的作業相關的各種指標

  4. 雲監控觸發告警時回撥指定的 SmartResource 介面,SR 根據告警資訊,在任務鏈路打上優化建議Tag;此外,需要調整資源的,結合使用者配置的伸縮規則自動計算需要伸縮的副本數,並告知後端服務

  5. 後端服務收到伸縮請求後,再次將此請求在診斷聯調上應用一遍來確認是否是個有效的請求,如果是會在資料庫中儲存一個狀態為 pending 的伸縮請求

  6. 當作業的 Checkpoint 完成後,會通知 ostream backend 然後開始執行Flink計算資源的伸縮


2.2 方案詳述:
Flink 叢集往往由一個 JobManager 配合多個 TaskManager 構成。在縱向上也就是在單個 TaskManager的引數配置上,主要關注 CPU、記憶體兩個方面。在橫向上主要關注 TM 的數量。同時 TM 數量也代表了整個叢集可用 slot 個數,我們在伸縮的時候也是從縱橫向兩個方面考慮。

1. 縱向伸縮:
縱向的伸縮主要依賴於 Pod 在宣告資源的時候設定 request 和 limit。當我們在建立 TaskManager的時候,在使用者配置的基礎資源量上額外設定最小資源量(降低下限),最大資源量會略大於使用者配置的基礎資源量(提高上限)。作業的負載波動的時候,單個 Pod(TM)佔用的資源也會在 request 和 limit 之間波動。這樣在縱向上,減少資源的固定佔用。也能很好的解決堆外記憶體佔用突高引起的容器OOM的問題。

示例配置如下:


2. 橫向伸縮
橫向的伸縮主要表現在 TaskManager 數量的增減上,TaskManager的增減同樣反應整個叢集可用的資源數上(slot),但是這裡兩個問題需要解決:
  • 當 TaskManager增減的時候 JobManager 以及已經申請的 TaskManager不能丟失,也就是怎麼保持已申請的資源?
  • 當 TaskManager增減的時候 JobManager 要快速感知新增的 slot,也就是如何感知資源變化並快速排程Job?

2.2.1 雲原生獨立部署模式
針對橫向伸縮第一個問題我們設計了基於 k8s 的獨立的作業部署式:kubernetes-standalone-application。此模式會獨立部署副本為1的JobManager,副本為n(根據使用者指定的併發自動計算)的TaskManager,兩者都是採用kubernetes deploy模式部署。由於TM的生命週期不在由JM控制,所以我們可以在外部控制TM的數量,這位我們後續的彈性伸縮打下了基礎。

此模式是我們使用雲原生的方式封裝了Flink自帶的standalone模式,在原生的standalone下,假如要部署JobManager、TaskManager的時候需要構建兩個非常複雜的的kubernetes yaml檔案(例如使用deploy),在部署、平臺化方面存在諸多不便之處。我們在原有的命令列基礎上支援了 standalone的部署模式的支援,相容現有客戶端的各種引數命令。

新的部署模式圖如下:


特點如下:
  • 雲原生一鍵部署;
  • 自動推斷資源引數;
  • 自研KSA Resourcemanager管理已申請資源;
  • 與現有管理平臺無縫整合
  • 通過k8s的watch機制自動追蹤資源狀態;

部署命令如下:


2.2.2 資源伸縮協調器
針對橫向伸縮第二個問題我們設計了RescaleMonitor,它是一個伸縮監視器,主要用於快速感知資源的變化並決定是否需要重新排程作業。它首先計算作業所需的資源,計算完資源後,會一直等到可用資源穩定下來,一旦資源穩定,會開始確定作業的實際並行度, 一旦確定了並行度並且執行與可用槽匹配,排程程式就會部署執行。

  • 快速部署 。只要有外部資源增加的時候,RescaleMonitor會判斷是否滿足排程作業的最小資源,如果滿足就會立刻部署 jobgraph,不滿足會一直等待。
  • 快速失敗 。當有外部資源減少的時候,依賴於Kubernetes的watch機制可以快速感知資源的變化,無需等待資源超時。此處我們以pod名字作為Resource ID,可以在內部快速定位資源建立連線,進而執行各種操作。
  • 安全恢復 。當有外部資源增減的時候不會立即執行,Pending下來等待checkpoint完成的時候會檢查是否存在資源增減的Request,如果由才會立即執行重新部署JobGrap並從當前完成的checkpoint恢復,這樣在保證作業不丟的情況下,儘量減少重複消費資料的可能。
  • 可固定併發 。支援固定某些運算元的最大併發,這在作業類似是消費 kafka 的時候特別有用。
  • UI聯動 。當資源變化的時候會實時通知web前端實時顯示最新的資源用量。

排程流程示意圖:


三、方案實踐及效果
3.1 彈性伸縮
我們在平臺提供了使用者開啟彈性伸縮的前端頁面,也給出了常用的預設設定,如下圖所示,在CPU利用率大於70%並持續5分鐘的時候,開啟擴容,在CPU利用率小於30%並持續5分鐘的時候,開啟縮容。

彈性伸縮效果圖如下,通過途中可以看出,作業在cpu利用率低時,自動降低的併發。

我們記錄了每次伸縮的事件,包括時間、觸發原因,伸縮前後的資源等,方便平臺跟使用者跟蹤資源的變化和排查問題。

3.2 自動診斷
以某作業為例,此次作業的存在明顯的波谷,且資源利用率很低。

通過我們的智慧診斷服務可以自動優化整個作業的資源配比,在不重啟作業的情況下完成TM的動態調整。

優化後的效果如下

經過我們計算經過自動診斷加彈性伸縮可以為業務帶來至少20%的成本降低。

其實成本降低只是收益一方面,讓流量更加契合資源,讓診斷更加智慧,讓作業穩定高效的執行,才能更好的服務於下游業務。也是我們實時計算平臺服務的宗旨。

四、後續規劃
後續我們在繼續優化彈性伸縮效果的基礎上,繼續朝著下面幾個方向努力。
  • batch任務的自適應排程
  • 基於機器學習的自動化診斷
  • 流批一體的錯峰排程


附錄

  1. https://nightlies.apache.org/flink/flink-docs-master/zh/docs/deployment/elastic_scaling/

  2. https://cwiki.apache.org/confluence/display/FLINK/FLIP-159%3A+Reactive+Mode

  3. https://cwiki.apache.org/confluence/display/FLINK/FLIP-160%3A+Adaptive+Scheduler

  4. https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/



作者簡介

John,OPPO實時計算平臺高階研發工程師,Apache Flink Contributor,長期專注於大資料計算領域。



本文分享自微信公眾號 - OPPO數智技術(OPPO_tech)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。