1、背景

隨著轉(zhuǎn)轉(zhuǎn)業(yè)務(wù)的不斷發(fā)展和用戶不斷增長，公司持續(xù)增加對(duì)硬件和基礎(chǔ)設(shè)施的投入，用于滿足業(yè)務(wù)發(fā)展的需要，然而資源的使用率卻逐步下降。因?yàn)樽畛醯哪繕?biāo)是發(fā)展業(yè)務(wù)，實(shí)現(xiàn)功能，隨著業(yè)務(wù)的發(fā)展成熟，逐步更加關(guān)注服務(wù)的穩(wěn)定性，性能、冗余、災(zāi)備等方案，這樣更會(huì)增加資源成本。那么如何在保障服務(wù)質(zhì)量和確保服務(wù)性能的前提下，同時(shí)降低運(yùn)營成本提高資源利用率呢？容量管理就是其中必不可少的一環(huán)。

2、容量管理的目標(biāo)

在解釋容量管理目標(biāo)之前，先來看一下容量管理的含義。

百度百科的定義：容量管理致力于在恰當(dāng)?shù)臅r(shí)間以一種經(jīng)濟(jì)節(jié)約的方式為數(shù)據(jù)處理和存儲(chǔ)提供所需的容量。

在我看來，容量管理的本質(zhì)是風(fēng)險(xiǎn)和成本之間的平衡，即在保障業(yè)務(wù)服務(wù)穩(wěn)定的前提下，以最低的成本保證最優(yōu)的服務(wù)質(zhì)量。所以容量管理的目標(biāo)有兩點(diǎn)：

• 成本控制：容量管理保證服務(wù)的容量和性能以最節(jié)約成本的方式滿足既定業(yè)務(wù)需求，并對(duì)資源進(jìn)行最有效的使用。
• 業(yè)務(wù)支撐：容量管理結(jié)合當(dāng)前服務(wù)質(zhì)量（SLA），保證服務(wù)提供連續(xù)的服務(wù)水平;容量管理結(jié)合容量規(guī)劃，指導(dǎo)業(yè)務(wù)規(guī)劃所需的費(fèi)用成本規(guī)劃和調(diào)整。

3、發(fā)展階段

轉(zhuǎn)轉(zhuǎn)的服務(wù)容量管理主要經(jīng)歷了3個(gè)階段。

• 第一階段：無容量管理，服務(wù)全部混合部署到物理機(jī)和KVM虛擬機(jī)上，單臺(tái)設(shè)備運(yùn)行幾十個(gè)服務(wù)，物理資源共享，造成服務(wù)間的互相影響。
• 第二階段：分析服務(wù)的可用性和性能數(shù)據(jù)配合運(yùn)維的服務(wù)管理經(jīng)驗(yàn)來降低服務(wù)混部比例，下線KVM虛擬機(jī)，調(diào)整服務(wù)配置，提升資源利用率，從而減少服務(wù)器數(shù)量，達(dá)到降低服務(wù)資源成本的目標(biāo)。
• 第三階段：隨著服務(wù)穩(wěn)定性和性能指標(biāo)數(shù)據(jù)的不斷完善，服務(wù)進(jìn)入云時(shí)代，加之壓測(cè)標(biāo)準(zhǔn)和資源利用率標(biāo)準(zhǔn)的制定，進(jìn)步一完善了容量管理的基礎(chǔ)，成本和服務(wù)質(zhì)量得到了有效的平衡。

第二階段完成后，IT相關(guān)資源成本節(jié)約了約50%，第三階段相較于第二階段，IT相關(guān)資源成本進(jìn)一步降低約50%。對(duì)于公司的降本增效的目標(biāo)起到了關(guān)鍵性作用。那么下面我們講講具體怎么做到這樣的成果的。

4 容量管理

4.1 容量水位

容量水位是當(dāng)前實(shí)際消耗的資源（包括裸金屬物理機(jī)、云資源和其他依賴的SaaS服務(wù)）占用當(dāng)前總體可用資源的比例。例如，B服務(wù)有4個(gè)云實(shí)例，但實(shí)際上只使用了2個(gè)云實(shí)例，另兩個(gè)實(shí)例并未加入分組提供線上服務(wù)，所以該服務(wù)的資源使用率只有50%，故當(dāng)前的容量水位是50%。只有獲取當(dāng)前的容量水位，才可以依此進(jìn)行各種判斷和規(guī)劃。后續(xù)進(jìn)行容量分析時(shí)也是基于容量水位的元數(shù)據(jù)進(jìn)行多維度數(shù)據(jù)整合分析并進(jìn)一步優(yōu)化。服務(wù)容量水位所需要收集的元數(shù)據(jù)如下表：

云主機(jī)：

• CPU
• 內(nèi)存
• 磁盤
• 網(wǎng)卡

