B站容量管理:遊戲賽事等大型活動資源如何快速提升10+倍?

語言: CN / TW / HK

一分鐘精華速覽

當成千上萬的服務器都處於低利用率時,就意味着鉅額的浪費,良好的容量管理可以幫助消除某些“最後時刻”的臨時應急式的盲目或者超量採購。除了成本合理控制方面,容量管理還要預估對客户可能產生影響的業務發展和風險變化。

B站在降本增效大背景下,從業務視角對整體容量做了可視化管理,本文詳細描述了其容量管理的背景、思路及成效。 file

作者介紹 file 嗶哩嗶哩資深SRE專家 張鶴

TakinTalks社區專家團成員,2020年加入B站,先後負責主站/直播/OGV/推廣搜相關的SRE工作。深度參與多活、活動保障、混沌工程、容量治理相關的建設,並主導容量管理平台、混沌平台的架構設計和落地。曾負責B站S賽、跨年晚會、拜年祭等相關活動的基礎架構保障工作,目前主要負責推廣搜業務的穩定性建設、PaaS治理。

温馨提醒:本文約4500字,預計花費9分鐘閲讀。

後台回覆 “交流” 進入讀者交流羣;回覆“2252”獲取課件資料;

背景

對於B站來講,我們最大的三個活動是S賽、拜年紀、B站跨年晚會。在用户增長的背後,SRE團隊做了非常多的事情來保障業務連續性,比如多活、混沌工程等等。

今天換個角度聊聊——“容量管理”,B站為什麼要做容量管理的平台?我們的容量管理體系是怎麼設計的?平台側和業務側我們是如何去運營、讓工作變得“可視化”的?我也將結合容量管理平台在S12賽事中的實際應用,來分享“賦能業務”的一些經驗。

一、為什麼B站要做容量管理?

在做容量管理之前,B站面臨了幾個很明顯的痛點,如下圖所示。

file 除了需要解決未知的容量風險,在提倡“降本增效”的大背景下,提高資源利用率,制定合理的、有數據支撐的預算決策也非常重要。

而此前,B站在大型活動中的容量決策,比如S9、S10等,並沒有沉澱下來可供S12參考的相關數據,系統本身容量是否足夠、是否需要擴容、應該擴容多少等等,少有容量數據支撐。另外,全年的預算制定也迫切需要參考容量數據。

二、B站容量體系是如何設計的?

2.1 不同角色的訴求

基於上述的痛點,我們計劃做整個容量體系的設計,其中不同的角色關注的流量指標其實不太一樣。比如:

研發部門:關注是否有足夠資源,能擴容、能發佈即可。級別比較高的研發Leader可能更關注整個部門的資源使用率、部門的成本是否合理等;

平台:更關注平台的售賣率、資源Buffer、資源使用率,以及其他降本增效的工作;

SRE:核心關注穩定性,還需要提升總體資源的使用率,實現降本增效的大目標;

成本部門:更關注賬單、成本、預算、資源使用量等,即節省整體費用。

2.2 容量體系整體設計

file 從下往上看,最下層主要是基礎數據(基礎容量),比如機器、資源池等偏向雲底層的層面。SRE和平台更多要感知到集羣的容量、資源池的容量等到底怎麼樣,無論資源池如何超賣或者調控,前提是整體底層的資源使用一定要在安全水位。

在基礎容量之上,我們構建了一套基VPA的伸縮策略,以及基於HPA 的彈性擴縮實例的策略。還和業務的資源池做了合池,合池後可能就會面臨一個問題,即都在一個大池子裏,如何控制每個業務方使用的資源?此時,就需要基於業務做配額管理,即管控每個業務能使用多少資源。

在更上層,我們還提供了一套容量可視化以及可運營的數據,提供給業務做支撐,提高業務團隊的效率,包括基於業務部門的組織容量、容量事件等,比如容量運營週報,將不同的部門的使用率公開排名,根據數據提供優化建議等,這部分我將在後面詳細地介紹。

三、容量運營與可視化如何幫助業務解決問題?

3.1 基礎容量

基礎容量是整個容量體系的基礎,上文提到基礎容量我們更關注集羣、資源池、 node 以及一些應用維度的容量報表,如下圖所示。

file

集羣:關注集羣容量水位和超賣率;

資源池:關注資源池容量水位、超賣率、資源宂餘度。資源使用率決定了我們是否需要及時採買機器、判斷是否能承載更多業務;

Node:關注Node資源水位、Node超賣率,因為超賣會有熱點帶來的壓力,所以對Node做了使用率相關的報表;

應用:關注使用量、使用率、實例數、單實例容器數等。業務比較關注應用層面的數據的,比如,服務是否是單點的,因為單點代表如果一台物理機掛了,恰巧服務在這台物理機上,此時服務會短暫不可用,對於核心業務來説是不能被接受的。

file

