轉轉微服務容量管理實踐

作者：張磊 2023-02-08 09:42:30

容量管理是一個復雜的系統工程，方式和方法多樣。不僅要在策略、方法、方式上進行定義、明確和落地，還需要在規范、流程上不斷細化和完善，這樣才能達到降本增效的目的。同時容量管理的重要性不言而喻，它是服務穩定性保障、資源成本控制的基石。隨著智能化運維技術的逐漸成熟，我們要朝著更低的成本更優的質量目標前進。

1、背景

隨著轉轉業務的不斷發展和用戶不斷增長，公司持續增加對硬件和基礎設施的投入，用于滿足業務發展的需要，然而資源的使用率卻逐步下降。因為最初的目標是發展業務，實現功能，隨著業務的發展成熟，逐步更加關注服務的穩定性，性能、冗余、災備等方案，這樣更會增加資源成本。那么如何在保障服務質量和確保服務性能的前提下，同時降低運營成本提高資源利用率呢？容量管理就是其中必不可少的一環。

2、容量管理的目標

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

百度百科的定義：容量管理致力于在恰當的時間以一種經濟節約的方式為數據處理和存儲提供所需的容量。

在我看來，容量管理的本質是風險和成本之間的平衡，即在保障業務服務穩定的前提下，以最低的成本保證最優的服務質量。所以容量管理的目標有兩點：

成本控制：容量管理保證服務的容量和性能以最節約成本的方式滿足既定業務需求，并對資源進行最有效的使用。
業務支撐：容量管理結合當前服務質量（SLA），保證服務提供連續的服務水平;容量管理結合容量規劃，指導業務規劃所需的費用成本規劃和調整。

3、發展階段

轉轉的服務容量管理主要經歷了3個階段。

第一階段：無容量管理，服務全部混合部署到物理機和KVM虛擬機上，單臺設備運行幾十個服務，物理資源共享，造成服務間的互相影響。
第二階段：分析服務的可用性和性能數據配合運維的服務管理經驗來降低服務混部比例，下線KVM虛擬機，調整服務配置，提升資源利用率，從而減少服務器數量，達到降低服務資源成本的目標。
第三階段：隨著服務穩定性和性能指標數據的不斷完善，服務進入云時代，加之壓測標準和資源利用率標準的制定，進步一完善了容量管理的基礎，成本和服務質量得到了有效的平衡。

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

4 容量管理

4.1 容量水位

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

云主機：

CPU
內存
磁盤
網卡

應用服務：

JVM內存
應用線程
GC頻率
QPS
響應時間

如下圖所示，可以看出，對于轉轉的用戶習慣，訪問量分布基本是在白天，晚上20:00-23:00用戶訪問量會逐步增加達到高峰。我們更要關注的是這個時間點上業務服務的容量是否能支撐系統的穩定運行，后續的容量規劃也需要按這個峰值的對應的容量水位來估算。

4.2 資源容量優化

了解了容量水位后再對比我們線上服務的資源使用情況發現很多的資源浪費是容量水位偏低造成的。每月服務相關資源的費用也是一個不小的數字，此時容量優化的意義和價值就會凸顯出來，這也是我們第二階段和第三階段做的事。

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

B服務容器內存為8G，根據內存公式，服務的JVM內存為6G，此時容器內存縮減到7G比較合理（由于業務場景不同，對于內存的使用需結合業務需要調整，避免引起GC異常或OOM）。

內存公式

JVM總內存 = heap 內存 + 線程stack內存 (XSS) * 線程數 + 啟動開銷（constant overhead）

2、混合部署/策略

在線業務和離線業務混合部署，晚間業務低峰期開啟離線業務計算任務，有效地利用CPU，實現峰谷輪動。
把低等級負載較低的服務或對服務可用性要求不高的服務與高等級或容量水位高的業務服務進行混合部署，充分地利用硬件或云主機資源。

例如：A服務是管理后臺服務，資源利用率約為10%；B服務為搜索服務，資源利用率約為40%，我們把兩個服務混合部署，充分利用主機資源。

4.3 集群容量

單純的依靠容量水位去評估服務容量只是利用服務管理經驗的服務監控數據控制資源成本。更精確更合理的方案是利用壓測結合容量水位確定服務集群的準確容量。獲取集群容量的方式通常有兩種，一種是通過日志回放，模擬線上流量對單實例壓測或者通過TCP-Copy的方式，把線上機器的流量拷貝對單實例進行壓測,轉轉初期就是使用這種方式壓測。另一種是對整個集群進行壓測，通過獲取集群的最大容量，再除以集群內實例數量來獲取服務單實例容量。從經驗和數據來看，采用集群壓測的方式更適合一些，因為這種方式完全使用線上真實業務場景進行壓測，獲取的數值更準確。所以我們現在的單實例容量都是通過集群壓測的方式獲得。

4.4 壓測指標

壓測指標通常關注兩類指標，一是系統類指標，二是服務類指標。

類指標。：

CPU使用率
內存使用率
磁盤I/O使用率
網卡帶寬

服務指標：

接口響應耗時
耗時分位
錯誤率
慢速比

4.5 壓測標準

通常情況下，資源使用率并不簡單地等于CPU利用率、CPU負載，也包括內存、I/O、服務相關配置不合理造成的瓶頸等等。所有這些資源的瓶頸最終都會表現為響應時間和錯誤率的增加，所以不論服務有多少資源，我們需要找到一個觸及系統資源瓶頸的臨界點（如下圖所示），在這個點之前，應用的性能表現和訪問量是呈線性關系的，一旦訪問量超過這個臨界點，應用的性能就會明顯下降。基于此，我們壓測的標準如下：

Error%（錯誤率）：

A級服務壓測請求錯誤比例<= 1%。
B級服務壓測請求錯誤比例<= 3%。
C級、D級、E級服務壓測請求錯誤比例<= 5%。

Response Times（響應時間）：

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

這個標準中可以看出，響應耗時方面，我們對于不同的百分位請求耗時有著不同的要求。比如A服務的壓測QPS為1000，TP50為100ms，TP90為300ms，TP99為800ms，很明顯服務的長耗時比較多，服務的性能下降嚴重，此時的壓測數據并不能代表服務的真實容量。所以我們基于現有的服務耗時數據結合服務性能目標，對服務的響應耗時規定了明確的浮動范圍。

壓測目標值配置和達標報告示例: