作者: 舟柒、樓臺

1. 業務背景與挑戰

1.1 實時計算叢集現狀

關於熱點機器處理一直是阿里雲 Flink 叢集運維的一大痛點，不管在日常還是大促都已經是比較嚴重的問題，同時這也是分散式系統的老大難問題。而在今年整個阿里雲成本控制的背景下，隨著叢集水位的逐步擡升，熱點問題愈發嚴重。日均有上千次的熱點機器出現，並且在晚上業務高峰期，整個熱點持續時間會超過 60min，對於業務以及對於平臺影響是比較大的。

這裡的影響是體現在穩定，成本，效率三方面的，首先熱點會導致作業的部分節點延時，高 SLA 要求任務的效能得不到保障，類似於下面這張圖。其次，受熱點機器這個短板的影響，整體叢集水位沒有辦法進一步擡升，影響成本控制。最後在我們沒有一個比較好地機制去處理熱點的情況下，是需要人肉並且非常被動地去處理熱點，費時費力，影響效率。

面對全面影響運維領域（穩定成本效率三個方面）的熱點問題，我們開發的 Flink 叢集的自愈系統，出發點就是要解決 Flink 叢集的熱點機器問題。

1.2 熱點問題分析

接下來具體分析為什麼會產生機器熱點。實際上不管說叢集是 20% 還是 60% 的物理水位，整體叢集的物理資源對於承載業務來說都是夠用的，K8S 的排程器預設會按照作業的 request 值去儘量平鋪。但是目前阿里雲的 Flink 叢集是允許任務進行超用的，就會出現下面這個圖的情況。

當任務配置不合理時，會導致部分的 Pod 超用，部分 Pod 不超用。使得機器之間雖然 request 差距不大，但是實際的usage 就會偏差比較大，毛刺的部分節點就會成為熱點機器。上面這幅圖我們可以看到一臺機器上 Pod 的實際消耗在業務高峰期會超過整體的申請值，這個時候就會造成熱點機器。

我們可以得出結論：熱點的出現與水位絕對值多少沒有必然關係，而與作業的超用程度正相關。因此 Flink 熱點的治理都是圍繞著解決作業超用問題展開的。

2. 成本優化 - 熱點處理

2.1 熱點機器處理思路

面對熱點機器問題，可以分為「大促」與「日常」兩類場景。
針對大促場景，任何在大促峰值期間做的運維操作，對於業務來說都是有損的，因此要儘量避免大促期間發生熱點而去執行運維操作，但是我們通常可以通過壓測去合理地預估作業在峰值的行為，通過一些提前的預測的方法在大促前規避作業超用，從而規避熱點的出現。因此，我們設計了一套基於作業的畫像系統，在熱點發生的事前去幹預熱點的出現。

針對日常場景，在 7*24 小時保障要求下，熱點發生的頻次高且型別多。疊加使用者操作，平臺變更等非預期行為干擾，往往熱點的出現是相對隨機且沒有辦法提前預測的。我們開發了熱點的事中自愈能力，追求熱點隱患出現後的快速消除，當熱點隱患發生後，能夠在敏感任務受影響的時效內完成熱點壓制。而與之相配套的事後恢復與運維可觀測效能力也同步建設。

整體的思路上，仍是圍繞處理超用任務來做，事前畫像是提前規避超用，事中自愈則是對超用的任務進行應急處理。針對熱點發生的時間線，形成了事前畫像，事中自愈，事後恢復，可觀測性四部分的熱點機器解決方案。接下來我會詳細展開介紹這四個部分的能力。

2.2 事前畫像

2.2.1 業務流程

首先什麼是事前畫像。前面提到的，事前畫像是針對大促場景下，通過對超用任務的提前規避，來實現消除熱點的方案。要提前規避任務超用，就需要作業在大促峰值的資源配置是精準的。但是目前參與大促的任務，往往作業拓撲是非常複雜的，且作業的數量非常巨大。單純的依靠資料研發同學人肉地去調優每個任務的每個節點是不現實的。因此，事前畫像就是用來解決超大量複雜作業資源精準配置的問題，讓作業在峰值期間不超用執行。

我們設計了一套自動迭代系統，輸入每個任務的目標 RPS，通過全鏈路的壓測平臺與 Flink 任務管控平臺，讓作業經過啟動壓測任務，灌入壓測流量，生成作業畫像結果，停止壓測流量，停止壓測任務，作業利用率及 RPS 實際值比對，更新畫像結果到壓測任務的模擬壓測流程，自動化地執行 N 輪迭代，產出一份作業 usage 與 RPS 均符合預期的資源配置檔案。整個迭代過程不需要資料研發同學參與，全自動完成。

