摘要

原文鏈接：https://dl.acm.org/doi/pdf/10.1145/3342195.3387524

在許多公共和私有云系統(tǒng)中闲坎，用戶需要指定資源量（CPU內(nèi)核和RAM）的限制以為其工作負荷提供資源秕重。 超出其限制的作業(yè)可能會受到限制或終止，從而導致最終用戶請求的延遲或丟棄玉掸，因此人工操作人員針對這種問題出于謹慎考慮陶衅，會申請高于任務自身需要的配置诱建。 從規(guī)模上講蜘醋，這將導致大量的資源浪費。

為了解決這個問題烤惊，Google使用Autopilot自動配置資源，同時調(diào)整作業(yè)中的并發(fā)任務數(shù)（水平縮放）和單個任務的CPU /內(nèi)存限制（垂直縮放）吁朦。 Autopilot與人工操作員遵循相同的原則：Autopilot的主要目標是減少松弛（slack）（申請資源和實際資源使用之間的差異）柒室，同時最大程度地降低因內(nèi)存不足（OOM）錯誤或 由于CPU節(jié)流，其性能下降喇完。 Autopilot將機器學習算法應用到有關(guān)作業(yè)先前執(zhí)行情況的歷史數(shù)據(jù)上伦泥，再加上一組經(jīng)過微調(diào)的啟發(fā)式方法來實現(xiàn)這一目標。 在實踐中锦溪，Autopilot工作只有23％的松弛（slack）不脯，而手動管理工作只有46％的松弛（slack）。 此外刻诊，Autopilot將受OOM嚴重影響的工作數(shù)量減少了10倍防楷。

盡管有其優(yōu)點，要確保Autopilot被廣泛采用仍需付出巨大的努力则涯，包括使尚未加入的客戶容易看到潛在的建議复局，自動遷移某些類別的任務以及增加對自定義推薦器的支持。 在撰寫本文時粟判，Autopilot任務占Google資源使用的48％以上亿昏。

ACM參考格式：

Krzysztof Rzadca，Pawel Findeisen档礁，Jacek Swiderski角钩，Przemyslaw Zych，Przemyslaw Broniek呻澜，Jarek Kusmierek递礼，Pawel Nowak，Beata Strack羹幸，Piotr Witusowski脊髓，Steven Hand和John Wilkes。 2020年栅受。

Autopilot：Google的工作負載自動縮放将硝。 在第十五歐洲2020年4月27日至30日恭朗，計算機系統(tǒng)會議（EuroSys'20），希臘伊拉克利翁袋哼。 ACM冀墨，美國紐約，紐約涛贯，共16頁诽嘉。 https://doi. org/10.1145/3342195.3387524

1 介紹

許多類型的公共云和私有云系統(tǒng)要求其用戶聲明在執(zhí)行期間其工作負載將需要多少個實例以及每個實例所需的資源：在公共云平臺中，用戶需要選擇他們需要租用虛擬機（VM）的類型和數(shù)量弟翘； 在Kubernetes集群中虫腋，用戶可以設置Pod副本的數(shù)量和單個Pod的資源限制; 在Google中，我們要求用戶指定所需的容器數(shù)量以及每個容器的資源限制稀余。 這些限制使云基礎架構(gòu)能夠提供足夠的性能隔離悦冀，從而使云計算成為可能。

但是限制（主要是）對用戶造成了麻煩睛琳。 很難估計一個作業(yè)需要多少資源才能最佳運行：CPU功率盒蟆，內(nèi)存和同時運行的副本數(shù)的正確組合。 負載測試可以幫助找到初始估計值师骗，但是隨著資源需求隨時間變化历等，這些建議將過時，因為許多最終用戶服務工作具有每日或每周的負載模式辟癌，并且隨著服務變得越來越流行寒屯，流量在更長的時間內(nèi)發(fā)生變化 。 最后黍少，處理給定負載所需的資源會隨著基礎軟件或硬件堆棧的新功能寡夹，優(yōu)化和更新而變化。如果CPU容量不足厂置，超出請求的資源可能會導致性能下降菩掏，或者導致任務被殺死 內(nèi)存不足（OOM）。 都不是好事昵济。

從調(diào)研結(jié)果看患蹂，理性的用戶將故意高估其工作所需的資源，從而導致對物理資源的不良利用砸紊。 一項分析[26]對在一個Google集群[27]上執(zhí)行的為期一個月的作業(yè)跟蹤顯示，平均內(nèi)存利用率為50％囱挑； 對阿里巴巴YARN集群的另一項分析[23]顯示任務的峰值內(nèi)存利用率從未超過80％醉顽。

針對配置資源的困難，一種常見的模式是采用水平自動縮放器平挑，該縮放器通過監(jiān)控終端用戶流量或平均CPU利用率的變化添加或刪除副本來縮放任務游添。 所有主要的云提供商（AWS系草，Azure和GCP）都提供水平自動擴展功能； 它在某些云中間件（如Kubernetes）中也可用唆涝。 較不常見的模式是使用垂直自動縮放來調(diào)整每個副本可用的資源量找都。 兩種技術(shù)也可以組合。

Autopilot是Google在其內(nèi)部云上使用的主要自動縮放器廊酣。 它提供水平和垂直自動縮放能耻。 本文重點介紹Autopilot的內(nèi)存垂直擴展，因為這種情況鮮為人知亡驰。 論文：

• 描述下Autopilot晓猛，以及它用于垂直自動縮放的兩個主要算法：第一個算法依賴于歷史用量的指數(shù)平滑滑動窗口； 另一個是基于從強化學習中借用的思想的元學習凡辱，該算法運行滑動窗口算法的許多變體戒职，并為每個任務選擇歷史數(shù)據(jù)表現(xiàn)最佳的算法。（譯注：強化學習：依賴海量的訓練透乾，并且需要精準的獎勵洪燥。成本較高且比較復雜。元學習：具備自學能力乳乌，能夠充分利用過去的經(jīng)驗來指導未來的任務捧韵。被認為是實現(xiàn)通用人工智能的關(guān)鍵。）

• 通過Google的工作負載采樣評估Autopilot算法的有效性钦扭；

• 討論為使我們的集群廣泛采用Autopilot而采取的步驟纫版。

2 通過Borg管理云資源

Autopilot的目標和制約因素來自Google的Borg基礎架構(gòu)，并且針對Google的工作負載進行了調(diào)整客情。 我們在此處提供了兩者的簡要概述：有關(guān)Borg的更多詳細信息其弊，請參見[34]，有關(guān)工作負載的更多詳細信息膀斋，請參見[26梭伐、27、31仰担、35]糊识。

2.1 機器、作業(yè)和任務

Google計算基礎架構(gòu)由分布在多個地理位置的許多集群組成摔蓝。一個中值集群大約有10,000臺物理機赂苗，并同時運行許多不同類型的工作負載。一臺物理計算機可能會同時計算大量占用內(nèi)存和CPU的批處理贮尉，提供存儲和內(nèi)存數(shù)據(jù)庫的切片提供查詢能力拌滋，還可以處理對延遲敏感的終端用戶請求。

（We call a particular instance of a workload a job.）我們稱工作負載的特定實例為工作猜谚。一項作業(yè)由一個或多個任務組成败砂。任務在單個物理計算機上執(zhí)行赌渣；一臺機器可以同時執(zhí)行多個任務。作業(yè)是與具有某些功能的服務（例如文件系統(tǒng)或身份驗證服務）相對應的邏輯實體昌犹；任務執(zhí)行實際工作坚芜，例如為最終用戶或文件訪問請求提供服務。一項作業(yè)持續(xù)數(shù)月的情況并不罕見斜姥，盡管在這段時間內(nèi)我們可能會多次執(zhí)行該任務運行的二進制文件鸿竖。在作業(yè)發(fā)布時，新任務逐漸取代了運行舊二進制文件的任務疾渴。

我們運行的工作負載可以分為兩類：服務和批處理千贯。服務工作通常旨在嚴格保證查詢響應時間的性能（例如，在95％的位置上搞坝，請求延遲服務級別目標或SLO≤50 ms）搔谴。如此嚴格的等待時間要求排除了OS內(nèi)核決定之外的任何帶內(nèi)資源分配決策，因此服務作業(yè)具有為其明確請求預留的資源桩撮。相反敦第，批處理作業(yè)旨在“快速”完成并退出，但通常沒有嚴格的完成期限店量。服務性工作是我們基礎架構(gòu)能力的主要驅(qū)動力芜果，而批處理工作通常會填充剩余或暫時未使用的能力，如[4]所示融师。

內(nèi)存不足（OOM）事件終止單個任務右钾。某些工作可以合理地容忍OOM事件。有些根本不是旱爆；還有一些介于兩者之間舀射。總體而言怀伦，由更多任務組成且狀態(tài)較少的作業(yè)在單個任務終止時遇到的服務故障越小脆烟，因此對OOM容災能力更高。有些作業(yè)需要低的房待，可重復的延遲來處理請求邢羔。有些沒有。Autopilot會根據(jù)作業(yè)的聲明大小桑孩、優(yōu)先級和類別選做默認值拜鹤，但允許我們的用戶覆蓋它們。Borg驅(qū)逐任務流椒，為了安全性和OS更新署惯，為更高優(yōu)先級的任務騰出空間，并讓我們更有效地將工作打包到計算機上镣隶。我們有意識的通過計算集群架構(gòu)和應用的彈性來分散負荷极谊。系統(tǒng)期望通過彈性解決任務驅(qū)逐和硬件故障問題。Borg發(fā)布了預期內(nèi)最大驅(qū)逐率安岂，觀察到的驅(qū)逐率之間的差異也使我們可以自由地使用任務的資源設置進行實驗-在了解任務需要時可以偶爾進行OOM轻猖。 （使用VM實時遷移之類的工具來隱藏外部Cloud VM的這些內(nèi)部優(yōu)化。）一個典型的服務工作有很多任務域那，并且負載均衡器將流量驅(qū)動到可用負載咙边，因此丟失任務只會導致其負載平攤給其他任務。 這是正炒卧保現(xiàn)象败许，而不是災難性的故障，它使我們能夠更加積極地利用基礎架構(gòu)淑蔚，并能夠妥善處理偶發(fā)的硬件故障市殷。 使用MapReduce [6]中使用的技術(shù)，在批處理作業(yè)中也內(nèi)置了類似的彈性刹衫。

