本文根據(jù)孫燕老師在《2019DAMS中國數(shù)據(jù)智能管理峰會》現(xiàn)場演講內(nèi)容整理而成。

講師介紹

孫燕，微博廣告基礎(chǔ)運(yùn)維負(fù)責(zé)人，2009年入職新浪，任職10年間參與博客、圖片、視頻、微博平臺監(jiān)控、微博廣告多個產(chǎn)品運(yùn)維，致力于運(yùn)維自動化、產(chǎn)品架構(gòu)優(yōu)化、服務(wù)治理、智能監(jiān)控及以監(jiān)控為依托的服務(wù)容災(zāi)建設(shè)。

1、為什么需要彈性計算

首先，在產(chǎn)品方面，我們的產(chǎn)品線很多，依賴關(guān)系比較復(fù)雜。

微博廣告相當(dāng)于一個橋梁，左邊連接的是廣告主，右邊連接的是客戶，需要將廣告主的廣告計劃轉(zhuǎn)化為用戶的需求，讓用戶看到自己想要看的廣告。

為了滿足兩邊不同的需求，產(chǎn)品的變更和發(fā)布非常重要且頻繁。

其次，在運(yùn)營方面，很多有推廣需求計劃的大型活動都有臨時擴(kuò)容需要，比如618跟雙十一，對于我們而言這兩個活動帶來了很大的沖擊。

在618和雙十一大促之前，為了加大自己的影響力，各個廣告主會增加廣告計劃，微博廣告這邊再針對廣告主的行為加大我們的曝光量，實(shí)現(xiàn)廣告主廣告計劃的轉(zhuǎn)化。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

2、傳統(tǒng)的業(yè)務(wù)運(yùn)維

按照傳統(tǒng)運(yùn)維模式，擴(kuò)容計劃從立項(xiàng)到服務(wù)器上線，會經(jīng)過諸多的流程跟漫長的等待。從結(jié)果上來看，服務(wù)器擴(kuò)容了，而且對傳統(tǒng)項(xiàng)目而言，整體流程都是可控的，這是它的優(yōu)點(diǎn)。

它的缺點(diǎn)不言而喻，有以下幾點(diǎn)：

首先，它時效性太差，如果按照新浪服務(wù)器的采購周期，從審計到上線需要兩個月的流程。兩個月后服務(wù)器上線，恐怕剛結(jié)婚的明星都已經(jīng)離婚了，突發(fā)事件流量都已經(jīng)過去了。

另外，它無法準(zhǔn)確預(yù)估容量，在傳統(tǒng)的業(yè)務(wù)運(yùn)維模式下，范冰冰分手、雙宋離婚帶來的流量是無法實(shí)現(xiàn)的，我們無法評估擴(kuò)容量。

除此之外，傳統(tǒng)模式下資源利用率比較低，服務(wù)器很難在業(yè)務(wù)間共享。

在這些問題共同作用下催生了動態(tài)擴(kuò)縮容體系。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

3、彈性計算：實(shí)時動態(tài)擴(kuò)縮容

動態(tài)擴(kuò)縮容不是一個工具，是一整套體系。它基于云服務(wù)，包含了在線壓力檢測和消耗度評測的功能，最終實(shí)現(xiàn)分級治理。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

1）彈性計算架構(gòu)

首先簡單介紹一下彈性計算的架構(gòu)，彈性計算依托于Kunkka自動化運(yùn)維平臺，以及Oops監(jiān)控平臺，在業(yè)務(wù)壓測的情況下獲取業(yè)務(wù)指標(biāo)監(jiān)控，將數(shù)據(jù)送到容量決策系統(tǒng)，做出是否擴(kuò)縮容的決定。

在云服務(wù)商方面，我們常用阿里云、華為云跟一部分自建的私有云。DCP混合平臺是我們微博另外一個團(tuán)隊(duì)做了幾年的平臺，它能夠?qū)釉品?wù)，快速生成云主機(jī)快速擴(kuò)容。今天的重點(diǎn)跟業(yè)務(wù)方有著最直接的關(guān)系：業(yè)務(wù)上要不要擴(kuò)容？什么時候擴(kuò)容？擴(kuò)多少？我們要解決這樣的問題。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

2）決策系統(tǒng)

在上文的架構(gòu)中，我們提到了容量決策系統(tǒng)，容量決策系統(tǒng)實(shí)際上指的是計算系統(tǒng)，會對我們獲取到的業(yè)務(wù)指標(biāo)進(jìn)行計算、評估，比如系統(tǒng)的基礎(chǔ)信息、一些業(yè)務(wù)上日志來源的信息等，得到當(dāng)前業(yè)務(wù)的容量，通過對歷史數(shù)據(jù)進(jìn)行同比、環(huán)比的分析，得到流量趨勢，了解接下來流量會變成什么樣子，這兩組數(shù)據(jù)計算結(jié)果會給出擴(kuò)縮容的建議。

