曾 理 呂曉丹

1(貴州大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 貴州 貴陽 550025) 2(貴州省公共大數(shù)據(jù)重點(diǎn)實(shí)驗(yàn)室 貴州 貴陽 550025)

0 引 言

微服務(wù)是一種將系統(tǒng)分解為小型、獨(dú)立、自治的服務(wù)體系結(jié)構(gòu),可以更輕松地在云環(huán)境中進(jìn)行部署。它解決了傳統(tǒng)的單片架構(gòu)隨著應(yīng)用程序通過子模塊部署的應(yīng)用擴(kuò)展而降低了開發(fā)效率并增加了維護(hù)成本的問題。容器作為一種輕量級的虛擬化技術(shù),在微服務(wù)的開發(fā)中起著重要的作用,可以大大提高部署環(huán)境的一致性并更好地利用資源。通常一種服務(wù)放置于一個(gè)容器中,因此微服務(wù)資源的彈性伸縮可以看成容器副本數(shù)的增加和減少。當(dāng)前大多數(shù)資源調(diào)度都是針對傳統(tǒng)的虛擬機(jī)技術(shù),但是傳統(tǒng)的虛擬機(jī)技術(shù)與容器技術(shù)本質(zhì)上不同。容器的啟動速度以秒為單位,而虛擬環(huán)境的啟動一般需要5～15 min[1]。與裸機(jī)相比,容器的性能幾乎沒有損失,但是虛擬機(jī)有明顯損失?；谏鲜鋈萜鞯膬蓚€(gè)特征,可以更容易地實(shí)現(xiàn)容器數(shù)量的伸縮。

然而容器進(jìn)行伸縮的時(shí)機(jī)尤為重要,伸縮算法的性能很大程度上取決于資源響應(yīng)時(shí)間。云資源的自動伸縮的過程主要可以分為兩類:響應(yīng)式和主動式[2]。響應(yīng)式算法根據(jù)系統(tǒng)的當(dāng)前狀態(tài)擴(kuò)展,雖然這樣滿足實(shí)時(shí)和容易擴(kuò)展的要求,但在準(zhǔn)確性方面,由于云服務(wù)負(fù)載狀態(tài)變化頻繁和數(shù)據(jù)傳輸延遲等原因[3]使得獲得的負(fù)載值存在很大的滯后性,這樣可能會導(dǎo)致服務(wù)QoS下降,無法滿足客戶的要求,甚至?xí)沟迷品?wù)提供商的成本增加[4]。主動式擴(kuò)展方法適用于云環(huán)境,尤其是在負(fù)載突然增加或者減少的時(shí)候,預(yù)測算法可預(yù)測將來的需求,然后根據(jù)預(yù)測結(jié)果主動進(jìn)行資源的自動伸縮。

多年來,工業(yè)界和學(xué)術(shù)界一直在積極地研究微服務(wù)中容器調(diào)度問題。在學(xué)術(shù)界有關(guān)微服務(wù)下的容器調(diào)度算法較少,因此尚未在該領(lǐng)域進(jìn)行比較全面的比較評估。郭楊虎[5]提出基于鄰域劃分的容器調(diào)度策略,將依賴關(guān)系緊密的服務(wù)盡量放在同一臺物理服務(wù)器上,以減少系統(tǒng)調(diào)用。這種方法沒有考慮多副本的服務(wù)情況。文獻(xiàn)[6-8]根據(jù)當(dāng)前資源使用情況通過提出動態(tài)容器調(diào)度策略,從而提高資源利用率。針對突發(fā)的服務(wù)負(fù)載,這種方法可能會降低QoS。文獻(xiàn)[9-11]通過時(shí)間序列預(yù)測方法對負(fù)載進(jìn)行預(yù)測,根據(jù)預(yù)測結(jié)果對容器數(shù)量進(jìn)行自動伸縮。但是并沒有對容器伸縮的數(shù)量進(jìn)行量化。關(guān)于時(shí)間序列預(yù)測模型,目前 ARIMA模型在時(shí)序預(yù)測方面有比較廣泛的應(yīng)用,文獻(xiàn)[10,12-13]選ARIMA來進(jìn)行負(fù)載預(yù)測,雖然建模方式上有所不同,但通過使用基于預(yù)測模型的資源調(diào)度算法能夠及時(shí)、有效地保證云服務(wù)質(zhì)量。

