本文根據(jù)孫燕老師在《2019DAMS中國數(shù)據(jù)智能管理峰會》現(xiàn)場演講內(nèi)容整理而成。
講師介紹
孫燕，微博廣告基礎運維負責人，2009年入職新浪，任職10年間參與博客、圖片、視頻、微博平臺監(jiān)控、微博廣告多個產(chǎn)品運維，致力于運維自動化、產(chǎn)品架構(gòu)優(yōu)化、服務治理、智能監(jiān)控及以監(jiān)控為依托的服務容災建設。
1、為什么需要彈性計算
首先，在產(chǎn)品方面，我們的產(chǎn)品線很多，依賴關系比較復雜。
微博廣告相當于一個橋梁，左邊連接的是廣告主，右邊連接的是客戶，需要將廣告主的廣告計劃轉(zhuǎn)化為用戶的需求，讓用戶看到自己想要看的廣告。
為了滿足兩邊不同的需求，產(chǎn)品的變更和發(fā)布非常重要且頻繁。
其次，在運營方面，很多有推廣需求計劃的大型活動都有臨時擴容需要，比如618跟雙十一，對于我們而言這兩個活動帶來了很大的沖擊。
在618和雙十一大促之前，為了加大自己的影響力，各個廣告主會增加廣告計劃，微博廣告這邊再針對廣告主的行為加大我們的曝光量，實現(xiàn)廣告主廣告計劃的轉(zhuǎn)化。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
2、傳統(tǒng)的業(yè)務運維
按照傳統(tǒng)運維模式，擴容計劃從立項到服務器上線，會經(jīng)過諸多的流程跟漫長的等待。從結(jié)果上來看，服務器擴容了，而且對傳統(tǒng)項目而言，整體流程都是可控的，這是它的優(yōu)點。
它的缺點不言而喻，有以下幾點：
首先，它時效性太差，如果按照新浪服務器的采購周期，從審計到上線需要兩個月的流程。兩個月后服務器上線，恐怕剛結(jié)婚的明星都已經(jīng)離婚了，突發(fā)事件流量都已經(jīng)過去了。
另外，它無法準確預估容量，在傳統(tǒng)的業(yè)務運維模式下，范冰冰分手、雙宋離婚帶來的流量是無法實現(xiàn)的，我們無法評估擴容量。
除此之外，傳統(tǒng)模式下資源利用率比較低，服務器很難在業(yè)務間共享。
在這些問題共同作用下催生了動態(tài)擴縮容體系。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
3、彈性計算：實時動態(tài)擴縮容
動態(tài)擴縮容不是一個工具，是一整套體系。它基于云服務，包含了在線壓力檢測和消耗度評測的功能，最終實現(xiàn)分級治理。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
1）彈性計算架構(gòu)
首先簡單介紹一下彈性計算的架構(gòu)，彈性計算依托于Kunkka自動化運維平臺，以及Oops監(jiān)控平臺，在業(yè)務壓測的情況下獲取業(yè)務指標監(jiān)控，將數(shù)據(jù)送到容量決策系統(tǒng)，做出是否擴縮容的決定。
在云服務商方面，我們常用阿里云、華為云跟一部分自建的私有云。DCP混合平臺是我們微博另外一個團隊做了幾年的平臺，它能夠?qū)釉品眨焖偕稍浦鳈C快速擴容。今天的重點跟業(yè)務方有著最直接的關系：業(yè)務上要不要擴容？什么時候擴容？擴多少？我們要解決這樣的問題。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
2）決策系統(tǒng)
在上文的架構(gòu)中，我們提到了容量決策系統(tǒng)，容量決策系統(tǒng)實際上指的是計算系統(tǒng)，會對我們獲取到的業(yè)務指標進行計算、評估，比如系統(tǒng)的基礎信息、一些業(yè)務上日志來源的信息等，得到當前業(yè)務的容量，通過對歷史數(shù)據(jù)進行同比、環(huán)比的分析，得到流量趨勢，了解接下來流量會變成什么樣子，這兩組數(shù)據(jù)計算結(jié)果會給出擴縮容的建議。
同時，他們會計算這些數(shù)據(jù)并予以呈現(xiàn)，提供一個輔助的API接口，給上下游部門做擴縮容數(shù)據(jù)。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
3）容量評估方法
這個業(yè)務的當前容量是什么樣的？是不是健康的？這個指標靠什么來評估？
由于業(yè)務系統(tǒng)、業(yè)務形態(tài)、架構(gòu)的不同，選取一個實時且通用的指標是非常具有挑戰(zhàn)性的，我們也嘗試了很久，引入了AVG-hits的概念。
對于處在不同時間內(nèi)的請求數(shù)進行加權、求和來擬合實際的單機消耗量，這個代表的是在不同的區(qū)間的耗時數(shù)，我們給它一個系數(shù)，大于5毫秒小于10毫秒，根據(jù)自己的業(yè)務給予耗時分區(qū)，這樣就能計算出來。
事實證明，與之前傳統(tǒng)的單一QPS負載對比起來，綜合的數(shù)據(jù)對業(yè)務的評估比這種單一指標是更加準確的。
在獲得這個數(shù)據(jù)之后是不是就能夠描述當前的系統(tǒng)容量呢？
回答是肯定不能，AVG-hits這個概念第一次接觸，確實是有點生澀，舉個簡單的例子來幫助理解，比如說某個業(yè)務消耗指標衡量非常簡單，需要通過內(nèi)存判斷消耗情況。
如果監(jiān)控指標提示內(nèi)存消耗到80G，那能不能用80G來描述當前系統(tǒng)的消耗情況？這樣問就比較容易理解，回答肯定是不能的，因為不知道服務器最大的內(nèi)存是多少，如果最大是96G，那么80G已經(jīng)超過80%了，接近危險值，如果最大內(nèi)存是256G則消耗不到30%，是非常安全的值。
道理是一樣的，僅拿到當前消耗值是不能對業(yè)務當前狀態(tài)進行描述的，還需要另一個評估標準。這個業(yè)務當前能承載的最大容量是多少？如果是看內(nèi)存就簡單了，可這是一個綜合評估標準，要怎么拿到它呢？
作為一個有經(jīng)驗的運維，我覺得根據(jù)服務器當前硬件的表現(xiàn)，猜測最大容量不是困難的事情，但現(xiàn)在都2019年了，靠猜是不行的，我們通過壓測獲取最大容量值。
在實際環(huán)境中減少服務器數(shù)量，減少到不能再少，記錄當前的容量值，作為最大容量，用壓測開始之前的實際消耗值除以壓測獲取的最大容量，得到整個系統(tǒng)的消耗比。這個消耗比就認為是當前這個系統(tǒng)消耗的畫像。
壓測壓到什么情況下達到最大容量不能再壓呢？是要壓到服務器宕機？我們接入了另外一個概念叫消耗比，在耗時最大區(qū)間的Ahits（請求數(shù)量）數(shù)（PPT上顯示：慢速比=100.0*當前容量（Ahits）/最大容量（max_Ahts））與總的請求數(shù)之比超過一定的比例，則是影響用戶的體現(xiàn)，這個壓力達到最大值就不能再壓了，就會記錄當時的Ahit數(shù)，作為這個接口最大容量。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
4）分級治理：水位線
現(xiàn)在拿到了一個非常重要的容量值及消耗比來進行容量評估，用于描述當前的容量消耗情況。拿到這個消耗比之后是不是就可以擴容了？還是可以縮容了？此處還需要一個評估標準，是30%就擴？還是50%再擴？
我們基于歷史數(shù)據(jù)給予分析，制定了三條水位線，包括安全線、警戒線和致命線，拿當前消耗值與水位線進行對比，在不同階段采取不同的措施。
比如，現(xiàn)在的消耗度遠遠低于安全線，說明現(xiàn)在服務器部署有冗余，我們可以進行逐步的縮容。如果說現(xiàn)在已經(jīng)高于致命線，則需要擴容，讓這個值更加接近安全線，保證系統(tǒng)的穩(wěn)定性。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
5）在線容量評估體系
現(xiàn)在自動擴縮容三個要素，當前消耗、水位線、容量決策系統(tǒng)都已經(jīng)具備了，我們?nèi)绾伟堰@三個點聯(lián)動起來？如何讓它串在一起完成擴容動作？這些環(huán)節(jié)都包含在在線容量評估體系內(nèi)，這個體系可以實現(xiàn)壓測的過程。
我們剛才說了壓測不是通過流量拷貝進行模擬測試的，我們是針對目標服務，就用線上的流量，記錄當前（Ahits）數(shù)，開始減少服務器的數(shù)量，一直到慢速比達到臨界值的時候，記錄Ahits數(shù)作為本服務單元最大的消耗，得到消耗值后和水位線進行對比，調(diào)用決策系統(tǒng)做出是否擴縮容的決定，接下來再對接云服務商，就完成了擴容的動作。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
6）實時演練體系
前面進行的數(shù)據(jù)采集、計算，以及動作的串聯(lián)，都是為了完成最后一個目標，服務擴容成功。
真正的服務器擴容到線上之后，怎么樣才能保證服務是健康可用的呢？我們還有另外一套輔助系統(tǒng)叫擴容演練。在實時演練過程中，要注意以下幾點：
①部署效率
我們通過擴容演練來尋找整個擴容過程中的瓶頸，比如，我們下發(fā)是通過DCP對接云服務商來完成擴容的。
在真正的線上擴容過程中，DCP有時要同時承載幾千臺節(jié)點的擴容并發(fā)。DCP的效率是否能夠滿足？在擴容演練過程中需要確認這一點。
②帶寬限制
微博和云服務商之間確實是拉了專線，但是微博和云服務商不只是微博廣告的一個業(yè)務，還有很多其他大戶。
而且一般在流量增加的時候他們的擴容也是非常猛烈的，所以帶寬是否可用，也是我們在日常演練過程中非常注意的現(xiàn)象。
③依賴服務
這方面有很多案例，在這里簡單分享一下，2015年春節(jié)，自動擴縮容的流程才剛剛開始，春節(jié)當天晚上我們擴容完幾千個節(jié)點后，忽然發(fā)現(xiàn)負載均衡加不上去。
之前做過演練，但不會拿幾千臺云服務器進行擴容，可能幾十臺確保功能可用就可以了，到時候要讓負載均衡的同事通過配置文件增加下memeber就可以。如果上千臺的服務器沒有辦法增加到負載均衡設備，那個時候大家手忙腳亂，最后通過手動的方式擴容節(jié)點。
大家知道春晚的流量高峰很短，但那天確實給了我們當頭一棒。接下來我們在擴容演練過程中，不僅會對負載均衡進行確認，還會對我們依賴的服務進行確認。比如每次發(fā)生熱點事件時，大家會說微博又崩了，評論又崩了，熱搜出不來了。其實應對峰值流量是件很頭大的事情，我把事情解決了，兄弟部門沒有解決，兄弟部門解決了，姐妹部門又出現(xiàn)了問題。
④安全限制
618大促時，京東的同學分享了在擴容的時候新增的服務器IP與VIP發(fā)生了沖突，而微博主要的體現(xiàn)就是數(shù)據(jù)庫會對很多業(yè)務的請求設置白名單，可是云服務器擴容之后ip是隨機的。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
另外，新浪對于通行證有很多IP限制，所以我們通過擴容演練體系不斷發(fā)現(xiàn)各個環(huán)節(jié)中的問題，加以解決，保證在擴容動作進行時能夠順利地完成，保證擴容出來的云主機真正安全上線服務。有了這個系統(tǒng)的加持，截止到現(xiàn)在自動擴容服務都處于比較穩(wěn)定的狀態(tài)。
我們立即與您溝通
營銷產(chǎn)品
旗下平臺
聯(lián)系我們
關注天擎天拓
