面向多應用混部的性能保障方法綜述

郭 靜 胡存琛 包云崗

（中國科學院計算技術研究所先進計算機系統研究中心 北京 100190）

（中國科學院大學 北京 100190）

（guojing171@mails.ucas.ac.cn）

隨著移動互聯網和交互式應用的大規模使用，數據中心已然成為重要的信息基礎設施，它支持著我們的日常生活和工作，例如即時通信、移動支付和視頻會議等應用的穩定運行均離不開數據中心的支持. 由于交互式應用直接面向用戶，為保障用戶體驗，應用需要能對請求進行快速響應[1-2]. 由于應用負載具有突發性特征，為保證應用在流量峰值時也能夠快速響應，服務提供商不得不采用為其分配冗余資源的方法，這就導致了大量資源空閑、使用效率低下[3-5].然而，若不為應用預留冗余的資源，當突發流量到來時，陡增的負載使得應用的資源壓力增大、應用性能下降，進而影響到應用的服務質量、用戶體驗和用戶滿意度，最終影響公司的收益. 因此數據中心面臨著資源使用效率和應用服務質量的矛盾.

為兼顧資源使用效率和應用服務質量，大量研究工作聚焦于保障交互式應用性能的同時提升資源使用效率. 由此，數據中心的資源使用效率開始穩步提升. 2012 年，谷歌數據中心平均CPU 和內存資源使用效率只有20%和40%[6]；2013 年，谷歌的在線應用集群和離線應用集群的CPU 利用率分別為30%和75%[2]，不過這種將在線應用和離線應用分開部署的方式，會導致集群出現資源使用效率不平衡的問題.為進一步提升數據中心的資源使用效率，最直接的方法就是將在線應用和離線應用混合起來運行，讓離線應用充分利用在線應用閑置的資源. 通過將在線和離線應用混部運行，2015 年，谷歌混部集群的平均CPU 資源使用效率達到了40%左右[4]；2018 年，阿里巴巴混部集群的平均CPU 和內存資源使用效率分別達到了38.2%和88.2%[5]；至2019 年，谷歌數據中心的CPU 和內存資源利用率分別達到了50%和55%[7].

數據中心資源使用效率穩步提升的關鍵在于應用混部. 混部，即將多個應用混合部署在同一物理資源上，充分利用空閑資源以降低成本. 這種混合式的應用放置方法雖然提升了數據中心CPU 和內存資源的使用效率，但是混合部署會造成應用間相互干擾，從而增加了應用性能的不可預測性[8-13]. 因此，利用應用混部提升資源使用效率的關鍵在于：如何在混部場景下保障應用的性能？

混部產生性能干擾的主要原因在于應用之間對共享資源的無序競爭. 共享資源是指從體系結構層次的CPU 核、末級緩存（last level cache，LLC）、內存帶寬、網絡帶寬等，到系統軟件層次的調度隊列、同步鎖、系統緩沖區等. 多個層次的共享資源競爭導致了應用的性能波動. 研究數據表明，同一臺服務器上同時運行2 個不同類型應用時，因資源無序競爭造成的性能突變可達3 倍之多[14]. 因此，在混部場景下保障應用性能的前提在于要能及時發現或預測應用在哪些資源維度上發生了資源競爭，同時能量化或評估出資源競爭對應用性能的影響程度，以此來指導采用何種性能保障策略.

這種因資源競爭導致的性能干擾不僅會影響到對延遲敏感（latency sensitive，LS）的交互式應用，還會影響到對延遲不敏感的盡最大努力（best effort，BE）完成的離線應用. 對于LS 應用，性能干擾會帶來3 個問題：1）影響用戶體驗. 對于交互式應用，響應時間是量化應用性能的關鍵指標，因性能干擾而造成的響應時間增加會影響用戶體驗. 2）影響公司經濟效益. 谷歌、微軟和亞馬遜均做過相關的實驗并發現應用的性能變化會直接影響到公司的收益. 當谷歌搜索結果的返回時間由0.4 s 增至0.9 s 后，其廣告收入下降20%[15]，微軟旗下必應搜索引擎的響應時間增加到2 s 時，每個用戶帶給企業的收益下降了4.3%[16]，亞馬遜主頁加載時間每增加0.1 s，其銷售額下降1%[17]. 3）威脅用戶安全. 有些應用如自動駕駛對實時性要求很高，快速響應對于實時識別交通狀況并作出反應至關重要. 對于延遲敏感度不高的BE 應用，為優先保障LS 應用的性能，集群管理系統往往將其視為“二等公民”對待[5]，很難保障BE 應用的資源公平性. 例如，當LS 應用發生性能突變時，集群管理系統通常會暫停BE 應用，甚至將其驅逐出該節點并重新調度其至其他節點上運行[3]. 在阿里巴巴的混部集群中，為保障LS 應用的性能，一些BE 應用不得不遭受反復的重調度[5]，這些運行一半的應用遭受重調度后需要重新運行，這不僅帶來了極大的資源浪費，同時也會影響到BE 應用的正常運行.

從混部的初衷出發，混部的主要目的是在保障應用性能的前提下充分利用閑置的資源以提升資源使用效率. 因此，如何保障混部應用的性能成為混部研究的關鍵. 對于LS 應用，需要保障其響應延遲；對于BE 應用，需要保障其運行時間和吞吐率，以充分利用物理資源處理更多的任務.

針對上述問題和挑戰，本文從“干擾發生—干擾消除”角度對應用性能保障問題進行拆分，并從應用和集群特征分析、干擾檢測、單節點資源分配和集群作業調度4 個方面進行闡述. 具體內容包括：1）特征分析是性能保障研究工作的基礎，通過分析應用的資源使用偏好、在不同干擾下的性能表現、應用在時間維度上的運行模式、集群的資源類型、應用運行方式和資源使用效率等特征，形成一套完整的應用和集群畫像，加強干擾檢測、資源分配和作業調度系統對應用和集群特征的感知；2）干擾檢測是應用性能保障的前提，只有能及時發現或預測到應用在哪些資源維度上發生了性能干擾，才能快速響應來保障應用性能；3）單節點資源分配是從單節點的資源管理層面來保障應用性能，通過為應用分配隔離的資源從根本上降低應用之間對共享資源的競爭，從而降低應用間干擾、保障應用性能；4）集群作業調度可視為宏觀層面的應用性能保障方法，即從集群的全局視角出發，在為應用選擇合適的節點時就將降低性能干擾作為調度約束的條件之一，避免將易相互干擾的應用調度到同一節點混合部署，從作業調度角度保障應用的運行時性能，同時通過緊湊的作業放置來最大化集群資源利用率. 這4 部分相關工作之間的關系如圖1 所示，特征分析形成的集群和應用畫像信息為集群調度和單節點資源分配提供了指導；集群作業調度器根據集群的全局信息和應用特征對用戶提交的應用進行調度（宏觀）；待應用調度到節點后對其進行單節點資源分配，在應用運行過程中，干擾檢測模塊會持續進行干擾檢測，并根據應用受到干擾的情況決定是否觸發資源再分配（微觀）；節點的狀態信息會定期上報集群，由中心節點更新全局信息. 這4 部分研究內容層層遞進，從應用和集群的特征分析切入，再從微觀和宏觀2 個層面共同保障混部應用性能. 此外，由于混部應用和集群特征等不同，性能保障工作所面臨的挑戰和問題復雜度也各異，例如單位資源上混合部署的應用數量和應用的運行方式會直接影響到共享資源的競爭強度和搜索資源空間的時間開銷. 因此，在對每部分研究內容進行討論和分析時，本文從問題復雜度的角度對性能保障問題進行分類，分別探討應用和集群特征、資源干擾維度和混部應用個數等特征對制定應用性能保障策略的影響，以此對相關研究工作的適應場景進行分類和總結.

Fig.1 Research framework of guaranteeing the performance of co-located applications圖1 面向多應用混部的性能保障研究框架

本文的主要貢獻包括4 個方面：

1） 對操作系統級別和硬件級別的資源隔離技術進行總結. 指出雖然這些資源隔離技術給予了更細粒度的資源操控方式，但如何根據應用的具體需求設計高效的軟硬件協同的應用性能保障方法依舊是尚未定論的開放性問題.

2） 從微觀和宏觀的角度對應用性能保障的相關工作進行分析和總結. 具體包括特征分析、干擾檢測、單節點資源分配和集群作業調度4 個方面，明確這4個方面的研究工作對混部應用性能保障的作用.

3） 從問題復雜度角度對干擾檢測、單節點資源分配和集群作業調度的相關工作進行分類總結. 具體討論因應用和集群特征、資源干擾維度和混部應用個數等不同對制定應用性能保障策略的影響. 指出因混部特征的不同而導致的問題復雜度各異是推動性能保障工作不斷演進的助推劑.

4） 對面向高密度混部場景下應用性能保障研究的發展方向和所面臨的挑戰進行討論和總結. 指出全棧式的軟硬件協同方法是保障高密度混部下應用性能的趨勢.

1 資源隔離技術

在混部場景下，為應用提供性能隔離是保障應用運行時性能的關鍵. 性能隔離是指應用在混部場景下運行時像獨占整個計算機資源一樣，無法感知其他應用的存在且不會被其他應用干擾. 為達到性能隔離的目標，應用要能夠獨占分配給它的資源. 本節首先從不同資源類型的維度來介紹資源隔離技術和工具，然后再從體系結構和軟件設計的角度來介紹資源隔離方案.

1.1 資源隔離技術