在工業(yè)界,為了解決容器的調(diào)度和復(fù)雜的管理問題,各大公司開發(fā)了自己的容器編排系統(tǒng)。其中比較著名的是Google公司的kubernetes、Docker公司的Swarmkit和Apache公司的Mesos[14]。然而Mesos主要的功能是數(shù)據(jù)中心資源的統(tǒng)一管理,其調(diào)度策略較少并且調(diào)度策略的實(shí)現(xiàn)和使用都比較復(fù)雜,對于非專業(yè)人員來說不太友好;Swarmkit[15]雖然原生支持docker,但它不能托管服務(wù),開發(fā)人員要時(shí)刻運(yùn)行服務(wù)發(fā)現(xiàn)引擎,并且對于版本的更新不能做到自動化;相較而言kubernetes提供了更加完善的功能,支持自動化的容器部署、擴(kuò)展和管理。k8s以其強(qiáng)大的服務(wù)編排能力和服務(wù)管理能力在一眾編排系統(tǒng)中脫穎而出。但k8s在進(jìn)行服務(wù)的擴(kuò)縮容時(shí),使用的擴(kuò)縮容算法過于簡單,使得在服務(wù)面對突發(fā)負(fù)載時(shí),無法保證服務(wù)的QoS。

綜合上述問題,本文通過使用時(shí)間序列預(yù)測模型根據(jù)最近一個(gè)時(shí)間區(qū)間內(nèi)的容器負(fù)載數(shù)據(jù),預(yù)測下一個(gè)時(shí)間區(qū)間內(nèi)的負(fù)載。使用預(yù)先訓(xùn)練的XGBoost模型,根據(jù)預(yù)測的負(fù)載壓力預(yù)測下一時(shí)間窗口內(nèi)所需的服務(wù)容器數(shù)量。本文的主要貢獻(xiàn)如下:

1) 本文通過使用時(shí)間序列預(yù)測模型ARIMA根據(jù)最近一個(gè)時(shí)間區(qū)間內(nèi)的pod負(fù)載數(shù)據(jù),預(yù)測下一個(gè)時(shí)間區(qū)間內(nèi)的負(fù)載,在負(fù)載突然上升或者下降時(shí)提供擴(kuò)縮容時(shí)機(jī)。

2) 基于XGBoost模型,根據(jù)預(yù)測的負(fù)載壓力結(jié)合pod中CPU和內(nèi)存使用率預(yù)測下一時(shí)間窗口內(nèi)所需的微服務(wù)/容器數(shù)量。

1 基于時(shí)序算法的負(fù)載預(yù)測

ARMA是由Roy等[16]提出的一種對負(fù)載進(jìn)行預(yù)測的時(shí)間序列模型。Calheiros等[17]在ARMA模型的基礎(chǔ)針對非平穩(wěn)的序列做了改進(jìn),提出差分自回歸移動模型ARIMA。ARIMA模型定義如下:

(1)

式中:p為自回歸階數(shù);φi是自相關(guān)系數(shù);L是滯后算子;d是差分項(xiàng);Xt是原序列;q是差分階數(shù),θi是誤差項(xiàng)參數(shù);εt是誤差項(xiàng)。差分算子的計(jì)算為:

Wt=ΔdXt=(1-L)dXt

(2)

建立ARIMA模型整體流程如圖1所示。

圖1 ARIMA模型方法流程

ARIMA模型方法主要分為四個(gè)步驟:

1) 平穩(wěn)性檢驗(yàn)。對于收集到的樣本數(shù)據(jù),其中不乏非平穩(wěn)的序列,若存在上升或下降趨勢,則進(jìn)行差分處理,消去其局部水平或者趨勢,得到的數(shù)據(jù)樣本就是平穩(wěn)的。

2) 模型識別。計(jì)算經(jīng)過平穩(wěn)化后的數(shù)據(jù)序列的自相關(guān)函數(shù)(ACF)和偏自相關(guān)函數(shù)(PACF),然后分析相關(guān)函數(shù)圖進(jìn)行模型識別如表1所示。