2.2 Borg調(diào)度架構(gòu)

每個集群都由我們專用的集群調(diào)度程序Borg的專用實例管理醋寝。 下面，我們簡要介紹Borg架構(gòu)和功能, 因為會直接影響Autopilot設計带迟； 請參閱[34]以獲取完整說明音羞。

Borg有一個多復本的Borgmaster，負責制定計劃決策仓犬，還有一個稱為Borglet的代理程序嗅绰，它在集群中的每臺計算機上運行。 一臺機器可以同時執(zhí)行Borglet控制的數(shù)十個任務搀继； 依次將其狀態(tài)和資源使用情況報告給Borgmaster窘面。 將新作業(yè)提交給Borgmaster時，它會選擇一臺或多臺機器律歼，這些機器上有足夠的空閑資源來執(zhí)行新提交的作業(yè)–或通過驅(qū)逐優(yōu)先級較低的作業(yè)來騰出空間來創(chuàng)建這種情況民镜。 在Borgmaster決定將任務的任務放置在何處后，它將啟動和運行任務的過程委派給所選計算機上的Borglet险毁。

2.3 通過任務限制進行資源管理

為了獲得可接受和可預測的性能制圈，必須將一臺計算機上運行的任務相互隔離。 與Kubernetes一樣畔况，Borg在單獨的Linux容器中運行每個任務鲸鹦，并且本地代理設置容器資源限制以使用cgroup實現(xiàn)性能隔離。 與操作系統(tǒng)級別的傳統(tǒng)公平共享不同跷跪，這可確保任務的性能在同一二進制文件馋嗜，不同機器（只要硬件相同）和不同鄰居（任務在同一機器上共同調(diào)度）的不同執(zhí)行之間保持一致 ）[38]。

在我們的架構(gòu)中吵瞻，CPU和RAM是需要管理的關(guān)鍵資源葛菇。 我們使用術(shù)語限制來指代通掣誓ィ可以消耗的每種資源的最大允許量。 由于Borg通常將作業(yè)的任務視為可互換的副本眯停，因此所有任務通常具有相同的限制济舆。

作業(yè)以標準化的毫核心表示其CPU限制[31]，并且此限制由標準Linux內(nèi)核cgroups機制強制執(zhí)行莺债。 如果爭用很少（以總體CPU利用率衡量）滋觉，則允許任務使用CPU超出其限制。 但是齐邦，一旦發(fā)生爭用椎侠，就會強制執(zhí)行限制，并且可能會限制某些任務以在其限制內(nèi)運行措拇。

作業(yè)以字節(jié)為單位表示其內(nèi)存限制我纪。 與標準Linux cgroup一樣，作業(yè)的RAM限制的實施可能是硬性的也可能是軟性的儡羔，并且作業(yè)的所有者在提交作業(yè)時聲明了實施類型宣羊。 一旦使用硬RAM限制的任務超過其限制，該任務就會因內(nèi)存不足（OOM）錯誤而被殺死汰蜘，并將故障報告給Borgmaster仇冯。允許使用軟RAM限制的任務可以內(nèi)存超過其限制，但如果計算機上的總體RAM利用率過高族操，則Borglet將開始殺死超出其限制的任務（帶有OOM錯誤）苛坚，直到該計算機不再受到威脅（參見標準）為止。 cgroup實施色难，只是防止超限容器保留更多的內(nèi)存）泼舱。

Borg允許作業(yè)在作業(yè)運行時修改其資源需求。在水平縮放中枷莉，作業(yè)可以動態(tài)添加或刪除任務娇昙。在垂直擴展中，作業(yè)可以更改其任務的RAM和CPU限制笤妙。增加作業(yè)的RAM和CPU限制是一項潛在的高成本操作冒掌，因為某些任務可能不再適合他們的計算機。在這種情況下蹲盘，這些計算機上的Borglet將終止一些優(yōu)先級較低的任務股毫；反過來，這些任務將重新安排到其他計算機上召衔，并可能觸發(fā)其他優(yōu)先級更低的任務的終止铃诬。 （幾年前贫途，我們大大降低了優(yōu)先級的有效數(shù)量礁鲁，以減少這種等級的數(shù)量）壁拉。

盡管通常會過度設置作業(yè)限制根穷，但存在一些背壓：我們向服務用戶收取他們保留的資源（而不是他們使用的資源）的費用，并且請求的資源會遞減用戶的配額-這是對用戶的嚴格限制他們可以在集群中的所有作業(yè)中獲得的資源總量吩坝。 這類似于對公共云中的VM使用定價和配額毒姨。 收費和配額都有幫助，但實際上效果有限：配置不足的弊端通常遠遠超過通過請求較少資源獲得的收益钉寝。 我們發(fā)現(xiàn)這是一個反復出現(xiàn)的主題：在實踐中，理論上可達到的效率通常很難實現(xiàn)闸迷，因為手動執(zhí)行所需的努力或風險過高嵌纲。 我們需要一種自動進行權(quán)衡的方法。 這就是Autopilot所做的腥沽。

3 Autopilot自動限制

Autopilot使用垂直縮放來微調(diào)CPU和RAM限制逮走，以減少冗余（即資源限制與實際使用之間的差異），同時確保任務不會耗盡資源今阳。 它還使用水平縮放（更改作業(yè)中的任務數(shù)）來適應更大的工作負載更改师溅。

3.1 架構(gòu)

Autopilot的功能體系結(jié)構(gòu)是三合一的閉環(huán)控制系統(tǒng)，一個用于每個作業(yè)級別的水平縮放盾舌，另兩個分別用于每個任務資源（CPU和內(nèi)存）的垂直縮放墓臭。該算法（在后續(xù)章節(jié)中詳細介紹）充當控制器。Autopilot單獨考慮作業(yè)-沒有跨作業(yè)學習能力妖谴。

Autopilot的實現(xiàn)（圖1）采用架構(gòu)上的一組標準作業(yè)的形式：每個集群都有自己的Autopilot窿锉。每個Autopilot的資源推薦器（根據(jù)其歷史使用情況來確定任務的大小）都作為單獨的任務運行膝舅，并具有三個任務副本以提高可靠性嗡载。多復本的Autopilot服務會選擇負責選擇用于作業(yè)的主推薦器，并通過執(zhí)行器作業(yè)將推薦信息（過濾后的）傳遞給Borgmaster仍稀。如果請求更改任務數(shù)量洼滚，則Borgmaster會相應地生成或終止任務。如果請求更改資源限制技潘，則Borgmaster首先會做出任何需要適應這些限制的調(diào)度決定遥巴，然后聯(lián)系適當?shù)腂orglet代理以應用更改。一個獨立的監(jiān)控系統(tǒng)跟蹤每個任務使用多少資源崭篡。Autopilot只是從中訂閱更新挪哄。

今天，我們的用戶通過一個簡單的標志設置就明確選擇了使用Autopilot的工作琉闪。 我們正在將其設置為默認值迹炼，并且允許顯式不使用。 用戶還可以通過多個方面配置Autopilot行為，例如：（1）強制所有副本具有相同的限制斯入，這對于只有一個活動主服務器的容錯程序很有用砂碉；（2）增加限制，以便來自另一個群集中的副本作業(yè)的負載將能夠立即故障轉(zhuǎn)移到該群集刻两。

將Autopilot的作業(yè)提交給Borgmaster時增蹭，它將暫時排隊，直到Autopilot有機會為其提出初步資源推薦為止磅摹。 之后滋迈，它將繼續(xù)進行正常的調(diào)度過程。

3.2垂直（每任務）自動縮放

Autopilot服務根據(jù)要自動縮放的資源是內(nèi)存還是CPU户誓，來選擇要用于作業(yè)的推薦器饼灿。 作業(yè)對資源不足事件的容忍度（延遲容忍度與否，OOM敏感度與OOM容忍度） 以及可選的用戶輸入（其中可能包括明確的推薦者選擇）或其他參數(shù)來控制Autopilot的行為帝美，例如可以設置的上限和下限碍彭。

3.2.1預處理：匯總輸入信號

推薦器使用預處理的資源使用信號。 大部分預處理是由我們的監(jiān)控系統(tǒng)完成的悼潭，以減少歷史數(shù)據(jù)的存儲需求庇忌。 聚集信號的格式類似于[35]中提供的數(shù)據(jù)。

低級任務監(jiān)控記錄原始信號是針對一項工作的每個任務的時間測量序列舰褪。 我們將監(jiān)視系統(tǒng)在任務time的時間recorded記錄為????[??]皆疹。 此時間序列通常每1秒包含一個樣本。

（例如抵知，TABLE1墙基。用于描述推薦者的符號

????[??] 每個任務的原始CPU / MEM時間序列（1s分辨率）

