鄒文仲，張高峰，章金峰

（南京南瑞繼保電氣有限公司，南京 211102）

0 引言

在云平臺部署的氣象決策系統(tǒng)作為電網(wǎng)公司內(nèi)部基礎(chǔ)應(yīng)用，具有顯著時間訪問特征，如災(zāi)害天氣來臨、工作日早會等時間系統(tǒng)訪問量會激增。此時固定云資源的部署方式不能承受激增的訪問量，必然會導(dǎo)致系統(tǒng)卡頓，甚至崩潰，普通閾值彈性伸縮也存在調(diào)節(jié)之后，伸縮抖動問題。所以急需一種可以提前擴(kuò)容的技術(shù)來解決上述問題。

作為Kubernetes核心的發(fā)布功能之一，彈性伸縮技術(shù)及其方案的設(shè)計與實現(xiàn)已成為衡量云平臺服務(wù)能力的重要參考標(biāo)準(zhǔn)［1-2］，現(xiàn)階段對云平臺彈性伸縮也做了大量研究。文獻(xiàn)［3］對比了三種預(yù)測模型的精度，但是未給出輸入?yún)?shù)的量化標(biāo)準(zhǔn)以及模型的適用場景。文獻(xiàn)［4］提供的方法解決了模型空間爆炸及算法可伸縮性受限問題，未考慮如何預(yù)測工作負(fù)載變化。文獻(xiàn)［5-7］介紹的彈性伸縮方案只考慮了系統(tǒng)集群CPU和內(nèi)存指標(biāo)，沒有考慮應(yīng)用的具體業(yè)務(wù)統(tǒng)計指標(biāo)，當(dāng)超大負(fù)載到來時，由于動作滯后性依然不能解決系統(tǒng)卡頓問題，文中同樣也未考慮預(yù)先伸縮，時效性不足。

因此，本文提出了一種基于神經(jīng)網(wǎng)絡(luò)預(yù)測訪問量的彈性伸縮方案。方案采用五層BP神經(jīng)網(wǎng)絡(luò)預(yù)測系統(tǒng)，通過反饋機(jī)制訓(xùn)練神經(jīng)網(wǎng)絡(luò)中的權(quán)值來逐漸優(yōu)化預(yù)測結(jié)果，并構(gòu)建了基于Ku?bernetes原生自定義指標(biāo)接口與HPA交互完成伸縮。該方案讓容器伸縮先于訪問流量的突變，減少系統(tǒng)的卡頓和抖動，實現(xiàn)最高層級系統(tǒng)彈性伸縮。

1 參數(shù)預(yù)處理及網(wǎng)絡(luò)模型設(shè)計

1.1 BP神經(jīng)網(wǎng)絡(luò)介紹及權(quán)值訓(xùn)練

BP神經(jīng)網(wǎng)絡(luò)是一種多層的前饋神經(jīng)網(wǎng)絡(luò)，其主要的特點是信號前向傳播，誤差反向傳播。神經(jīng)網(wǎng)絡(luò)的上一層輸出數(shù)據(jù)是下一層的輸入數(shù)據(jù)。原始的輸入數(shù)據(jù)，通過第一層隱含層的計算得出的輸出數(shù)據(jù)，會傳到第二層隱含層，從而依次類推，神經(jīng)網(wǎng)絡(luò)的層級數(shù)根據(jù)實際數(shù)據(jù)進(jìn)行設(shè)置［7-8］。

神經(jīng)網(wǎng)絡(luò)的訓(xùn)練過程分為兩部分：向前傳播得到預(yù)測數(shù)據(jù)以及反向傳播更新權(quán)重，流程如圖1所示。

圖1 神經(jīng)網(wǎng)絡(luò)訓(xùn)練過程

1.2 輸入?yún)?shù)預(yù)處理及網(wǎng)絡(luò)模型設(shè)計

影響氣象決策系統(tǒng)訪問量的因素主要有日期、主要城市溫度、臺風(fēng)狀態(tài)、山火狀態(tài)、線路覆冰狀態(tài)等。其中日期因素主要分為工作日、休息日，不同日期因素影響下系統(tǒng)的訪問量存在一定差異；溫度因素包括日最高氣溫、最低氣溫等，氣溫的高低影響訪問量變化；臺風(fēng)因素主要有臺風(fēng)是否在24小時警戒線內(nèi)，臺風(fēng)預(yù)測是否登陸，臺風(fēng)強(qiáng)度。天氣因素即天氣類型，主要分為晴、多云、陰、雨、大雨、雪等類型［9］。量化的原則是數(shù)值類數(shù)據(jù)保持不變，如溫度；互斥類數(shù)據(jù)采用布爾型變量，用1代表是，2代表否，如若是工作日，則D等于1。具體量化規(guī)則如表1所示。