根據共享資源類型，資源隔離技術可分為功耗、末級緩存資源、內存帶寬資源、CPU 時間片資源、內存資源、網絡帶寬資源、磁盤帶寬資源等7 類。

1）功耗. 數據中心每年的電費開銷都達到了上億美元[18]，因此功耗是影響數據中心經濟效益非常重要的指標. 在硬件層面可使用動態電壓頻率調節（dynamic voltage and frequency scaling，DVFS）和高級配置與電源接口（advanced configuration and power interface，ACPI）等技術來調整每個CPU 核的頻率[19].DVFS 通過調整CPU 核的頻率和電壓來調整該核的性能和功耗；Linux 內核中的ACPI CPUfreq 驅動程序可以通過ACPI 控制特定CPU 的頻率從而調整功耗.

2）末級緩存資源. 末級緩存是非常重要的片上資源，研究表明，應用對末級緩存的無序競爭會影響應用的性能和服務質量[3,20]. 當前一些工作嘗試從軟件層面[21-24]或硬件層面[25-28]來實現對末級緩存資源的劃分，操作系統的“頁著色（page coloring）”技術即是其中之一. 頁著色技術的核心思想是通過控制地址映射來實現硬件資源的管理，從而實現末級緩存資源的劃分. 隨著處理器核數的不斷增加，為在硬件上提供資源管理的能力，2016 年英特爾公司在最新硬件上加入了資源調配技術（resource director technology，RDT），該技術支持細粒度的末級緩存、內存帶寬等硬件共享資源的管理，可以給每個CPU 核或進程分配隔離資源. 其中緩存分配技術（cache allocation technology，CAT）通過路劃分（way-partition）為CPU 核或進程分配隔離的LLC 資源，避免應用之間對末級緩存資源的競爭.

3）內存帶寬資源. 混部應用之間對于內存帶寬資源的競爭會直接影響到應用的訪存請求延遲，從而影響應用的性能[29]，因此內存帶寬資源的隔離對上層應用性能保障至關重要. 一些研究工作嘗試從軟件層面對內存帶寬資源進行管理，例如MemGuard[30]和文獻[31-32]通過控制CPU 核的訪存請求速率來間接控制內存帶寬；PARTIES 通過為應用分配隔離的LLC 資源來間接減少內存帶寬競爭[9]，當應用分配的LLC 容量較小時，應用會傾向于使用更多的內存帶寬資源[33-34]. 為了在硬件上支持內存帶寬資源的隔離，英特爾在RDT 中引入了內存帶寬分配（memory bandwidth allocation，MBA）技術，該技術可為每個CPU核或進程分配隔離的內存帶寬資源，減少應用之間在內存帶寬層面的競爭.

4）CPU 時間片資源. CPU 時間片是重要的計算資源之一，當前操作系統提供了2 種分配CPU 資源的方式：第1 種是以CPU 核為粒度進行資源分配，每個應用獨占1 個或多個CPU 核資源；第2 種是以CPU 時間片為粒度進行資源分配，多個應用可共享同一個CPU 的時間片. Linux 的Cgroups 提供的CPUset和CPU 子系統與taskset 命令用于支持以上2 種資源分配方式. 應用獨占CPU 資源雖然能保證資源隔離、減少共享資源的干擾，但由于應用往往無法充分利用獨占的資源，因此該資源分配方式會導致較低的資源使用效率. Cgroups 的CPU 子系統的CPU share和CPU quota 機制可以限制應用在單位時間內可使用的時間片，從而讓多個應用共享同一CPU 資源，但該機制會使CPU 核內共享資源（如LLC）競爭加劇.因此，云服務提供商通常會采用超賣的方式綜合使用上述2 種資源分配方法[4-5,7,35]，對于LS 應用以CPU核為粒度分配資源，對于BE 應用，使其充分利用節點上空閑的CPU 時間片，通過在有限的資源上超額售出資源以提升CPU 資源使用效率.

5）內存資源. 內存是重要的計算資源之一，當前的計算機系統都采用虛擬存儲技術來實現內存資源的管理. 每個進程都擁有獨立的地址空間，在執行指令時，通過內存管理單元（memory management unit，MMU）將指令中的虛擬地址轉換為主存上的物理地址，實現不同進程地址空間的隔離. 操作系統負責分配并管理MMU 的地址映射，將不同進程的虛擬地址空間映射到不同的物理地址空間，從而實現內存資源的隔離. 在系統軟件層面Linux 的Cgroups 提供的內存子系統可用于限制每個應用能使用的最大內存容量. 與CPU 資源超賣不同的是，內存超賣或者在應用運行時降低其內存資源可能會導致應用程序因內存不足而被操作系統驅逐. 但近些年，一些工作利用頁壓縮[36-37]或SWAP 設備[38-39]等進行內存資源超賣，以進一步提升內存資源使用效率. 例如，在2019 年谷歌內存超賣數量已與CPU 相當，而2011 年谷歌并沒有對內存資源進行超賣[7].

6）網絡帶寬資源. 網絡資源是數據中心基礎設施的核心資源之一，用于支持服務器之間數據傳輸、請求的接收與返回等. 例如，谷歌利用扇形結構來構建其搜索應用[1]，通過請求樹來分解請求并合并結果，這需要網絡資源的支持；在阿里巴巴的混部集群中，因為BE 應用采取了存儲與計算分離的架構[5]，BE 應用在運行時需要消耗網絡資源從遠端存儲服務器拉取計算使用的數據. 應用對于網絡帶寬資源的競爭會引起網絡包排隊時間增長，進而影響LS 應用的延遲和BE 應用的運行時長，從而影響應用的性能和服務質量. 在軟件系統層面，可使用3 種方法對網絡帶寬資源進行隔離：①流量控制，Linux 的qdisc 流量控制機制[40]可對網絡帶寬進行限制[9]；②基于優先級的網絡包劃分[41-43]，即通過為網絡包劃分不同優先級的方式使得高優先級的網絡包可直接越過低優先級網絡包的發送隊列，從而降低排隊時間；③網絡帶寬劃分[44-46]，即通過為運行時應用配置合適的網絡帶寬來降低應用對網絡帶寬資源的競爭.

7）磁盤帶寬資源. 磁盤帶寬資源是數據中心基礎設施核心資源之一，用于支持數據的讀取與存儲.Linux 的Cgroups 提供的磁盤子系統可用于限制每個應用可使用的最大磁盤讀帶寬，減少多個進程共同讀寫同一塊磁盤而產生的干擾.

1.2 軟/硬件級別資源隔離方案

在混部場景中，應用對共享資源的競爭可能分布于整個系統棧中，為保障應用的性能隔離，需要為應用提供一個良好的資源隔離環境而不被其他應用干擾. 根據應用之間共享資源的程度不同，應用的隔離環境可分為不同類型的資源隔離抽象，如硬件分區、虛擬機、容器、函數等.

在硬件分區方面，PARD[47]提出了一種標簽化的馮·諾伊曼體系結構，它通過為用戶提供邏輯域來實現資源隔離，通過打標簽的方式將硬件資源劃分為不同的地址空間來實現性能隔離. 性能標簽還可將上層應用的服務質量需求傳遞到底層硬件之中，共享的硬件部件能根據標簽識別出來自不同應用的請求和請求處理的優先級，以實現應用之間的區分化服務，從而優先保障關鍵應用的性能. 此外，虛擬化技術的使用使得1 臺服務器能像2 臺或更多臺獨立運行的服務器一樣為應用提供獨立的運行環境[48]，其中虛擬機和容器被廣泛應用于數據中心的混部場景中. 虛擬機是一種創建于硬件資源之上的虛擬環境，是操作系統級別的資源隔離，它通過模擬出包括CPU、內存、網絡等整套硬件資源為應用提供可靠的性能隔離. 容器是一種輕量級的虛擬化技術，與硬件分區和虛擬機所不同的是，容器之間共享同一份操作系統內核，是進程級別的資源隔離，這樣的設計使得它占用更少的資源并獲得更快的啟動時間，并能有效地提高資源使用效率.

1.3 總 結

系統軟件和硬件層面的一系列資源隔離技術為混部場景下應用運行的性能隔離提供了技術支撐和保障. 從不同資源類型的維度出發，當前軟/硬件級別的資源隔離工具如表1 所示，這些工具給予了更細粒度的資源操控方式，系統軟件能夠根據應用運行時的請求調用特征，通過有效地使用軟/硬件提供的接口設計資源分配策略，降低混部場景下應用對共享資源的競爭，從而增強關鍵應用的抗干擾性. 但由于數據中心應用的多樣性、負載特征的多樣性和共享資源的種類較多，應用對共享資源的競爭可能分布于整個系統棧中，為保障應用的性能隔離，需要根據實際的資源競爭特征制定針對性的資源調整策略.因此，如何根據應用的具體需求設計高效的軟/硬件協同的應用性能保障方法依舊是尚未定論的開放性問題.

Table 1 Summary of Resource Isolation Tools表1 資源隔離工具匯總

2 特征分析

混部應用和集群的特征分析是性能保障研究工作的基礎，這些特征數據可用于指導制定具體的性能保障策略. 通過分析應用的資源使用偏好、在不同干擾下的性能表現、應用在時間維度上的運行模式、集群的資源類型、應用運行方式和資源使用效率等特征，可形成一套完整的應用和集群畫像，該畫像信息可用于加強干擾檢測、資源分配和作業調度系統對應用和集群特征的感知.