????[??] 按任務匯總的CPU / MEM時間序列（直方圖，5分鐘分辨率）

??[??] 每個作業(yè)的匯總CPU / MEM時間序列（直方圖刷喜，5分鐘分辨率）

?[??] 每個作業(yè)負載調(diào)整后的直方圖

??[??] 直方圖的第k個bin的值（邊界值）

??[??] the weight to decay the sample aged ??

??[??] 時的移動窗口推薦??

?? 模型（參數(shù)化的arg min算法）

???? 使用model模型的衰減率

???? 使用model的安全浮動空間

?? 推薦器測試的極限值

????[??] 使用模型??推薦的極限值

??[??] ML推薦器的最終推薦

??（??）限度的超支成本??

??（??）限制的底線成本??

???? 超支成本的權(quán)重

???? 不足成本的權(quán)重

??Δ?? 改變限制的懲罰權(quán)重

??Δ?? 權(quán)改變模型的懲罰重

?? 衰減率残制，用于計算模型成本

????[??] 模型m的（已減少）歷史成本

CPU或RAM使用率，或收到的查詢數(shù)）

為了減少設置作業(yè)限制時存儲和處理的數(shù)據(jù)量掖疮，我們的監(jiān)視系統(tǒng)將????[??]預處理為匯總信號??[??]初茶，該信號通常在5分鐘的窗口內(nèi)匯總值。 匯總信號??[??]的一個樣本是一個直方圖浊闪，總結(jié)了這5分鐘內(nèi)所有工作任務的資源使用情況恼布。

更詳細的內(nèi)容。對于每個窗口搁宾，聚合的每個任務信號????[??]是一個矢量折汞，其中的直方圖保持在原始信號????[??]上，其中??∈??盖腿。對于CPU信號爽待，此向量????[??] [??]的元素對落入大約400個使用桶中的每個原始信號樣本signal [??]的數(shù)量進行計數(shù)：????[??] [??] = |{????[??] : ?? ∈ ?? ∧?? [?? ? 1] ≤ ????[??] < ?? [??]}|损同，其中??[??]是第k個bin的邊界值（這些值由監(jiān)視系統(tǒng)固定）。對于存儲信號鸟款，我們在直方圖中僅記錄5分鐘窗口內(nèi)任務的峰值（最大）請求（即膏燃，每個任務直方圖????[??] [??]僅具有一個非零值）。內(nèi)存信號使用峰值而不是整個分布何什，因為我們通常希望提供（接近）峰值內(nèi)存使用率：與CPU相比组哩，任務對內(nèi)存不足配置（因為它將以OOM結(jié)尾）更加敏感。它只會受到CPU限制）处渣。

然后伶贰，我們通過簡單地將??[??] [??] = Σ?? ????[??] [??]，將每個任務的直方圖????[??]聚合為單個的每個作業(yè)的直方圖??[??]罐栈。 我們沒有明確考慮個別任務-例如幕袱，通過檢查極端價值。 由于大多數(shù)Borg作業(yè)中的單個任務都是可互換的副本悠瞬，因此除少數(shù)特殊情況外，我們對所有其他任務使用相同的限制涯捻。

3.2.2 移動窗口推薦器

移動窗口推薦器通過使用聚合信號?? 的統(tǒng)計信息來計算限制浅妆。

我們希望限制隨著使用量的增加而迅速增加，但要在負載減少后緩慢減小障癌，以避免對工作量暫時下降的過快響應凌外。 為了平滑對負載尖峰的響應，我們通過指數(shù)衰減權(quán)重??[??]對信號進行加權(quán)：

[圖片上傳失敗...(image-485e74-1610255534492)]

其中??是樣本年齡涛浙，而??1/ 2是半衰期：權(quán)重減少一半之后的時間康辑。 Autopilot適合長期運行的工作：我們將CPU信號的半衰期設為12小時，將內(nèi)存的半衰期設為48小時轿亮。使用以下有關(guān)的統(tǒng)計信息之一來計算時間??的推薦??[??]：

峰值(??max) 返回最近采樣的最大值疮薇，??max [??] = max?? ∈ {???(?? ?1),...,?? } {?? [??] : ??[??] [??] > 0}, 最近N個樣本中非空存儲桶的最大值，其中N是固定的系統(tǒng)參數(shù)我注。

加權(quán)平均 (????????)按咒，計算平均信號值的時間加權(quán)平均值：

[圖片上傳失敗...(image-d80952-1610255534492)]

??[??]是直方圖的平均使用率，[圖片上傳失敗...(image-bd1659-1610255534492)]

%j 調(diào)整使用量(??????),首先計算負載調(diào)整后的衰減直方圖?[?]但骨，其第??個元素?[??] [??]將第??個桶中的衰減樣本數(shù)乘以負載??[??]：

[圖片上傳失敗...(image-53749d-1610255534492)]

然后返回該直方圖的某個百分位數(shù)????（?[??]）励七。 ?與標準直方圖??的區(qū)別在于，在??中奔缠，每個樣品都具有相同的單位重量掠抬，而在?中，存儲桶??中的樣品重量等于負載??[??]校哎。

請注意两波，負載調(diào)整后的使用率的給定百分位數(shù)隨時間的變化可能與相同的使用率百分位數(shù)顯著不同。在許多情況下，我們要確保在設置限制以容納提供的負載時可以提供給定負載的給定百分位數(shù)雨女，而不是簡單地計算瞬時觀測到的負載可以處理的次數(shù)-即谚攒，我們希望根據(jù)負載而不是樣本數(shù)量來加權(quán)計算。圖2中說明了這種差異：如果將極限設置為1（時間的90％）氛堕，則最后時刻的9/19單位負載將超過極限（虛線下方）馏臭。在這種情況下，負載調(diào)整后的直方圖?的計算如下讼稚。由負載調(diào)整后的直方圖count計數(shù)的單個觀測值可以解釋為在一定負載（信號的當前電平）下處理的信號區(qū)域的單位括儒。 ?等于?[1] = 1·9（9個時間單位中的1的負載）和?[10] = 10·10（1個時間單位中10的負載）。因此锐想，?的90％ile（即要求以極限值或低于極限值處理90％的信號區(qū)域所需的極限）為10 –在這種情況下帮寻，意味著可以在極限范圍內(nèi)處理整個信號.

[圖片上傳失敗...(image-656a9-1610255534492)]

圖2.負載信號的90％ile可能與負載時間曲線積分的90％ile顯著不同。在此示例中赠摇，

使用基于時間的樣本固逗，負載的90％ile為1個單位，但如果還考慮了負載的大小藕帜，則為10個單位

Autopilot根據(jù)信號使用以下統(tǒng)計信息和作業(yè)類行烫罩。 對于CPU限制，我們使用：

• 批處理作業(yè)：????????洽故，這是因為贝攒，如果一項作業(yè)可以承受CPU限制，則對基礎結(jié)構(gòu)的最有效限制是該作業(yè)的平均負載时甚，這使該作業(yè)得以繼續(xù)進行而不會累積延遲隘弊。

• 服務作業(yè)：根據(jù)負載對延遲的敏感度，調(diào)整負載后的使用量是????95（95％ile）或????90（90％ile）荒适。

對于內(nèi)存梨熙，Autopilot根據(jù)作業(yè)的OOM公差使用不同的統(tǒng)計信息。 對于大多數(shù)大型作業(yè)吻贿，默認設置為“低”串结，對于小型作業(yè)，默認設置為“最小”（最嚴格）舅列，但可由用戶覆蓋：

• ????98 適用于OOM容錯低的作業(yè)肌割。

• ??max 適用于OOM容錯小的作業(yè)。

• 對于具有中等OOM容錯的作業(yè)帐要，我們選擇值來（部分）覆蓋短負載峰值把敞。 我們通過使用最大值????60（加權(quán)的60％ile）和最大值0.5％（最大值）的一半來做到這一點。

最后榨惠，這些原始建議在應用之前先進行后處理奋早。 首先盛霎，建議增加10％到15％的安全裕度（對于較大的限制較小）耽装。 然后愤炸，我們采用過去一小時內(nèi)看到的最大推薦值，以減少波動掉奄。

3.2.3基于機器學習的推薦器

原則上规个，Autopilot解決了機器學習問題：針對一項工作，根據(jù)其過去的使用情況姓建，找到一個限制诞仓，可以優(yōu)化表示該工作和基礎架構(gòu)目標的功能。上一節(jié)中描述的方法（基于對移動窗口的簡單統(tǒng)計來設置限制）指定了解決此問題的算法速兔。相比之下墅拭，Autopilot的ML推薦器從成本函數(shù)（所需解決方案的規(guī)格）開始，然后針對每個工作選擇合適的模型參數(shù)來優(yōu)化此成本函數(shù)涣狗。這種自動化使Autopilot可以為每個作業(yè)優(yōu)化先前方法為所有作業(yè)固定的參數(shù)谍婉，例如衰減率??1/ 2，安全裕度或縮減穩(wěn)定期镀钓。

在內(nèi)部屡萤，ML推薦器由許多模型組成。推薦者針對每項工作定期選擇效果最佳的模型（根據(jù)下面根據(jù)歷史使用情況計算得出的成本函數(shù)）掸宛；然后由所選模型負責設置限制。每個模型都是簡單的arg min類型算法招拙，可最大程度地降低成本–模型因分配給arg min（譯注：arg min 就是使后面這個式子達到最小值時的變量的取值）各個元素的權(quán)重而異唧瘾。機器學習方法反復出現(xiàn)的問題之一是其結(jié)果的可解釋性[8]：在Autopilot中，推薦器設置的限制必須向工作負責人解釋别凤。擁有許多簡單的模型有助于解釋ML推薦器的操作：單個模型大致對應于推斷的工作特征（例如饰序，穩(wěn)定時間長的模型對應于利用率變化迅速的工作）。然后规哪，考慮到所選模型所施加的權(quán)重求豫，其決策很容易解釋

