Who limits the resource efficiency of my datacenter: an analysis of Alibaba datacenter traces

這篇文章發在 IWQoS 2019，是包雲崗老師團隊的工作，是 Jing Guo 和 Zihao Chang 在阿里巴巴實習期間發表的文章。本文對阿里巴巴 2018 年公布的第二版開源數據進行了詳細的分析，主要聚焦在數據中心資源使用效率上。

阿里巴巴在 2018 年 12 月公布了其第二版混部集群的開源數據，這版數據包含了4000+台機器的 8 天運行時數據，包括 4K 台機器、9K 個在線任務和 4M 個離線任務的靜態和運行時數據。

需要注意的是，2017、2018 這兩版數據，均是阿里巴巴內部私有雲的集群數據，並不是阿里雲的數據。

開源數據傳送門：github.com/alibaba/clus

論文傳送門：dl.acm.org/citation.cfm?

本文對阿里巴巴 2018 年的公開數據集進行了詳細的分析，從在線任務和離線任務資源分配方式的不同切入，揭示了三個 insight：

  1. 在阿里巴巴的混部集群中，內存似乎成為了新的瓶頸，限制了資源使用效率的進一步提升。
  2. 離線任務在阿里巴巴的混部集群中優先順序低於延遲敏感型任務，同時具有相對較低的資源 QoS 要求，被限制了在混部集群的可調度時間、資源使用等，同時部分任務也出現了重調度等問題
  3. 在這版數據集中，90%以上的在線應用為 Java 應用，大量封裝在虛擬機中的 JVM，使集群中資源管理更加複雜，同時進一步限制了資源使用效率。

建議對本文感興趣的小夥伴可以閱讀一下論文原文，以下內容只是論文中的一小部分。

阿里巴巴混部集群架構

看過這篇文章（《集群調度框架的架構演進過程》）的小夥伴應該了解到，目前的集群作業調度框架有幾種主流形式：單體式、兩層架構、共享狀態、分散式（具體可參考以上文章）。

因為一些歷史原因，阿里巴巴的混部集群中，為了將在線任務和離線任務混合在一起運行，他們沒有重新設計一個調度器，而是使用了一種共享狀態和兩層調度相混合的調度框架。如下圖所示，Sigma 負責調度集群內的在線任務，Fuxi 負責調度集群內的離線任務。因為本身這兩個調度框架是獨立的，但為了實現混部和統一在離線資源池的目的，使用了一個協調的方式來解決調度的問題。Level-0（零層）就扮演了這麼一個協調的角色，它負責兩個調度器之間的數據傳輸、通信等等，通過這種方式來將兩個獨立的資源池合併起來。Level1 中有兩個調度器（Sigma 和 Fuxi），每個調度器的 Master 節點都可以看到整個統一資源池中機器節點的狀態，每台機器上都有這兩個調度器的 agent。同時在調度器的上一層（Level2）是各個不同的業務，如搜索、資料庫、MaxCompute 等。

這種共享狀態和兩層調度相結合的調度框架，在 2017 與 2018 年兩年的雙十一都得到了成功的驗證。

在這樣的調度架構下，在線和離線任務混合運行的方式也很特別

  • 在線任務由 Sigma 進行調度，均運行在容器中，即調度粒度是容器
  • 離線任務由 Fuxi 進行調度，直接在物理機上運行，調度粒度是 instance （下面會介紹離線任務的 Job-task-instance 模型）

這種半容器式的作業運行方式下，由 cgroup 分組來限制兩種作業的資源使用量。在線和離線作業生命周期的管理也依舊由各自的 agent 進行管理。

資源使用效率

那麼在這樣的調度架構和半容器式的作業運行方式下，整個集群的 CPU 和 Memory 使用情況如以下熱圖所示。橫軸代表 8 天的時間，縱軸代表了 4K 台機器，圖中每條水平的直線都代表這一台機器在這 8 天中每 15 分鐘的平均資源利用率，其中顏色越紅代表資源使用率越高。

CPU 利用率在時間維度和集群維度上能看到很強的周期性變化，每天早上 6 點左右集群 CPU 利用率到達了峰值（早上運行的有消耗大量資源的定時任務）。而內存利用率很奇怪，集群整體在 8 天維度下利用率都非常高，且沒有呈現很強的周期性變化規律（公開的數據中，內存利用率中算上了 cache 等）。

從混部集群技術演進的角度來看，將阿里巴巴在 2017 年公開的數據集與 2018 年的數據集中 CPU 和 Memory 資源利用率相比較，可以看到 CPU 和 Memory 資源利用率都有了很大的提升，其中內存的提升尤為明顯。在去掉 cache 等數據的干擾，也達到了很高的利用率。根據阿里工程師的確認，目前混部集群中經常遇到的一個問題就是，因為沒有足夠的 Memory 資源，無法調度更多的離線任務到機器上運行，進而導致無法進一步提升 CPU 的資源利用率。

資源分配方式

在阿里巴巴的混部集群中，因為其調度框架沿用了在線和離線任務自己的調度器，因此在線任務和離線任務使用了兩種不同的資源分配方式，分別為保守式和樂觀式資源分配。

保守式分配

阿里公開 Trace 中的在線任務，均是延遲敏感型（latency-critical，LC）的在線應用，其包含我們平時經常使用的淘寶、天貓等應用，這些在線應用對延遲非常敏感，稍微的延遲增高都有可能造成用戶的體驗下降。為了保障這些 LC 應用的服務質量（Quality of Service，QoS），避免突發的流量引起性能波動通常為這些應用預留過多的資源（over-provisioning）。如下圖所示，是在機器維度上，為線任務預留的資源量和使用率的分布圖，其中橫軸代表 4K 台物理機（根據為在線任務預留的資源多少排過序），紅色和橙色的表示該機器上分配給在線任務的 CPU、Memory 資源總和。

可以看到，單單是在線任務，其基本上佔用了所有機器的 CPU 資源，有些機器甚至僅給在線任務分配的 CPU 資源就出現了超賣現象（分配的 > 實際機器的量）。然而分配了這麼多的資源，資源使用率並不高，可以看到機器上，在線任務平均使用的 CPU 資源只有 10% 左右，內存還好一些，大部分分配的資源都使用了。 但是因為 90%+ 的在線任務都是 Java 寫的，調度器分配給容器一部分內存資源後，就相當於那部分資源無論用多少都被 JVM 佔住了（絕大部分應用的 xms=xmx），就算是容器本身沒有很好地用起來那部分內存資源，暫時也沒辦法分配給其他應用使用。

簡單的一句話總結：為保障在線任務的服務質量，阿里採取了保守式的資源分配方式，為每個在線容器都分配過量的資源。

樂觀式分配

與在線任務運行在容器中所不同的是，由 Fuxi 調度的離線任務是直接運行在物理機上的，其包括 SQL、MapReduce 等任務。離線作業可以用 Job-task-instance 模型來表示，用戶提交的作業為 Job，每個 Job 會被拆分為多個 Task，這些 Task 之間可能存在 DAG 依賴，每個 task 都擁有一個或者多個 instance，同一個 task 的所有 instance 都是相同的二進位文件。因此對於離線任務而言，最小的調度粒度是 instance，最小的資源消耗單位也是 instance。

如下圖所示，表示離線任務申請的資源數和實際使用的資源數目，可以看到絕大部分 instance 實際使用的資源數量均大於調度時申請的資源數目，有些甚至超過了很多倍。那麼需要注意的是，數據集中 request 這個值是假的，是在調度時隨便寫的一個值，並且在調度時也不會根據這個值來進行調度，instance 被調度到一台機器上後，上面空閑的資源是可以隨便用的（當然有 cgroup 會去限制可以使用的資源上限）。

同時，因為離線任務其優先順序低於延遲敏感型在線任務，若在線任務的性能出現了波動，在線任務會優先搶佔離線任務，並從技術上保障二者之間的資源隔離效果。首先會停止離線任務，若依舊沒有改善會將離線任務 kill 掉，並將其重新調度到其他的節點上運行，因此這也是離線任務頻繁經受重新調度的原因之一（資源不夠、優先順序等等問題也是原因之一）。進一步地，當在線任務空閑的時候，離線任務可以通過各種方式共享在線任務沒有使用的各類資源，提高集群的資源使用效率。

簡單的一句話總結：離線任務雖然看起來有 request 值的限制，但是實際上，在線任務空閑時，它可以直接使用機器上空閑的資源（依舊是有一定的限制），是一種樂觀的資源分配方式（實際使用量 > 申請的量）。這種分配方式為整個集群帶來了很大的彈性，即可以通過集群資源分時復用的方式，在集群空閑時（如凌晨）調度更多的離線任務到混部集群中，拉高整體集群的資源使用率。


推薦閱讀：
相关文章