近些年，隨著云計算的飛速發展[49-50]、數據中心機器規模的日益擴大和應用種類的不斷增加，各大云服務提供商為在提升資源使用效率、作業調度、應用性能保障等方面尋求更優的解決方案，紛紛開源了一部分他們生產環境的數據集供研究使用并公開了其所面臨的挑戰. 例如，谷歌在2011 年和2019年分別開源了其集群管理系統Borg 的數據集[51]；阿里巴巴在2017 年、2018 年、2020 年、2021 年分別開源了其混部集群的數據集、GPU 集群數據集和微服務數據集[52]；微軟在2017 年、2019 年、2020 年分別開源了其Azure 虛擬機和函數服務相關的數據集[53]. 這些數據集的開源為相關領域學者提供了更廣闊的視角. 基于這些開源數據集和基準測試集，針對分析的主體不同，可將特征分析工作分為2 大類：針對應用的特征分析和針對集群的特征分析.

2.1 應用特征

相比于在單物理機上運行的應用，在數據中心運行的應用性能的不確定性更大. 例如程序在單物理機上運行1 萬次，其性能波動幅度低于1%[54]，而在數據中心運行的真實應用，性能波動幅度超過了600%[55]，因此端到端的用戶體驗也遭受著極大的不確定性[56-57]. 多方面因素造成了在數據中心運行的應用具有更大的性能波動性，如請求的大小不同、查詢結果是在緩存或磁盤、應用的上下游依賴和應用間的性能干擾等. 因此，深入理解應用性能變化的原因能更有針對性地進行性能保障.

從應用的自身特征來分析，目前影響應用性能的因素涉及到應用的開發語言、業務邏輯、資源需求、干擾敏感度、請求特征和上下游依賴等. 下文將著重從應用的資源需求和干擾敏感度、請求特征、上下文依賴這3 個方面進行探討.

2.1.1 資源需求和干擾敏感度

應用對資源的需求量指的是應用在某一負載強度下保證應用性能所需的資源量. 若某一資源類型為應用的主要消耗資源，則可稱該應用為該資源密集型應用，如CPU 密集型、緩存密集型應用等. 由于應用負載的動態性[6,58]，應用的真實資源需求是隨著負載的變化而動態變化的. 因此，在對應用進行混部時，為降低應用對共享資源的競爭，應根據應用的資源需求特征避免將對同一資源需求量大的應用放置在一起運行.

應用對某一資源類型的干擾敏感度指的是在不同程度的資源競爭下應用的性能下降程度，性能下降程度高表明應用對該類干擾的敏感度高，反之則敏感度低. 目前，量化應用對特定資源干擾敏感度的最常用方法是通過構建針對特定資源的基準測試集并將其與應用混部運行[9,14,59-60]，即通過手動注入干擾的形式對應用進行離線分析，在各種共享資源上通過調節資源競爭強度來量化應用性能下降程度.

一些研究發現，不同的負載強度下應用對干擾的敏感度也各異，根本原因在于當應用負載強度增強時，應用對資源的需求也隨之增大，導致對共享資源的競爭也隨之增強[9,14,59]. 因此，為量化應用在特定的資源隔離方案下的抗干擾性或驗證資源分配方案的有效性，常使用應用在特定干擾或混部場景下能支持的最大負載量作為量化指標之一[9,61]. 與此同時，應用的資源需求特征和干擾敏感度等信息還可作為應用的畫像信息之一來預測應用在不同資源分配方案或干擾場景下的性能變化[3,62-64]，以此來指導應用的資源分配和作業調度，避免將對同一資源類型需求量大或敏感度高的應用放置在一起運行.

2.1.2 請求特征

根據應用的請求特征，可將應用分為3 類：周期性的、持續性的和突發性的. 周期性應用在請求間隔和請求頻率上表現為每隔一定時間就會出現單個請求峰值[65-67]；持續性應用在整個時間維度上表現為較為一致的請求頻率[9,65]；突發性應用表現為在不定時間間隔下會出現不定強度的突發性請求[66,68-69].

隨著應用請求特征的不同，其性能保障的復雜度也會隨之變化. 對于周期性應用和持續性應用，因其請求和負載強度特征明顯且單一，可通過預測應用未來的負載情況來指導資源分配和作業調度[58]. 同時，還可根據應用請求的晝夜規律，通過在夜間調度更多的BE 應用來分時復用在線應用的空閑資源[5].對于突發性應用，因其請求沒有規律性且難以預測，使得應用的性能保障更為復雜. 對于突發性應用需要在干擾產生時能做到及時響應和處理.

2.1.3 應用間依賴關系特征

應用在運行時可能會需要1 個或多個上游應用的輸出結果作為輸入[55]，因此從全局角度看應用之間的依賴關系，可將其繪制成一個復雜的應用間調用圖[70]. 其中，調用圖中的節點為應用，節點間的連線代表應用之間有調用關系且線的方向為應用間的調用方向. 不同的請求內容會通過不同的應用鏈處理后向用戶返回結果.

文獻[71]表明，應用之間的復雜依賴會引發排隊延遲效應，即應用因其上下游應用的請求排隊問題所造成的性能下降不會馬上顯示，而可能會在幾個單位時間后才出現. 在該場景下，排隊延遲效應使得一些通過預測應用性能來進行資源分配或作業調度決策的工作有效性下降，原因在于這些工作主要針對應用下一時間戳的性能進行預測，而因排隊延遲效應導致的性能下降卻要在幾個時間戳后才能顯現出來. 因此，需要基于應用間的依賴關系構建更加具有前瞻性的性能預測模型.

同時，由于應用之間的依賴關系引入的反向壓力（backpressure）效應和級聯（cascading）效應等使得集群中的應用管理變得更加復雜[72-73]. 反向壓力是指在應用依賴鏈中由于處于后端的應用飽和，導致前端應用也隨之飽和的現象. 此時，集群管理系統可能會錯誤地擴展前端飽和的應用，而忽略了根本原因在于后端應用. 若應用的飽和問題沒有及時得到解決，由應用飽和所造成的服務質量（quality of service，QoS）違例問題會隨著反向壓力效應逐級向上傳遞，造成QoS 違例的級聯效應. 級聯效應是指在應用依賴鏈中由于處于后端的應用飽和而發生QoS 違例，該性能問題通過依賴鏈逐級向上傳遞，導致其上游應用均發生QoS 違例的現象. 例如，某應用利用同步請求向其下游應用請求數據時，由于一直在阻塞等待下游返回結果而導致其自身延遲增加，但此時發生性能問題的根本原因在于下游應用，若不考慮應用的上下游依賴而盲目地為該應用增加資源或擴展實例，不僅無法及時地改善性能還會造成資源浪費.因此，當某一應用發生性能下降時，在采取具體措施之前需要考慮應用之間的依賴關系對端到端性能的影響.

另外一些研究發現，應用之間依賴關系的形態也會影響應用的性能，例如樹的深度和寬度、節點的出度和入度等[1,70,74]. 谷歌的搜索應用之間是一種扇形（fan-out）依賴關系，該扇形由1 個根節點和N個葉子節點組成[1]. 根節點的請求處理時間取決于所有的葉子節點，只有當所有的葉子節點均返回結果時根節點才能向用戶返回結果. 當葉子節點的數量增加時，即便葉子節點發生QoS 違例的概率很低，根節點應用發生QoS 違例的概率也會隨之增加. 假設1 個葉子節點應用有99%的概率會在1s 之內向根應用返回結果，而根應用需要等待100 個葉子應用均返回結果后才能向用戶返回最終結果，那么對于fan-out 的依賴模型而言，葉子節點個數從1 增加到100，會導致根節點發生QoS 違例的概率從1%增加到63%（63%=1-0.99100）. 如若在fan-out 模型的基礎上再增加深度，根應用的QoS 違例概率會隨著樹深度的增加而被逐級放大. 與此同時，對于出度或入度較大的應用節點，可將其視為請求路徑上的關鍵應用節點，若關鍵節點出現性能違例，其影響的范圍會隨著出度和入度的節點不斷向四周擴展.

2.1.4 小 結

除2.1.1～2.1.3 節所述的特征分析工作外，一些研究工作還聚焦于應用的類型[4-7]、性能變化特征[55]、應用在不同體系結構下的性能表現[33,75]等. 因此，雖然應用在共享環境中運行時對共享資源的競爭會產生性能干擾，并且針對應用在各個維度上的特征不同，要解決的性能保障問題的復雜度也各異，但可以根據應用的這些特征有針對性地設計資源分配和作業調度策略，以保障應用性能.

2.2 集群特征

從全局視角來觀察，集群特征主要包括集群的資源類型、資源使用情況、負載均衡和作業運行方式等4 個方面. 其中，由于一些應用對硬件資源類型很敏感[66,76]，在作業調度時應考慮到集群資源的類型不同，保證應用性能；由于不同類型的應用對CPU 和內存資源的需求各異[5-6]，在進行資源分配和作業調度時應考慮整體資源分配的均衡性；由于不同類型應用的運行方式會影響集群的資源分配和使用情況，在制定資源分配方案時需根據應用間運行方式的不同有針對性地設計資源分配策略. 因此，深入理解集群的資源類型、運行的應用種類、應用的運行方式和各維度資源分配及使用情況等特征能幫助系統開發者更有針對性地設計資源調度和性能保障策略.下文將依次從集群的資源類型、資源分配和資源利用率2 個維度對集群特征進行探討.

2.2.1 資源類型