更正式地說，對于信號??诉稍，在時間??蝠嘉，ML推薦器從一組模型{??}中選擇一個單個模型??[??]，用于推薦極限值杯巨。模型是參數(shù)化的arg min算法蚤告，可計算給定歷史信號值的極限。模型??由衰減率????和安全裕度????設置參數(shù)服爷。

在每個時刻??杜恰，模型都會測試所有可能的極限值??（可能的極限值對應于直方圖塊的后續(xù)邊界??∈{??[0]获诈，...，??[??]}）心褐。 對于每個極限值舔涎，模型都會根據(jù)最近的使用直方圖??[??]計算當前的超支和超支成本，然后用歷史值對其進行指數(shù)平滑逗爹。 超支成本??（??）[??]計算最近直方圖中超出限制??的存儲桶中的樣本數(shù)：

[圖片上傳失敗...(image-84fa43-1610255534492)]

同樣亡嫌，cost ??(??) [??] 計算低于限制??的存儲桶中的樣本數(shù)，

[圖片上傳失敗...(image-540fc2-1610255534491)]

然后桶至，模型選擇一個極限?? ′ ?? [??]昼伴，以使極限的可能變化最小化超限，超限和罰分Δ(??, ??′ ?? [?? ? 1])的加權(quán)和：

[圖片上傳失敗...(image-74df9e-1610255534491)]

如果??≠??镣屹，則Δ（??圃郊，??）= 1，否則為0女蜈。 （使用Kronecker delta持舆，Δ（??，??）= 1-????伪窖，??逸寓。）此函數(shù)包含在大型系統(tǒng)中做出資源分配決策的三個關(guān)鍵成本。 溢出表示損失機會的成本–在服務工作中覆山，發(fā)生溢出時竹伸，查詢會延遲，這意味著某些最終用戶可能不太愿意繼續(xù)使用該系統(tǒng)簇宽。 營業(yè)不足表示基礎設施的成本：工作儲備的資源越多勋篓，所需的電力，機器和人員就越多魏割。 懲罰項Δ有助于避免過于頻繁地更改限制譬嚣，因為這可能導致任務不再適合其當前計算機，從而導致其（或其他任務）被逐出.

最后钞它，將限制增加安全系數(shù)????拜银，即

[圖片上傳失敗...(image-6401b5-1610255534491)]

為了在運行時選擇模型（從而優(yōu)化特定作業(yè)的衰減率????和安全裕度）），ML推薦器為每個模型維護其（指數(shù)平滑）成本????遭垛，它是超限尼桶，不足和限制更改的懲罰：

img

由于歷史成本包括在???? [?? ? 1],中，因此給定模型的欠額????和超額????成本僅考慮最新成本锯仪，即直方圖樣本數(shù)超出最后一個樣本的限制疯汁，因此???? (???? [??], ??) = sigma:?? [??]>?? ??[??] [??], and ???? (???? [??], ??) = sigma ??:?? [??]<?? ??[??] [??].

img

最后，推薦人選擇的模型可以最大程度地降低此成本卵酪，但要更改限額和模型會受到其他懲罰：

img

總體而言幌蚊，該方法類似于multi-armed bandit problem（參考：https://blog.csdn.net/coffee_cream/article/details/58034628） 多臂老虎機問題谤碳，其中匪徒的“手臂”與限制值相對應。但是溢豆，多臂匪的關(guān)鍵特性是蜒简，一旦選擇了一個分支，我們就無法觀察到所有其他分支的結(jié)果漩仙。相反搓茬，一旦知道下一個時間段的信號，Autopilot便可以計算所有可能極限值的成本函數(shù)-除非極少數(shù)情況下队他，激活極限太小且任務以OOM終止（我們展示OOM在4.3節(jié)中很少見）卷仑。這種完全的可觀察性使我們的問題變得相當容易。

集成具有五個超參數(shù)：上面定義的成本函數(shù)中的權(quán)重（??麸折，????锡凝，????，??Δ??和??Δ??）垢啼。這些權(quán)重大致對應于美元機會與美元基礎設施成本窜锯。我們在離線實驗中調(diào)整這些超參數(shù)，在這些實驗中芭析，我們根據(jù)從代表性工作中獲取的已保存跡線的樣本來模擬Autopilot的行為锚扎。這種調(diào)整的目的是產(chǎn)生一種配置，該配置在大部分樣本中占據(jù)著替代算法（例如馁启，移動窗口推薦器）的主導地位驾孔，并且具有類似（或略低）數(shù)量的超限和極限調(diào)整，以及明顯更高的利用率惯疙。這種調(diào)整是迭代的和半自動的：我們對權(quán)重的可能值執(zhí)行參數(shù)掃描（詳盡搜索）助币；然后手動分析異常值（表現(xiàn)異常差的作業(yè)）。如果我們認為這種行為是不可接受的螟碎，則在下一次參數(shù)掃描的迭代中匯總結(jié)果時，我們會手動增加相應作業(yè)的權(quán)重迹栓。

這些離線實驗使用原始的（未調(diào)整的）使用軌跡掉分，即它們不嘗試根據(jù)新設置的限制來調(diào)整信號（例如，在OOM之后克伊，應終止任務然后重新啟動）酥郭。但是，根據(jù)特定的作業(yè)愿吹，OOM或CPU節(jié)流的影響可能有所不同–對于某些作業(yè)不从，OOM可能會增加未來的負載（因為終止的任務的負載由其他任務接管），而對于其他任務犁跪，這可能會導致服務質(zhì)量下降（當服務質(zhì)量下降時椿息，最終用戶會掉下來）歹袁。實際上，這不是問題寝优，因為使用情況調(diào)整事件很少發(fā)生条舔，而且我們會持續(xù)監(jiān)控生產(chǎn)中的Autopilot，在這種情況下乏矾，很容易發(fā)現(xiàn)過頻繁的OOM等問題孟抗。

3.3水平自動縮放

對于許多作業(yè)，僅垂直自動縮放是不夠的：單個任務不能超過其正在運行的計算機钻心。 為了解決這個問題凄硼，Autopilot水平縮放可根據(jù)作業(yè)的負載動態(tài)更改作業(yè)中的任務數(shù)量（副本）。 水平和垂直擴展機制相互補充：垂直自動擴展確定單個任務的最佳資源分配捷沸，而水平自動擴展隨著服務的受歡迎程度和負載的變化添加或刪除副本摊沉。

水平自動縮放使用以下來源之一在時刻?? 推導出原始建議????[??]：

CPU使用率：作業(yè)所有者指定（1）CPU使用率信號的平均窗口（默認為5分鐘）； （2）視界長度??（默認視界為72小時）亿胸； （3）統(tǒng)計??：max或??95坯钦，即95％ile； （4）目標平均利用率侈玄。 Autopilot根據(jù)最新T利用率樣本的值time在時間time處計算副本數(shù)number [??] = ????∈[?????婉刀，??] {??????[??]}。 然后序仙，原始建議的副本數(shù)為????[??] =????[??] /???突颊。

目標大小：作業(yè)所有者指定用于計算任務數(shù)量的函數(shù)潘悼，即????[??] =??[??]律秃。 該功能使用來自作業(yè)監(jiān)視系統(tǒng)的數(shù)據(jù)。 例如治唤，使用排隊系統(tǒng)管理請求的作業(yè)可以按請求處理時間的95％縮放棒动； 文件系統(tǒng)服務器可能會根據(jù)其管理的文件空間量進行擴展。

水平自動縮放比垂直自動縮放需要更多的自定義宾添，垂直自動縮放不需要為絕大多數(shù)作業(yè)進行配置船惨。即使在標準的CPU利用率算法中，作業(yè)所有者也必須至少設置目標平均利用率???（這與配置公共云中的水平自動縮放的方式類似）缕陕。在我們的基礎架構(gòu)中粱锐，水平自動縮放主要用于大型作業(yè)。他們的所有者通常喜歡調(diào)整自動縮放器以優(yōu)化特定于作業(yè)的性能指標扛邑，例如95％的延遲（直接通過指定目標大辛场；或通過實驗性地改變目標平均利用率并觀察對指標的影響來間接地）蔬崩。

然后對原始建議????[??]進行后處理恶座，以生成穩(wěn)定的建議????[??]搀暑，該建議旨在減少任務數(shù)量的突然變化。 Autopilot為工作負責人提供以下平滑策略選擇（對平均工作具有合理的默認值）：

遞減的縮減會從????最近的建議中返回最大建議：????[??] =max??-????奥裸，??{????[??]}险掀。因此，縮小是推遲到用戶指定的時間湾宙，而放大是立即進行的樟氢。我們的大多數(shù)工作都使用????：大約40％的員工使用2天； 35％的人使用3天侠鳄。

緩慢衰減可避免同時終止太多任務埠啃。如果當前任務number [??]的數(shù)量超過穩(wěn)定的建議????[??]，則某些任務將每5分鐘終止一次伟恶。選擇一次終止的任務數(shù)以在給定時間內(nèi)將任務數(shù)減少一半（98％的作業(yè)使用默認的一小時）盼铁。

