Redis容器化收益测算

背景

公司有私有云，前些年随着业务的增长IDC的投入规模也不断的增加，但近些年随着业务收缩相对应的资源成本变成领导最关心的议题，业务研发中心、基础设施团队也结合业务容量不断的再缩减资源规模，但通过缩减规模总会达到新的瓶颈，有点像经济学里的“黄宗智”效应；如果想进一步控制资源成本，这个时候只能通过技术能力升级实现。

年初部门定下了Redis向容器化方向，忙活了大半年最近总算要落地了，开始给公司和各业务线老板汇报的时候涉及项目真实可推广范围，以前可节省物理资源时，又重新做了细致的测算。（之前立项也做过一版粗的）。

Redis容器化收益测算：

Redis容器化大体会有两个方面的收益：

1.技术升级，效率方面；比如服开一个Redis实例相比KVM可节省的时间，容器环境下自愈能力的提升等等；

2.另一个大方向就是资源成本的节约；从KVM迁容器后资源上的节约，这块是公司切实关注的。

对于第一方面，本次不过多赘述，重点谈谈第二点，由于我们目前私有云KVM集群里，超分的部分是CPU、但内存未超分，因此制约分配率和利用率的是内存制约，所以本次资源收益测算主要以内存提升为主：

1. 虚拟化节省：从KVM迁容器首先会有一个虚拟化上的节省，如下图和第二列所示；我们对比过同等规格下不同虚拟化环境当中虚拟化后的收益，如2C2G，大概可以节省100M；这部分后续可以体现在Redis可用内存的增加上；

1. 增加规格：考虑到虚拟机环境中我们Redis允许的规格密度较低，在这次容器化过程当中，我们结合实例数量重新增加了部分规格；（如上图绝色部分，对于原来没有的规格，我们虚拟化过程参考了更低规格的收益）；

当然增加规格的主要目的是后续在KVM迁容器的过程当中，我们会根据体系内容量规划平台对于系统真实用量的资源画像给出建议规格，用于指导研发中心降配；（由于我们这次容器化过程当中会限制Redis在资源争抢过程当中被驱逐，所以没有采用Request去超分，理论上如果调度可以满足上述需求完全可以不降规格，不让研发中心感知完成资源降配实现资源收益；）

这里我提供下我们内部的推荐规格计算公式：

推荐规格=向上取近似规格 |(资源画像内存使用量 -X)* 2 * K |

X: 为虚拟化节省(参看表2）

2：主从切换等（全量数据同步期间内存使用量翻倍)，

K: 为用户真实用量提供的冗余系数，按30%测算；降规格后资源内存水位在38%，不会触及50%内存告警)

从KVM往容器迁移的过程当中，更多的效益是来自SRE运维工作效率提升，Redis服务可用性的提升等；资源层面的节约主要还是超分或降规格带来的收益，研发中心从KVM向容器化迁移的过程当中，我们提供子专用迁移工作，并且把上述的规则（如推荐规格、redis maxmemory 设置调整等）全部内置进迁移工具，进一步降低研发中心迁移的门槛。