許多研究工作均假設集群中的資源為同構資源，即所有服務器的資源配置均相同. 同構資源能簡化集群的作業調度和負載平衡等問題，并且減少了集群的維護負擔. 然而，在真實生產環境中，集群通常由多種不同類型配置的服務器組成[4,6-7]. 集群資源異構性的主要原因是隨著時間的推移和技術升級，數據中心的服務器逐步地增添和替換，因此在數據中心中通常有10～40 種不同配置的服務器[6,76]. 在進行集群作業調度時，需要考慮到異構資源對應用性能的影響. 研究表明未考慮資源異構性的作業調度器會使應用的運行速度平均降低22%，有些甚至會慢200%[76]. 這種因忽略了資源的異構性而導致的性能下降，不僅會影響應用的性能，還會造成集群的資源浪費. 因此，為了使用戶能更方便地使用異構資源，谷歌抽象出了谷歌計算單元（Google compute units，GCUs）概念[7]，通過為每種機器類型設置GCU 到CPU 核的轉化比例，從而保證一個GCU 為應用提供的計算資源是相同的. 同時，集群中還會有一些不同類型的計算硬件，例如GPU、FPGA 或低功耗的CPU 等[11,66,73,77]，因此在進行作業調度時要根據應用需求和資源情況制定相應的調度策略.

2.2.2 資源分配和資源利用率

從全局角度分析集群的資源使用特征可用于指導集群的作業類型配比和負載均衡調整. 一些研究發現集群的CPU 資源使用率遵循很強的晝夜模式[5,38]，主要原因在于用戶的行為具有晝夜特性，因此集群可在夜間調度更多的BE 應用來分時利用集群空閑的資源. 一些研究發現，當前數據中心的資源分配和資源使用效率具有很強的不平衡性[3,6,58,78]，例如，阿里巴巴混部集群的不平衡性主要體現在空間、時間和資源類型的不平衡，空間與時間的不平衡主要是集群作業調度或負載不均衡所致[78]. 資源類型的不平衡主要是指CPU 和內存資源使用的不平衡，產生的原因有2 個方面：1）作業對資源使用的不平衡，阿里巴巴的BE 應用對CPU 和內存資源的需求比為1∶4[79]，即每使用1 個CPU 資源就需要消耗4GB 的內存資源. 2）應用類型和運行方式的影響，阿里巴巴90%以上的LS 應用和部分BE 應用為Java 應用，并且這些Java 應用被封裝在容器中運行. 然而，由于缺乏有效的內存重分配技術來回收Java 虛擬機（Java virtual machine, JVM）中的內存并將其重新分配給其他應用，因此內存資源的占而不用現象將不斷擴大[5]. 此外，大量封裝在容器中的JVM，使得在JVM、容器和底層操作系統之間進行整體的內存資源管理變得更為復雜.

2.2.3 應用運行方式

除2.2.1 節和2.2.2 節分析的應用晝夜模式和資源使用的不平衡外，應用在集群上的運行方式也會影響到集群資源分配策略的制定. 應用的運行方式是指，應用是以虛擬機、容器或二進制等形式在物理機上運行. 例如，在阿里巴巴的混部集群中，LS 應用運行在容器中，而BE 應用以二進制的形式直接在物理機上運行[5,80]；在微軟的Azure 集群中，應用均運行在虛擬機中[68]；一些研究工作假設應用均運行在容器中[9,66,81]；在無服務計算場景下，有些函數應用以沙盒的形式運行在虛擬機中[82]. 應用運行方式的多樣性使得集群資源管理系統需要在JVM、容器、虛擬機和底層操作系統之間進行協調調整，使得資源管理變得更加復雜. 因此在設計作業調度和資源管理策略時，需要針對應用具體的資源需求和運行方式制定策略.

2.2.4 小 結

總結來說，在制定集群的資源分配策略和應用性能保障策略時，不僅要關注應用自身的特征，還需要關注集群資源的異構性、資源分配策略和應用運行方式等對應用運行效率的影響，從微觀和宏觀2 個角度共同指導集群資源分配和性能保障策略的制定.

2.3 總 結

關于應用特征和集群特征分析的代表性工作如表2 所示. 這些研究工作從真實的生產環境數據或代表應用入手，對應用和集群的多個維度進行深入分析，揭示了影響應用性能和集群資源使用效率的關鍵因素和挑戰. 應用和集群在各個維度上的多樣性特征打破了許多針對特定應用類型和特定環境的資源與作業調度策略，服務器和應用因其特征的多樣性需要被區別對待. 根據所要解決的問題、應用與集群的特征不同，問題的復雜度也隨之變化. 因此，在不同的混部場景下，應全面地從微觀（應用特征）和宏觀（集群特征）角度出發，有針對性地設計性能保障策略.

Table 2 Summary of Feature Analysis Research Work表2 特征分析研究工作總結

3 干擾檢測

為了解決混部場景下應用性能干擾問題，首先要能及時檢測或預測干擾的發生. 最直接的方法是通過實時監控應用的直接性能指標來判斷應用是否受到干擾. 在無法獲取直接性能指標的場景下，可采用間接性能指標來判斷應用在各個資源維度受到的干擾. 然而，隨著資源干擾維度的增加，應用在多資源維度下的行為愈加復雜，單一的間接性能指標已無法全面地展現應用在多個資源類型維度下受到的性能干擾，此時干擾檢測的問題復雜度隨著資源類型的增加而增加. 在這種場景下，通常通過構建應用性能干擾模型來預測應用的性能變化，根據預測出的性能來判斷是否發生性能干擾. 然后，根據干擾的具體情況采用不同的性能保障策略.

3.1 單資源維度干擾檢測

直接性能指標，如應用延遲，最能直觀體現應用的性能變化情況，因此，應用延遲常作為直接性能指標來判斷應用是否受到干擾，并用來量化由于干擾造成的性能下降程度[3,9,14,64,83]. 例如，Bubble-up[62]利用統計學方法，通過離線分析構建應用的延遲與內存壓力的敏感度曲線來刻畫應用對內存干擾的敏感度，敏感度曲線量化了應用在不同的內存壓力下應用性能的下降程度，在相同的內存壓力下，應用的延遲升高的越多，代表該應用對內存資源的干擾越敏感. 應用在運行時根據敏感度曲線能準確預測應用由于內存資源的競爭而導致的性能下降，同時敏感度曲線還可用于指導混部應用之間的資源分配和集群層面的作業調度.

然而，在生產環境中，由于無法及時獲取應用的延遲信息，一些服務提供商利用間接指標來衡量應用的性能變化. 間接性能指標是指應用在軟件系統或硬件層面的指標，可用于量化應用在某一資源類型下受到的干擾程度或性能變化情況. 谷歌發現，計算密集型應用的CPI（cycles per instruction）指標可以準確地反映應用在CPU 資源維度所受到的干擾[4]. 對于計算密集型應用，CPI 不僅與BE 應用的吞吐率有很強的正相關性，與LS 應用的延遲也有很強的正相關性，因此其干擾檢測工具CPI2[84]利用CPI 指標來量化應用的性能變化，并通過應用的CPI 概率分布來判斷應用是否在CPU 資源維度受到干擾. 為尋找干擾源，CPI2 通過計算時間窗口內受干擾應用的CPI 與其他應用CPU 利用率的相關系數來尋找干擾應用，最終利用CPU 帶寬控制機制來降低干擾應用對CPU 資源的使用，該方法已在谷歌集群中被大規模使用并驗證了其有效性. Bubble-flux[63]發現應用的IPC（instruction per cycles）指標與應用的平均查詢延遲有很高的相關性，因此利用IPC 作為反映應用性能的指標，通過運行時探測技術來構建應用的IPC與內存壓力的敏感度曲線. 在敏感度曲線中，IPC 值下降得越多代表應用的性能下降越多，即代表應用對內存干擾越敏感. 利用該敏感度曲線預測應用在內存資源維度受到的干擾程度，依此來調整混部決策. Bubble-flux 通過利用應用運行時的IPC 數據，不僅解決了Bubble-up 需要提前進行離線分析的局限性，還能捕捉到應用的真實運行狀態（例如負載和輸入的變化）.

同時，系統軟件層面的指標（如排隊時間）也可作為干擾檢測的間接指標. Shenango[85]利用線程和網絡包的排隊時長來量化評估CPU 資源的繁忙程度，若應用的排隊時長增加則推斷應用的計算資源可能趨于飽和，并依此判斷是否需要給應用分配更多的CPU 資源. 然而，在混部時應用之間對于共享資源的競爭可能涵蓋多個不同的資源類型，而CPI2 與Shenango 所用的間接性能指標僅適用于CPU 資源層面的干擾檢測，Bubble-up 和Bubble-flux 僅適用于內存資源層面的干擾檢測，而忽略了其他資源維度可能產生的干擾. 并且，CPI2 假設干擾應用的CPU 利用率和受干擾應用的CPI 之間存在線性相關關系，該假設忽略了CPU 內部共享資源，如LLC、內存帶寬的復雜性.

總結來說，應用受制于公有云環境或大規模數據中心的黑盒特性和隱私條款，無法直接獲取延遲信息作為直接性能指標，因此選取合適的間接指標來判斷應用是否受到干擾并量化由于干擾造成的性能的下降程度成為關鍵. 指標的選取應既能體現應用在干擾下性能的變化，又需要綜合考慮到多維度的資源競爭情況.

3.2 多資源維度干擾檢測