延遲較小的更改在某種程度上與緩慢衰減相反：當建議與當前任務數(shù)之間的差異較小時灌灾，它忽略更改。

限制增長使工作所有者可以對正在初始化的任務（即尚未響應運行狀況檢查）的部分指定限制，從而限制任務的添加速度缘揪。

4 推薦系統(tǒng)質(zhì)量

本部分使用來自我們生產(chǎn)工作負載的樣本荒吏，探討了Autopilot在Google上的有效性号杠。 我們在這里集中討論RAM的垂直擴展称簿，因為OOM具有直接可測量的影響。 關(guān)于CPU擴展影響的概述即寒，請參見[31]橡淆。

4.1方法論

我們的結(jié)果基于監(jiān)視系統(tǒng)的觀察結(jié)果，該監(jiān)視系統(tǒng)使用我們的基礎結(jié)構(gòu)監(jiān)視所有作業(yè)母赵。大規(guī)模的運營為我們提供了對Autopilot實際收益的良好統(tǒng)計估計逸爵，但是任何純粹的觀察性研究的不利之處在于，它無法控制工作獲得的收益（Autopilot或手動設置的限值）凹嘲，因此我們需要盡可能彌補這一點师倔。

觀察性研究的另一種選擇是A / B實驗，在該實驗中周蹭，我們會將Autopilot應用于隨機抽樣的一組工作樣本中趋艘。盡管我們對小組工作進行了A / B研究，但遷移高優(yōu)先級谷醉，大型生產(chǎn)工作需要得到工作所有者的明確同意，因此在統(tǒng)計學上意義重大冈闭。

另一個選擇是使用記錄的跟蹤進行模擬研究俱尼，但是它們有其自身的偏差，并且我們沒有可靠的方法來預測實際作業(yè)將如何響應諸如CPU限制之類的模擬事件（例如萎攒，最終用戶觀察延遲增加可能會斷開連接遇八，降低CPU使用率矛绘，或者重新發(fā)出查詢，從而增加CPU使用率）或OOM事件（例如刃永，如果問題是暫時性的過載货矮，則任務可能會重新啟動并成功執(zhí)行，或者如果是由問題引起的斯够，則再次出錯內(nèi)存泄漏）囚玫。

為了減輕可觀察性研究的問題，我們使用從幾個不同工作人群中抽樣的結(jié)果读规。

第一個群體是在我們的作業(yè)集合中隨機選擇的20000個工作的（有偏見）樣本抓督。我們從以下四個類別中分別采樣了5000個作業(yè)：具有使用硬RAM限制的手動設置的限制的作業(yè)；具有使用軟RAM限制的手動設置的限制的作業(yè)束亏；使用Autopilot移動窗口推薦器的作業(yè)铃在；以及使用Autopilot ML推薦器的作業(yè)。只要我們控制了一些潛在問題碍遍，這些群體就可以為我們提供所有服務集對Autopilot效果的衡量指標：

• 大多數(shù)具有手動設置的RAM限制的作業(yè)都使用硬限制定铜，而Autopilot將其所有作業(yè)切換到軟RAM限制。 此開關(guān)本身可能會減少OOM的數(shù)量怕敬。 我們通過對相同數(shù)量的具有硬RAM和軟RAM限制的作業(yè)進行采樣來緩解此問題揣炕。

• 作業(yè)可能被迫使用手動限制，因為Autopilot無法正確設置其限制赖捌。 我們通過使用第二個群體來解決此問題祝沸，該群體包括在特定日歷月開始使用Autopilot的500個工作樣本。 我們報告了更改前后兩個日歷月的性能越庇，以減輕二進制文件或負載特性可能已更改的風險罩锐。 因為我們只能抽樣成功遷移的工作，所以即使這個群體也可能有偏見卤唉，但是我們的成功率很高涩惑，因此我們認為這不是一個重大問題。

4.1.1 指標

我們報告的績效指標基于整個日歷日（在5分鐘的匯總窗口內(nèi)（我們的監(jiān)控系統(tǒng)的默認設置）桑驱，在日歷天內(nèi)（與我們對資源分配的收費方式保持一致）所取的樣本）竭恬，并且通常使用95％百分位數(shù)來實現(xiàn) 利用率和OOM率之間的適當平衡。 指標如下：

在一個日歷日內(nèi)熬的，一項工作的足跡是任務平均限制的總和（每個任務均以當日的運行時間加權(quán)）痊硕。占用空間直接與作業(yè)的基礎結(jié)構(gòu)成本相對應：任務一旦請求資源，其他高優(yōu)先級任務便無法回收它們押框。占地面積以字節(jié)表示岔绸；但是，我們通過將原始值（以字節(jié)為單位）除以一臺（大型）計算機所擁有的內(nèi)存量來對其進行歸一化。因此盒揉，如果一個作業(yè)占用10臺計算機晋被，則意味著為其分配的RAM數(shù)量等于10臺計算機的內(nèi)存（這并不意味著它在專門用于此作業(yè)的10臺計算機上分配）。

在一個日歷日內(nèi)刚盈，某項工作的相對空閑時間是（限制減去使用量）除以限制-即請求資源中未使用的部分羡洛。在這里，使用量是一個日歷日報告的所有任務所有5分鐘平均使用量值的95％藕漱，而限制是該24小時內(nèi)的平均限制欲侮。

日歷日內(nèi)工作的絕對空閑時間（以字節(jié)為單位）直接衡量浪費：這是一項工作的所有任務的極限秒數(shù)減去使用秒數(shù)的總和，除以24×3600（一天）谴分。這種聚集將更多的重點放在更大锈麸，成本更高的工作上。此處牺蹄，limit-seconds是使用5分鐘的平均值在任務的運行時間內(nèi)所請求的內(nèi)存限制的整數(shù)忘伞。我們在對占用空間進行歸一化的同時對絕對松弛進行歸一化，因此沙兰，如果算法的總絕對松弛為50氓奈，則我們浪費的RAM數(shù)量等于50臺計算機的數(shù)量。實現(xiàn)絕對值的較小值是一個雄心勃勃的目標：它要求所有任務的限制幾乎始終與使用相同鼎天。

相對OOM率是一天中某項工作經(jīng)歷的內(nèi)存不足（OOM）事件數(shù)舀奶，除以該天該工作具有的平均運行任務數(shù)。它直接關(guān)系到我們的用戶需要多少工作量才能容忍Autopilot對工作造成的額外不可靠性斋射。由于OOM很少育勺，因此我們還跟蹤根本沒有OOM的工作日數(shù)。

針對工作日報告指標（即罗岖，每個工作將在一個日歷月中報告30或31個這樣的值）涧至，并在所有報告日中為所有工作計算統(tǒng)計數(shù)據(jù)（例如，相對相對松弛中位數(shù)）桑包。 當自動嘗試嘗試增加作業(yè)的限制時（例如南蓬，任務變得大于可用的配額，用戶指定的邊界甚至一臺機器的大醒屏恕）赘方，自動駕駛儀可能會達到擴展限制。 我們并未篩選出此類OOM弱左，因為目前尚不清楚該工作的未來行為窄陡，并且此類事件的影響應獨立于所使用的算法。

4.1.2作業(yè)采樣和過濾

我們顯示了單個日歷月（或4個月拆火，以分析遷移的工作）在基礎架構(gòu)上執(zhí)行的工作樣本的性能跳夭。 盡管我們的基礎架構(gòu)可以運行許多類型的作業(yè)鳖悠，但其規(guī)模是由高優(yōu)先級的服務性作業(yè)驅(qū)動的，因為可以保證此類作業(yè)獲得其聲明為極限的資源优妙。 因此，更嚴格的限制直接轉(zhuǎn)化為更大的容量和未來基礎架構(gòu)擴展速度的降低憎账。 因此套硼，我們的分析重點是這些工作。

除非另有說明胞皱，否則我們僅考慮長期運行的工作（至少在整個日歷月內(nèi)提供服務的工作）邪意，因為這些工作對我們的基礎架構(gòu)影響最大[26]。 我們還將使用特殊反砌，不尋常的SLO和使用自定義推薦程序的作業(yè)篩選出一些作業(yè)類別雾鬼，以使討論重點放在默認算法的質(zhì)量上。

4.2 減少預估與真實用量差值

與非Autopilot作業(yè)相比宴树，Autopilot作業(yè)的松弛度要低得多策菜。圖3a顯示了每個工作日的空閑時間的累積分布函數(shù)（CDF）。非Autopilot作業(yè)的平均相對松弛度為60％（硬性限制）至46％（軟性限制）酒贬；而Autopilot作業(yè)的平均相對松弛度為31％（移動窗口）至23％（ML）又憨。

非Autopilot的工作浪費了大量的能力。圖3b顯示了樣本中作業(yè)絕對松弛的累積分布函數(shù)锭吨。我們的10,000個非Autopilot工作樣本的總絕對松弛總和（按月平均）等于12,000多臺機器蠢莺；而Autopilot作業(yè)樣本的絕對松弛量少于500臺計算機。差異相當于數(shù)千萬美元的機器成本零如。

但是躏将，這些比較可能會有偏差，因為在構(gòu)建這些樣本時考蕾，我們控制了每個類別的作業(yè)數(shù)量祸憋，而不是資源的總量：如果所有Autopilot作業(yè)的使用率較低，而所有非Autopilot作業(yè)的使用率較高辕翰，則可能不管每個組的限制質(zhì)量如何夺衍，最終都可以節(jié)省類似的絕對松弛量（但是，相對松弛度比較仍然有效）喜命。為了解決這個問題沟沙，我們在圖3c中顯示了作業(yè)足跡的CDF。該圖確認了與非Autopilot作業(yè)相比壁榕，Autopilot作業(yè)的占地面積確實較小矛紫。但是，正如我們在分析遷移到Autopilot的作業(yè)時所看到的那樣牌里，這種較小的占用空間至少部分是Autopilot減少作業(yè)限制的結(jié)果颊咬。此外务甥，默認情況下，小型作業(yè)使用Autopilot（第5節(jié)）喳篇。

