聊聊降本提效這件事兒

本文根據作者在 9 月 20 日由中國計算機學會組織的 CCF TF 會議演講整理。

今天數字化的生產與生活方式成為後疫情時代的新常態，雲端計算也已經成為社會的數字化基礎設施。如何利用雲原生技術幫助企業實現降本增效是很多 IT 管理者和開發者關注的話題。

01

阿里雲容器產品家族

阿里雲容器產品 ACK 覆蓋了從公共雲、邊緣雲、到本地資料中心的各個場景，讓所有需要雲能力的地方，都能獲得統一的容器基礎設施。

容器服務 ACK 支援了外部數萬企業客戶 IT 架構的容器化，優化上雲成本，提升用雲效率，同時 ACK 也是很多阿里雲產品的基礎設施，支撐雲產品的 Serverless 化。比如阿里雲上訊息服務、RDS 資料庫、資料湖分析、彈性 AI 服務等等。同時容器服務也支撐了阿里集團的全面雲原生化，目前規模已達到數千萬核。

02

FinOps 與雲原生

站在經濟學角度，雲端計算是將 IT 的固定成本轉化成為可變成本，這對企業傳統的 IT 成本管理方法也帶來了挑戰。於是 FinOps 理念也應運而生。

在 FinOps 基金會的定義中：FinOps 是一種不斷髮展的雲財務管理科學與實踐，通過資料驅動的支出決策幫助工程、財務、技術和業務團隊進行協作，使組織能夠獲得最大的業務價值。

FinOps 是“Finance”和“DevOps”的綜合體，強調業務團隊和工程團隊之間的溝通與協同。 在 FinOps 實施過程中我們可以將其劃分為：成本洞察、成本優化、成本運營三個階段，幫助企業通過數字化手段實現成本可視，可優化與可控。

利用雲原生技術實現上雲效益優化，可以從幾個層次入手：

在 基礎設施層 ，我們關注的要點有：

• 用法 – 選擇合適的算力適配工作負載，比如對高效能運算等場景，選擇計算型例項，或者利用 GPU、RDMA 等加速裝置實現降本提效。

• 用量 – 根據工作負載的特徵，進行合理的容量規劃。

• 價格 – 選擇包年包月、按量付費，採用不同計費方法，在資源的確定性、成本之間進行合理取捨。

在 容器編排層 ，我們關注在分散式叢集上，讓應用更加穩定、高效地執行，並充分利用雲的彈效能力降低成本。

在 應用架構層 ，我們既需要解決架構中的效能瓶頸，也需要關注應用架構的現代化，並將穩定性、可觀測性、安全等在研發流程左移，實現應用生命週期中的成本效率優化。

今天我會將聚焦在容器編排中的智慧彈性、任務混部與資料加速等幾個方面介紹如何實現成本優化和效率提升。

彈性是雲最核心的能力之一，可以有效降低計算成本，ACK 在資源層和應用層提供了豐富的彈性策略。

在資源層，當 K8s 叢集資源不足時，ACK 叢集可以利用 cluster-autoscaler 在節點池中自動建立新的節點例項。ACK 可以根據應用負載，選擇 ECS 虛擬機器、神龍裸金屬例項進行擴容。基於阿里雲強大的彈性計算能力，可以在分鐘級實現千節點擴容。

在 ACK 叢集中一個更加簡化的方案是利用 ECI 彈性容器例項來實現彈性。ECI 基於輕量虛擬機器提供了 Serverless 化的容器執行環境，具備強隔離、高彈性、免運維、免容量規劃的特性。彈性容器例項可以在 30 秒內擴容 3000 Pod，新浪微博利用 ECI 可以輕鬆應對突發的新聞事件；自動駕駛模擬模擬客戶可以在 1 分鐘內拉起數萬核算力進行計算。

值得一提的是，我們可以使用 ECS 或者 ECI 的競價例項，利用阿里雲的空閒計算資源， 成本折扣可以低至按量付費例項的 90%。 競價例項非常適合無狀態和容錯性好的應用，比如批量資料處理或者視訊渲染等。