表1 系統(tǒng)訪問量影響因素量化規(guī)則

神經(jīng)網(wǎng)絡(luò)初始輸入層節(jié)點數(shù)為表1的八個量以及當(dāng)前Pod數(shù)量以及綜合負(fù)載率，以上數(shù)據(jù)相差較大，神經(jīng)網(wǎng)絡(luò)不容易收斂，神經(jīng)元會出現(xiàn)飽和現(xiàn)象。為了避免以上情況，采用類似標(biāo)幺值的方式對輸入量進(jìn)行歸一化預(yù)處理，把所有量值限制在同一等級，待預(yù)測完成后，再轉(zhuǎn)化成實際值，規(guī)則如下：

歸一化處理：

歸一值轉(zhuǎn)換為實際值：

式（1）和式（2）中xmax、xmin分別為某項輸入量的最大值、最小值。xi、yi為某項輸入量歸一化之前及之后的值。本文主要對非布爾變量做歸一化處理，布爾型變量維持不變。

完成輸入數(shù)據(jù)的預(yù)處理后，考慮到系統(tǒng)收斂速度及輸出精度，構(gòu)建了單隱含層的五層神經(jīng)網(wǎng)絡(luò)，輸出量為預(yù)測綜合負(fù)載率，隱含層的節(jié)點數(shù)N通過經(jīng)驗公式和試湊法進(jìn)行確定，經(jīng)驗公式為

式（3）中，N為隱含層節(jié)點數(shù)，m為輸入層節(jié)點數(shù)，l為輸出層節(jié)點個數(shù)，q為調(diào)節(jié)常數(shù)，取值范圍為[1,10]。

2 云原生自定義指標(biāo)接口設(shè)計

Kubernetes上的彈性伸縮會在節(jié)點和服務(wù)兩個粒度進(jìn)行。彈性伸縮分為垂直彈性伸縮（Ver?tical Pod Autoscaler，VPA）和水平彈性伸縮（Horizontal Pod Autoscaler，HPA）。垂直彈性伸縮是指調(diào)整節(jié)點或服務(wù)的資源配額，水平彈性伸縮是指調(diào)整節(jié)點或服務(wù)的數(shù)量［5］。垂直伸縮對應(yīng)用系統(tǒng)本身無感，但是對云服務(wù)器要求較高，此外單臺服務(wù)器的資源有限，業(yè)務(wù)高峰時可能無法滿足要求。水平伸縮則是要求應(yīng)用系統(tǒng)是無狀態(tài)的，伸縮過程中系統(tǒng)之間通過調(diào)用關(guān)系進(jìn)行實時調(diào)整。因氣象決策系統(tǒng)采用微服務(wù)的開發(fā)架構(gòu)，水平彈性伸縮更適合解決訪問量激增的問題，故本文基于水平彈性伸縮進(jìn)行自定義指標(biāo)接口設(shè)計。

常規(guī)HPA的判據(jù)是Pod的CPU或者內(nèi)存使用率，基本原理是Metrics Server會持續(xù)采集Pod的指標(biāo)數(shù)據(jù)，HPA控制器通過Metrics Server的API獲取這些數(shù)據(jù)，基于用戶定義的擴(kuò)縮容規(guī)則進(jìn)行計算，得到目標(biāo)Pod副本數(shù)量。當(dāng)目標(biāo)Pod副本數(shù)量與當(dāng)前副本數(shù)量不同時，HPA控制器就向Pod的副本控制器（Deployment、RC或Rep?licaSet）發(fā)起scale操作，然后副本控制器會調(diào)整Pod的副本數(shù)量，完成擴(kuò)縮容操作，具體過程如圖2所示。

圖2 HPA控制器原理圖

對于使用自定義指標(biāo)的HPA，上述方案就不適用了，為此設(shè)計了基于第三方監(jiān)控軟件的自定義指標(biāo)接口。首先搭建Metrics Server，在Kubernetes1.7版本中引入了聚合層，允許第三方應(yīng)用程序通過將自己注冊為API附加組件來擴(kuò)展Kubernetes API。Custom Metrics API和聚合層可以讓監(jiān)控系統(tǒng)向HPA開放第三方應(yīng)用程序的指標(biāo)。

目前業(yè)界通常使用Promethues來監(jiān)控Kuber?netes系統(tǒng)。Promethues可以獲取應(yīng)用自定義的指標(biāo)數(shù)據(jù)，并將其注冊到Kubernetes系統(tǒng)中供HPA讀取，進(jìn)行擴(kuò)容縮容操作，所以本文采用Prometheus來實現(xiàn)基于自定義指標(biāo)的彈性伸縮。數(shù)據(jù)接口示意如圖3所示，圖中PromQL相當(dāng)于用sql語句來完成數(shù)據(jù)查詢，即通過中間表的形式完成神經(jīng)網(wǎng)絡(luò)與HPA的通信。詳細(xì)流程如下：