最后敞临，我們分析了最近開始使用Autopilot的工作減少的情況（圖4）。在遷移之前麸澜，幾乎所有作業(yè)都使用了硬盤限制挺尿。遷移之后，幾乎所有人都使用ML推薦器炊邦。我們的圖表顯示了超過4個月的工作壽命的結(jié)果编矾。所有作業(yè)在同一日歷月開始使用Autopilot，表示為第0個月（m0）馁害。我們顯示了前兩個月中這些作業(yè)的效果窄俏，當作業(yè)使用手動限制時分別表示為m-1和m-2。以及遷移后兩個月內(nèi)的性能碘菜，當作業(yè)使用Autopilot設置的限制時表示為m + 1和m + 2凹蜈。

圖4a顯示了每個工作日相對松弛的CDF。遷移前一個月的平均相對松弛度為75％忍啸，中位數(shù)為84％踪区。遷移后的一個月，平均相對松弛度下降到20％吊骤，中位數(shù)下降到17％缎岗。遷移后的兩個月內(nèi)，松弛值的分布保持一致白粉，這表明收益是持久的传泊。

絕對的空閑時間（圖4b）表明可以節(jié)省大量資金：在遷移之前，這些作業(yè)浪費了相當于1870臺計算機的RAM容量鸭巴；遷移后眷细，這些作業(yè)僅浪費了162臺計算機：通過遷移這些作業(yè)，我們節(jié)省了1708臺計算機的容量鹃祖。

遷移后的工作足跡的CDF（圖4c）表明溪椎，工作足跡隨著時間的推移而增加，表明流量的有機增長恬口。遷移前兩個月的工作總規(guī)模小于遷移前一個月校读；同樣，遷移后一個月的總足跡要小于遷移后兩個月的足跡祖能。 m0的遷移逆轉(zhuǎn)了這一趨勢：盡管足跡逐月有機增長歉秫，但m + 1的足跡明顯小于m-1的足跡。遷移后养铸，足跡的增長速度也降低了雁芙，因為m + 2的CDF比m-2的CDF接近m-1轧膘。

500個已遷移工作的足跡分布（圖4c）與我們整個機隊采樣的2萬個工作的足跡分布（圖3c）不同：遷移的工作所占足跡比整個船隊要大。這是因為許多小型作業(yè)會Autopilot到m0之前兔甘，而m0是我們選擇作為該樣本參考月份的月份（有關(guān)詳細信息谎碍，請參見第5節(jié)）。

4.3可靠性

上一節(jié)演示了Autopilot可以大大減少浪費的容量洞焙。 但是椿浓，將這些限制設置為0的瑣碎算法將通過這些指標獲得更好的結(jié)果–以頻繁的OOM為代價！ 在本節(jié)中闽晦，我們展示了Autopilot作業(yè)比非Autopilot作業(yè)具有更高的可靠性。

圖三

圖四

圖五

圖六

圖5顯示了按工作日劃分的相對OOM的累積分布函數(shù)（CDF）提岔。 OOM很罕見：超過99.5％的Autopilot工作日沒有OOM仙蛉。 雖然ML推薦器產(chǎn)生的無OOM的工作日數(shù)比移動窗口推薦器要多一些，但它也導致相對的OOM數(shù)略多（每任務日0.013比0.002）碱蒙。 兩種算法顯然都占主導地位的手動限制設置荠瘪。 由于存在硬RAM限制，因此約98.7％的工作日不使用OOM赛惩。 相對OOM率為0.069 /任務日哀墓。 軟RAM限制作業(yè)的相對OOM比率較好，為0.019喷兼，但無OOM的工作日略少（97.5％）篮绰。

OOM的數(shù)量自然取決于相對的松弛度-較高的松弛度意味著更多的可用內(nèi)存，因此一項任務應該很少出現(xiàn)OOM季惯。圖6中的線斜率表示OOM速率與松弛的相關(guān)程度吠各，而截距則反映了OOM的總數(shù)。具有軟限制的非Autopilot作業(yè)的回歸線低于具有硬限制的非Autopilot作業(yè)的回歸線勉抓；在使用移動窗口算法的Autopilot作業(yè)和使用軟限制的非Autopilot作業(yè)之間也有類似的嚴格控制贾漏。但是，ML算法的回歸與使用手動指定的軟限制的作業(yè)線和使用移動窗口自Autopilot方案的作業(yè)線相交藕筋，建議對于松弛率低的作業(yè)使用更多的OOM纵散，而對于松弛度較高的作業(yè)則使用更少的OOM。

表2.按算法隐圾，受OOM嚴重影響的工作日數(shù)伍掀。每行對應一個不同的閾值，用于將工作日歸為受OOM嚴重影響的類別：例如暇藏，在第一行中硕盹，如果工作任務的5或1/7（以較高者為準）會嚴重影響工作日以OOM終止。 “硬”和“軟”都有手動限制設置叨咖。

表2

由于ML推薦器比滑動窗口推薦器產(chǎn)生的平均相對OOM比率更高瘩例，因此ML推薦器可能會過于積極地降低作業(yè)限制啊胶。但是，ML推薦器旨在偶爾對不會受到太大影響的工作進行OOM垛贤。正如我們在第2節(jié)中所解釋的焰坪，我們的工作旨在吸收偶發(fā)的故障-只要有足夠多的尚在執(zhí)行的任務能夠吸收已終止任務一旦處理的流量即可。這按預期工作聘惦，并且好處是可以節(jié)省更多資源某饰。但是，可能還是有理由擔心推薦者過于激進善绎。

為了探討這種擔憂黔漂，我們將一個工作日歸類為當OOM在一天中經(jīng)歷的OOM數(shù)量大于其閾值數(shù)量（例如4）或分數(shù)（例如1/7）中較大者時受到OOM的嚴重影響。表2顯示了在某些閾值設置（從更寬松（最高）到更保守（最低））中禀酱，受OOM嚴重影響的工作日數(shù)炬守。盡管絕對數(shù)略有變化，但是方法的相對順序保持不變剂跟。

在非Autopilot作業(yè)中减途，我們驚奇地發(fā)現(xiàn)具有硬RAM限制的作業(yè)雖然具有相對較高的OOM（如上所述），但受OOM的影響較小曹洽。我們假設用戶可能會手動為具有不穩(wěn)定的內(nèi)存使用模式的作業(yè)手動指定軟限制鳍置，這特別難以設置。正如預期的那樣送淆，在Autopilot作業(yè)中税产，盡管使用移動窗口算法的作業(yè)的相對OOM較少，但是與使用ML算法的作業(yè)相比偷崩，它們更可能受到OOM的嚴重影響砖第。

我們還更詳細地研究了OOM如何集中于各個工作。如果大多數(shù)OOM僅發(fā)生在少數(shù)幾個工作中环凿，則可能表明自動縮放算法存在系統(tǒng)性問題-我們寧愿許多工作很少遇到OOM梧兼。我們分析了當月至少有一個OOM的作業(yè)。對于每項這樣的工作智听，我們用至少一個OOM來計算天數(shù)（我們計算OOM天數(shù)羽杰，而不是簡單地計算OOM或相對OOM，而是著眼于可重復性到推，而不是我們上面測量的幅度）考赛。對于Autopilot ML，此類作業(yè)中有46％僅一次進行OOM莉测； 4天或更短時間內(nèi)完成80％的工作OOM颜骤。相比之下，在Autopilot移動窗口推薦器中捣卤，只有28％的工作完全是OOM一次忍抽； 21天或更短時間內(nèi)完成80％的工作OOM八孝。

在我們的第二個樣本群體中（遷移到Autopilot的工作），OOM的數(shù)量太少鸠项，無法對相對OOM和嚴重OOM進行有意義的估計干跛。在遷移前的一個月中，總共有348個工作日祟绊，其中至少有一個OOM楼入；遷移后，這個數(shù)字減少到只有48牧抽。這些工作的遷移成功嘉熊。

圖七

4.4限制變更次數(shù)

手動控制的工作很少會改變其限制：在我們的10,000個手動限制的工作樣本中，我們觀察到一個月內(nèi)有334次變化扬舒，或者每個工作日大約0.001次變化阐肤。 圖7顯示了Autopilot更改10,000個工作樣本限制的頻率：每個用戶的頻率比用戶高出幾百倍。 但是呼巴，它仍然相當穩(wěn)定：在大約70％的工作日中，沒有任何變化御蒲。 而99％ile的工作日一天內(nèi)只有6（移動窗口）到7（ML）的限制變化衣赶。 考慮到即使被逐出，找到任務的新位置通常只需要幾十秒鐘厚满，那么為節(jié)省大量資金似乎是一個合理的價格府瞄。

有人可能會爭辯說，上一節(jié)中報告的OOM（和嚴重的OOM）的減少僅僅是由于比操作員更頻繁地更改限制而引起的碘箍。 在圖7中遵馆，AutopilotML和移動窗口具有相似數(shù)量的極限變化。 但是丰榴，如表2所示货邓，Autopilot ML更有效地利用了這一中斷預算。

4.5及時行為

