精細化容量管理的設備成本優化之路

版權聲明：本文由梁定安原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/224

來源：騰雲閣 https://www.qcloud.com/community

 

做者簡介:梁定安，現就任於騰訊社交網絡運營部，負責社交平臺、增值業務的運維負責人，開放運維聯盟專家委員，騰訊雲佈道師，騰訊課堂運維講師。

SNG社交網絡運營部管理着近10萬臺的Linux服務器，以此支撐着騰訊社交業務海量業務與用戶，如日活2.47億的QQ、月活5.96億的QQ空間（數據來源：騰訊2016Q2財報）等衆多千萬級在線的胖子業務。

面對業務體量的不斷增胖的社交類UGC業務，如何能既保證業務的發展，又能有效的控制運營成本的增加？是運維團隊迫在眉睫要解決的運營成本難題。通過不斷的探索和深挖，咱們慶幸在過去的2年中，找到了一條有效的設備成本管理的路子——精細化容量管理的設備成本優化之路，並連續2年，每一年爲公司節約過億的運營成本。

衆所周知，提高設備的使用率是運維界經常使用的管控運營成本的有效辦法，那麼如何可以針對不一樣的設備使用場景、不一樣的設備類型制定出適宜的度量與管理辦法呢？請看騰訊運維在實踐中總結出的6個方法：

方法1：性能管理法

在衡量服務器的使用合理性中，CPU使用率當仁不讓的成爲頭號被關注對象。隨着多核超線程技術CPU的普及，CPU負載不均的問題逐漸在海量運維場景下，成爲了設備運營成本的吞噬者。

爲了發現並優化多核CPU負載不均的現象，咱們提出了CPU極差的度量指標，
CPU（極差）=CPU（max）-CPU（min），若CPU（極差）>30%，則該設備存在CPU使用率不合理的問題，需優化整改。
（備註：優化方法可參考多隊列網卡優化與CPU親和，本文不展開）。

同理，在分佈式集羣的模塊容量管理中，運維規範要求實現模塊的一致性管理，包括容量一致性，爲此咱們一樣提出模塊的容量極差的度量指標，模塊CPU使用率極差= CPU最高的IP的CPU使用率 - CPU最低的設備的CPU使用率，若同模塊下不一樣設備的CPU使用率極差>30%，則該模塊容量使用不合理，須要優化整改。
（備註：通常此類狀況源於配置、權重、調度等不一致管理問題，不問不展開。）

方法2：密度管理法

對於內存使用的合理性，很難直接用內存使用率來度量，爲此，在內存型設備使用中，咱們提出了密度管理的管控辦法——訪問密度。訪問密度計算公式：，模塊下的設備內存訪問密度應該一致，不然歸入負載不均的一致性整改範疇。經過對全量內存型模塊訪問密度的統計分析，咱們能夠得出一條平均負載水平線，結合容量管理的實際須要，提升平均水平線或優化低於水平線的模塊，都能實現優化設備成本管理的目的。同時，密度管理法也適用於SSD盤的使用場景。（備註：訪問密度會受業務請求包大小的影響，可是在海量的運維場景下，個別狀況能夠忽略。）

方法3：特性管理法

特性管理法，同功能模塊的QPS管理相似，就是用來衡量在特定業務場景下，業務邏輯的處理性能是否最優，要結合不一樣產品下的同類應用場景的QPS同比來得出分析結論。這種管理辦法因業務邏輯而異，本文主要舉例說明下。

例如，在移動互聯網的業務運維場景中，有些場景是很是規容量管理手段能度量的，針對一些個性可是規模龐大的模塊，咱們提出了特性管理法。舉個例子，QQ、QQ空間、信鴿等業務都有長鏈接功能模塊，該場景的容量CPU少而使用內存多，所以可使用每G內存維持的長鏈接數量來橫向比較QQ、QQ空間、信鴿等業務，督促性能低的業務程序整改優化。

又例如，在直播場景中，有對主播視頻實時在線轉碼的需求，不一樣的開發可能使用的轉碼技術方案不一，也能夠利用一樣的特性管理法來衡量在線轉碼的性能是否有優化空間。

方法4：碎片管理法