基於這些指標,我們做了一些可視化的界面,與對外監控系統 Grafana 數據默認存儲 2 周不同的是,我們整個容量平台的數據是持久存儲的,目前已存儲接近兩年的數據。

3.2 業務組織容量

file

在降本增效的背景下,如何幫助業務去解決問題?業務側一般更關注如何找出哪些服務佔用了較多容量、哪塊業務的資源使用率比較低可以縮容、成本突增或者使用突然增多到底是哪個業務導致的、業務治理或者架構整合後到底治理效果如何等等,需要比較直觀的界面,能幫他們瞭解全局。

所以基於以上幾點,我們做了基於業務組織的容量報表,如下圖所示。

file

以B站直播業務為例,直播作為一個大部門,假設整體容量使用率是 40%,想要提高使用率,通過直觀的可視化報表可以看到直播大部門下,分支業務例如營收,會有送禮、抽獎之類的服務,發現其資源較多且使用率低時,業務團隊就能依據可視化報表的信息,提前做治理從而獲得更多的收益。

file

同時,能夠基於趨勢圖,看到直播業務下哪些業務突然佔用了較大容量,比如新業務場景、研發或者業務突然擴容等,並且支持數據下鑽,可以下鑽到營收業務下,瞭解到底是抽獎還是送禮業務引起的變化。

3.3 容量事件

從事件源上看,能引起容量變化的事件有很多,其中包括髮布平台/HPA變更平台/Node管理,在發佈平台裏,研發可以擴容或新增服務,以及修改容量配置等,所以發佈平台會導致容量的變化。另外,HPA擴縮容、Node物理機新增或刪除等,也會導致容量的變化。

所以我們內部對接了各種容量變更的平台,做了容量事件相關的能力,當一個業務發現整體資源使用變化很多,此時能通過容量事件快速定位事件源,及時感知容量風險,並追溯容量變化的根因。

file

3.4 容量週報

容量每週都在發生變化,所以我們平台做了週報的分析,從成本、效率、風險這三個核心出發,業務部門和平台方的週報關注點差異較大。

file

3.4.1 部門容量週報(業務側)

業務側週報核心關注以下4點——

**整體資源容量,資源使用率,環比上週變化。**即和上週比較,資源使用率增加或減少了多少。

應用容量Top。即哪些應用佔用了較多資源,方便業務快速感知大頭資源,提高降本優化效率。

**風險應用Top(優先展示L0/L1應用)。**本部門是否有風險較大的應用,如有使用率較高的核心服務,可以提前擴容。

**一週容量變化應用Top。**即新增了哪些服務、哪些服務做了擴縮容、下線了哪些服務等,做到一目瞭然。

file (外部週報展示--部門main整體資源利用率)

3.4.2 內部週報(平台側)

平台側週報核心關注以下2點——

部門資源使用率及排名,部門容量Top; 部門資源空閒率Top(大於5000核部門)。

通過公開排名,瞭解哪些業務的容量治理較弱,並優先治理。同時,由於其資源使用量較大,優先對其做治理,平台也將得到更大的治理收益。 file (內部週報展示--整體資源利用率)

3.5 容量巡檢

不管是在活動大促,還是在日常業務穩定性保障中,我們都需要密切關注整體容量是否存在風險,所以有了容量巡檢體系。

3.5.1 業務類巡檢

根據業務側關注的2個方面——應用容量巡檢、配額巡檢,我們做了可視化展示。

應用峯值使用率較高的,會有穩定性風險,需要考慮緊急擴容;而應用使用率較低的,則要考慮是否可以縮容以節省資源。

file

前面講到我們做了合池,那麼需要關注合池後配額使用率過高的情況,避免導致後續擴容或新增業務無法滿足,提前發現風險並做治理。

3.5.2 平台類巡檢

平台更關注底層的使用率情況,可調度實例數是否滿足後續的業務需求,以及資源池是否是單節點等等。同時,因為平台覆蓋了 VPA,那麼VPA 調整完後的失敗率也是平台比較關注的。

基於此,我們做了平台巡檢大盤、資源池巡檢管理、VPA巡檢管理等等。在巡檢大盤中,對風險資源池/空閒資源池Top、風險應用Top、風險配額Top等做了相應展示。

file

3.6 容量管理的業務價值

file

容量管理落地後,我們可以直觀看到整體工作對業務帶來的幫助,比如容量資源導致的發佈問題減少80%、容量問題導致的線上故障降低90%等等。從這個角度來看,業務部門並非是在配合平台做容量管理,而是大家共同在為最終的業務目標努力,能確保容量管理落實好後,業務的訴求得到更快響應,穩定性也能得到較大提升。

四、容量管理是如何支撐S12賽事的?

前面我們講的是平台側的能力、業務側的需求,接下來,我將以剛過去的B站大型賽事S12為例,具體闡述容量管理平台在具體業務場景中的應用。

4.1 S12活動節奏

file

4.2 S12賽前容量預估

S12賽前的容量預估主要分為三大步。