2.2.2 實現方案

除了自動化的迭代流程外，整個環節中最為關鍵的就是畫像是如何產生任務資源配置的，這裡的能力是依託於阿里雲作業管控平臺中的 Autopilot 服務來完成的。

Autopilot會定時取樣每個 TM 所有資源使用資訊（包括 cpu usage, mem usage, delay）等，統計在壓測峰值視窗內TM 使用的資源 p95 值，剔除毛刺或傾斜的 TM 帶來的干擾，並通過 TM 到 ssg 到 task 的對映關係，生成符合大促峰值需求的配置。

2.2.3 實現效果

在今年的雙 11 大促，事前畫像的能力也得到了了充分的驗證。這 5 個圖中輪次 1 代表畫像迭代前，輪次 2 代表畫像迭代後。

今年大促，實時鏈路團隊緊貼 DT 業務方深入合作，創新性地提出作業畫像結合壓測來智慧化地學習、調整作業合理資源配置，不僅在穩定性上實現叢集 65% 水位 0 熱點，而且幫助業務降低 17% 成本（如上圖所示），更是幫助 DT 完成上百個作業數千次自動化調優。同時還提出了叢集按業務優先順序錯峰管理模式，通過 VVP 限流功能與作業動態佈局，達成不同優先順序作業在各自大促峰值期間滿足延遲要求，提升了叢集整體水位，二者在雙 11 生產首次應用，節約了 100 臺機器，在後續大促中也可持續優化應用。

2.3 事中自愈

2.3.1 技術選型

面向超用作業，如何進行事中自愈有多種方案，目前阿里雲內部的其他分散式系統主要有以下四種方案 ：

a.全域性允許超用，也就是以前Flink叢集使用的方案
b.全域性強限制不允許超用；
c.通過靜態的規則限制超用；
d.動態限制超用能力。

由於實時計算的業務是有其特殊性的（比如說需要有一定的 burst 的能力應對「回追/FO/大促」的場景；低優作業往往傾向於通過犧牲一定程度的效能來換取成本減少；複雜拓撲下不同運算元或輕或重的傾斜問題導致資源需求不同等等這些要求）。我們認為超用對於實時任務是一個長期會存在且合理的需求，結合日常，故障，壓測，大促幾種場景比較，第四種方案，也就是通過 Inspector 來實現區域性的動態限流是比較合適的方案。在熱點出現時自動化地針對熱點隱患機器上的 作業 進行限流及重排程，讓熱點消除。而在熱點消除後，再根據實際情況重新恢復作業的超用能力。

2.3.2 業務流程

整體業務流程總的來說分為三個部分，感知，決策，執行。對於事中自愈來說，通過設定閾值與機器學習的方法識別機器異常進行感知，基於SRE 經驗沉澱的決策樹對作業進行決策，通過降級，限流，驅逐等作為執行方法。

2.3.3 難點與創新

2.3.3.1. 決策樹（難點）

在決策這一部分中，以 SRE 的經驗，我們總結了針對熱點處理的決策樹，用來判斷需要選擇什麼作業來進行操作。這個決策樹是基於「業務影響」與「熱點快速消除」這兩者的平衡來做。對於平臺側而言，肯定是想要熱點消除的越快越好，也就是直接剔除掉使用最高的作業好了。但是另外一方面，平臺需要承接業務，需要考慮業務方面受不受得了這種操作，也就意味著平臺上的作業會有不同的需求，包括有的作業不接受 FO / 延遲，對他們的作業操作後，我們需要給他們有個解釋等等，這對如何挑選作業增加了難度，需要根據不同的場景在這裡進行不同的取捨。我們將業務的重要程度抽象為作業的優先順序指標，整個決策樹需要考慮的因子包括作業的優先順序，超用程度，規格，黑白名單，以及血緣關係等。

對於具體的決策樹而言，我們首先是考慮業務，追求儘量降低對高優先順序業務的影響以及減少對業務的影響面，因此我們優先考慮非白名單的，低優的，超用多的，使用高的作業進行操作。但是由於優先順序和超用數值並不是消除熱點的最優路徑，如果一些優先順序高的作業使用非常多導致的熱點，也就意味著 Inspector 需要限制很多低優先順序的任務才能把熱點降下來，而這意味著，從叢集層面來說，對業務的影響面反而增大，並且熱點消除時間相對變長，為了減少影響面以及考慮到可解釋性，我們還增加了從快速消除熱點為出發點的規則，也就是如果優先順序高並且超用高於閾值，我們會優先處理這類作業。另外，對於對作業操作的數量來說，我們會設定一個回收的限度，僅回收足夠資源讓機器不熱為止。

