概述
1. 背景
隨著業(yè)務(wù)形態(tài)發(fā)展,更多的生產(chǎn)力集中到業(yè)務(wù)創(chuàng)新,這背后要求研發(fā)能力的不斷升級(jí)。阿里文娛持續(xù)傾向用更加高效、穩(wěn)定、低成本的方式支持快速軟件交付,保障高可用。于是運(yùn)維力從 “HaaS”(Handwork as a Service)到“PaaS”再到“SaaS”(System as a Service),運(yùn)維生產(chǎn)力從 Ops 到 DevOps 再到 NoOps。
在傳統(tǒng)應(yīng)用容量管理模式下,應(yīng)用、集群容量評(píng)估缺乏有效數(shù)據(jù)依據(jù)與支撐,往往犧牲效率或成本來平衡經(jīng)驗(yàn)決策風(fēng)險(xiǎn),另一方面,人肉決策和執(zhí)行難以滿足業(yè)務(wù)對(duì)穩(wěn)定性和效能的追求。因此,阿里文娛急需一個(gè)能夠把優(yōu)酷所有應(yīng)用的容量管理起來的能力。
2. 目標(biāo)
整體目標(biāo)分成 2 個(gè)階段,一是摸清各應(yīng)用容量水平,二是為所有應(yīng)用賦予彈性伸縮的能力, 最終直觀看到各應(yīng)用及總體資源使用率的明顯提升。
技術(shù)挑戰(zhàn)與解法
1. 單機(jī)性能
既然談到容量問題,已知的壓測(cè)方案有鏈路壓測(cè)方案、模擬流量壓測(cè)方案等。為什么還要 自研一套基于單機(jī)引流的壓測(cè)方案來評(píng)估應(yīng)用容量水平?
1)更接近日常真實(shí)水平;
2)無(wú)人工決策,純機(jī)器決策單機(jī)性能瓶頸;
3)全自動(dòng),比如配置成發(fā)布結(jié)束后進(jìn)行單機(jī)性能壓測(cè)。
2. 彈性
彈性指標(biāo)選擇:僅靠集群 CPU 水位彈性確實(shí)可以解決絕大多數(shù)類型應(yīng)用,但若基于集群QPS 水位則可更精準(zhǔn)的進(jìn)行彈性伸縮。
1)多維度彈性指標(biāo),同時(shí)也需要支持自定義指標(biāo);
2)多方位彈性方案,使用條件編排策略來達(dá)到多個(gè)彈性指標(biāo)之間的協(xié)同。
技術(shù)方案
1. 全自動(dòng)單機(jī)性能探索
與各接入層對(duì)接,自動(dòng)配置權(quán)重完成單機(jī)引流,配合性能拐點(diǎn)算法支撐,完成自動(dòng)識(shí)別性 能拐點(diǎn)并終止壓測(cè),最后一并記錄單機(jī)能力值。并允許每天定時(shí)壓測(cè)、發(fā)布結(jié)束壓測(cè)來感知每 天、或每次發(fā)布給單機(jī)性能帶來的變化,使用戶更親近自身應(yīng)用的容量水平。
2. 彈性伸縮
與底層交付系統(tǒng)聯(lián)動(dòng),打造從規(guī)劃,交付,計(jì)費(fèi),彈性水平擴(kuò)展、回收、資源排布調(diào)度全 生命態(tài)面向業(yè)務(wù)需求的自驅(qū)動(dòng)統(tǒng)籌調(diào)度資源管理系統(tǒng)。一方面,業(yè)務(wù)資源統(tǒng)一平臺(tái)構(gòu)建與維護(hù), 挖掘空閑資源,共享彈性計(jì)算力,整體提高部署密度,降低業(yè)務(wù)單位成本;另一方面,面向不 同應(yīng)用場(chǎng)景,自動(dòng)化容量管理,按需分配,保證應(yīng)用服務(wù)可用性,提高容量運(yùn)維效能。
3. 方案結(jié)合
全自動(dòng)單機(jī)性能探索與彈性伸縮的結(jié)合框架,如下圖:
1)應(yīng)用接入:無(wú)縫接入;
2)單機(jī)性能壓測(cè)自定義配置:無(wú)需再定義配置過多配置,默認(rèn)“智能探索”可以支持大部分 場(chǎng)景;
3)單機(jī)引流:從集群中其他機(jī)器的流量引流至被壓測(cè)機(jī)器;
4)智能拐點(diǎn)識(shí)別:使用時(shí)間序列數(shù)據(jù)趨勢(shì)轉(zhuǎn)折點(diǎn)提取算法,進(jìn)行拐點(diǎn)識(shí)別;
5)單機(jī)性能預(yù)測(cè):詳見技術(shù)細(xì)節(jié);
6)基礎(chǔ)彈性配置:詳見技術(shù)細(xì)節(jié)。
技術(shù)細(xì)節(jié)
1. 單機(jī)引流權(quán)重優(yōu)化
1)調(diào)整權(quán)重就是調(diào)整單機(jī)流量,且權(quán)重越高,單機(jī)流量越高;
2)增加自動(dòng)化調(diào)整權(quán)重策略方法。權(quán)重優(yōu)化:用于已經(jīng)識(shí)別出拐點(diǎn),保證下一次壓測(cè)接近 MAX 權(quán)重保持平緩;權(quán)重遞增:用于未觸發(fā)拐點(diǎn),保證下一次壓測(cè)能引更多的流量。
2. 響應(yīng)時(shí)間拐點(diǎn)識(shí)別
使用算法:箱線圖。基于 IQR 定制多組 k 的箱線圖上限的異常提取,上限=Q3+k*IQR 實(shí)現(xiàn)。而效果能夠定位到多數(shù)拐點(diǎn),并且一般拐點(diǎn)前的一個(gè)時(shí)間點(diǎn)的值為單機(jī)能力值。
3. 成功率拐點(diǎn)識(shí)別
0 錯(cuò)誤代表 100%成功率
成功率拐點(diǎn)識(shí)別相比響應(yīng)時(shí)間拐點(diǎn)識(shí)別更加嚴(yán)格。雖然同樣是“基于 IQR 定制多組 k 的箱 線圖”實(shí)現(xiàn),但此時(shí) k 必須收緊,因?yàn)槌晒β手笜?biāo)較為敏感,稍有波動(dòng)就應(yīng)該終止壓測(cè)。
4. 拐點(diǎn)提取參考了“時(shí)間序列數(shù)據(jù)趨勢(shì)轉(zhuǎn)折點(diǎn)提取算法”文章
比如在 3 個(gè)連續(xù)點(diǎn) Xi、Xi+1、Xi+2 的判定上,它們的發(fā)展趨勢(shì)共有 9 種情況:當(dāng) Xi+2-Xi>0, 即圖 a,b,e 這 3 種情況屬于總體趨勢(shì)上升,當(dāng) Xi+2-Xi<0,即圖 f,g,i 這 3 種情況屬于總體 趨勢(shì)下降,當(dāng) Xi+2-Xi=0,即圖 c,d,h 這 3 種情況屬于總體保持不變。
而我們通過“基于 IQR 定制多組 k 的箱線圖”可以識(shí)別出上升和下降 2 種拐點(diǎn),分別對(duì)應(yīng) 不同的場(chǎng)景,如響應(yīng)時(shí)間拐點(diǎn)識(shí)別(上升拐點(diǎn)識(shí)別),成功率拐點(diǎn)識(shí)別(下降拐點(diǎn)識(shí)別),而 k 的定義方式也參考近期數(shù)據(jù)。
比如某個(gè)應(yīng)用日常響應(yīng)時(shí)間穩(wěn)定在 100-200ms 和某個(gè)應(yīng)用日常響應(yīng)時(shí)間穩(wěn)定在 2-3ms 的 k值是不一樣的,不合適的 k 用在 2-3ms 的這種數(shù)據(jù)上會(huì)導(dǎo)致異常識(shí)別較為頻繁及不準(zhǔn)確。
5. 單機(jī)性能預(yù)測(cè)方案
單機(jī)性能與什么有關(guān),系統(tǒng)指標(biāo)?如果是 JAVA 應(yīng)用還和 JVM 相關(guān)指標(biāo)有關(guān)?而應(yīng)用本身 有會(huì)有各種池的限制,如 JVM 相關(guān)池、TOMCAT 相關(guān)池、DB 相關(guān)池、Redis 相關(guān)池、隊(duì)列相 關(guān)池等,這些都可以作為預(yù)測(cè)單機(jī)性能的特征。先基于 PCA 抽象出 N 個(gè)特征,也稱降維,可 將兩兩線性相關(guān)的因素進(jìn)行整合或排出,降維后建立線性回歸模型,而擬合度較高的模型將予 以采納并進(jìn)行預(yù)測(cè)。同時(shí)預(yù)測(cè)參數(shù)也需要實(shí)事求是,比如日常 CPU 區(qū)間為 2-60%,那預(yù)測(cè)參數(shù) 可以為 80%,此時(shí)若超過 100%那將毫無(wú)意義。
6. 流量驅(qū)動(dòng)彈性方案
基于 CPU 指標(biāo)的彈性伸縮:比如 CPU 超過 60%則執(zhí)行彈性擴(kuò)容,CPU 低于 20%則執(zhí)行彈 性縮容。擴(kuò)容與縮容允許按機(jī)器數(shù)比例進(jìn)行伸縮:如按 5%的機(jī)器數(shù)進(jìn)行彈性擴(kuò)容。定義彈性區(qū) 間:如 10-20,機(jī)器數(shù)會(huì)在 10-20 區(qū)間變動(dòng)。
一般低峰期會(huì)處在最低機(jī)器數(shù)區(qū)域,高峰則會(huì)處在最高機(jī)器數(shù)區(qū)域,基于外掛單機(jī)能力模 型。允許基于 QPS 水位指標(biāo)進(jìn)行彈性,可隨 QPS 增加而增加機(jī)器數(shù),反之則減少機(jī)器數(shù)。
總結(jié)
自動(dòng)化容量管理與彈性伸縮的深度結(jié)合解決了當(dāng)前容量預(yù)估的問題,使得資源能夠被合理使用。一方面,用戶專注業(yè)務(wù)層,做基于業(yè)務(wù)需求的容量規(guī)劃、交付和維護(hù),革命性改變生產(chǎn)關(guān)系,提高研發(fā)迭代效率;另一方面,更加細(xì)粒度的彈性伸縮,比如小時(shí)、分鐘的資源的快速流轉(zhuǎn),資源粒度分解到具體硬件計(jì)算垂直伸縮,也是一種更優(yōu)的解決方案,使得彈性更加迅速能做到秒級(jí)能力,進(jìn)一步壓縮集群密度,降低單位成本。