同時，他們會計算這些數(shù)據(jù)并予以呈現(xiàn)，提供一個輔助的API接口，給上下游部門做擴(kuò)縮容數(shù)據(jù)。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

3）容量評估方法

這個業(yè)務(wù)的當(dāng)前容量是什么樣的？是不是健康的？這個指標(biāo)靠什么來評估？

由于業(yè)務(wù)系統(tǒng)、業(yè)務(wù)形態(tài)、架構(gòu)的不同，選取一個實(shí)時且通用的指標(biāo)是非常具有挑戰(zhàn)性的，我們也嘗試了很久，引入了AVG-hits的概念。

對于處在不同時間內(nèi)的請求數(shù)進(jìn)行加權(quán)、求和來擬合實(shí)際的單機(jī)消耗量，這個代表的是在不同的區(qū)間的耗時數(shù)，我們給它一個系數(shù)，大于5毫秒小于10毫秒，根據(jù)自己的業(yè)務(wù)給予耗時分區(qū)，這樣就能計算出來。

事實(shí)證明，與之前傳統(tǒng)的單一QPS負(fù)載對比起來，綜合的數(shù)據(jù)對業(yè)務(wù)的評估比這種單一指標(biāo)是更加準(zhǔn)確的。

在獲得這個數(shù)據(jù)之后是不是就能夠描述當(dāng)前的系統(tǒng)容量呢？

回答是肯定不能，AVG-hits這個概念第一次接觸，確實(shí)是有點(diǎn)生澀，舉個簡單的例子來幫助理解，比如說某個業(yè)務(wù)消耗指標(biāo)衡量非常簡單，需要通過內(nèi)存判斷消耗情況。

如果監(jiān)控指標(biāo)提示內(nèi)存消耗到80G，那能不能用80G來描述當(dāng)前系統(tǒng)的消耗情況？這樣問就比較容易理解，回答肯定是不能的，因?yàn)椴恢婪?wù)器最大的內(nèi)存是多少，如果最大是96G，那么80G已經(jīng)超過80%了，接近危險值，如果最大內(nèi)存是256G則消耗不到30%，是非常安全的值。

道理是一樣的，僅拿到當(dāng)前消耗值是不能對業(yè)務(wù)當(dāng)前狀態(tài)進(jìn)行描述的，還需要另一個評估標(biāo)準(zhǔn)。這個業(yè)務(wù)當(dāng)前能承載的最大容量是多少？如果是看內(nèi)存就簡單了，可這是一個綜合評估標(biāo)準(zhǔn)，要怎么拿到它呢？

作為一個有經(jīng)驗(yàn)的運(yùn)維，我覺得根據(jù)服務(wù)器當(dāng)前硬件的表現(xiàn)，猜測最大容量不是困難的事情，但現(xiàn)在都2019年了，靠猜是不行的，我們通過壓測獲取最大容量值。

在實(shí)際環(huán)境中減少服務(wù)器數(shù)量，減少到不能再少，記錄當(dāng)前的容量值，作為最大容量，用壓測開始之前的實(shí)際消耗值除以壓測獲取的最大容量，得到整個系統(tǒng)的消耗比。這個消耗比就認(rèn)為是當(dāng)前這個系統(tǒng)消耗的畫像。

壓測壓到什么情況下達(dá)到最大容量不能再壓呢？是要壓到服務(wù)器宕機(jī)？我們接入了另外一個概念叫消耗比，在耗時最大區(qū)間的Ahits（請求數(shù)量）數(shù)（PPT上顯示：慢速比=100.0*當(dāng)前容量（Ahits）/最大容量（max_Ahts））與總的請求數(shù)之比超過一定的比例，則是影響用戶的體現(xiàn)，這個壓力達(dá)到最大值就不能再壓了，就會記錄當(dāng)時的Ahit數(shù)，作為這個接口最大容量。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

4）分級治理：水位線

現(xiàn)在拿到了一個非常重要的容量值及消耗比來進(jìn)行容量評估，用于描述當(dāng)前的容量消耗情況。拿到這個消耗比之后是不是就可以擴(kuò)容了？還是可以縮容了？此處還需要一個評估標(biāo)準(zhǔn)，是30%就擴(kuò)？還是50%再擴(kuò)？

我們基于歷史數(shù)據(jù)給予分析，制定了三條水位線，包括安全線、警戒線和致命線，拿當(dāng)前消耗值與水位線進(jìn)行對比，在不同階段采取不同的措施。

比如，現(xiàn)在的消耗度遠(yuǎn)遠(yuǎn)低于安全線，說明現(xiàn)在服務(wù)器部署有冗余，我們可以進(jìn)行逐步的縮容。如果說現(xiàn)在已經(jīng)高于致命線，則需要擴(kuò)容，讓這個值更加接近安全線，保證系統(tǒng)的穩(wěn)定性。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