為了從多個資源維度綜合判斷混部場景下的資源競爭情況，可通過引入更多的間接性能指標對多個資源維度逐一判斷. Caladan[86]在Shenango 的基礎上引入了處理時間、內存帶寬、LLC 未命中率等多指標作為判斷依據，例如通過測量全局的內存帶寬利用率來判斷DRAM 資源的飽和程度，通過測量每個核上的LLC 未命中率來判斷應用對于LLC 資源的利用情況，從而從多個共享資源維度來綜合判斷CPU 資源的競爭情況，并通過調整應用的CPU 核數量來減少內存帶寬方面的干擾，通過禁止使用CPU核的sibling 來減少超線程的干擾. Alita[87]利用硬件層面的鎖頻率（split lock frequency）指標來判斷應用間對內存總線鎖的競爭情況，利用CPU 的資源利用率和CPU 核的溫度來判斷CPU 功耗層面的干擾，最終對受干擾應用通過小步調整資源的方式來緩解競爭帶來的干擾. DeepDive[88]利用CPI 以及軟/硬件層面的多個指標來綜合判斷應用在一級緩存（first-level cache，L1）、二級緩存（second-level cache，L2）、內存和網絡等資源層面的競爭程度，并通過聚類算法進行干擾檢測，利用retired 指令數的變化情況來量化應用的性能下降程度.

然而，隨著要管理的資源種類增加，應用的行為在多維度資源干擾下變得愈加復雜，利用間接指標分別判斷各個資源維度的干擾已很難綜合判斷應用的受干擾情況. 因此，需要通過構建函數模型來量化應用的受干擾程度. 模型的輸入為系統軟件或體系結構層次指標，一般通過干擾注入還是實時監控獲取；模型的輸出為預測的應用性能指標，如應用延遲、IPC 等. 通過構建應用性能與多資源維度干擾下的關系函數來預測應用在不同負載強度和資源競爭情況下的性能變化，依此來判斷應用是否受到干擾并量化受到干擾的程度. 這些指標因便于獲取且通用性強，并能解決單一指標下無法涵蓋某些干擾場景的問題，被廣泛用于模型構建中.

干擾注入法是構建應用性能-干擾模型最常用的方法，指利用精心設計的資源干擾程序模擬多個資源維度的競爭[9,59-60]，通過改變干擾程序的強度模擬共享資源的競爭強度，從而獲取目標應用的干擾-性能變化數據，利用這些數據快速構建應用的性能-干擾模型，最終通過構建好的模型來預測應用的性能變化. GAugur[89]通過對目標應用在多個資源維度上注入干擾來獲得應用在多個資源維度上的性能干擾敏感度數據，并利用分類模型判斷當前應用性能是否滿足QoS 需求，利用回歸模型量化因混部而造成的性能下降程度. Amoeba[90]利用干擾注入方法獲取應用的敏感度信息并構建應用延遲-干擾模型，根據應用在運行時各個資源維度上的壓力來預測應用的延遲，最終通過改變應用的部署方式來消除多維度資源干擾對應用性能的影響.

然而，由于干擾注入法等同于對應用進行窮舉式離線分析，需要引入額外的時間與資源開銷，另一類工作利用應用的運行時數據或統計學習和神經網絡等方法構建性能-干擾預測模型. 文獻[91]發現在給定的處理器平臺上，用于體現應用性能干擾的函數模型都是相同的，只有函數模型的具體系數由應用本身決定，基于此該工作提出了一種2 階段方法，該方法利用回歸分析來分別構建抽象函數模型和實例化抽象函數模型，以降低構建應用性能干擾模型的開銷，最終利用該模型來預測應用在多維度干擾下的性能變化情況. MAGI[92]利用神經網絡和應用的靜態特征指標（如各類型指令數等）與動態特征指標（如CPU 周期數、各級緩存為命中率等）擬合出應用的IPC 與各維度指標的關系函數模型，通過模型預測的IPC 值來判斷應用是否發生性能干擾并量化性能的下降程度，然后通過敏感度分析法來尋找最大干擾源.

總結來說，利用統計學、機器學習或神經網絡等方法構建的應用干擾模型能捕捉到應用的深層次特性，并能快速識別干擾的發生，然后通過利用資源分配、作業調度或改變部署方式等方法消除性能干擾.然而，該方法有3 點局限性：1）模型訓練時間開銷大，無論是利用干擾注入的離線分析方法還是實時監控來獲取應用干擾數據，機器學習和神經網絡等方法均需要通過不斷訓練模型來提升性能預測的精確度；2）模型訓練需要大量的訓練數據；3）機器學習和神經網絡等模型因其黑盒特性導致可解釋性差.

3.3 總 結

干擾檢測是混部應用性能保障的關鍵一步. 3.1節和3.2 節的研究或通過監測直接性能指標或間接性能指標來判斷應用在哪些資源維度發生了干擾，并量化應用因干擾所導致的性能下降程度；或通過構建應用的性能-干擾模型來預測應用的性能變化，根據預測的性能來判斷應用是否受到干擾，這2 種方法均通過量化資源競爭對應用性能的影響程度來指導后續的應用性能保障. 目前，通過利用干擾檢測方法構建“性能監測—發現干擾—消除干擾”的動態反饋調節機制來保障應用性能的方法已被廣泛應用到真實場景中. 該方法通過觀察/預測應用性能來做到干擾的及時發現，并通過及時消除干擾來保障應用的性能. 基于干擾檢測的性能保障相關工作如表3 所示.

Table 3 Summary of Interference Detection Research Work表3 干擾檢測研究工作總結

4 單節點資源分配

混部場景下，應用間產生性能干擾的根本原因在于對共享資源的無序競爭，因此為應用分配隔離的資源成為保證應用性能隔離的關鍵. 資源分配的理想狀態為資源的分配量與應用的資源需求量恰好匹配. 然而，由于應用種類的多樣性、應用負載的動態性和混部場景的復雜性等因素，不同應用的資源需求是隨著負載和環境的變化而動態變化的，因此在多維度資源空間下尋找單節點最優的資源分配方案成為一大研究熱點. 多應用間資源分配問題類似于最優化問題，在滿足節點資源總量、應用資源要求和應用性能要求等一系列約束下進行最小化資源分配，以達到在保障應用性能的前提下盡可能地混合部署更多應用以提升資源利用率的目標. 該優化問題的復雜度受資源類型數量、混部應用個數、應用性能與資源數量的函數關系是否為凸函數等因素的影響，在不同的復雜度下需采用不同的最優化算法.

4.1 基于梯度下降

在應用性能與資源數量關系是凸函數且混部應用數量不多的情況下，因資源搜索空間較小且混部場景簡單，可對發生QoS 違例的應用利用梯度下降法來尋找全局最優資源分配方案. 基于梯度下降的資源分配方法是指通過對目標應用增加或減少確定步長的資源數量，并結合應用實時性能變化來尋找最優資源分配方案的方法.

最具有代表性的研究工作是Heracles[14]和PARTIES[9]. Heracles 發現谷歌的LS 應用在CPU 核和LLC資源維度下應用性能變化是凸函數，因此它利用應用延遲作為直接性能指標來進行干擾檢測，在檢測到應用發生QoS 違例時通過梯度下降的方法來保障LS 應用性能. 對于目標LS 應用，Heracles 依次在CPU 核與LLC 這2 個維度上為其逐步增加資源以尋找最優資源分配方案；對于BE 應用，Heracles 降低其CPU 頻率和網絡帶寬來減少對LS 應用的干擾. 從節點資源分配角度看，Heracles 將節點資源分為2 大部分：一部分供單個LS 應用使用；另一部分供所有BE應用使用，即單個LS 應用與多個BE 應用之間相互隔離，從而保證了延遲敏感型應用的性能隔離. 然而，由于Heracles 將節點上的資源僅分為2 部分，因此該工作只能支持單個LS 應用和BE 應用的混部. 為支持多個LS 應用和BE 應用混部，PARTIES 在Heracles 的基礎上進行了進一步的優化，對節點上運行的每個LS 應用都進行了資源隔離，對已經發生或可能發生QoS 違例的LS 應用逐個通過梯度上升方法在計算和存儲2 類資源中尋找最優資源分配方案. 當LS 應用的性能滿足QoS 要求時，PARTIES 和Heracles均利用梯度下降方法對LS 應用收回部分空閑資源供BE 應用使用，以提升資源使用效率.

總結來說，基于梯度下降的資源分配方法簡單且易于理解，通過對目標應用在每個資源維度依次增加資源的方式來逐步尋找最優資源分配方案，以保障應用的性能. 為找到全局最優解，該方法要求應用性能與資源數量為凸函數，且局限于應用數量較少且資源維度較少的情況. 當資源維度增加時，資源搜索空間增大，在一個多維的資源空間中通過依次對每個資源維度逐步增加資源這種小步慢跑方式的時間開銷也隨之增大，很難在有限時間內找到最優解，同時對于請求特征為突發性的應用很難做到及時響應到位. 當混部的應用個數增加時，若多個LS應用同時發生QoS 違例，這種1 次只增加1 個LS 應用中1 種資源的逐個調整方式易導致對目標應用無法及時響應的問題. 因此，在資源類型多且混部應用多的場景下，基于梯度下降的資源分配方法可能會出現反應不及時或難以找到全局最優解的問題.

4.2 基于經驗規則

基于經驗規則的資源分配方法是指根據已制定的規則對應用進行資源分配. 規則通常根據系統和應用的特性、具體需求或專家經驗制定，用于達成特定目的，通過規則得出的資源分配方案不一定是全局最優解，但卻是為達成特定目的的可行解之一. 該方法適用于對混部場景、應用特性或資源需求有較為深入了解的場景，能根據具體應用和場景特征設計合理的資源分配規則.