圖3 自定義指標(biāo)API部署示意圖

（1）BP神經(jīng)網(wǎng)絡(luò)把運(yùn)行結(jié)果存入中間表中。

（2）由Prometheus監(jiān)控程序定時去獲取最新的指標(biāo)數(shù)據(jù)，并由Kube-state-metrics模塊匯總。

（3）Custom Metrics API模塊中的Adapter從Prometheus得到業(yè)務(wù)數(shù)據(jù)，轉(zhuǎn)成Kubernetes支持的格式。

（4）HPA定時通過Metrics API中的kubeaggregator獲取第三方指標(biāo)數(shù)據(jù)完成后續(xù)功能。

3 考慮綜合負(fù)載彈性伸縮方案

當(dāng)應(yīng)用Pod數(shù)大于1時，采用單一Pod的CPU使用率作為比較基準(zhǔn)不夠精確，因此本文設(shè)計了綜合負(fù)載作為比較指標(biāo)。所謂綜合負(fù)載，即考慮所有副本Pod的資源使用情況的負(fù)載，可以是單一的CPU、內(nèi)存綜合負(fù)載，也可以是考慮多種因素的綜合負(fù)載。應(yīng)用Pod的資源使用情況可以通過監(jiān)控組件Promethues實時采集，數(shù)據(jù)傳輸流程參照圖3。本文以電網(wǎng)公司氣象決策系統(tǒng)為例，考慮到后臺服務(wù)絕大多數(shù)是數(shù)據(jù)的計算，以CPU綜合負(fù)載進(jìn)行說明。CPU綜合負(fù)載的計算方法為

其中Cused是綜合負(fù)載，n表示Pod的個數(shù)，Urequest為Pod分配的CPU數(shù)量，Uiused為第i個Pod的CPU使用數(shù)量。

本文的伸縮方案采用橫向模式，采用五層BP神經(jīng)網(wǎng)絡(luò)，流程為：首先用神經(jīng)網(wǎng)絡(luò)預(yù)測出結(jié)果，比較結(jié)果和設(shè)置的閾值來決定是否要進(jìn)行伸縮，假如綜合負(fù)載超限則把結(jié)果回饋至神經(jīng)網(wǎng)絡(luò)重新訓(xùn)練。流程設(shè)計中不僅設(shè)計HPA模塊的伸縮，也有神經(jīng)網(wǎng)絡(luò)的反饋。神經(jīng)網(wǎng)絡(luò)的反饋機(jī)制基本準(zhǔn)則是若神經(jīng)網(wǎng)絡(luò)預(yù)測結(jié)果不能滿足系統(tǒng)指標(biāo)要求，則把預(yù)測結(jié)果修正后重新訓(xùn)練網(wǎng)絡(luò)并觀察系統(tǒng)指標(biāo)，直至系統(tǒng)指標(biāo)滿足要求。詳細(xì)集群擴(kuò)容、縮容方案如下所示。

圖4 系統(tǒng)擴(kuò)容縮容流程圖

（1）神經(jīng)網(wǎng)絡(luò)模塊系統(tǒng)獲取影響系統(tǒng)訪問量的因素如：日期類型、天氣類型、臺風(fēng)、山火個數(shù)、應(yīng)用Pod實時數(shù)量以及實時綜合負(fù)載等，并對輸入量參數(shù)歸一化處理，根據(jù)獲取的因素用BP神經(jīng)網(wǎng)絡(luò)計算未來一段時間系統(tǒng)的預(yù)測綜合負(fù)載Cpre。

（2）設(shè)置綜合負(fù)載閾值參數(shù)Tu、tolerance。Tu為伸縮閾值，此值根據(jù)分配Pod的CPU、內(nèi)存相關(guān)，tolerance為彈性閾值，根據(jù)系統(tǒng)實際情況取值，本文取0.1。

根據(jù)以上參數(shù)計算綜合負(fù)載擴(kuò)容閾值及縮容閾值up=Tu*(1+tolerance)，down=Tu*(1-tolerance)。

（3）把神經(jīng)網(wǎng)絡(luò)預(yù)測綜合負(fù)載Cpre以及實際綜合負(fù)載Cused一同傳入HPA資源對象進(jìn)行擴(kuò)容和縮容操作。擴(kuò)容的判據(jù)為Cpre>up，縮容判據(jù)為Cused

（4）對擴(kuò)容或者縮容后系統(tǒng)的實際綜合負(fù)載進(jìn)行觀察，看是否在規(guī)定的范圍內(nèi)。