在前面的部分中四濒，我們專注于長期運行的工作：我們的工作至少連續(xù)工作一個月换况。在本部分中，我們將根據(jù)工作年齡來分析Autopilot的性能盗蟆。圖8a顯示了每個不同年齡段的1000個工作的相對松弛的CDF戈二。

運行少于一天的作業(yè)的松弛度要比運行時間更長的作業(yè)高得多：這是Autopilot針對長期運行的作業(yè)進行調(diào)整的直接結(jié)果–歷史記錄越多，松弛度越低喳资。但是即使在14天之后觉吭，松弛度仍高于上一部分中分析的穩(wěn)態(tài)。

對相對OOM速率的分析（圖8b）表明仆邓，Autopilot對于短期工作非常謹慎鲜滩。對于持續(xù)時間少于24小時的作業(yè)伴鳖，幾乎沒有OOM：但是，如果我們過濾掉短期作業(yè)（總?cè)蝿粘掷m(xù)時間少于1.5小時的作業(yè)）绒北，則OOM會比穩(wěn)定狀態(tài)更多黎侈。一旦我們考慮了7天或更早之前開始的工作，相對OOM比率就可以與穩(wěn)態(tài)行為相提并論闷游。

圖八

5 贏得用戶的信任：增加采用率的關(guān)鍵

我們的基礎架構(gòu)為成千上萬具有不同角色峻汉，經(jīng)驗和期望的內(nèi)部用戶提供服務。 較小或較新的服務通常由最初創(chuàng)建它們的軟件工程師在生產(chǎn)中運行脐往，而較大的休吠，已建立的服務則具有專門的開發(fā)人員/操作團隊。 為了增加Autopilot的采用率业簿，我們不僅必須確保算法的質(zhì)量可以接受瘤礁，還必須確定并滿足工程師對基礎架構(gòu)的需求。 本節(jié)討論這些定性方面梅尤。 我們的經(jīng)驗鞏固了[5]中描述的許多課程

5.1評估過程

我們與Autopilot一起開發(fā)了評估潛在推薦者的流程柜思。推薦人首先在脫機模擬中使用代表作業(yè)樣本的資源使用情況進行評估。盡管這樣的評估還遠遠沒有完成（我們將在4.1節(jié)中詳細說明問題）巷燥，但足以確定是否值得在推薦者身上投入更多的精力赡盘。如果是這樣，我們將繼續(xù)使用空運行缰揪，其中推薦程序與其他推薦程序一起作為生產(chǎn)Autopilot服務的一部分運行–已記錄其建議陨享，但未執(zhí)行。在兩個階段中钝腺，我們分析通常的統(tǒng)計匯總抛姑，例如均值和高百分位數(shù)，但也要特別注意離群值-推薦者在其中表現(xiàn)特別差的工作艳狐。這些異常值有助于捕獲實現(xiàn)中的錯誤以及算法的意想不到的后果定硝。

之后，我們執(zhí)行A / B測試毫目，其中新推薦程序為選定集群中的一小部分用戶提高生產(chǎn)限制喷斋。即使在此階段完全失敗的算法也不大可能造成災難性的災難：如果一個群集中的一項作業(yè)失敗，該服務的負載均衡器會將其流量切換到其他群集蒜茴，這些群集應具有足夠的能力來應對浪涌星爪。

最后，當新推薦人在A / B測試中獲得好評時粉私，我們逐漸將其推薦為整個車隊的新標準顽腾。為了降低可能發(fā)生故障的風險，分批進行分批部署，它們之間有多個小時的間隔抄肖，如果發(fā)現(xiàn)異常久信，則可以回滾。

5.2作業(yè)所有者可以輕松訪問Autopilot限制

我們用于資源監(jiān)視的標準儀表板（圖9）顯示了作業(yè)CPU和內(nèi)存使用情況的分布以及Autopilot計算的限制-即使對于未Autopilot的作業(yè)（對于這些作業(yè)漓摩，Autopilot在模擬模式下運行）裙士。 儀表板可幫助用戶了解Autopilot的操作，并建立對Autopilot在Autopilot上啟用的功能的信任：用戶可以看到Autopilot將如何響應每日和每周的周期管毙，新版本的二進制文件或突然變化的負載

5.3自動遷移

一旦我們對大型離線模擬研究和較小規(guī)模的A / B實驗對Autopilot的操作有了足夠的信任腿椎，就可以將其作為所有現(xiàn)有小型作業(yè)的默認設置（總計最多限制10臺機器），并且 所有新工作夭咬。 提前通知了用戶啃炸，他們可以選擇退出。 這種自動遷移幾乎沒有用戶反沖卓舵，從而大大提高了采用率南用。

圖九

(a)Autopilot作業(yè)的痕跡。 8:00之后掏湾，一些任務開始顯示出更高的內(nèi)存使用量裹虫； Autopilot迅速提高了工作限制。

(b)使用手動指定的限制以及在模擬模式下運行的Autopilot來跟蹤作業(yè)融击。 新推出的產(chǎn)品存在內(nèi)存泄漏筑公，導致內(nèi)存使用量穩(wěn)定增加。 在工作開始到OOM時砚嘴，工作的監(jiān)視系統(tǒng)在17:30左右開始尋呼呼叫十酣。

直到19:30涩拙，值班開發(fā)人員才設法提高工作的內(nèi)存限制（18:20到19:00之間的限制振蕩是來自監(jiān)視系統(tǒng)的時間序列數(shù)據(jù)未對齊的產(chǎn)物）

际长。 如果該作業(yè)是自動執(zhí)行的，則可能不會進行OOM設置兴泥，因為自動增加的限制將使dev / ops有更多時間發(fā)現(xiàn)內(nèi)存泄漏并回滾到二進制的先前版本工育。

5.4用自定義推薦器覆蓋推薦器

Autopilot的算法依靠歷史CPU /內(nèi)存使用情況來設置將來的限制或任務計數(shù)。但是搓彻，對于某些作業(yè)，其他信號可以更好地預測極限：例如，我們的文件系統(tǒng)服務器的負載幾乎線性地取決于服務器控制的文件的總大小现喳。此外吟税，一些長期運行的服務在Autopilot之前已經(jīng)開發(fā)了自己的水平自動縮放器，其中一些包含經(jīng)過細化的稀轨，經(jīng)過微調(diào)的邏輯扼脐，這些邏輯已經(jīng)經(jīng)過了多年的完善（盡管它們通常僅具有Autopilot的一部分功能，而它們并沒有始終跟上Borg的變化）。 Autopilot的自定義推薦程序使用戶可以保留此類算法的關(guān)鍵部分（計算任務數(shù)量或單個任務資源限制）瓦侮，同時將支持功能（如致動）委派給Autopilot生態(tài)系統(tǒng)艰赞。

定制推薦器很受歡迎：在提供三個月后，定制推薦器管理著我們?nèi)繖C隊資源的13％肚吏。

6 減少工程量

Google遵循減少勞動量的dev / ops原則：繁瑣方妖，重復的工作應該由機器而不是工程師來完成，因此我們在自動化上進行了投資罚攀。Autopilot就是一個例子党觅。

隨著工作量的增加，需要增加工作的限制坞生。受歡迎的服務仔役，即使不包括最初的快速增長階段，也可能應該每兩周或每月調(diào)整一次是己。而且每次推出新的二進制版本都可能需要調(diào)整限制又兵。假設這些是手動完成的。我們假設手動調(diào)整大小平均需要30分鐘的工作：更改配置文件卒废，將更改提交到版本控制系統(tǒng)沛厨，查看建議的更改，初始化發(fā)布并監(jiān)視其結(jié)果摔认。對于我們的1萬個具有手動限制的工作的樣本逆皮，甚至334個手動限制的調(diào)整也代表了大約一個人月的工作量，并且這大大少于預期的更新次數(shù)参袱。

Autopilot的水平縮放-向正在運行的作業(yè)中添加任務-自動處理自然的負載增長电谣。Autopilot的垂直縮放可以處理每個任務的負載變化，也可以處理推出新二進制文件帶來的影響抹蚀。兩者都代表著顯著的人工減少剿牺。

我們詢問了幾位大型工作的老板，這些老板遷移到了Autopilot环壤，以估計他們所經(jīng)歷的辛苦工作減少了晒来。一項大型服務（由多個作業(yè)組成）報告，在遷移到Autopilot之前郑现，他們每月執(zhí)行大約8次手動調(diào)整大小湃崩。

另一項服務估計，Autopilot每月可以為他們節(jié)省2個小時的人工調(diào)整之前的人工工作接箫。另一個服務的負載在群集之間和時間上變化很大攒读，每月需要大約12次手動調(diào)整大小。另一個好處是減少了必須由待命的dev / ops工程師處理的中斷（頁面）辛友。隨著可靠性的提高薄扁，任務失敗的頻率降低，報告系統(tǒng)發(fā)出的警報也更少。對于集群中負載差異很大的作業(yè)泌辫，這種減少尤為明顯：設置不同的手動限制的工作是經(jīng)常出現(xiàn)的問題根源随夸，甚至使監(jiān)視變得復雜。一項服務報告說震放，遷移后宾毒，Autopilot增加了某些群集中的內(nèi)存限制，這導致OOM的數(shù)量從每天大約2000個減少到可以忽略的數(shù)量殿遂。遷移后的將近一年中诈铛，另一個服務沒有報告OOM。通話頁面的數(shù)量從每周3個減少到少于1個（其余頁面用于無關(guān)的問題）墨礁。