在應用層，Kubernetes 提供了 HPA 的方式進行 Pod 的水平伸縮，和 VPA 進行 Pod 的垂直伸縮。ACK 還內建了基於機器學習的 AHPA 方案來進一步簡化彈性體驗，提升彈性的 SLA。

01

應用水平伸縮面臨的挑戰與解決之道

在實踐中，很多業 務都存在波峰波谷，如果採用固定例項數的方式會造成較大的資源浪費。 因此 Kubernetes 中提供了 HPA 實現按需擴容例項數量，減少資源浪費。

HPA 可以根據應用負載變化調整設定例項數量，當應用負載高時擴容，當應用負載低時則縮容例項。但是 HPA 存在兩個不足：

• 彈性的滯後性。彈性伸縮基於對監控指標的被動響應，此外由於應用本身啟動、底層資源擴容也需要一定時間。如果當業務高峰到達再擴容，有可能導致業務受損；

• 配置的複雜性。HPA 的執行效果取決於彈性閾值的配置，配置過於激進可能導致應用穩定性受影響；配置過於保守，成本優化的效果就大打折扣。需要反覆嘗試才能達到一個合理的水平。而且隨著應用的變化，也會需要重新調整彈性策略。

CronHPA 是使用者根據業務的週期性設定定時規則，在指定時間進行例項數伸縮，結合 HPA 可以在業務高峰期到來之前完成擴容，具備很好的確定性。它的缺點是手動設定較為複雜。

為此，達摩院團隊和阿里雲合作提出了一種 智慧化彈性伸縮方案 AHPA ，可以根據歷史時序資料進行主動預測，提前擴容，避免彈性滯後。並且會根據實時資料動態調整主動預測結果，相容週期變動等場景，減少人工干預。

01

核心辦法

AHPA 整體架構如圖 1 所示，分為資料採集、預測及彈性伸縮三大部分。

• Data Collection 模組負責從資料來源收集監控 Metrics 指標並將資料轉為統一的格式傳入給 Prediction 模組，相容多種資料來源，支援多種擴縮容指標。

• Prediction 模組負責根據輸入指標預測所需的 Pod 數量。Preprocessing 負責資料預處理，比如處理缺失資料等。完成預處理後將時序資料傳遞給 RobustScaler 演算法進行分析和預測。

• Scaling 模組根據 Prediction 給出的結果，對 Pod 數量進行擴縮容。為保證應用平穩執行，其中  ScalingProtection 元件會對演算法預測出的 Pod 數量進行修正，採取快速擴容，緩慢縮容的策略。

預測模組中 RobustScaler 的演算法框架實現如圖 2 所示。

• 其中 Forecasting 元件用於時序資料分解。首先利用 RobustPeriod 演算法檢測資料是否有周期性。如果資料存在週期性，則呼叫 RobustSTL（Seasonal-Trend Decomposition）演算法分解出資料的趨勢、週期及殘差項；如果資料沒有周期性，則呼叫 RobustTrend 演算法分解出趨勢和殘差項。

• ResourceModel 元件用於資源模型構建，該模型的輸入為指標的時序資料，輸出為 Pod 數量。模型選用了統計學中的排隊模型。具體的模型與輸入的指標有關，單指標一般採用線性模型，多指標時往往採用非線性模型。

• Planning 元件分為 Proactive 及 Reactive 兩種模式。Proactive 根據歷史指標資料進行主動預測，Reactive 根據實時資料進行被動預測。兩種模式的預測結果進行處理後輸出最終的擴縮容策略。

02

實驗結果

AHPA 採用的演算法相比其他演算法相比，具有較少的訓練資料量，更好的通用性和魯棒性等優勢。

AHPA 相關論文也被 ICDE、SIGMOD 等頂會收錄。

03

AHPA 基於預測的自動彈性

AHPA 經在菜鳥 PaaS 平臺、阿里雲智慧語音服務多種場景經過驗證。