應(yīng)用服務(wù)：

• JVM內(nèi)存
• 應(yīng)用線程
• GC頻率
• QPS
• 響應(yīng)時(shí)間

如下圖所示，可以看出，對(duì)于轉(zhuǎn)轉(zhuǎn)的用戶習(xí)慣，訪問量分布基本是在白天，晚上20:00-23:00用戶訪問量會(huì)逐步增加達(dá)到高峰。我們更要關(guān)注的是這個(gè)時(shí)間點(diǎn)上業(yè)務(wù)服務(wù)的容量是否能支撐系統(tǒng)的穩(wěn)定運(yùn)行，后續(xù)的容量規(guī)劃也需要按這個(gè)峰值的對(duì)應(yīng)的容量水位來估算。

4.2 資源容量優(yōu)化

了解了容量水位后再對(duì)比我們線上服務(wù)的資源使用情況發(fā)現(xiàn)很多的資源浪費(fèi)是容量水位偏低造成的。每月服務(wù)相關(guān)資源的費(fèi)用也是一個(gè)不小的數(shù)字，此時(shí)容量優(yōu)化的意義和價(jià)值就會(huì)凸顯出來，這也是我們第二階段和第三階段做的事。

1、服務(wù)配置縮減 A服務(wù)CPU為4核，內(nèi)存為8G。如下圖所示，單日最高CPU使用率為8%（上限400%），內(nèi)存使用率72%，在保證服務(wù)資源冗余30%的情況下，我們會(huì)把服務(wù)的CPU配置縮減為2核。

B服務(wù)容器內(nèi)存為8G，根據(jù)內(nèi)存公式，服務(wù)的JVM內(nèi)存為6G，此時(shí)容器內(nèi)存縮減到7G比較合理（由于業(yè)務(wù)場(chǎng)景不同，對(duì)于內(nèi)存的使用需結(jié)合業(yè)務(wù)需要調(diào)整，避免引起GC異?；騉OM）。

• 內(nèi)存公式

JVM總內(nèi)存 = heap 內(nèi)存 + 線程stack內(nèi)存 (XSS) * 線程數(shù) + 啟動(dòng)開銷（constant overhead）

2、混合部署/策略

• 在線業(yè)務(wù)和離線業(yè)務(wù)混合部署，晚間業(yè)務(wù)低峰期開啟離線業(yè)務(wù)計(jì)算任務(wù)，有效地利用CPU，實(shí)現(xiàn)峰谷輪動(dòng)。
• 把低等級(jí)負(fù)載較低的服務(wù)或?qū)Ψ?wù)可用性要求不高的服務(wù)與高等級(jí)或容量水位高的業(yè)務(wù)服務(wù)進(jìn)行混合部署，充分地利用硬件或云主機(jī)資源。

例如：A服務(wù)是管理后臺(tái)服務(wù)，資源利用率約為10%；B服務(wù)為搜索服務(wù)，資源利用率約為40%，我們把兩個(gè)服務(wù)混合部署，充分利用主機(jī)資源。

4.3 集群容量

單純的依靠容量水位去評(píng)估服務(wù)容量只是利用服務(wù)管理經(jīng)驗(yàn)的服務(wù)監(jiān)控?cái)?shù)據(jù)控制資源成本。更精確更合理的方案是利用壓測(cè)結(jié)合容量水位確定服務(wù)集群的準(zhǔn)確容量。獲取集群容量的方式通常有兩種，一種是通過日志回放，模擬線上流量對(duì)單實(shí)例壓測(cè)或者通過TCP-Copy的方式，把線上機(jī)器的流量拷貝對(duì)單實(shí)例進(jìn)行壓測(cè),轉(zhuǎn)轉(zhuǎn)初期就是使用這種方式壓測(cè)。另一種是對(duì)整個(gè)集群進(jìn)行壓測(cè)，通過獲取集群的最大容量，再除以集群內(nèi)實(shí)例數(shù)量來獲取服務(wù)單實(shí)例容量。從經(jīng)驗(yàn)和數(shù)據(jù)來看，采用集群壓測(cè)的方式更適合一些，因?yàn)檫@種方式完全使用線上真實(shí)業(yè)務(wù)場(chǎng)景進(jìn)行壓測(cè)，獲取的數(shù)值更準(zhǔn)確。所以我們現(xiàn)在的單實(shí)例容量都是通過集群壓測(cè)的方式獲得。

4.4 壓測(cè)指標(biāo)

壓測(cè)指標(biāo)通常關(guān)注兩類指標(biāo)，一是系統(tǒng)類指標(biāo)，二是服務(wù)類指標(biāo)。

類指標(biāo)。：

• CPU使用率
• 內(nèi)存使用率
• 磁盤I/O使用率
• 網(wǎng)卡帶寬