在公有云中，不同的資源分配方式，如按需分配和使用預留資源會直接影響到應用的性能和用戶的經濟效益. 因此，為了能通過靈活調整資源分配方式來保障公有云中應用的性能和高資源利用率，HCloud[83]根據當前的資源分配方式、負載變化和應用特征提出了一種混合式的資源分配策略. HCloud利用Quasar[3]來決定為應用具體分配多少資源，并根據系統的運行時信息設置了軟閾值和硬閾值作為調整資源分配方式的規則線，在不同的規則線下，LS 應用和BE 應用根據運行時性能來選擇是按照應用實際需求來分配資源還是使用預留資源. 為了保障按照規則線來調整資源分配方式的有效性和靈活性，具體規則線的值可以根據系統的隊列長度動態調整.

在私有云中，微軟根據其混部場景中搜索應用具有突發性負載的特性以及搜索應用的QoS 需求設計了性能隔離框架PerfIso[69]. PerfIso 框架根據既定規則對CPU 資源和磁盤I/O 資源進行分配和調整，在保障搜索應用在突發性負載時滿足性能約束的前提下，盡可能地讓BE 應用利用空閑資源. 對于CPU 資源，為保障搜索應用在突發性負載下的性能，微軟發現需要始終為搜索應用預留空閑的CPU 資源來保障流量高峰時的用戶體驗；為提升資源利用率，PerfIso同時允許BE 應用在其他空閑CPU 核上運行. 對于磁盤I/O 資源，PerfIso 通過調整進程的優先級和權重來進行資源分配. 該工作的局限性在于，由于其始終為搜索應用預留了空閑的CPU 資源，這些空閑的資源限制了進一步提升CPU 資源使用效率.

在多應用混部場景下，保證各應用能公平共享資源份額是重要的約束條件之一，即要保證多應用間資源分配的公平性[93-94]. DRF[95]提出了一種主資源公平分配策略，根據該資源分配規則可保障應用之間在多資源類型的混部場景下資源分配的公平性.在此之前，最大最小公平分配策略是最常用的資源公平分配策略之一，同時它還被推廣到了帶權重的范疇，每個應用得到的資源數量與應用的權重成比例，并且能支持包括基于優先級在內的分配策略. 但因其局限于單一資源類型的分配，在多資源類型環境中需要新的機制來滿足應用的多資源需求. DRF將最大最小公平分配策略擴展到支持多種資源類型的公平分配策略，它根據規則將應用的資源需求中占總資源比重最大的視為主資源，主資源對應的資源份額稱為主份額，其中，不同應用的主資源可能不同. DRF 力求最大化系統中最小的主導份額，從而實現多資源維度下的公平分配，當資源維度降為1 時，DRF 退化為最大最小公平分配策略.

總結來說，基于規則的資源分配方法需要在非常了解集群應用和混部特征的前提下，對于應用的主要需求能根據專家經驗、應用和集群特征有針對性地制定資源分配規則.

4.3 基于啟發式算法

啟發式資源搜索算法是基于直觀或專家經驗構造的算法，在資源分配空間中，它能夠通過指導搜索向最優解的方向前進從而降低了復雜性，使之能在可接受的時間開銷內搜索出一個混部場景下資源分配的可行解，該可行解不一定是全局最優解. 這種探索資源分配空間的啟發式方法相對簡單、易于理解，并且能利用啟發式知識來剪枝以減少搜索空間，從而消除組合爆炸. 該啟發式的資源搜索方法與基于經驗規則的資源分配方法的區別在于，后者根據既定規則和已知的資源量直接對應用進行資源分配，而前者通過在資源空間中搜索來尋找可行解.

爬山法（hill climbing）和向前搜索法（lookahead）是其中最簡單的2 類啟發式搜索方法. 其中，爬山法要求應用的性能與資源數量之間的關系函數為凸函數，它總是沿著應用性能收益最大的方向進行搜索；而向前搜索法類似于窮舉法，可適用于應用性能函數為非凸函數的場景. Whirlpool[96]利用爬山法計算應用的性能收益來決定將當前一路LLC 資源分配給哪個資源組，最終對所有LLC 資源逐個進行分配，該方法將平方階的搜索復雜度降低為線性的搜索復雜度，降低了時間開銷. 然而，Whirlpool 通過逐個單位進行資源分配的方法對搜索空間進行剪枝，雖然降低了搜索復雜度，但是易錯過某些最優資源分配方案. UCP[97]和KPart[98]利用向前搜索法對每種可能的資源分配方案都計算了性能收益，通過全局搜索來選擇收益最大的方案. 該方法類似于窮舉搜索法，其較高的時間復雜度限制該方法僅適用于應用數量和資源類型數量較少的場景. 此外，KPart 和Whirlpool均通過合并應用的性能信息來計算不同資源分配方案的性能收益，該方法雖然利用了應用對資源使用偏好的多樣性將干擾較低的應用混部在一起運行來降低干擾的影響，但當混部的應用數量增多時，這種按照概率計算性能組合的方式會隨著迭代次數的增多而導致誤差被放大，使得最終計算出的性能損失精確度降低，因此這2 個工作都僅適用于應用數量較少的場景.

為解決窮舉搜索法所帶來的高額時間開銷問題，Avalon[99]提出了基于二分搜索的資源分配器. 該分配器負責搜索CPU 核和LLC 這2 個維度的資源，通過分析發現，應用的性能在CPU 和LLC 資源上是一個凸函數，從而保證了二分搜索能像窮舉搜索一樣得到最優資源分配方案. 針對目標應用，Avalon 資源分配器首先將LLC 資源設置為最大值，二分搜索CPU資源分配方案查找最優的CPU 資源數量，待CPU 資源確定后再繼續二分查找最優的LLC 資源數量. 該方法通過將搜索最優解的復雜度降低到log 級別從而做到快速搜索最優解. CoPart[34]將資源分配問題表述為醫院/居民的多對一匹配問題，通過維護LLC 和內存帶寬2 個有限狀態機來判斷每個應用的狀態，并向資源富裕的應用回收資源，將其重新分配以保證整體資源分配的公平性. Lin 等人[100]對函數應用的上下游依賴信息進行建模，利用函數應用存在關鍵路徑的特性提出了一種基于關鍵路徑的算法PRCP，該算法通過貪心策略來遞歸優化關鍵路徑上函數應用的內存配置，從而得到最優內存資源配置方案，該算法的目標在于解決預算約束下的應用最佳性能和性能約束下的最佳成本問題.

總結來說，雖然啟發式算法利用專家經驗剪枝降低了搜索資源空間的復雜度，但僅適用于資源類型較少的場景，原因有2 點：1）應用在多資源維度下的性能關系函數更復雜，此時可能無法用凸優化算法來尋找可行解，并且啟發式搜索算法易落入局部最優解；2）當要分配的資源類型增加時，待搜索的資源空間呈指數級增長，使得搜索最優解的復雜度增加.

4.4 基于資源分配模型

基于資源分配模型的資源分配方法是指利用數據挖掘、機器學習或神經網絡等方法構建資源分配方案與應用性能的模型，模型的輸入通常為應用的畫像信息、節點負載情況、應用上下游依賴信息、資源類型與數量或應用運行時指標等，模型的輸出為最優資源分配方案、預測的應用性能值或應用發生QoS 違例的概率. 該方法適用于應用在多資源維度下應用性能與各維度資源數量的函數關系未知的場景.

針對多維度資源下應用性能與資源分配量的函數關系不是凸函數的場景，CLITE[61]和SATORI[101]利用貝葉斯優化來構建資源分配模型，從而在多資源維度下快速尋找最優解. 貝葉斯優化是一種通用的黑盒優化算法，用于求解未知目標函數的極值問題.它首先對目標函數進行建模，即利用高斯過程回歸計算每一個采樣點函數值的均值和方差，然后根據均值和方差構造采集函數. 之后，利用采集函數來尋找下一個最有可能是極值的點，并將該點加入采樣點集合中，重復這一搜索過程，直到迭代結束. 最后這些采樣點中目標函數值最大的點即為最優解. 利用貝葉斯優化來構建資源分配模型的優勢在于其適合黑盒優化問題，無需應用的先驗知識即可自動搜索出最優資源分配方案以最大化目標函數. 根據構建的打分函數不同，貝葉斯優化可用于解決不同優化目標下的資源分配問題. 為解決LS 應用與BE 應用混部時的性能保障與最大化資源使用率問題，CLITE 在運行時分別計算LS 應用和BE 應用的性能分數，通過構建2 階段打分函數來衡量當前資源分配方案的有效性. 為保障多BE 應用混部時應用間資源分配的公平性以及最大化系統吞吐率的問題，SATORI 在運行時根據節點信息動態調整打分函數中的資源公平性和吞吐率需求的權重值，以此來達到全局最優性能收益.