在智慧語義互動場景中， 90% 的例項可以在業務來臨之前就緒。相比之前採用 HPA 方案，CPU 利用率提升 10% ，資源成本節省 20%。

Kubernetes 作為一個分散式叢集管理系統，它的一個重要目標是：將適合的資源分配給適合的應用，滿足對應用的 QoS 要求和獲得最優的資源使用效率。

然而，分散式系統的資源排程有著非常高的複雜性。主要挑戰包括：

• 對多形態異構資源的支援。今天應用所需的計算資源不只是簡單的 CPU、記憶體、儲存等，而且包括多樣化的加速裝置，比如 GPU、RDMA 等。而且，為了考慮到計算效率的最優化，要考慮到計算資源之間的拓撲，比如 CPU core 在 NUMA 節點間的佈局，GPU 裝置間 NVLink 拓撲等。此外隨著高效能網路的的發展、GPU 池化、記憶體池化等相繼出現，給資源排程帶來更多的動態性和複雜性。

• 對多樣化的工作負載的支援。從 Stateless 的 Web 應用、微服務應用，到有狀態的中介軟體和資料應用，再到 AI、大資料、HPC 等計算任務類應用，他們對資源申請和使用方式有不同的需求。

• 對多維度業務需求的支援。排程系統在滿足應用對資源需求的同時，也要滿足不同的業務需求，比如計算效率、優先順序、穩定性、利用率等等。

排程系統需要多樣化的資源和多樣化約束之間進行動態決策，整體挑戰很高。

01

Koordinator-非侵入擴充套件 Kubernetes 支援任務混部

K8s 目前已經成為了容器編排和容器排程的事實標準，是雲時代的作業系統。我們希望可以利用 K8s 的編排排程能力，充分利用多種應用負載之間的削峰填谷效應，讓工作負載以更穩定、更高效、更低成本的方式去使用資源，這也是大家常說的任務“混部”能力。

阿里巴巴早在 2016 年就啟動了雲原生混部技術研發，歷經多輪技術架構升級和“雙 11”錘鍊，目前已實現全業務規模超千萬核的雲原生混部，日常 CPU 利用率在 50% 左右。基於阿里集團內部超大規模生產實踐經驗，阿里雲近期開源了雲原生混部專案 Koordinator ，它在 K8s 之上提供了對編排排程能力的增強。它包含三大核心能力：

• 差異化 SLO 保障 ：在 Kubernetes 之上抽象一套面向 QoS 的資源排程機制，比如延遲敏感型的線上類任務，和 Best effort 型別可搶佔的計算任務。在提升資源利用率的同時，讓低優先順序的任務對延遲敏感型任務的影響 < 5%。

• QoS 感知排程 ：包括 CPU、GPU 拓撲感知等精細排程能力，幫助應用優化執行時效能效率，通過資源畫像、熱點打散等技術增強系統的排程和重排程能力，幫助應用改進執行時穩定性。

• 任務排程 ：支援大資料與 AI 相關的任務排程，比如 Gang、批量、優先順序搶佔以及彈性 Quota（佇列間借用）等，從而更好地去彈性使用整個叢集資源。

Koordinator 專案完全相容上游標準的 K8s，無需做任何侵入式修改。阿里雲容器服務提供了產品化支援，使用者也可以基於開源專案應用在自己的場景中。這個專案還在快速發展的過程中，也歡迎大家一起共建。

02

差異化 SLO

Koordinator 可以 讓類似 Dubbo 微服務這樣的延遲敏感應用與 Spark 任務這樣的批處理計算任務可以同時執行在一個叢集中，從而提高叢集的資源利用效率。

Koordinator 提供了若干預定義的 QoS 類別，用於區分延遲敏感業務和延遲不敏感業務對執行時資源的差異化需求。Koordinator 通過資源畫像演算法預測，可以將高優先順序應用已分配但尚未使用的資源，超售給低優先順序的計算任務。這樣可以將節點資源的分配率提高超過 100%。

