以下内容來自公衆号【螞蟻技術風險TRaaS】
1.前言
線上服務提供商比如Google、Facebook、螞蟻、騰訊等為了保證自身服務的SLO，在進行資源配置時通常會采取“保守”政策：即配置相對較低的目标CPU使用率，以預防峰值流量帶來的沖擊，即使這将導緻潛在的資源浪費。
但研究表明，伺服器叢集長期處于較低的CPU使用率，除了實體資源的浪費，能源消耗（電力）同樣會大幅增長[12, 18, 19]。針對這個問題，直覺上可以将低負載服務的實體資源騰挪給高負載服務，來提高低負載服務的資源使用率，減少資源浪費和能源消耗，另一方面，更能夠有效提升高負載服務的業務體驗（例如降低RT、減少error）。
為此，螞蟻一直在試圖尋找一種自動化容量評估系統來使系統的CPU使用率能夠被穩定在所需的目标水位，并能夠保障我們的服務SLO得到滿足。
這項工作在耗時敏感的金融支付服務中，挑戰更為嚴峻：
●首先需要確定以及時、反應迅速的服務來保證使用者的體驗品質（穩定性）
●其次應當確定适當的資源供應，而不會出現明顯的過度供應（有效性）
●并能夠适應連續、顯著的負載變化（靈活性）
為此，我們結合螞蟻自身的基礎設施架構、線上業務訴求，設計開發了這一套名為DeepScaling的自動化容量評估系統，在減少線上伺服器叢集資源消耗低同時，保障線上業務SLO不被打破。即通過深度學習方法尋找能夠保障服務SLO的最大CPU使用率，并将線上服務CPU使用率穩定在這一水位，以實作資源節省，如下圖1所示：
圖1.DeepScaling的達成目标示例
這套系統于2020年底開展規劃，于2021年上半年完成開發，2021年中投入使用。基于該工作沉澱出的學術論文《DeepScaling: Microservices AutoScaling for Stable CPU Utilization in Large Scale Cloud Systems》[0] 已發表于雲計算領域唯一頂會ACM Symposium on Cloud Computing（SoCC) 2022。該工作由螞蟻集團、重慶大學、加州大學河濱分校(UC Riverside)合作完成。
SoCC 2022從數百篇投稿中僅僅接收了38篇論文，來自世界著名大學如MIT，UCBerkeley，Stanford，UIUC等以及雲計算大廠Microsoft，Amazon，Google，IBM等。來自國内企業界的論文包含華為參與的有4篇，阿裡巴巴參與的有5篇(恭喜阿裡雲)，來自螞蟻的隻有我們這一篇。
2.背景和現狀
2.1 螞蟻背景
目前螞蟻擁有超過大量線上應用部署單元，資源規模龐大，雖然部分應用的峰值CPU使用率較高，但線上應用的平均CPU使用率長期處于低水位，存在大量波谷資源的優化空間。
一個典型的微服務系統如下圖2所示，通常以使用者請求開始，以對資料的操作結束，且系統中每個微服務節點，由其所在鍊路層級決定，各自承載不同的業務量，如PV、rpc、msg、dal、cal等，由此導緻每個app都具有不同的workload特性。
圖2.一個簡單的擁有5個微服務的系統架構
另一方面，即使是同一workload類型主導的應用，由于上下遊鍊路承載業務的差異性，波峰波谷周期的差異性，以及系統内部定時任務的差異性，真正模組化時也擁有着各種各樣的特性。
是以，我們需要一套适合螞蟻線上應用的全局容量自動化評估體系，滿足線上如此複雜業務特性的業務高穩定性和千人千面的需求。
2.2. 業界現狀
過往，工業界和學術界對于自動化容量評估的研究，主要可以劃分為兩大類：
●rule based schemes [2, 3, 7]
●learning-based schemes [4, 8, 10, 13, 14, 15]
Rule based方法通常采取對系統性能名額（如CPU使用率，記憶體使用率等）/業務名額（如RT、error等）設定門檻值的方式，當觀測名額上漲超過上界時進行擴容，當觀測名額下降低于下界時觸發縮容。Rule based方法的主要限制在于，它們需要大量的專家經驗/領域知識來為不同的服務設定适當的門檻值。此外，為每個微服務設定門檻值需要大量人力投入（該成本可能接近甚至超過資源節省的收益），因為大規模工業系統通常有超過數千個微服務，且由于不同的微服務特性不盡相同（如計算密集型和資料密集型等），不同服務的門檻值必須以不同的方式進行設定。這在大規模雲服務系統中是難以實作，且成本巨大的。
Learning-based方法可以有效地減少人力投入，這在大規模雲服務系統中是至關重要的，但目前的研究很少兼顧資源浪費（由于服務負載的變化）和SLO的保證 [14]。而這在生産雲環境中卻十分常見，例如螞蟻自身的線上支付系統需要數以萬計的容器以滿足一天中某些時段的峰值需求，而在其餘時間隻需要幾千個容器，在夜間可能需求更少。但資源管理者傾向于過度提供服務資源以滿足高峰期的SLO，導緻各種資源的長期處于低使用率狀态（平均意義上）。
目前業界公開的learning-based方案主要以減少系統異常為目标，這些異常通常包括服務RT達到某一臨界值，CPU使用率過高，或者出現記憶體溢出等，此類架構主要以FIRM和Autopilot為代表，分别來自學術界UIUC和Google工業界實踐。
●FIRM使用機器學習技術檢測服務性能異常（例如，微服務的RT異常升高），以便在發生此類異常時，可以通過添加更多的pod或計算資源來擴容。FIRM最主要的限制在于，隻有在性能異常發生後才會進行自動縮放，這有可能使服務異常持續一段較長的時間。大規模的自動縮放可能需要幾分鐘的冷啟動，或者至少幾秒鐘的熱啟動。FIRM的另一個限制是，由于通過系統異常進行觸發，當配置設定給微服務的資源超過必要時，它無法提供縮小規模的政策。
●Autopilot将微服務的CPU使用率的時間序列作為輸入，通過啟發式機制輸出目标CPU使用率，然後使用此目标CPU使用率以線性函數折比的形式計算所需的pod數。Autopilot的優勢在于設計簡潔，但根據我們對Autopilot的實作和實驗，Autopilot仍然面臨比較嚴峻的系統穩定性問題，因為對所需pod數量的估計常常不夠精确。這主要由如下兩個原因導緻：（1）CPU使用率和計算資源之間的關系通常是非線性的，而Autopilot則使用完全的線性假設；（2） 不同的微服務對計算和I/O資源的需求通常存在差異，不應簡單視為一緻。
此外，也有很多工作負載驅動的自動縮放方法。例如，[1]使用回歸樹來模組化pod數量和RT之間的關系，然後生成建議的pod數量，以避免服務RT逾時。[13]利用工作負載的目前狀态、微服務調用鍊資料來模組化微服務，以及使用圖形神經網絡（GNN）表示調用結構，其專注于預測尾部延遲，尋求主動優化每個微服務可用的總CPU資源，同時滿足延遲SLO。這些基于RT的方法雖然直接對SLO進行優化，但通常難以精确模組化，原因在于RT的分布和狀态轉移比起CPU使用率的刻畫，是十分困難的。
由此，一個簡單的想法是規避SLO的直接模組化，通過一個性能模型來描述服務CPU使用率或記憶體使用率的變化，來間接反應。例如，[6]建議對每個pod執行個體的個體性能進行基準測試，并預測工作負載。[17]提出了一種方法，可以自動識别需要擴充的服務，并對其進行擴充以滿足SLA，同時為系統提供最佳成本。然而，這些方法在維護SLO之外，對于節省服務資源并未能取得顯著成效。
3.DeepScaling詳解
DeepScaling提出了一個新的容量評估目标，旨在從一個最初的粗略的目标CPU水位出發，通過機器學習方法，最大化目标CPU使用率（即自動尋找能夠保障服務SLO的最大CPU使用率，規避專家經驗/領域知識），并将線上服務CPU使用率穩定在這一水位（以實作資源節省）。整體架構如圖3所示。
圖3.DeepScaling系統架構
3.1 DeepScaling整體架構
整體的系統架構如圖3所示，包含如下子產品：
●Load Balancer：每個服務的負載均衡強制執行一個政策，将請求公平地分發到為相應服務提供的pods。服務在同一資料中心部署和自動擴充，該區域通常具有相同的硬體配置，以便服務的每個執行個體，承載大緻相同的工作負載，并具有相同的CPU使用率。
●Service Monitor：服務監控側重于實時收集所有服務的名額，包括七個工作負載名額、CPU使用率、有關實作SLO的資訊（RT、error等）以及執行個體數，收集的資料被聚合到分鐘粒度。對所有工作負載度量資料進行彙總，并對每個服務的所有執行個體的CPU使用率資料進行平均。
●Workload Forecaster：我們分析每個微服務的調用圖和主要工作負載名額，然後使用時空圖網絡（STGNN）預測每個微服務的工作負載。調用圖有助于模組化服務之間的流量關系。是以，STGNN對每個時間段（例如30分鐘）的工作負載名額進行了高度準确的預測，預測的工作負載将被回報到CPU Utilization Estimator。
●CPU Utilization Estimator：此子產品基于7個工作負載名額以及3個特定的輔助變量（服務ID、時間戳和執行個體計數）估算CPU消耗。這10個（=7+3）名額與CPU使用率之間的非線性關系由深度機率回歸網絡模組化。依據Scaling Decider給出的最新執行個體數作為輸入，本子產品輸出CPU使用率的估計。
●Scaling Decider：在本子產品中，采用強化學習（RL）模型生成自動縮放政策。詳細來說，model based DQN模型與CPU Utilization Estimator一起工作，以快速确定最佳服務執行個體數。為了允許共享政策生成模型中包含多個服務，我們将服務ID包含在DQN模型的經驗池中。
●Target level Controller：CPU目标水位(𝑇 ) 是DeepScaling的核心參數，𝑇 的初始值是過去正常執行服務的最大CPU使用率。DeepScaling會提供一定的緩沖(𝜏 = 5%），以考慮可能的模型誤差和其他噪聲。當服務在目标水位附近(𝑇 ± 𝜏)運作時，将擷取建議的執行個體個數， 不打破SLO。對于目标水位，此緩沖值還可以應對輕微的負載均衡變化、預測或估計的錯誤以及非均勻的CPU特性。急劇的變化或者較大的估計錯誤将觸發SLO違規，此時将降低目标CPU水位 𝑇 , 以使服務達到新的穩定值。
●SLO Monitor：SLO監控通過觀測微服務響應時間（RT）、GC（垃圾收集）時間、I/O RT等名額來确定核心微服務是否違反其SLO。當SLO監控檢測到核心微服務的路徑成本異常時，它會通知Target level Controller降低該服務的目标CPU水位。
●Instance Controller：作為整體自動縮放任務的一部分，Instance Controller實時完成服務停用（關閉執行個體）任務，并通過熱啟動所需數量的執行個體（在15秒内）或冷啟動（在5分鐘内）來完成服務部署任務。Instance Controller通過增加或減少pod的數量來調整每個微服務的服務資源。
●Vertical Pod Autoscaler (VPA) Controller：DeepScaling原則上使用标準容器（Kubernetes 4C8G-4 CPU核心，8 GB RAM）來實作服務的水準自動伸縮（HPA）。而為了支援不同類型服務的特定資源需求，系統支援VPA控制器，用于在部署之前對每個服務的pod配置進行全局設定。這意味着，在水準擴充期間，每個服務執行個體共享相同的pod配置。對于大多數服務，VPA控制器不被激活，僅對少量特殊需求的服務開啟。例如，對于某些記憶體敏感服務，資源管理者調用VPA控制器将預設的配置修改為比如4C16G。VPA通常配置為在部署前進行優化，而DeepScaling考慮在部署後通過自動縮放pod副本數目進行叢集級别的資源管理。
3.2 DeepScaling模型介紹
DeepScaling包含三個主要算法子產品：流量預測模型（Workload Forecaster），CPU估計模型（CPU Utilization Estimator），容量決策模型（Scaling Decider）。三者均有其自身的挑戰。3個算法子產品的示意圖如圖4所示。下面我們分别介紹3個算法子產品。
圖4.DeepScaling的3個算法子產品示意圖
A. 流量預測模型
大規模微服務系統在調用鍊路上通常存在廣泛的關聯性，業界普遍采用的基于單時序的自回歸預測模型 [1, 9] 很難刻畫出不同微服務間流量的互相影響，也就很難做出準确的預測。針對流量預測，算法團隊提供了一系列不同的算法來支援不同需求，包括Pyraformer處理長程依賴, 以及基于時空圖網絡(Spatio-temporal graph neural networks, STGNN)來捕獲這種空間上的廣泛關聯。STGNN通過模組化服務調用圖的互相作用，以及流量負載名額之間的多變量關系（包括RPC、MSG、PV等各種流量負載），使我們的流量預測模型能夠提供更大的時間跨度來進行資源規模的調整。
B. CPU估計模型
在流量預測模型的基礎上，CPU估計模型将會建構流量負載到CPU使用率的映射，當然也包括一些背景任務對伺服器的影響。業界公開的容量評估系統通常采用RPC刻畫伺服器CPU使用率，但這在系統架構可能是不完備的，原因在于不同微服務/不同請求的性質可能截然不同，有些是計算密集型，有些是I/O密集型等等。為了解決這個問題，我們收集了每個服務的多元工作負載，包括RPC請求、檔案I/O、DB 通路、消息請求、HTTP請求，以及特定的輔助特征（執行個體數、服務ID、時間戳等），以全面描述服務的工作負載，使模型能夠準确估計伺服器的CPU使用率。所有這些特征将通過一個我們設計的基于深度機率網絡的模型作用于CPU使用率的估計，以準确估計CPU消耗，即使在特殊條件下，例如在周期性任務和内部系統事件的影響下，模型預測仍然準确有效。
C. 容量決策模型
最後，我們需要在模型估計的CPU使用率基礎上，進一步給出每個服務所需的最合适的資源配置，這是自動化容量評估的最終目的。一個服務所需的資源與其CPU消耗的關系通常十分複雜，特别是當其CPU使用率接近某些臨界水位時（性能衰減），為此我們提出了一個改進的DQN模型，該模型以一個基于目标CPU水準的專用損失函數進行優化，使我們能夠快速找到最佳資源需求。
每個服務都與 DQN模型中的一個唯一ID相關聯，這使得用一個共享模型對多個服務進行模組化成為可能。對于DQN模型，我們從一下幾個方面描述：
●Action Space：動作空間包括三種不同的操作：增加、減少和不變。
○增加: 此操作增加執行個體數，通過兩種方式實作：按比例增加執行個體數（例如，5%）或按一定的數字（例如，10）增加執行個體數。
○減少: 此操作減少執行個體數。同樣，它也通過兩種方式實作：按比例減少執行個體數（例如，5%）或按一定數量減少執行個體數（例如，10）。
○不變: 此操作将保持服務的執行個體數不變。
4.模型效果
下面對三個模型的效果進行詳細的分析：
4.1 流量預測模型
為了全面評估流量預測模型，我們訓練了不同的模型，包括N-beats[11]和Transformer[16]。N-beats是一種最先進的預測模型，它是一種基于前向和後向殘差連接配接以及非常深的全連接配接層的深度神經網絡架構。Transformer是另一種流行的預測模型。圖5展示了流量名額在不同預測模型的歸一化平均絕對誤差（MAE）和均方誤差（RMSE）[5]。與N-beats和Transformer相比，DeepScaling将MAE降低了35.66%和25.26%，RMSE也分别降低了36.80%和28.51%。
圖5.不同流量預測模型的效果對比
4.2 CPU估計模型
圖6.不同CPU估計模型的效果對比
4.3 容量決策模型
我們将DeepScaling與其它三種SOTA方案進行了比較：Autopilot、FIRM和基于規則的方法。
●基于工作負載的自動縮放方法（Autopilot）：谷歌的自動縮放方式，名為Autopilot[15]，通過尋找與目前視窗最比對的曆史時間視窗來建構最佳資源配置。
●基于SLO的自動縮放方法（FIRM）：FIRM[14]是一種基于RL的自動縮放方式，它通過異常檢測算法查找具有異常響應時間（RT）的服務，并通過RL疊代調整服務資源。
●基于規則的自動縮放方法：它根據監控的性能名額并使用SRE專家經驗制定的規則動态縮放微服務的執行個體數。
圖7.DeepScaling與其他SOTA方法在兩個典型微服務上
執行效果對比
對于服務A1，如圖7（左）所示，基于規則的自動縮放方法無法準确估計服務所需的資源，這會導緻每個周期的CPU使用率大幅波動。對于FIRM，CPU使用率在第二天超過70%，盡管此時目标水準設定為55%，SLO監控檢測到異常響應時間。最終，FIRM的目标水位設定為50%，以保證它不會出現太多SLO違規。Autopilot的目标水位為80%，實作了62%的最大服務CPU使用率，即使在七天後也有很大的波動。此時，DeepScaling十分接近所需的SLO，将最終目标CPU使用率設定為65%。服務A2也存在類似情況，如圖7（右）所示。FIRM的目标水位最終設定為42%。相比之下，DeepScaling在第三天達到了接近預期的SLO，最終目标水位設定為55%。Autopilot的目标水位設定為77%，但CPU使用率的最大值僅達到55%。
與其他業界公開方案相比，對于服務A1和服務A2，DeepScaling使服務運作更接近所需的SLO界限。
在這兩個名額上，如圖8所示，DeepScaling比業界SOTA方案（FIRM）分别領先了24.6%和14.0%。
圖8.DeepScaling與其他SOTA方法的RCS 和 RRU
5.線上收益
對于螞蟻自身，自2021年中投入使用，如圖9所示，平均可産生3w core/day的CPU資源，6w GB/day的記憶體資源節省（1core/day=24core/hour = 1440core/mintue）。
圖9.每天資源節省情況統計資料
6.總結和展望
目前業界公開的雲服務自動縮放方法很難平衡最小化資源配置設定，同時避免RT異常和SLO違規，進而導緻過度供應和資源浪費。為了克服這一挑戰，我們開發了DeepScaling，這是一種基于深度學習的自動縮放方法，強調将CPU使用率穩定在期望的目标水位。DeepScaling由三個主要元件組成：流量預測模型、CPU估計模型和容量決策模型。我們使用目螞蟻可觀測性平台AntMonitor監控可采集的最全面的多元名額來描述微服務的負載。全面的工作負載特性幫助我們實作了準确的CPU使用率估計，以便DeepScaling實作穩定的容量決策。
另一方面，目前螞蟻線上叢集所部署的機型逐漸增多，各種機型間的性能差異對模型準确性的考驗也越發嚴峻，未來我們将深入展開機型模組化相關的探索，以求在進行自動化容量評估時，除了推薦期望的pod數目，能夠更進一步實作所需機型配置的推薦，使線上服務的運作更為穩定高效。
以上，就是DeepScaling方法的主要内容。更多詳細的内容和實驗分析大家可以參考我們的論文，論文《DeepScaling: Microservices AutoScaling for Stable CPU Utilization in Large Scale Cloud Systems》[0] 已發表于ACM SoCC 2022，歡迎大家的批評指正。
緻謝
感謝螞蟻集團各合作團隊，及重慶大學、加州大學河濱分校各位老師、教授在機制理論方面及學術化過程中提供的幫助。
參考文獻
[0] ZiliangWang, Shiyi Zhu, Jianguo Li,Wei Jiang, K. K. Ramakrishnan,Yangfei Zheng, Meng Yan, Xiaohong Zhang, and Alex X Liu. 2022. DeepScaling: Microservices AutoScaling for Stable CPU Utilization in Large Scale Cloud Systems. In Proceedings of Proceedings of the 13th ACM Symposium on Cloud Computing (SoCC ’22).
[1] Muhammad Abdullah, Waheed Iqbal, Josep Lluis Berral, et al. 2020. Burst-aware predictive autoscaling for containerized microservices.IEEE Transactions on Services Computing (2020). [2] AWS. 2022. AWS auto scaling documentation. Retrieved June, 2022 from https://docs.aws.amazon.com/autoscaling/index.html
[3] Azure. 2022. Azure autoscale. Retrieved June, 2022 from https: //azure.microsoft.com/en-us/features/autoscale/
[4] Xiangping Bu, Jia Rao, and Cheng-Zhong Xu. 2009. A reinforcement learning approach to online web systems auto-configuration. In IEEE International Conference on Distributed Computing Systems (ICDCS). [5] Tianfeng Chai and Roland Draxler. 2014. Root mean square error (RMSE) or mean absolute error (MAE)?–Arguments against avoiding RMSE in the literature. Geoscientific model development 7, 3 (2014), 1247–1250.
[6] Jiang Dejun, Guillaume Pierre, and Chi-Hung Chi. 2011. Resource provisioning of web applications in heterogeneous clouds. In USENIX conference on Web application development.
[7] Google. 2022. Google cloud load balancing and scaling. Retrieved June, 2022 from https://cloud.google.com/compute/docs/loadbalancing-and-autoscaling.
[8] Waheed Iqbal, Mathew N Dailey, and David Carrera. 2015. Unsupervised learning of dynamic resource provisioning policies for cloudhosted multitier web applications. IEEE Systems Journal 10, 4 (2015), 1435–1446.
[9] Waheed Iqbal, Matthew N Dailey, David Carrera, et al. 2011. Adaptive resource provisioning for read intensive multi-tier applications in the cloud. Future Generation Computer Systems 27 (2011), 871–879. [10] Rafael Moreno-Vozmediano, Rubén S Montero, Eduardo Huedo, et al. 2019. Efficient resource provisioning for elastic Cloud services based on machine learning techniques. Journal of Cloud Computing 8,1 (2019), 1–18. [11] Boris N Oreshkin, Dmitri Carpov, Nicolas Chapados, et al. 2020. NBEATS: Neural basis expansion analysis for interpretable time series forecasting. In International Conference on Learning Representations (ICLR). [12] Sourav Panda, K. K. Ramakrishnan, and Laxmi N Bhuyan. 2021. pMACH: Power and Migration Aware Container scHeduling. In IEEE International Conference on Network Protocols (ICNP). 1–12. [13] Jinwoo Park, Byungkwon Choi, Chunghan Lee, et al. 2021. GRAF: a graph neural network based proactive resource allocation framework for SLO-oriented microservices. In International Conference on emerging Networking EXperiments and Technologies. 154–167. [14] Haoran Qiu, Subho S Banerjee, Saurabh Jha, et al. 2020. FIRM: An Intelligent Fine-grained Resource Management Framework for SLOOriented Microservices. In USENIX Symposium on Operating Systems Design and Implementation (OSDI). 805–825. [15] Krzysztof Rzadca, Pawel Findeisen, Jacek Swiderski, et al. 2020. Autopilot: workload autoscaling at Google. In European Conference on Computer Systems (EuroSys). 1–16. [16] Ashish Vaswani, Noam Shazeer, Niki Parmar, et al. 2017. Attention is all you need. In Advances in neural information processing systems (NeurIPS). 5998–6008.