5）在線容量評估體系

現(xiàn)在自動擴(kuò)縮容三個要素，當(dāng)前消耗、水位線、容量決策系統(tǒng)都已經(jīng)具備了，我們?nèi)绾伟堰@三個點(diǎn)聯(lián)動起來？如何讓它串在一起完成擴(kuò)容動作？這些環(huán)節(jié)都包含在在線容量評估體系內(nèi)，這個體系可以實(shí)現(xiàn)壓測的過程。

我們剛才說了壓測不是通過流量拷貝進(jìn)行模擬測試的，我們是針對目標(biāo)服務(wù)，就用線上的流量，記錄當(dāng)前（Ahits）數(shù)，開始減少服務(wù)器的數(shù)量，一直到慢速比達(dá)到臨界值的時候，記錄Ahits數(shù)作為本服務(wù)單元最大的消耗，得到消耗值后和水位線進(jìn)行對比，調(diào)用決策系統(tǒng)做出是否擴(kuò)縮容的決定，接下來再對接云服務(wù)商，就完成了擴(kuò)容的動作。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

6）實(shí)時演練體系

前面進(jìn)行的數(shù)據(jù)采集、計算，以及動作的串聯(lián)，都是為了完成最后一個目標(biāo)，服務(wù)擴(kuò)容成功。

真正的服務(wù)器擴(kuò)容到線上之后，怎么樣才能保證服務(wù)是健康可用的呢？我們還有另外一套輔助系統(tǒng)叫擴(kuò)容演練。在實(shí)時演練過程中，要注意以下幾點(diǎn)：

①部署效率

我們通過擴(kuò)容演練來尋找整個擴(kuò)容過程中的瓶頸，比如，我們下發(fā)是通過DCP對接云服務(wù)商來完成擴(kuò)容的。

在真正的線上擴(kuò)容過程中，DCP有時要同時承載幾千臺節(jié)點(diǎn)的擴(kuò)容并發(fā)。DCP的效率是否能夠滿足？在擴(kuò)容演練過程中需要確認(rèn)這一點(diǎn)。

②帶寬限制

微博和云服務(wù)商之間確實(shí)是拉了專線，但是微博和云服務(wù)商不只是微博廣告的一個業(yè)務(wù)，還有很多其他大戶。

而且一般在流量增加的時候他們的擴(kuò)容也是非常猛烈的，所以帶寬是否可用，也是我們在日常演練過程中非常注意的現(xiàn)象。

③依賴服務(wù)

這方面有很多案例，在這里簡單分享一下，2015年春節(jié)，自動擴(kuò)縮容的流程才剛剛開始，春節(jié)當(dāng)天晚上我們擴(kuò)容完幾千個節(jié)點(diǎn)后，忽然發(fā)現(xiàn)負(fù)載均衡加不上去。

之前做過演練，但不會拿幾千臺云服務(wù)器進(jìn)行擴(kuò)容，可能幾十臺確保功能可用就可以了，到時候要讓負(fù)載均衡的同事通過配置文件增加下memeber就可以。如果上千臺的服務(wù)器沒有辦法增加到負(fù)載均衡設(shè)備，那個時候大家手忙腳亂，最后通過手動的方式擴(kuò)容節(jié)點(diǎn)。

大家知道春晚的流量高峰很短，但那天確實(shí)給了我們當(dāng)頭一棒。接下來我們在擴(kuò)容演練過程中，不僅會對負(fù)載均衡進(jìn)行確認(rèn)，還會對我們依賴的服務(wù)進(jìn)行確認(rèn)。比如每次發(fā)生熱點(diǎn)事件時，大家會說微博又崩了，評論又崩了，熱搜出不來了。其實(shí)應(yīng)對峰值流量是件很頭大的事情，我把事情解決了，兄弟部門沒有解決，兄弟部門解決了，姐妹部門又出現(xiàn)了問題。

④安全限制

618大促時，京東的同學(xué)分享了在擴(kuò)容的時候新增的服務(wù)器IP與VIP發(fā)生了沖突，而微博主要的體現(xiàn)就是數(shù)據(jù)庫會對很多業(yè)務(wù)的請求設(shè)置白名單，可是云服務(wù)器擴(kuò)容之后ip是隨機(jī)的。

圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT

另外，新浪對于通行證有很多IP限制，所以我們通過擴(kuò)容演練體系不斷發(fā)現(xiàn)各個環(huán)節(jié)中的問題，加以解決，保證在擴(kuò)容動作進(jìn)行時能夠順利地完成，保證擴(kuò)容出來的云主機(jī)真正安全上線服務(wù)。有了這個系統(tǒng)的加持，截止到現(xiàn)在自動擴(kuò)容服務(wù)都處于比較穩(wěn)定的狀態(tài)。