（5）若在規(guī)定范圍為，結(jié)束流程；若不在規(guī)定范圍內(nèi)，把誤差e反饋給神經(jīng)網(wǎng)絡(luò)進(jìn)行新權(quán)值的訓(xùn)練完善，當(dāng)修正后的權(quán)值計算得出的綜合負(fù)載滿足要求后，流程結(jié)束。

對于系統(tǒng)縮容功能，提前縮容會導(dǎo)致運(yùn)行Pod資源使用率迅速增長，故對縮容的判據(jù)為實際綜合負(fù)載小于設(shè)置的縮容閾值。神經(jīng)網(wǎng)絡(luò)的訓(xùn)練需要一定的時間，故前期測試時對應(yīng)用Pod副本數(shù)沒有限制，待系統(tǒng)穩(wěn)定運(yùn)行后，對Pod副本數(shù)進(jìn)行限制，繼而在流程中加入此項數(shù)值的判別［10］。

4 工程應(yīng)用分析

本文所述伸縮方案已成功應(yīng)用于南方電網(wǎng)試點項目中，所用Kubernetes集群為1.7版本，集群有3個master節(jié)點（主備），11臺node節(jié)點，單個應(yīng)用Pod資源分配為：CPU為3core，內(nèi)存為8 G，觀察臺風(fēng)來臨時刻系統(tǒng)Pod數(shù)量、資源使用情況以及網(wǎng)頁訪問速率。臺風(fēng)1發(fā)生時刻采用普通彈性伸縮方案，判據(jù)為CPU使用率超過80%進(jìn)行擴(kuò)容；臺風(fēng)2采用了本文神經(jīng)網(wǎng)絡(luò)預(yù)測方案。

圖5展示了臺風(fēng)1來臨時刻系統(tǒng)資源使用情況。臺風(fēng)登陸時，系統(tǒng)的訪問量激增，普通彈性負(fù)載具有一定滯后性，在21:45系統(tǒng)負(fù)載流量激增時，伴隨著CPU負(fù)載的提高，POD數(shù)量也逐漸增加，但是此時POD數(shù)量增加的速度還是跟不上負(fù)載的增長，所以綜合負(fù)載一直居高不下。伴隨著訪問量的穩(wěn)定，POD數(shù)量也擴(kuò)充到9個左右，此時，綜合負(fù)載也快速下降，逐漸達(dá)到穩(wěn)定狀態(tài)，單個Pod維持在2.3core左右CPU使用量。

圖5 臺風(fēng)1登錄時系統(tǒng)資源使用情況

圖6展示了臺風(fēng)2登錄時系統(tǒng)資源使用情況。在14:58流量開始激增前，根據(jù)神經(jīng)網(wǎng)絡(luò)的預(yù)測，提前把POD的數(shù)量擴(kuò)增至5個，此時流量的增長沒有對Pod中CPU造成任何壓力，綜合負(fù)載平穩(wěn)增長。伴隨著流量的繼續(xù)激增，神經(jīng)網(wǎng)絡(luò)在15:04時把POD數(shù)量擴(kuò)展至9個，此時，綜合負(fù)載維持在75%左右，并沒有無節(jié)制的攀升至Pod崩潰，最終單個Pod維持在2.4core左右的使用量，且過程平穩(wěn)，未出現(xiàn)單個Pod的資源使用率激增導(dǎo)致卡頓的現(xiàn)象。

圖6 臺風(fēng)2登錄時系統(tǒng)資源使用情況

工程應(yīng)用結(jié)果表明，神經(jīng)網(wǎng)絡(luò)預(yù)測方案的使用，讓系統(tǒng)做到了提前擴(kuò)容，無論是系統(tǒng)綜合負(fù)載還是系統(tǒng)訪問平均等待時間都更趨向平穩(wěn)，系統(tǒng)體驗及可靠性得到了顯著提升。

5 結(jié)語

本文設(shè)計了一種基于Kubernetes云平臺的彈性伸縮方案。該方案首先對影響系統(tǒng)訪問量的因素進(jìn)行量化歸算作為神經(jīng)網(wǎng)絡(luò)預(yù)測算法的輸入，通過HPA調(diào)用云原生自定義指標(biāo)接口來控制彈性伸縮。工程應(yīng)用結(jié)果表明，該方法可以增強(qiáng)應(yīng)用集群的高可用能力，降低集群因流量暴增而導(dǎo)致服務(wù)卡死的幾率，提升了系統(tǒng)體驗。下一步將在神經(jīng)網(wǎng)絡(luò)的預(yù)測中引入更多的變量，進(jìn)行中長期的負(fù)載預(yù)測，讓系統(tǒng)更加健壯。