第一步,參考歷史基礎容量數據,計算容量delta

無論S賽事還是跨年晚會,B站多年來的大型活動,沉澱了一些歷史數據可作參考,基於歷史數據可以計算出增量。

舉個例子,S11 在11月舉行總結賽,活動保障啟動在8月,拿8月的使用量a和S11峯值使用量b做比較,並根據delta = 1 + (b-a) / a,來算出S11當年的增量係數,比如1.3、1.5等。

第二步,S12新增場景,預估增量

考慮到S12在原有基礎上,會有一些新增場景,此時需要在業務目標明確後,將其轉化成技術目標,技術目標再去轉化為容量需求,得到一個預估的增量d。

第三步,S12容量預估,得到資源缺口

在資源準備中,額外buffer通常是10%~20%。總容量的預估,可以根據S12當前8月的使用量e和buffer來推算,公式參考如下:

容量預估=(e * delta + d ) * (1 + buffer )

這部分預估的容量,減去當前的總資源存量,即可得到整體的資源缺口,並以此為依據進行容量調整。

4.3 S12的PaaS合池

4.3.1 合池前後對比

在合池之前,各塊物理資源池相對獨立,如下圖所示,漫畫業務的整體資源使用率最低,而直播可能已接近飽和,此時由於直播是完全獨立的物理資源池,漫畫和電商業務的空閒資源無法被利用。在往年,例如S11時期,就需要採購資源或臨時從雲上新增資源來支撐整個活動。

file

S12賽前,我們把諸如漫畫、電商、直播等的在線類微服務合池完後,業務不再需要關心總體的物理資源池,即只需關心自身業務邏輯配額的使用率,而非底層的分配率或使用率。在物理層面有在線統一物理資源池,底層的分配率、使用率完全由 SRE 和平台來保證。

4.3.2 合池可能風險

合池後可能會面臨一些不穩定因素,比如,不同的資源池或不同的業務,其內核版本可能有差異,所以我們做了整體物理層的標準化,統一內核以及去CPUSET化,通過底層的 VPA 策略動態調整整體資源使用。

4.4 S12的配額管理

由於合池後的每個業務都共用一個資源池,所以各業務的資源配額需要做到細分管理,避免資源被無限度使用。這裏我們通過容量管理平台進行管理,容量配額下發邏輯如下圖所示。

file

配額是基於組織數來下發的,比如某個組織能使用多少配額,策略下發後會作用在規則引擎上,業務變更時,比如要做發版前,會先在規則平台上了解對應業務的配額是否足夠做發版,若資源不夠,則會提醒配額不足,此時需聯繫 SRE 調整配額或者進行配額治理。以此我們就能做到配額管控,保證整個資源池不會被亂用。

4.5 S12的容量支撐

整個 S12 賽事期間,容量支撐可以大致分為四個方面——HPA、VPA、彈性上雲、容量巡檢,如下圖所示。 file

4.6 S12的容量監控大盤

對於S12賽事活動保障,整體關注的核心指標有業務指標、SLO、資源飽和度,容量監控大盤能根據核心指標,幫助更快地定位潛在風險點,並快速做決策。

file

首先是業務指標,S12我們比較關注直播間在線人數,如超過1000萬、2000萬等等。當賽事期間的整體流量增加,點播業務也會被影響,所以點播在線人數也是我們關注的業務指標之一。

其次是SLO,SRE團隊會更關注核心接口的QPS,以及吞吐、延遲、錯誤率等。

最後是資源飽和度,包括核心服務飽和度、核心中間件飽和度等。

五、未來規劃

5.1 容量風控

我們發現有一些服務的容量變更操作缺乏依據,比如想當然地做縮容,沒有指標去提示或驗證,很有可能導致服務故障。所以我們會做容量風控相關的攔截策略,基於容量畫像、應用羣包,去做到容量變更風險控制。

5.2 彈性伸縮

第一塊是分時調度。B站有些小活動比如漫畫業務,基本是在夜間有1個小時左右的峯值流量,其他時間點都是正常的流量。加入分時調度後,比如夜間0-1點的活動,我們就可以在23點前提前做好擴容,活動結束後完成縮容。 第二塊是彈性預測。一方面是能夠預測有規律的流量壓力並提前擴容,另一方面如果監控系統掛了,彈性的預測數據也可以作為監控數據的兜底。

5.3 熱點打散

我們是基於軟限調度,同時軟限也基於 VPA 做了調整,但仍難避免有些服務在物理機上會有熱點,所以我們將基於物理機去做二次調度等工作。(全文完)

file file

添加助理小姐姐(shulie888),憑截圖免費領取以上所有資料

並免費加入「TakinTalks讀者交流羣」

聲明:本文由公眾號「TakinTalks穩定性社區」聯合社區專家共同原創撰寫,如需轉載,請後台回覆“轉載”獲得授權。

本文由博客一文多發平台 OpenWrite 發佈!