騰訊社交網絡業務歷史悠久，從「大哥」QQ到「新秀」企鵝FM，業務類型覆蓋IM、UGC、多媒體、閱讀、動漫、遊戲、直播等主流的娛樂化社交玩法，其中有當紅的產品，也有長尾的產品；有幾十億次每秒功能模塊，也有幾十次每秒的功能模塊。碎片化管理法，就是針對請求量不高的小集羣準備的。由於分佈式高可用的運維要求，一般生產環境的部署最小單元都爲2臺設備，在物理機時代，訪問量小的模塊浪費成本嚴重，但隨着虛擬化技術的普遍應用，該場景遇到的問題迎刃而解。利用虛擬化技術將硬件資源碎片化，讓小模塊能夠很好的兼顧設備成本和高可用。

與虛擬化解決碎片資源利用率的方案相似，咱們還有PaaS平臺「蜂巢」，基於騰訊社交的標準開發框架SPP，解決小業務小模塊的容量管理難題。（後續專題聊蜂巢。）

方法5：木桶管理法

騰訊平臺級的業務，如QQ、QQ空間、QQ音樂等，基本上都普及了三地三活的SET（專區）容災架構能力，這是真正意義上的異地多活。（正巧在923上海運維大會的海量運維專場，會有個主題與異地容災的海量運維實踐分享，若是你們感興趣的話，誠邀你們參加。）對於平臺級業務的運維，咱們會根據運維規範管理的要求，將實現必定業務場景的多個模塊劃分爲SET（減小運維對象），在不一樣的社交場景下，咱們就得出了各類不一樣類型的SET，經過自動化運維能力擴大到SET的自動化運維能力，運維能很輕鬆的實現SET異地化部署，如此實現該業務場景異地多活的容災容錯。

再說SET的容量管理，平臺級SET就意味着用戶量和請求量不會暴增，那麼對於SET的可運維性而言，咱們必需要對SET的請求量和用戶量等指標進行量化度量。爲此，運維賦予SET一個可量化的指標，在咱們的場景下，如在線用戶數、核心請求量等視SET的用途而定，基於壓測能夠獲得單SET的最合理的容量值，該值符合木桶原理，也就是咱們的木桶管理法，SET由多個模塊組成（SET=木桶，模塊=木板），支撐必定的用戶量，SET的容量管理就像木桶原理同樣，木桶的水位高低取決於最短板，所以SET的最大容量取決於SET中性能最低的模塊容量。

騰訊的平臺級業務同時在線用戶數是相對穩定的，也就意味着全國要實現多地多活，須要準備多少冗餘容量是可預期可規劃的，換而言之，要部署的SET的數量是能被提早量化的。同時，結合業務的自動化部署、調度方案、柔性策略和有損服務能力，咱們就能夠利用很合理的成本就能實現異地多活。

舉例說明，假設咱們共有1000w的同時在線用戶，且用戶量相對穩定，咱們就能夠規劃3個支撐500w在線的SET，利用業務架構的調度能力分別讓3個SET的容量平均化，在災難場景時，1個SET不可用，另外兩個SET能夠徹底容災，在此規劃下，極端場景2個SET不可用是要開有損服務的。經過量化SET管理，業務運維則能夠靈活的根據成本管理的需求調整SET的容量水位，以達到最優性價比的高可用架構。

方法6：硬件選型法

關注硬件瓶頸，升級硬件下降單機運營成本。好比，過去作UGC內存存儲時（QQ相冊、視頻），使用了大量2T硬盤，當4T、8T硬盤成本量產使用，及時的升級硬盤容量，能夠有效的提高單機存儲量，以規模效應實現花小价格換來了大成本。又如，在圖片社交或視頻社交的業務場景下，因玩法的多樣性需求，會延伸出不少計算量繁重的邏輯，像人臉識別、鑑黃等功能，這時候選用GPU設備代替CPU設備，也是讓性能飛的一種有效作法。（該方法尤其適用於UGC類的存儲量只增不減的業務，如微雲、網盤、圖片存儲、視頻存儲等。）

後記：

包括但不限於上述6種容量管理的方法，使得咱們能在用戶數據只增不減社交UGC業務中，能穩步的可持續前行。設備成本管理還涉及不少細節的技術手段和業務代碼優化，本文只是從運維的視角闡述對容量管理的思考，但願可以拋磚引玉，對各位同行有幫助。帶寬成本管理的優化帶來的成本節省價值會更大，由於其中涉及的技術點和方法論更多，此文不深刻探討。