歷時三個多月的HBase成本優化專案按照預期交付了，HBase雲資料庫月度成本下降了32.5%，超出預期達成目標。

我們對本次HBase成本優化專案進行深度覆盤，並進一步嘗試總結雲資料庫的FinOps之道。

希望能夠賦能mysql、redis、mongo等其他雲資料庫產品實現降本增效，進而給網際網路寒冬環境下的企業IT降本增效，提供一個參考思路。

本文將從4個方面進行展開：

• 雲資料庫成本挑戰
• 什麼是FinOps
• HBase成本優化實踐
• 雲資料庫FinOps之道

1、雲資料庫成本挑戰

在早期，雲端計算被視為企業降低IT管理成本、提高業務敏捷性的重要途徑。尤其是雲資料庫，高效能、高可用、彈性使用等特性，「資料庫上雲」是降本增效的一個重要途徑。

但是，隨著雲資料庫大規模使用，雲產品的成本問題開始顯現。比如我們使用的雙叢集HBase，在投入使用2年後，已經成為所有云資料庫類別中，成本佔比最大的元件。

如何解決雲資料庫成本優化問題？尤其在這樣的網際網路寒冬下，是擺在很多技術團隊面前的首要問題。

常見的成本優化挑戰包括四種情況：

• 挑戰一：無法準確衡量資料庫資源是否存在浪費
• 挑戰二：縮容、降配等手段效果不明顯，沒啥別的優化措施
• 挑戰三：基礎架構團隊很著急，一線業務團隊不care
• 挑戰四：「運動式」成本優化，無法形成長效機制

為了系統化解決這些問題，就需要引入FinOps(雲成本優化)的概念了。

2、什麼是FinOps

FinOps 是「Finance」和「DevOps」的綜合體，也被稱為「雲財務管理」、「雲成本管理」或「雲財務優化」等。

FinOps有一個權威組織——FinOps 基金會，FinOps 基金會是Linux 基金會發起的專案，致力於通過最佳實踐、教育和標準來推動實踐雲財務管理學科。

FinOps基金會對FinOps定義如下：

FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.
(Definition Updated: November 2021 by the FinOps Foundation Technical Advisory Council

這裡有三點非常關鍵：

• cultural practice文化建設：FinOps的準測與文化需要建設推廣。（自上而下）
• collaborate 跨團隊共同作業：工程、財務、技術和業務團隊。（FinOps絕不只是任意一個團隊的工作）
• data-driven 方式：資料驅動。（如何推動共同作業的關鍵）

此外，FinOps還有幾個非常重要的維度，包括六大原則、角色、迴圈方法論、成熟度模型。

3、HBase成本優化實踐

參考FinOps六大原則，我們來看看 HBase成本優化專案 中如何落地。

3.1 團隊共同作業

原則1:Teams need to collaborate

原則2:Everyone takes ownership for their cloud usage

這兩條原則非常具有現實意義，成本優化很難由單一團隊負責，必須各個團隊都把 成本 作為一個關鍵指標，持續優化，提高效率和創新能力。

在HBase成本優化專案的 立項之初，我們就提前和各個業務團隊進行深入溝通，對HBase成本優化的 現狀、價值、實施路徑 充分對齊。

因此，在專案開展過程中，各個團隊能結合各自的業務特點，採用 業務架構優化、資料架構優化、雲原生技術 等手段，共同朝著HBase成本優化的大目標前進。

3.2 中心化驅動

原則3:A centralized team drives FinOps

專門有一個團隊來推動FinOps的開展，包括各項流程的推進、基礎設施的搭建等。

本次HBase成本優化專案中，採用 專案制 的形式，由基礎架構團隊進行推進，提供了諸如 成本優化目標、資源使用狀況、資料增長變化、業務改造方案支援 等指標與工具。

後續，我們會開發一個統一的 FinOps平臺產品，由一個 中心化產品，進行長效持久地推進雲資料庫成本優化。

3.3 視覺化資料與報告

原則4:Reports should be accessible and timely

HBase目前是叢集模式運作，各個叢集都存在業務團隊共用叢集的情況。另外，業務數量眾多（近百個敏捷組），如何快速識別成本大頭進行優化，也是一個重點問題。

因此，本次HBase成本優化專案中，充分踐行了 資料驅動 的理念。

• 巨量資料量識別篩選出單副本大於5T的業務，共15個敏捷組，佔總儲存80%以上
• 高增速識別篩選出增速較快的業務。
• 優化效果指標評判採用指令碼統計的方式記錄資料，跟蹤目標業務的優化情況。

這些資料驅動的能力，後續會沉澱為FinOps平臺上的通用元件能力。

3.4 因地制宜，業務優化

原則5:Decisions are driven by business value of cloud

獲得成本相關資料後，根據實際業務價值和使用情況進行成本優化決策。

本次HBase成本優化專案中，各個業務團隊充分利用各自業務特點，進行相關業務優化。

3.4.1 減少副本數

以HBase為例，本身儲存在本地盤的HDFS上，通過三副本機制保證資料不丟失。

為了提高應用穩定性，降低單HBase不可用帶來的風險，我們核心服務都配備了雙叢集主備架構的HBase。這樣導致了一份資料會存在六個副本，造成了磁碟空間使用率的極速膨脹。

在多副本災備架構下，可以對主備叢集內資料都調整為兩副本（去掉replica3、replica6），整體變為四副本，可以降低30%的磁碟空間使用。

某業務團隊單副本140T資料，六副本840T，磁碟使用率不斷上漲，造成巨大成本壓力。我們通過調整副本數量為四副本（從原來的六副本），有效降低了280T資料的磁碟使用空間。

3.4.2 資料冷熱分離

如果資料量過大，一般可以考慮根據資料生命週期特點，實施冷熱分離、無效資料清理。

關鍵邏輯

• 使用者端寫熱儲存
• 使用者端查詢時，根據 業務冷熱劃分邏輯 進行路由查詢。
• 遷移任務根據 業務冷熱劃分邏輯（一般為生產時間或修改時間）進行 查詢&過濾 ，將符合條件的冷資料寫入冷儲存，並且從熱儲存中刪除
• 對賬任務根據遷移任務的記錄紀錄檔log，進行定時校驗，確保資料不丟失，校驗無誤後清理log

3.4.3 做好資料壓縮，減少儲存量

對於單value比較大的資料，可以通過資料壓縮演演算法，如snappy、lz4、gizp等，提高資料壓縮比，降低儲存。

HBase、mongo等資料庫伺服器端可以做自動壓縮的設定，如果伺服器端不支援自動壓縮的，可以採用使用者端壓縮後再寫入。

3.5 充分利用雲產品

原則6:Take advantage of the variable cost model of the cloud

充分利用好不同的雲產品計費模型。這個目前其實做的比較多了，比如選擇不同雲廠商的不同產品、根據不同場景選擇不同計費模式（ 包年包月、按量付費、serverless等）等。

本次HBase成本優化專案中，典型的就是在某個特定業務場景下，引入了 HBase serverless方案 作為災備叢集，降低了普通叢集作為災備叢集的低效支出。

4、雲資料庫FinOps之道

前面聊了HBase成本優化實踐的若干原則與具體操作，比較偏重「術」的層面。

下面，我們再結合FinOps的迴圈治理方法論，來更全面地思考雲資料庫的FinOps之道。

FinOps 基金會建議採用迭代方法來管理雲服務的可變成本。最佳實踐包括應持續管理的三個環節：通知、優化和運營。

4.1 通知（Inform）

核心在於 資料視覺化 與 可分配。

業務團隊和財務利益相關者能夠確保他們在控制預算和準確預測支出的同時提高ROI，避免意外。

同時，也能作為一個業務團隊的基礎指標，來衡量並提升團隊成本優化效率。

4.1.1 資料視覺化

俗話說，It you can’t measure it, you can’t manage it。

資料驅動理念在FinOps中同樣處於核心地位。

包括但不限於：

• 資源（CPU/記憶體/磁碟）使用率
• 資源增長速率
• 資源預算
• 資源實際使用超額比例
• 資源使用預測

準確而全面的視覺化，可以較好解決成本優化的挑戰一，精準衡量是否存在資源浪費的情況。

4.1.2 可分配

對於所有云上資源，都要儘可能精細化、準確 分配到各個實際使用團隊上。

目前在微服務架構下，單範例型別的元件比較容易跟上游應用繫結，進而分配到具體業務團隊。但是叢集型別的元件（如HBase)，仍然需要做進一步細粒度的計算與分配。

4.2 優化（Optimize)

一旦資源優化指標準確係結到 實際使用團隊後，就可以開展各項優化工作。

最基礎的方式，是根據資料使用率指標，對空閒資源進行降配、縮容等方式。

更深度的優化，需要結合實際業務場景，參考3.4的內容，實施 減少副本數、冷熱分離、資料壓縮 等手段。（解決挑戰二）

4.3 運營（Operate)

4.3.1 文化建設

通過FinOps進行成本優化的文化建設是首要條件。必須自上而下推行這種意識和相關的獎懲制度。

讓基礎團隊、業務團隊認識到這項工作不是某個人、某個團隊的事情，而是各個團隊在架構設計、技術優化、績效達成中的關鍵任務。（解決挑戰三）

如果沒有自上而下推行這種文化，FinOps肯定無法落地，更不用談長期機制了。

4.3.2 自動化流程與機制

為了使FinOps成為一種長期機制，除了文化建設外，必須將人工流程自動化。

從 資料化、成本問題識別、任務分配、優化完成、資料追蹤 等環節入手，將一整套流程以平臺產品的形式沉澱下來。

轉變」運動式「優化的困境，形成真正的長期機制。（解決挑戰四）

5、小結

本文從雲資料庫成本挑戰引入FinOps的概念，結合HBase成本優化專案闡述了FinOps的具體原則與實踐案例。

最後總結了雲資料庫FinOps之道，形成資料庫成本優化真正的閉環解決方案，形成長效機制，徹底解決四種常見成本優化挑戰。

 

希望能夠拋磚引玉，提供一些啟發和思考。如果你有其他補充和建議，歡迎留言討論。

 

都看到最後了，原創不易，點個關注，點個贊吧～

文章持續更新，可以微信搜尋「阿丸筆記 」第一時間閱讀，回覆【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回覆【資料】獲取一線大廠面試資料。

知識碎片重新梳理，構建Java知識圖譜：github.com/saigu/JavaK…（歷史文章查閱非常方便）