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