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

文章大綱：

一、背景

二、技術方案

• 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，長期專注於大資料計算領域。