服務(wù)指標(biāo)：

• 接口響應(yīng)耗時(shí)
• 耗時(shí)分位
• 錯(cuò)誤率
• 慢速比

4.5 壓測(cè)標(biāo)準(zhǔn)

通常情況下，資源使用率并不簡單地等于CPU利用率、CPU負(fù)載，也包括內(nèi)存、I/O、服務(wù)相關(guān)配置不合理造成的瓶頸等等。所有這些資源的瓶頸最終都會(huì)表現(xiàn)為響應(yīng)時(shí)間和錯(cuò)誤率的增加，所以不論服務(wù)有多少資源，我們需要找到一個(gè)觸及系統(tǒng)資源瓶頸的臨界點(diǎn)（如下圖所示），在這個(gè)點(diǎn)之前，應(yīng)用的性能表現(xiàn)和訪問量是呈線性關(guān)系的，一旦訪問量超過這個(gè)臨界點(diǎn)，應(yīng)用的性能就會(huì)明顯下降。基于此，我們壓測(cè)的標(biāo)準(zhǔn)如下：

Error%（錯(cuò)誤率）：

• A級(jí)服務(wù)壓測(cè)請(qǐng)求錯(cuò)誤比例<= 1%。
• B級(jí)服務(wù)壓測(cè)請(qǐng)求錯(cuò)誤比例<= 3%。
• C級(jí)、D級(jí)、E級(jí)服務(wù)壓測(cè)請(qǐng)求錯(cuò)誤比例<= 5%。

Response Times（響應(yīng)時(shí)間）：

• Median（中位數(shù)）：50%響應(yīng)耗時(shí)不超過服務(wù)平均耗時(shí)（Average）2倍。
• 90th pct：90%響應(yīng)耗時(shí)不能超過服務(wù)平均耗時(shí)（Average）5倍。
• 99th pct：99%響應(yīng)耗時(shí)與90%響應(yīng)耗時(shí)差值>=2倍，注意分析耗時(shí)長的接口慢的原因。

這個(gè)標(biāo)準(zhǔn)中可以看出，響應(yīng)耗時(shí)方面，我們對(duì)于不同的百分位請(qǐng)求耗時(shí)有著不同的要求。比如A服務(wù)的壓測(cè)QPS為1000，TP50為100ms，TP90為300ms，TP99為800ms，很明顯服務(wù)的長耗時(shí)比較多，服務(wù)的性能下降嚴(yán)重，此時(shí)的壓測(cè)數(shù)據(jù)并不能代表服務(wù)的真實(shí)容量。所以我們基于現(xiàn)有的服務(wù)耗時(shí)數(shù)據(jù)結(jié)合服務(wù)性能目標(biāo)，對(duì)服務(wù)的響應(yīng)耗時(shí)規(guī)定了明確的浮動(dòng)范圍。

壓測(cè)目標(biāo)值配置和達(dá)標(biāo)報(bào)告示例:

壓測(cè)獲取的服務(wù)容量數(shù)據(jù)會(huì)統(tǒng)一記錄到服務(wù)信息管理平臺(tái)。

5、擴(kuò)容、縮容

如下圖：基于服務(wù)容量數(shù)據(jù)，在公司的促銷活動(dòng)中，我們實(shí)現(xiàn)了定時(shí)擴(kuò)縮容功能；對(duì)于日常服務(wù)質(zhì)量保障，我們將利用服務(wù)容量數(shù)據(jù)實(shí)現(xiàn)服務(wù)容量彈性伸縮功能。

隨著日常服務(wù)壓測(cè)的流程和規(guī)范不斷完善，服務(wù)的容量數(shù)據(jù)也日趨完善，這些數(shù)據(jù)不僅對(duì)服務(wù)的擴(kuò)縮起到指導(dǎo)作用，更是對(duì)服務(wù)穩(wěn)定性提供了保障。

6、總結(jié)

容量管理是一個(gè)復(fù)雜的系統(tǒng)工程，方式和方法多樣。不僅要在策略、方法、方式上進(jìn)行定義、明確和落地，還需要在規(guī)范、流程上不斷細(xì)化和完善，這樣才能達(dá)到降本增效的目的。同時(shí)容量管理的重要性不言而喻，它是服務(wù)穩(wěn)定性保障、資源成本控制的基石。隨著智能化運(yùn)維技術(shù)的逐漸成熟，我們要朝著更低的成本更優(yōu)的質(zhì)量目標(biāo)前進(jìn)。

關(guān)于作者

張磊，轉(zhuǎn)轉(zhuǎn)應(yīng)用運(yùn)維負(fù)責(zé)人。主要負(fù)責(zé)業(yè)務(wù)系統(tǒng)的可用性、性能、容量、運(yùn)維自動(dòng)化平臺(tái)等SRE體系建設(shè)。