表1 ACF-PACF模型識別

自相關(guān)函數(shù)定義如下:

3) 模型定階。雖然觀察自相關(guān)和偏相關(guān)函數(shù)的拖尾和截尾可以給模型定階,但這種定階方法往往具有很強(qiáng)的主觀性?？梢愿鶕?jù)信息準(zhǔn)則函數(shù)赤池信息準(zhǔn)則AIC和貝葉斯信息準(zhǔn)則BIC來確定模型階數(shù)。

AIC=2k-2ln(L)

(4)

BIC=kln(n)-2ln(L)

(5)

4) 模型檢驗(yàn)。通過白噪聲進(jìn)行檢驗(yàn),如果模型的噪聲訓(xùn)練通過檢驗(yàn),那么模型完全或者基本符合了數(shù)據(jù)的相關(guān)性,如果不能通過噪聲檢驗(yàn),應(yīng)該重新擬合模型直到通過白噪聲檢驗(yàn)。

2 基于XGBoost的容器數(shù)量預(yù)測

2.1 問題定義

隨著云計(jì)算技術(shù)的興起,容器和微服務(wù)兩大技術(shù)應(yīng)運(yùn)而生,容器技術(shù)的發(fā)展為微服務(wù)提供了良好的客觀條件,而輕量級的容器技術(shù)則為微服務(wù)提供了最佳的運(yùn)行環(huán)境。與此同時(shí)微服務(wù)架構(gòu)所暴露出來的服務(wù)管理和服務(wù)發(fā)現(xiàn)等問題,促使了服務(wù)管理平臺的誕生。其中最優(yōu)秀的管理平臺是谷歌推出的kubernetes。圖2是基于k8s平臺的微服務(wù)部署架構(gòu)。

圖2 基于k8s平臺的微服務(wù)部署架構(gòu)

微服務(wù)與單體應(yīng)用的區(qū)別在于一組微服務(wù)只使用一個(gè)代碼庫,實(shí)現(xiàn)單一的功能,每個(gè)服務(wù)可以獨(dú)立部署獨(dú)立發(fā)布,每個(gè)微服務(wù)放置于一個(gè)容器中。開發(fā)人員在部署微服務(wù)的時(shí)候,通常將一組服務(wù)放到一個(gè)pod中,同一個(gè)pod中的服務(wù)共享網(wǎng)絡(luò)與存儲,這樣可以使得服務(wù)間的通信能力大大提高。在微服務(wù)架構(gòu)下,當(dāng)負(fù)載急劇增加時(shí),可以通過增加該pod中服務(wù)/容器數(shù)量,降低訪問壓力;相反pod中容器資源利用低下時(shí),通過減少容器數(shù)量來達(dá)到節(jié)約資源的作用。因此負(fù)載發(fā)生變化時(shí),服務(wù)/容器數(shù)量的伸縮數(shù)量至關(guān)重要。

為了解決上述問題,收集了大量有關(guān)負(fù)責(zé)壓力和所需容器數(shù)量的數(shù)據(jù),建立了實(shí)驗(yàn)數(shù)據(jù)集。每個(gè)樣本數(shù)據(jù)都包含了4個(gè)標(biāo)簽,分別是CPU使用率、內(nèi)存使用率、服務(wù)的負(fù)載壓力和容器數(shù)量。通過使用XGBoost算法,獲得服務(wù)的負(fù)載、CPU、內(nèi)存使用情況和容器數(shù)量之間的關(guān)系,從而達(dá)到預(yù)測容器數(shù)量的目的。實(shí)驗(yàn)有兩個(gè)約束條件,分別是服務(wù)質(zhì)量QoS和資源利用情況。

2.2 XGBoost算法

XGBoost算法是在GBDT基礎(chǔ)上對Boosting算法進(jìn)行改進(jìn)的機(jī)器學(xué)習(xí)算法。為了防止模型出現(xiàn)過擬合,增強(qiáng)模型的泛化能力,加入模型復(fù)雜度的正則表達(dá)式項(xiàng)。同時(shí)對損失殘差使用二階泰勒展開。相較于其他分類算法,該算法的訓(xùn)練速度和分類效果有著顯著的提升。