2.3.3.2 執行上的創新

上述說的是決策樹方面偏重業務層的考慮，接下來介紹再針對作業驅逐的執行操作上的，且深入到軟體側的技術創新點：

對於「驅逐」操作而言，一般對 Pod 進行驅逐的過程，是將驅逐請求發往 API Server，刪除 Pod 後，由排程器選擇其他節點將 Pod 排程上去。之前黑盒排程指的是在排程器這一環節上，Pod 會受到排程器各種外掛的影響，給每個節點進行打分，相對 Inspector 而言，最終 Pod 具體排程到哪一個節點的不確定性比較大，不太明確，這會阻礙 Inspector 後續決策的進一步優化。而我們針對這一點，提出白盒排程，將排程邏輯放入 Inspector 內部，由 Inspector 根據內部演算法指定 Pod 所排程到的節點。整個過程會更明確和可控。具體白盒排程實現細節就是 Inspector 會建立 K8S 的 自定義的資源 ReserveResource，在裡面指定好這個資源的所屬 owner 就可以了，排程器這邊已經更改好排程的邏輯，適配 Inspector，每次排程 Pod 的時候，會先看 ReserveResource 這個預留的資源的 owner 裡面，是否有這個 Pod，如果有，就白盒排程到指定的 Node 上去。不走排程器本身複雜的排程邏輯。

執行的操作方案，除了「驅逐」，還有「限流」，限制整個作業的資源使用量。整個流程為 Inspector 向 JM 發出一個非同步的更新請求，傳送完請求 Inspector 這邊流程就結束，JM 接收到這個請求之後，先持久化到 TM Pod 建立模板裡，保證 新建立的 TM 以及 TM FailOver 了之後，所有 TM 資源限制配置是一樣的，JM 保證了增量的 TM 一致後，再去修改線上存量的 TM 配置，向 API Server 傳送 patch 請求修改 TM Pod spec 裡的資源配置，TM Pod 所在節點的 kubelet 就會 watch 到這個變化，從而去修改 TM Pod 的 cgroup，借用 Linux 的能力動態限制 TM 的資源使用情況，從而形成「限流」這麼一個效果。Inspector 之後會非同步地去檢查限流是否生效，與此同時在 K8S Event 中也可以觀察到這個變化。

2.3.4 效果

從執行效果這一角度來看 Inspector 整個事中自愈，熱點的消除的過程，比較 high-level 一點，可以說就是降低低優任務的使用，將資源讓位給高優任務，從而降低它的延遲，這麼個效果。對應圖中來講，從 CPU 維度而言，就是通過限制左邊這個低優任務的 CPU 使用，緩解叢集熱點情況，讓右邊的高優任務延時降低。

上圖為 Inspector 整體的叢集效果，流量高峰期間，產生了 100+ 的熱點，通過開啟 Inspector，將熱點在 3min 內完全壓制。

從單作業角度來看，當熱點機器消除後，很明顯的，處於熱點機器的 TM 延遲就被消除了，資料就會回追回來。

2.4 事後恢復

2.4.1 業務流程

講完事中自愈，對於事後恢復流程來說，剛剛事中自愈中被限流的作業，如果在空閒機器，它有使用需求，那麼就需要把限制放開來。通過這種讓作業使用量的峰值錯開，在高優任務使用峰值過去後，低優任務仍能夠使用空閒的機器資源，恢復延時，從而達到兼顧業務穩定性以及提高叢集水位的效果。

2.4.2 決策樹

同樣，面對如何挑選作業的問題，也會有一個制衡，整個過程就和洗手類似，如果水龍頭直接放開到最大，就會水花四濺，對比這裡如果直接放開作業的資源使用過猛，單臺機器作業資源使用量突然快速增加，就會將機器迅速打到熱點，從而引發 Inspector 事中自愈，又會將作業資源使用量限制回去，反反覆覆就會導致如圖中所示的這種「震盪」的問題，影響叢集和作業的穩定性。因此，我們需要通過合理控制作業恢復的頻率與數量，讓作業能夠平緩地追資料，避免震盪。