此外，機器學習也被廣泛應用于應用性能關系函數未知的場景中. DRLPart[102]利用深度強化學習構建了多資源分配模型，該模型通過系統運行時信息學習最優的資源分配方案. 為了降低模型訓練成本，通過構建性能預測模型來降低訓練開銷，并結合反饋調節機制解決可能出現的錯誤決策，以保障應用性能. 相似地，Hipster[103]使用了啟發式和強化學習相結合的混合式資源分配方法. Hipster 將資源分配問題描述為馬爾可夫決策過程，首先它根據應用當前所處的狀態選擇要執行的動作，再根據所選擇的動作和當前狀態估計執行該動作所能收到的獎勵，來確定下一個時間間隔的資源配置；之后，它通過不斷填充查找表來在線學習合適的資源配置. 在模型學習階段，Hipster 利用反饋控制循環將LS 應用部署到對應的資源上，當應用負載較低時，為應用分配較小的CPU 核和較低的CPU 頻率；反之則為應用分配較多的資源. 在模型利用階段，Hipster 使用查找表根據負載來選擇合適的CPU 核和頻率設置，同時不斷更新查找表的信息. 與Hipster 利用查找表類似，CuttleSys[104]利用協同過濾方法來推斷應用在不同資源配置下的性能和功耗，并通過動態維度搜索來尋找合適的資源配置方案，以保障LS 應用的性能.

由于上述方法在構建資源分配模型時僅考慮了應用自身的性能變化，因此，其僅適用于無上下游依賴的單體式應用. 然而，近年來云應用已經逐漸從單體式應用轉變為有多層依賴關系的微服務，這種復雜的依賴關系為系統的資源管理帶來了新的挑戰，例如應用間復雜的拓撲使得端到端請求的關鍵路徑不斷變化[60]，此外還加劇了排隊延遲效應[71]，應用因上下游應用的排隊問題造成的性能下降可能會在幾個單位時間后才表現出來，同時還引入了級聯效應[72,105]等. 由此，根據應用的上下游依賴信息綜合構建應用資源分配模型成為新的研究熱點.

為解決因微服務之間的依賴關系導致的排隊延遲效應問題，Sinan[71]構建了一個2 級資源分配模型：在給定資源配置下，第1 級模型利用卷積神經網絡預測應用在下一個時間戳的延遲；第2 級模型利用卷積神經網絡中提取的變量和提升樹（Boosted Trees）來判斷目標應用在下一個時間戳之后未來應用發生QoS 違例的概率. Sinan 選擇2 級模型是因為若只預測應用在下一個時間戳的性能，會忽略應用因上下游依賴所導致的排隊延遲效應，而排隊效應所帶來的性能下降需要在幾個時間戳后才能顯現出來；若直接預測應用在未來幾個時間戳下發生QoS 違例的概率，一種直觀的方法是使用多任務學習神經網絡，但該方法會嚴重高估應用的延遲和發生QoS 違例的概率，預測準確率低. 因此，這種2 級資源分配模型可以用于解決復雜依賴下應用的資源分配問題.

在函數應用存在復雜依賴網絡和關鍵路徑會動態變化的場景下，為保障函數鏈的整體性能，FIRM[60]提出了一個基于機器學習的2 級資源分配模型. 為減少需要調整的目標應用個數，第1 級模型用于尋找延遲波動最大的應用并將其視為關鍵路徑上的目標應用；第2 級模型用于自動搜索資源分配空間并優化資源管理策略，它通過分析共享資源的競爭情況來判斷是否對目標應用調整資源數量或調整部署的應用個數，并通過反饋循環來不斷優化模型.

總結來說，基于資源分配模型的資源分配方法雖然能解決未知目標函數的極值問題，但需考慮的參數更多，不僅包括多維度資源還包括應用的負載變化、應用間干擾和上下游依賴信息等，同時需要大量的訓練數據來訓練模型以提升模型預測的準確率.因此，在模型未訓練完成時，可以與4.1～4.3 節所述的資源分配方法配合使用.

4.5 總 結

總結來說，第3 節所述的干擾檢測是混部場景下應用性能保障的第1 步，最終的保障需要落實在本節討論的資源分配上. 在資源空間尋找最優資源分配方案是單節點性能保障的關鍵，該問題類似于最優化問題，通過構建最優化算法，根據專家經驗、規則或黑盒模型在資源空間中得到滿足約束條件的最優解，其代表性工作匯總如表4 所示. 此外，相較于“發生干擾—干擾消除”的事后性能保障方法，若能在應用發生性能干擾之前就未雨綢繆，通過從多個資源類型維度同時入手，利用資源隔離技術在干擾的源頭直接保障應用性能，以此尋找最優資源配置能產生更直接的保障效果. 但這對應用性能預測工作提出了更高的要求.

Table 4 Summary of Node Resource Allocation Research Work表4 單節點資源分配研究工作總結

5 集群作業調度

集群作業調度是用于決定將用戶提交的應用放置到具體哪個節點上運行，它從宏觀的角度出發通過避免將易產生干擾的應用放置在同一節點來最小化性能干擾，從而在保障應用性能的同時提升資源使用效率. 混部場景下的作業調度是一個多目標優化問題，調度結果不僅要滿足應用的資源規格和資源數量需求，還需要兼顧集群整體的吞吐率、負載均衡和混部性能干擾影響等. 根據資源類型數量、應用數量、應用資源需求和最小化性能干擾等約束和目標不同，需要用不同的方法來解決.

5.1 基于經驗規則

基于經驗規則的集群作業調度方法是指根據專家經驗、優化目標和約束條件制定規則，調度器按既定規則對新到來的應用進行調度. 該方法要求優化目標和約束條件能量化表示.

對于存在復雜依賴的大型LS 應用，Rhythm[81]利用子應用對整體LS 應用性能的貢獻度和子應用的干擾耐受性來指導BE 應用的調度，在保證LS 應用不受影響的前提下，混合部署更多的BE 應用以充分利用閑置資源. 分析發現大型LS 應用的各個子應用對干擾的耐受性是不同的，因此從應用的整體性能出發，通過計算單個子應用性能的均值、方差和相關系數來量化子應用對整體性能的貢獻度. 之后根據貢獻度信息對每個LS 子應用推導出2 個閾值，分別用于表示該子應用能否與BE 應用混合部署和能給BE 應用分配多少資源，以此來指導對BE 應用的調度，對整體性能貢獻度較小的子應用可以混合部署更多的BE 應用. 另一類工作利用應用的上下游依賴信息來制定作業的調度策略. CARBYNE[106]利用應用之間的上下游依賴、資源需求和持續時間等信息，在最大化資源分配公平性、最小化應用完成時間和最大化資源利用率的目標下，通過使用最短剩余時間優先（shortest remaining time first，SRTF）的作業調度算法，盡可能將更多的應用調度到集群的剩余資源中，以提升資源利用率.

此外，一些工作通過量化作業調度的約束條件來設計打分規則，并根據這些規則對備選節點進行打分，最后調度器根據節點的分值大小來進行作業調度決策. 文獻[65]提出利用物理機的歷史資源利用率信息和應用特征來指導BE 應用的調度方法，根據物理機的3 種資源利用率模式和BE 應用的依賴信息設計打分規則，對于每個BE 應用根據最后分數來選擇合適的節點，從而通過充分利用集群中空閑的計算和存儲資源來提升資源利用率. 文獻[107]提出5 項原則來指導作業調度，根據應用的負載特征和優先級等信息對5 項原則設置了不同的權重，每個節點的最終分值為5 項分數的加權和，最終將應用調度至分值最大的節點.

總結來說，基于經驗規則的作業調度算法其優化目標和約束條件較為簡單，能通過量化來形成經驗規則或打分規則，但不適用于優化目標較多或約束條件較為復雜的場景，原因有2 點：1）當優化目標增多時，優化問題復雜度上升，在設計打分規則時難以兼顧多個目標；2）當約束條件較為復雜時，其形式化難度也隨之上升，同時針對不同的約束條件，其分值權重的變化會直接影響到作業調度結果，因此，如何選擇合適的權重值也成為新的挑戰.

5.2 基于性能預測

基于性能預測的集群作業調度算法是指利用機器學習等方法來構建應用的性能預測模型，通過模型來推斷應用在不同的約束條件、干擾強度或作業放置方案等場景下的性能，以此來指導調度決策.

一些工作利用推薦算法來推測新提交的、未知應用的性能，根據應用在不同干擾和資源配置下的預測性能來進行調度決策. Paragon[76]，Quasar[3]，Mage[108]均利用協同過濾方法推斷新提交的應用在干擾或不同資源配置下的性能，并利用應用的分類信息和貪心算法進行作業調度決策，為應用分配最匹配的服務器類型、資源數量和混部應用，以最小化應用間干擾并最大化資源利用率. 區別在于Paragon 只負責為BE 應用選擇合適配置的物理機節點，它利用協同過濾方法推斷應用在不同異構資源下的性能和應用在不同干擾下的性能來選擇合適的物理機，以最小化性能干擾. 而Quasar 在為應用選擇合適配置的物理機和最小化性能干擾的同時，還利用協同過濾算法為應用尋找合適的資源分配量. Mage 利用一個3 階段的協同過濾模型來對未知的應用進行調度. 階段1通過利用干擾注入法來獲得目標應用在多個資源維度上的干擾敏感度信息；階段2 利用階段1 的干擾敏感度信息和初始化作業調度方案來獲得目標應用的性能；階段3 利用階段2 的輸出結果來推斷所有作業調度方案的性能. 最終在階段3 的輸出中選擇全局性能最優的調度方案.