XGBoost是通過隨機(jī)地進(jìn)行特征分裂來生成樹,也就是為了擬合前面預(yù)測的損失殘差,每次學(xué)習(xí)一個(gè)新的函數(shù)f(x),最后將k棵樹的結(jié)果求和作為最終的預(yù)測值。

(6)

Γ={f(x)=ωq(x)}(q:ω∈RT)

(7)

式中:xi代表第i個(gè)樣本;k表示樹的數(shù)量;T是對應(yīng)樹的葉子節(jié)點(diǎn)個(gè)數(shù);q表示將樹與對應(yīng)的葉子節(jié)點(diǎn)映射的空間結(jié)構(gòu);f(x)包括該樹的空間結(jié)構(gòu)和葉子節(jié)點(diǎn)的權(quán)重;ω表示葉子節(jié)點(diǎn)的權(quán)重。

(8)

由于式(9)無法使用傳統(tǒng)方法進(jìn)行優(yōu)化,因此在模型訓(xùn)練時(shí),使每一輪訓(xùn)練都會保留前t-1模型的預(yù)測,這樣就大大減少計(jì)算復(fù)雜度,式(10)為新的目標(biāo)函數(shù)。

(10)

為了方便計(jì)算損失函數(shù)L(φ),直接基于損失函數(shù)的二階泰勒展開式來求解,分別對損失進(jìn)行一階導(dǎo)和二階導(dǎo)獲得:

通過把所有葉子節(jié)點(diǎn)區(qū)域和每個(gè)葉子節(jié)點(diǎn)區(qū)域最優(yōu)值訓(xùn)練,將葉子節(jié)點(diǎn)最優(yōu)值代入目標(biāo)函數(shù),最終的目標(biāo)函數(shù)可以表示為:

(12)

最后目標(biāo)函數(shù)基于最大分?jǐn)?shù)對應(yīng)的特征分裂子樹,通過不斷的迭代得到弱學(xué)習(xí)器,然后更新強(qiáng)學(xué)習(xí)器。

大量實(shí)驗(yàn)表明CPU、內(nèi)存、服務(wù)負(fù)載是調(diào)整容器數(shù)量的重要的三個(gè)因素。這三個(gè)特征組成特征樣本輸入XGBoost進(jìn)行模型預(yù)測。算法步驟如算法1所示。

算法1基于XGBoost的容器數(shù)量預(yù)測算法

輸入: 訓(xùn)練集S=(xi,yi),(xi+1,yi+1),…,(xn,yn),特征集合F。

輸出: XGBoost Tree。

function (S,F)

fork=1 to m do

GL=0,HL=0

foriin sorted(Ik,xik) do

GL=GL+gi,HL=HL+hi

GR=G-GL,HR=H-HL

end

end

Return The learned Tree XGBoost

end function

3 實(shí) 驗(yàn)

3.1 實(shí)驗(yàn)環(huán)境

本實(shí)驗(yàn)選取貴州翔明云科技公司微服務(wù)化的ERP系統(tǒng),部署于kubernetes平臺上。本實(shí)驗(yàn)硬件環(huán)境:采用5臺戴爾服務(wù)器,內(nèi)存:DDR3 1 066 MHz,CPU:E5506。其中:3臺服務(wù)器作為master節(jié)點(diǎn),其中2臺既作為master節(jié)點(diǎn)也作為node節(jié)點(diǎn);剩余2臺作為node節(jié)點(diǎn)。集群硬件環(huán)境如表2所示。

表2 集群硬件環(huán)境表

3.2 服務(wù)負(fù)載預(yù)測效果對比

為了驗(yàn)證時(shí)序預(yù)測方法的有效性,采集貴州翔明云的ERP系統(tǒng)五月到七月三個(gè)月的負(fù)載數(shù)據(jù),從數(shù)據(jù)庫獲得負(fù)載數(shù)據(jù),將前面三個(gè)月數(shù)據(jù)作為訓(xùn)練集,選取后面8月1日8點(diǎn)到12點(diǎn)的數(shù)據(jù)作為測試集,然后使用ARIMA模型進(jìn)行訓(xùn)練,預(yù)測結(jié)果如圖3所示。