如何保障資源超售場景下的應用穩定性是其中最大的挑戰。在執行態，Koordinator 節點側元件結合 CPU 微架構、OS、容器等多維度的資源隔離、干擾檢測、干擾抑制等手段，讓低優先順序的任務對延遲敏感型任務的影響 < 5%。

這裡面會利用作業系統核心 cgroup的一部分能力；也針對新一代雲原生晶片進行優化。比如，通過 CPU 微架構的精細化拓撲感知，優化程序排布，提升快取命中率，降低跨 NUMA 記憶體訪問等。在 Intel 晶片之上，我們可以通過引入 RDT、HWDRC 等技術可以根據使用者應用的 QoS，動態調整 L3 快取頻寬，降低由於記憶體頻寬爭搶導致的效能波動。

03

Spark 混部效果展示

在測試的 ACK 叢集上，有兩個 8 核 8G 工作節點。 每個節點已經部署一個 Nginx 測試應用。

我們把 Spark 任務以混部的方式提交到叢集上。這裡通過 metadata 指明瞭其 qosClass 為 BE，也就是 BestEffort,。並通過擴充套件資源描述了其資源申請和限額。

通過混部，我們可以看到，系統 CPU 利用率從不足 20%提升至近 50%；而且測試應用的響應延遲只增加了 4.4%。

Koordinator 可以在保障延遲敏感型應用的 QoS 前提下，實現資源利用率提升。

04

QoS 感知排程、重排程

此外，在 K8s 叢集中的工作負載是持續變化、彈性伸縮的。隨著時間的推移，叢集的資源分配狀態可能會失去平衡，比如可能出現部分負載熱點，可能導致應用執行延遲大幅增長。

以 CPU 負載為例，Koordinator 提供了 CPU 負載感知的排程能力，讓 Kubernetes 排程意識到資源分配和實際資源利用率之間的差距，在排程打分階段進行綜合的決策，避免將負載排程到熱點的節點上導致雪崩。

同時，為了持續的保障節點負載均衡，Koordinator 吸納了社群的經驗，為使用者提供了下一代可擴充套件的重排程框架，同時提供了預設的負載感知重排程策略，持續的驅動叢集的負載編排向優化目標靠攏。

下圖顯示了經過 Koordinator QoS 感知排程和重排程，叢集中節點資源實際利用率相對均衡，消除了熱點。

越來越多的 AI/大資料應用，希望通過容器化來簡化管理、提升彈性、優化資源利用率。過去 K8s 主要面向 Stateless 和 Stateful 應用，對計算任務類應用支援有限。阿里雲團隊和 K8s 社群展開了很多合作，完善了 Scheduler framework 並提供了一些關鍵的排程外掛，來滿足計算任務類應用對資源效率、任務特徵、業務需求等的特殊性。目前，Kubernetes 社群成立 Batch Working Group，我們也一起定義 Batch Job、Queue 等核心 API、標準架構和參考實現。

我們也計劃通過 Koordinator 中開放 ACK 產品中對 AI、大資料、HPC 等異構工作負載的支援。

在 ACK 中，通過 CPU 拓撲感知排程，在記憶體密集型任務場景，相比於社群方案有 20%~40%的效能優化，在 AI 分散式訓練任務，排程器針可以自動選擇最佳多 GPU 卡間互聯拓撲，提供最大通訊頻寬，提升計算效率。對 ResNet、VGG 等典型 CV 類模型訓練有 1~3 倍加速。

除了排程之外，AI，大資料，HPC 等資料密集型應用雲原生化，還有一些技術挑戰有待解決， 具體來說：

• 異構資料來源帶來的多樣性挑戰 ：企業中不同應用所依賴的儲存實現各不相同，有 HDFS、NAS、S3/OSS等等；其資料訪問的 I/O 特性也不同，比如隨機讀海量小檔案和順序讀大檔案。隨著業務場景的發展，經常需要聯合處理來自不同的儲存系統的資料，這樣帶來了異構資料來源訪問的複雜性。

