历时三个多月的HBase成本优化项目按照预期交付了，HBase云数据库月度成本下降了32.5%，超出预期达成目标。
我们对本次HBase成本优化项目进行深度复盘，并进一步尝试总结云数据库的FinOps之道。
希望能够赋能mysql、redis、mongo等其他云数据库产品实现降本增效，进而给互联网寒冬环境下的企业IT降本增效，提供一个参考思路。
本文将从4个方面进行展开：
- 云数据库成本挑战
- 什么是FinOps
- HBase成本优化实践
- 云数据库FinOps之道
在早期，云计算被视为企业降低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成本优化的 现状、价值、实施路径 充分对齐。
|
业务团队 |
目前成本 |
优化成本 |
优化方案 |
预计人力投入 |
|
A团队 |
xxx |
5k/月 |
降低副本数 |
20人日 |
|
B团队 |
xxx |
8k/月 |
业务降级，取消灾备 |
30人日 |
|
C团队 |
xxx |
4k/月 |
替换云原生数据库 |
25人日 |
|
D团队 |
xxx |
10k/月 |
冷热分离 |
40人日 |
因此，在项目开展过程中，各个团队能结合各自的业务特点，采用 业务架构优化、数据架构优化、云原生技术 等手段，共同朝着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…（历史文章查阅非常方便）