Autopilot的資源限制越來越嚴格幢竹，可能會暴露出一些漏洞，而這些漏洞卻由于較大的限制而未被發(fā)現(xiàn)恩静。眾所周知焕毫，罕見的內(nèi)存泄漏或越界訪問是很難找到的。盡管Autopilot儀在大多數(shù)情況下都能很好地工作驶乾，但它可能仍需要針對一些工作進行自定義配置邑飒。因此，當作業(yè)遷移到Autopilot然后頻繁開始進行OOM時级乐，可能很難區(qū)分Autopilot配置錯誤和真正的錯誤疙咸。一個小組將這種問題歸咎于Autopilot的內(nèi)存限制設置算法，并在幾周后才發(fā)現(xiàn)根本原因：很少觸發(fā)的越界內(nèi)存寫操作风科。

最后撒轮，批處理作業(yè)會大量使用Autopilot（CPU啟用了88％的此類作業(yè)）。我們推測這是因為Autopilot使用戶甚至不必為此類工作指定限制

7 相關(guān)工作

盡管Autopilot執(zhí)行贼穆，UX和某些自定義特定于Borg题山，但Autopilot解決的問題幾乎在云資源管理中普遍存在。

預期的副本數(shù)及其資源需求將由許多云資源管理系統(tǒng)中的用戶提供扮惦，因為調(diào)度程序使用它們將任務打包到機器上[14]臀蛛。 Borg [34]亲桦，Omega [29]和Kubernetes [3]都要求用戶在提交作業(yè)（Borg崖蜜，Omega）或吊艙（Kubernetes）時設置此類限制。 YARN [32]要求應用程序（作業(yè)）聲明容器（任務）的數(shù)量以及每個容器的CPU和RAM資源需求客峭。在有些不同的情況下豫领，用于HPC系統(tǒng)的調(diào)度程序（例如Slurm [37]）需要每個批處理作業(yè)來指定計算機的數(shù)量。

其他研究證實舔琅，當手動設置作業(yè)限制時等恐，我們在基礎架構(gòu)中觀察到的私有云利用率較低。 [30]分析了阿里巴巴的一萬臺機器的YARN集群的5天使用情況，并報告說80％的時間中RAM利用率低于55％课蔬。 [23]分析了一個短時間（12小時）的阿里巴巴跟蹤囱稽，表明對于幾乎所有實例（任務），峰值內(nèi)存利用率為80％或更少二跋。 [26]分析了30天的Google集群跟蹤[27]战惊，結(jié)果表明，盡管平均請求內(nèi)存幾乎等于總可用內(nèi)存扎即，但實際使用量（超過一小時窗口的平均值）低于50％吞获。

設置更精確的限制的一種替代方法是超額訂閱資源，即有意分配給機器任務谚鄙，以使它們的要求總和高于本地可用的物理資源量各拷。 [30]顯示了一個系統(tǒng)過度訂閱YARN群集中的資源。盡管超額預訂可用于可以承受偶爾的速度下降的批處理工作負載闷营，但它可能導致服務工作負載的尾部等待時間顯著增加-這需要仔細的概率處理[2烤黍，21]。

水平和垂直自動縮放需要作業(yè)具有彈性傻盟。通常蚊荣，眾所周知，許多類別的應用程序都很難擴展莫杈。例如互例，JVM在其默認配置下不愿意釋放堆內(nèi)存。幸運的是筝闹，對于Autopilot而言媳叨，Google的絕大多數(shù)工作都是在考慮擴展的基礎上進行的。

自動縮放是一個發(fā)達的研究領(lǐng)域关顷。最近的調(diào)查包括[11糊秆，16，22]议双。大多數(shù)研究涉及水平自動縮放痘番。 [17]通過實驗分析了一些針對工作流的水平自動縮放算法的性能。 [10]建立了AWS和Azure中水平自動縮放器的概率性能模型平痰。 [24]測量了AWS汞舱，Azure和GCE中水平自動縮放器的性能。雖然Autopilot還具有反應式水平自動縮放器宗雇，但本文主要集中于垂直縮放（在[16]中也稱為調(diào)整大小或VM適應）昂芜。 Kubernetes垂直吊艙自動縮放器（VPA，[15]）使用移動窗口上的統(tǒng)計信息來設置容器的限制（例如赔蒲，對于RAM泌神，24小時內(nèi)的第99個百分點）良漱。 Kubernetes的方法直接受到我們移動窗口推薦器的啟發(fā)（第3.2.2節(jié)）。 [25]提出了一種估計器欢际，該估計器使用窗口中樣本的中值和標準差之和母市。

我們描述了兩個推薦器：一個基于從移動窗口計算出的統(tǒng)計信息，其中包含窗口參數(shù)（例如损趋，長度）由工作所有者設置（第3.2.2節(jié)）窒篱；另一個根據(jù)成本函數(shù)自動選擇移動窗口參數(shù)（第3.2.3節(jié)）。這些簡單的統(tǒng)計數(shù)據(jù)的替代方法是使用更高級的時間序列預測方法舶沿，例如自回歸移動平均（ARMA）（如[28]中也使用工作績效模型）墙杯，神經(jīng)網(wǎng)絡（如[18]中）， [9括荡，20]中的遞歸神經(jīng)網(wǎng)絡或[13]中的自定義預測表明基于馬爾可夫鏈的預測比基于自回歸或自相關(guān)的方法表現(xiàn)更好高镐。我們使用此類方法進行的初步實驗表明，在絕大多數(shù)博格案例中畸冲，不需要ARMA的其他復雜性：作業(yè)傾向于使用較長的窗口（例如嫉髓，移動窗口推薦器中內(nèi)存的默認半衰期為48小時，第3.2.2節(jié)）邑闲；并且日間趨勢足夠小算行，以至于一個簡單的移動窗口能夠迅速做出反應。對于可以由用戶配置的推薦器苫耸，我們相信參數(shù)具有簡單的語義并且可以可預測地調(diào)整推薦器更為重要州邢。

Autopilot不建立工作績效模型：它不會嘗試優(yōu)化批處理工作的完成時間或服務于工作的最終用戶響應延遲。我們發(fā)現(xiàn)褪子，控制限制使工作所有者可以推理工作績效（和性能問題）量淌，并在工作與基礎架構(gòu)之間進行區(qū)分。關(guān)注點的分離部分取決于群集和節(jié)點級調(diào)度程序嫌褪。例如呀枢，Autopilot不需要考慮所謂的嘈雜鄰居的性能問題，因為Borg通過特殊機制對其進行處理[38]笼痛。為了涵蓋其余的一些特殊情況裙秋，Autopilot提供了水平縮放掛鉤，以允許團隊使用自定義指標甚至自定義推薦程序缨伊。相比之下摘刑，許多研究旨在直接優(yōu)化工作的績效指標，而不僅僅是分配的資源量倘核。例如泣侮，在Quasar [7]中即彪，用戶指定性能限制紧唱，而不是限制活尊，而調(diào)度程序負責滿足這些限制。在公共云中漏益，在其中將作業(yè)嚴格分配給VM蛹锰，Paris [36]建議在具有代表性任務及其性能指標的情況下配置VM。 D2C [12]是一種水平自動縮放器绰疤，它通過學習每一層的性能參數(shù)（使用排隊論建模）來縮放多層應用程序每一層中的副本數(shù)量铜犬。學習過程是在線的–不必預先對應用程序進行基準測試。

如果作業(yè)類別更窄轻庆，則可以進行更具體的優(yōu)化癣猾。 Ernest [33]專注于批處理，機器學習工作余爆，而CherryPick [1]也考慮分析工作纷宇。盡管本文著重于服務工作，但Google的88％批處理工作也使用了Autopilot（以CPU消耗量衡量）蛾方。 [19]使用強化學習（RL）來驅(qū)動服務工作的水平擴展（具有效用函數(shù)像捶，考慮了副本的數(shù)量，吞吐量和任何違反SLO的響應時間）桩砰。 Autopilot的ML推薦器借鑒了RL的一些想法拓春，例如根據(jù)模型的歷史表現(xiàn)選擇模型和極限值。

8 結(jié)論

彈性伸縮對于云來說效率亚隅、可靠性硼莽、運維工作量至關(guān)重要。手動設置的限制不僅浪費資源（平均配置限制太高）煮纵，而且隨著負載增加或新版本的服務推出時沉删，會導致頻繁違反限制。

自動擴縮對于云來說效率醉途、可靠性矾瑰、運維工作量至關(guān)重要。手動設置的限制不僅浪費資源（平均配置限制太高）隘擎，而且隨著負載增加或新版本的服務推出時殴穴，會導致頻繁違反限制。Autopilot是Google使用的垂直和水平自動縮放工具货葬。通過自動提高限制設置的精度采幌，它減少了資源浪費并提高了可靠性：內(nèi)存不足錯誤不那么常見，不那么嚴重震桶，并且減少任務間項目影響休傍。使用簡單的時間加權(quán)滑動窗口算法可以實現(xiàn)其中一些增益，但是切換到受強化學習啟發(fā)的更復雜的算法可以實現(xiàn)更大的增益蹲姐。

現(xiàn)在磨取，Autopiloted工作占我們整個集群使用量的48％以上人柿。 實現(xiàn)如此高的采用率需要采取重大的發(fā)展和建立信任的措施，即使在可靠性和效率上都有明顯的提高忙厌。 但是凫岖，我們證明了這種額外的工作已獲得回報，因為用戶不再需要手動調(diào)整其工作大小逢净，而提高的可靠性導致更少的通話警報哥放。 我們向其他大型計算集群的用戶強烈推薦這種方法。