另一類工作利用應用之間的上下游依賴、執行重疊度或干擾敏感度等信息預測應用混部后的性能，從而向集群中空閑的資源上調度更多的BE 應用，在保障LS 應用性能的同時提升作業混部密度，以最大化資源使用率. 為了解決應用之間因灰度干擾導致的性能下降，Gsight[109]基于請求在不同的執行路徑上端到端性能的空間變化性與應用之間在不同程度的執行重疊下其性能的時間變化性等特征，提出了一種干擾感知的作業調度策略，該策略利用函數應用鏈的端到端調用路徑的時空干擾畫像構建增量學習模型，通過模型預測應用在不同節點上的性能以輔助作業調度決策. 最終Gsight 利用二分搜索算法從應用之間完全重疊開始搜索調度方案，以實現將應用調度到盡可能少的節點上. Pythia[110]通過構建一個線性回歸模型來預測LS 應用與BE 應用混部后LS應用的性能，最后利用最佳適應（best fit）算法從全部可用節點中選擇能滿足LS 應用性能約束且資源大小最小的節點，并將BE 應用調度到該節點運行.

5.3 總 結

總結來說，集群作業調度可視為宏觀層面的應用性能保障方法，即從集群的全局視角出發，在為應用選擇合適的節點時就將降低性能干擾作為調度約束條件之一，避免將易產生干擾的應用調度到同一節點混合部署，從作業調度角度保障應用的運行時性能，同時通過緊湊的作業放置來最大化集群資源利用率，其代表性工作匯總如表5 所示. 在調度目標和約束較為簡單且可量化的場景下，可利用專家經驗直接制定調度規則或打分規則來指導調度；而當調度目標與約束條件很難用簡單方法量化時，可通過構建應用的性能預測模型來預測應用在不同的約束條件或混部場景下的性能，以此來指導作業調度.集群作業調度方法與上述的干擾消除、單節點資源分配方法是正交的，可以在混部場景中同時采用，從全局視角和單節點的局部視角2 方面同時保障應用性能并提高資源利用率. 文獻[79]詳盡地介紹了以上3 種方法在工業界的系統實例.

Table 5 Summary of Cluster Job Scheduling Research Work表5 集群作業調度研究工作總結

6 挑戰與展望

隨著編程模型的快速發展，大型應用往往被劃分成一組小的應用，每個應用獨立運行，應用之間通過松耦合的形式相互連接、協調通信并對外提供服務. 這種松耦合的架構促使將復雜應用進行細粒度的分解，這極大增強了服務的可擴展性和容錯性，同時也便于單個應用模塊的升級與維護，如近幾年備受關注的微服務[72]和無服務計算[49]. 對于無服務計算，大型應用被分解成小應用，以函數的形式提供簡單服務，多個函數應用之間構成復雜依賴網絡對外提供復雜服務. 然而，隨著應用粒度越來越小，應用的部署密度趨于不斷增加，應用間的依賴關系也變得愈加復雜. 部署密度是指單位資源上（如CPU 核）運行的應用個數. 在無服務計算的場景下，1 個CPU核上需要支持多個函數應用的運行[111]，這些函數應用共享同一CPU 核資源. 這種核內共享的混部方式使得資源管理與性能保障變得更為復雜.

本文介紹的混部場景下應用性能保障研究主要聚焦于低密度混部場景，即1 個或多個單位資源上只運行1 個應用. 若將其遷移到無服務計算的高密度混部場景下，由于在單位資源上混部應用個數不斷增加、在空間上應用的依賴關系愈加復雜，使得在單節點尋找最優資源分配方案、在全局尋找最佳作業調度方案等研究的復雜度也隨之增加. 因此，當前的工作仍然存在3 個問題和挑戰.

1） 更細粒度的資源分配. 與傳統應用相比，函數應用需要更少的資源來滿足性能約束. 當前，無服務計算的服務提供商不僅限制了函數應用代碼的大小，還限制了請求和響應包的大小，這種拆分成函數粒度的應用使得其具有更細粒度的資源需求. 在LLC資源方面，傳統應用至少需要4～6 MB 緩存資源來保障性能[112]，而函數應用僅需要1～3 MB 緩存資源就可支持應用在高負載下運行[33]，在低負載時較少的LLC 的資源即可滿足性能約束；在CPU 資源方面，不同于大型應用需要獨占多個CPU 核，多個函數應用可共享同一CPU 核資源；在內存資源方面，資源分配單位不再是按照GB 分配，而是按MB 進行分配，在微軟的函數集群中，99%的函數應用消耗的內存不超過1 024 MB[67]. 如表4 所示，當前只有少數代表性工作支持內存資源的劃分，且已有工作均是以GB 為單位進行資源分配，這需要更細粒度的內存分配算法支持. 因此，在高密度混部下資源分配需要滿足2點需求：1）性能隔離，在軟件或硬件層面需要更細粒度的資源隔離機制以保障應用的性能；2）更合理的資源分配方案. 應用更細粒度的資源需求需要更靈活的資源分配模式，如何更高效地將多個應用整合到1 個資源單位中，哪些應用可以共享資源而哪些應用必須使用隔離資源，這些都是在高密度混部場景下需要解決的挑戰.

2） 更高維度的資源空間. 在高密度共享下，單位資源上運行的應用數量不斷增加，CPU 核內資源共享使得資源的分配粒度更細，內存資源從以GB 為單位降低到以MB 為單位進行分配，進而導致資源搜索空間以指數級增長. 在更高維度的資源空間下，上述窮舉搜索、梯度下降等最優資源分配搜索方法因時間開銷大、易落在局部最優解上等局限性已無法應用于該場景，需要更高效的資源分配算法. 因此，在更高維度資源空間下的資源分配算法應滿足2 點要求：1）時間開銷小. 能在高維資源空間和高密度混部下快速找到最優的資源分配方案. 2）質量高. 能找到全局最優解或次優解，在保障應用性能的同時留出更多的資源供其他應用使用，以提升資源利用率.

3） 全局視角下性能感知和干擾感知的作業調度. 為了降低應用的運行時干擾，一些工作[113]設計了以CPU 核為粒度的作業調度器，將函數應用直接調度到核上，同時避免將多個函數應用調度到同一CPU 上運行以實現性能隔離，但是其在進行調度決策時忽略了應用之間的依賴關系. 目前，LS 應用間的依賴關系已經愈加復雜，與之相應的請求調用鏈路長度也在增加. 在阿里巴巴的混部集群中，1 個LS 應用請求的調用深度平均為4.27，即1 個請求平均需要經過4 個應用處理后才能向用戶返回結果，請求鏈路最深能達到20[70]. 雖然阿里巴巴在集群各個層面都做了緩存，但不斷增加的調用深度加劇了請求性能的不可預測性，調用鏈中的任何一個應用出現干擾都可能會影響整個請求的響應時間，同時該應用節點也會影響到上下游其他調用鏈路的性能. 因此，全局視角下的作業調度應滿足2 點要求：1）全局性能感知. 當單個應用出現性能干擾時能根據其所處的節點位置和上下游依賴關系做到及時預判，對可能影響到的端到端請求和級聯效應做到及時調整資源或彈性伸縮. 2）全局干擾感知. 在作業調度時能根據集群中作業整體部署情況和應用的干擾敏感度有針對性地進行調度，在減少混部干擾的情況下做到高質量作業放置.

總結來說，高密度混部的應用性能保障不僅對單節點的干擾檢測和資源分配提出了更高的要求，對集群層面的作業調度和宏觀資源分配更是提出了新的挑戰. 將上述兩者相互結合，構建全棧式的軟/硬件協同資源保障方法能夠在混部集群全面地保障應用性能. 全局作業調度從宏觀角度降低應用間的混部干擾，單節點干擾檢測和軟/硬件資源分配從微觀角度為應用的性能保障兜底. 在高密度混部場景下，該方法有助于在滿足應用性能約束的情況下提升整體資源使用率，最大化數據中心經濟效益.

7 全文總結

混部作為提升數據中心資源使用效率的關鍵技術已被廣泛應用于真實場景中. 然而，由于混部應用對共享資源的爭搶，如何解決因資源爭用導致的性能干擾已成為混部場景下的關鍵問題.

本文介紹了面向多應用混部的性能保障方法的研究工作，從特征分析、干擾檢測、單節點資源分配以及集群作業調度4 個方面討論了其代表性工作，并對相應方法做出了總結. 其中集群和應用的特征分析是干擾檢測和應用性能保障的基礎，為應用的資源分配決策提供了依據. 然而，由于集群資源與應用特征的多樣性，使得資源分配、作業調度等優化問題的復雜度也隨著場景的不同而變化. 從混部場景下優化問題的復雜度來看，可將本文工作思路歸納為2 類：基于專家經驗和規則的性能保障方法和基于模型的性能保障方法. 對于混部應用個數較少、資源空間較小、約束條件和目標能量化表示等場景，可根據專家經驗來制定啟發式算法或規則對應用進行資源分配和作業調度. 然而，對于混部應用個數較多、資源空間較大、目標函數未知等場景，由于難以用簡單的規則刻畫應用在多因素共同影響下的復雜行為和性能變化，需要通過數據挖掘、強化學習等方法構建資源干擾/分配和應用性能變化的模型，以此來指導資源分配和作業調度. 本文最后梳理了隨著混部密度不斷增加，應用性能保障的挑戰與展望，總結性提出了保障混部應用性能發展趨勢是采用全棧式的軟/硬件協同的方法，該方法有助于在高密度共享下保障應用的性能以及提高數據中心的資源使用效率.

作者貢獻聲明：郭靜負責搜集、整理混部場景下性能保障相關的研究工作和工作之間的邏輯聯系，以及文章整體架構設計、撰寫和修改；胡存琛負責干擾檢測部分的相關工作整理，以及單節點資源分配相關工作分類的指導，并對全文提出指導意見和修改論文；包云崗負責文章整體思路的指導和邏輯的調整，提出指導意見并修改論文.