• 存算分離架構導致的 I/O 效能和吞吐的挑戰 ：計算儲存分離架構可以大大降低儲存成本，並且提升計算彈性。但相應增加了了資料訪問延時。這有可能導致計算效能的下降，降低 CPU/GPU 等資源的實際利用率。而隨著彈性深度學習等技術的興起，算力可以根據計算成本或者收斂效率變化而動態擴縮容，進而帶來 I/O 容量規劃和供給的變化。

• 跨作業資料共享效率低下的挑戰 ：通過對模型訓練叢集的觀察，我們發現很多訓練任務使用同樣的資料集。同一作業流水線上的不同步驟也可能需要訪問相同的資料。但是由於這些資料重用無法被排程系統感知，導致資料被反覆拉取，降低了整體計算效率，也加劇了對資料來源 I/O 資源的爭搶。

01

Fluid-資料編排的核心方法

為了能夠更好的解決資料密集型應用在雲原生環境上的問題，我們在開源資料編排專案 Fluid 中 對“計算任務使用資料的過程”進行抽象，提出了彈性資料集 Dataset 的概念，並作為“first class citizen”在 Kubernetes 中實現。

• 資料集 Dataset，可以實現對異構資料來源的統一管理和統一訪問抽象。

• 通過自動快取擴容和智慧預取實現資料加速；還可以根據資料集的訪問的模式，來自動優化資料快取的生命週期策略。

• 排程系統可以自動感知多工之間的資料集關聯與血緣，基於資料共享優化作業排程。

02

Fluid-雲原生資料編排與加速

Fluid 是阿里雲容器服務團隊和南京大學、Alluxio 聯合發起的開源專案，目前是 CNCF 託管的 Sandbox 專案，並且在 ACK 上也有對應的產品能力。主要由阿里雲容器服務團隊維護。另外 Fluid 也得到了也得到許多業界同行的支援，像中國電信、SAP、百度雲、騰訊雲都在積極貢獻。

Fluid 在架構上有幾個特點：

• 零侵入 – 無縫融合 Kubernetes 生態；

• 可擴充套件 – 支援多種快取引擎，比如阿里雲 JindoFS、騰訊雲 GooseFS、開源的 Alluxio、JuiceFS 等等；

• 高彈性 – 除了支援經典的 K8s 之外，對 Serverless 容器也進行支援，支援快取 I/O 吞吐的水平擴充套件。

如果大家有 興趣可以進一步瞭解 Fluid 背後設計的思想的一些探索，相關論文已經被 ICDE 接收，歡迎查閱。 這個領域也是非常新的一個領域，希望大家能夠一起在社群參與創新。

03

Fluid-加速 AI 訓練效果

比如在 Resnet50 影象分類模型訓練中。如果直接使用 OSSFS 進行資料訪問，在多機訓練環境中會受到 OSS 總頻寬的限制，訓練效能出現衰減。利用 Fluid 快取加速支援分散式訓練，可以實現接近線性的橫向擴充套件能力。與原方案相比，在 16 臺 128 卡環境下，效能提升 80%。

在微博測試場景中，Fluid 針對海量小檔案快取優化，可以大大降低 HDFS 壓力，訓練速度提升 9 倍。

阿里云為企業構建了先進、普惠的雲原生產品家族。

2022 年 1 季度，在權威諮詢機構 Forrester 釋出的公共雲容器平臺分析師報告中，阿里雲容器服務 ACK 成為比肩 Google 的全球領導者，這也是首次有中國科技公司進入容器服務領導者象限。

在 2022 年 8 月，CSDN 2022  中國開發者調查報告中，52%開發者選擇阿里雲容器雲平臺。

今年 5 月阿里雲憑藉在雲上成本管理的產品能力，以滿分的成績通過了全部 33 個能力指標，成為國內首家通過信通院《雲成本優化標準》的雲服務商。

非常期待與大家共同探索，利用雲原生 FinOps 產品能力和技術，助力企業實現高效用雲。