2.5 可觀測性

2.5.1 整體建設思路

作為平臺的 SRE，在服務上線後，需要特別關注服務的「業務效果」與「使用者影響面」，比如看 Inspector 有沒有做出一些有害的操作，出現有害的操作的時候，需要提前想好它的預案，立馬停止不當的操作並且回滾回去。因此需要建立完整的可觀測效能力。總體來說，可觀測性可以分為兩個角度，一個是偏運維的 SRE 角度，一個是偏使用的使用者角度。

對於 SRE 而言，當有熱點機器的時候，我們需要看 Inspector 有沒有做出操作，以及這個操作是否合理，因為正常情況下是沒有熱點機器的，再看看整個決策樹是否可以優化。另外當天的結果覆盤時，可以看看 Inspector 的影響面如何，從優先順序角度而言，可以看到高優任務受影響比例，形成一個簡單的報表，這些點我們都需要視覺化，來幫助 Inspector 的不斷成長從而提高叢集的安全水位。

對於使用者角度而言，當他們的作業出現「延遲」 或者「FO」的情況時，可以用「視覺化的大盤」來檢視這些情況是否是 Inspector 操作導致的影響，從而讓使用者自己考慮優化作業，包括調整資源，作業優先順序調整等等，讓使用者答疑自閉環，減少工單量。

2.5.2 效果

那麼具體實現效果圖而言，可以在 Grafana 上配置大盤，可以看到這段時間 Inspector 操作過的作業數目，以及各個優先順序作業彙總情況，以及 誤操作的作業名單，Inspector 操作的詳情，包括熱點機器 sn，作業優先順序，熱點機器超用數值等等。這些都可以幫助 Inspector 不斷的優化迭代。

給使用者呈現的大盤裡面，使用者可以通過「作業名字」來進行查詢，得到 Inspector 是否有操作過這個作業，以及相應的修改建議等等。

3. 整體規劃和未來方向

3.1 計劃藍圖

Flink Cluster Inspector 的定位是面向於叢集異常的自愈系統，期望通過穩定，成本，效率三大領域的異常進行自愈，實現 Flink 叢集的自動駕駛。當前的能力主要集中於成本領域，主要是針對各類熱點機器進行自愈，包括 CPU，記憶體，磁碟三個維度。後續會往穩定性領域，也就是單節點的異常，系統服務的異常以及叢集所承載的業務異常進行自愈，同時會往效率領域拓展，對於整體叢集水位以及庫存方面的異常通過彈性的擴縮容能力進行自愈。

目前整個系統都是圍繞雲原生構建的，在 Flink 系統雲原生化的背景下，運維能力也全面雲原生化，基於雲原生的技術棧如 Operator，SideCar，申明式 API 等，構建了圍繞 CR 開發，基於 GitOps 的 CI/CD，以及可觀測高可用的運維。而承載上述業務能力的技術核心，則是緊貼於排程系統的異常自愈框架，我們抽象了針對異常自愈的感知,決策,執行三個關鍵環節，並通過一個統一的框架整合，方便各運維同學以外掛式的方式快速實現各自的業務需求。同時也深度貼合調度層，與 K8S 的同學協同，開發面向於 Flink 場景的排程器增強能力。

3.2 頂層視角

基於以上 Inspector 的能力，我們將 Flink 叢集打造成為一個將成本穩定性效率串聯起來的聯動系統，進行精細化的成本控制。我們定義了 24h 平均安全水位和瞬時安全水位，分別用來衡量叢集的成本控制能力，和叢集穩定性問題臨界能力。通過設定當前所能達到的安全水位，當叢集水位較低的時候，能夠通過隔離業務，在業務影響面最低的情況下將機器下線。而如果叢集水位過高，則快速申請預算，進行機器的擴容。通過 Inspector 中動態容量維持模組，將叢集水位始終控制在安全水位附近。

在某些緊急情況下，叢集的瞬時值可能會過高，觸發叢集整體穩定性問題。當水位已經超過了所能夠承載的安全水位上限，則需要進入應急處理流程，通過 3-5-20 報警處理，批作業限制，大促緊急預案等消除異常。當水位仍在安全水位範圍內，由自愈服務進行兜底，通過自動化的將異常的機器或者業務進行隔離或限制，將穩定性問題自動恢復。容量模組不斷擡升水位，錘鍊自愈服務的可靠性，而自愈能力的增強，又能夠反過來提升安全水位，進而擡升叢集水位，形成聯動。