圖3 負(fù)載預(yù)測結(jié)果對比

可以看出本文的預(yù)測方法對突發(fā)負(fù)載保持了較好的預(yù)測精度,通過原始數(shù)據(jù)與預(yù)測數(shù)據(jù)曲線對比,ARIMA模型的預(yù)測方法能夠很好地預(yù)測負(fù)載。

3.3 容器數(shù)量預(yù)測效果對比

為了驗(yàn)證本文提出的XGBoost預(yù)測方法的有效性,對比kubernetes自帶的HPA(Horizontal Pod Autoscaler)算法。HPA通過Metrics API 獲取CPU、內(nèi)存等資源信息,其算法原理是調(diào)整容器副本數(shù)目使得資源使用率盡量向期望值靠近,每次Pod伸縮的數(shù)量算法為:Ceil(當(dāng)前采集到的資源使用率/用戶自定義的使用率)×Pod數(shù)量。

對比圖4和圖5可以發(fā)現(xiàn),在負(fù)載上升時(shí),HPA算法并不能馬上做出擴(kuò)容的反應(yīng);而本文方法能在負(fù)載上升之前擴(kuò)容。在負(fù)載下降時(shí),為了保證服務(wù)的QoS,將縮容的時(shí)機(jī)調(diào)整到負(fù)載下降之后。這里在擴(kuò)縮容時(shí)是在不同物理服務(wù)器上進(jìn)行,因此物理機(jī)負(fù)載變化影響較小。兩種方法縮容時(shí)機(jī)相同,但是縮容的數(shù)量不同。因此基于ARIMA-XGBoost的方法比HPA的方法在負(fù)載變化的云環(huán)境更適合,每次都在負(fù)載上升之前做好了擴(kuò)容的準(zhǔn)備。

圖4 HPA擴(kuò)縮容過程

圖5 ARIMA-XGBoost擴(kuò)縮容過程

3.4 服務(wù)擴(kuò)縮容響應(yīng)時(shí)間和資源利用情況對比

為了驗(yàn)證基于本文的方法比HPA算法好, 采用服務(wù)擴(kuò)縮容響應(yīng)時(shí)間和資源利用率情況兩個(gè)衡量指標(biāo)?；?.3節(jié)容器擴(kuò)縮容的過程,記錄下的服務(wù)響應(yīng)時(shí)間對比如圖6和圖7所示,資源利用情況對比如圖8所示。

圖6 HPA方法擴(kuò)縮容響應(yīng)時(shí)間

圖7 ARIMA-XGBoost方法擴(kuò)縮容響應(yīng)時(shí)間

圖8 資源使用率對比

由圖6和圖7可以看到HPA算法在1～3 min時(shí)隨著負(fù)載的增加,沒能及時(shí)擴(kuò)增容器數(shù)量,導(dǎo)致服務(wù)響應(yīng)時(shí)間超出了200 ms(在云計(jì)算中服務(wù)的響應(yīng)時(shí)間超過200 ms定義為服務(wù)質(zhì)量低),而本文方法可以使服務(wù)的響應(yīng)時(shí)間保持在200 ms以內(nèi)。在15 min以后負(fù)載下降,兩種方法都沒有立刻縮容,因此服務(wù)響應(yīng)時(shí)間均保持在200 ms以內(nèi)。

由圖8可以看出在0～25 min的擴(kuò)縮容的過程中,在保證服務(wù)質(zhì)量的情況下,本文方法比HPA算法擴(kuò)縮容的數(shù)量少,因此資源的使用率比HPA方法低,因此資源的利用率比HPA算法高。

4 結(jié) 語

本文通過使用ARIMA時(shí)序預(yù)測方法得知服務(wù)負(fù)載將來的變化,然后根據(jù)預(yù)測的負(fù)載結(jié)合pod中CPU、內(nèi)存的使用情況使用XGBoost算法預(yù)測需要擴(kuò)縮的微服務(wù)/容器數(shù)量,對比kubernetes的HPA算法,本文方法能在保證服務(wù)質(zhì)量QoS的同時(shí)降低系統(tǒng)資源的使用。