服务器成本优化
背景
2021.11月会上,在公司开源节流方向指引下,技术委员会执行小组提出将成本优化作为2021Q4的重点项目跟进,服务器成本作为其中重要的一项,需要在公司层面提供一套可行的标准和方案,供业务线制定各自的计划并落地。
现状
概要:
- 总成本TOP3:短信、号码、电商
- 腾讯云已支撑公司大部分业务
- 云产品成本TOP3:主机、带宽、Redis
- k8s主机:cpu 30%+;内存 50%+;硬盘 25%+
- 大数据主机:CPU 70%+;内存 70%+;硬盘 50%+
- 非容器主机:参差不齐
- 带宽:按流量计费
- Redis:超大型redis治理
问题
- 公共平台在推动服务器优化的过程中,标准不明确
- 业务线暂未制定各自服务器成本的核心指标
- 执行过程中,公共平台角色错位,导致冲突
- 公司层面没有将服务器成本优化与绩效考核挂钩
调研
服务器利用率
调研了国内的几个大厂,基本上都有自己的一套定义服务器利用率的方法,然后根据利用率的情况进行治理。
- 腾讯:CPU周峰值:低于45%需要治理。
- 美团:MAX(cpu_util,net_util,io_util,disk_util,mem_util),低于20%需要治理。
- cpu_util:10秒种一个点,每1分钟取该分钟内6个点中最大的一个,将每分钟内最大的点从大到小排列后在一天的1440个分钟里取最大的60个数,求平均。
- mem_util: 1分钟一个点,取TP90,也即90%的时间低于此值。
- io_util:max(disk.io.util),选用io_util最大的块设备取值。
- disk_util:磁盘空间利用率
- net_util:对于物理机,net_util = traffic/网卡工作带宽;对于虚拟机,net_util = traffic/最小保障带宽。其中最小保障带宽为宿主机网卡工作带宽/VM个数。
- 滴滴:最近30天,CPU平均利用率≤5%,峰值≤30%,进行降配;内存使用过低(目前无原则),考虑降配;业务偶发高峰,可不降配。
- 新浪:服务器利用率(CPU/内存/硬盘/网络/成本综合考虑,具体公式不详)≥45%
业务成本核心指标
- 单订单成本(电商类)
- 千元收入成本
- 百万请求服务器成本
标准讨论
服务器利用率
- 生产环境:在不影响业务开展需要的TP999/SLA的情况下,综合考察利用率
- 虚拟机:cpu利用率30%60%之间,内存利用率处于40%70%,数据盘利用率30%~60%之间
- k8s的node节点,由公共平台负责
- 非k8s服务器,由对应业务方负责,公共平台负责提供监控数据
- redis:日常峰值QPS≥30% || 内存≥50%,默认最低规格,有需要随时扩容
- mysql:日常峰值QPS≥30% || 存储 ≥30%,默认最低规格,有需要随时扩容
- mongodb:日常峰值QPS≥30% || 存储 ≥30%,默认最低规格,有需要随时扩容
- elasticsearch:日常峰值QPS≥30% || 存储 ≥30%,默认最低规格,有需要随时扩容
- kafka:日常峰值QPS≥30% || 存储 ≥30%,默认最低规格,有需要随时扩容
- 大数据:考察报表时间段资源利用率
- CPU:60%~90%
- 内存:60%~90%
- 硬盘:75%~90%
- 算法策略:原则上满足模型运算需要最低规格
- 虚拟机:cpu利用率30%60%之间,内存利用率处于40%70%,数据盘利用率30%~60%之间
- 开发测试环境:对利用率不作要求,重点控制规格
- 服务器:原则上单机不超过2C4G
- redis:原则上最低配
- mysql:原则上一个业务线一个最低配实例,业务线内混用
- mongodb:原则上一个业务线一个最低配实例,业务线内混用
- elasticsearch:原则上全公司混用一个最低配实例
- kafka:原则上全公司混用一个最低配实例
- 大数据:原则上提供最低配的大数据集群
- 算法策略:原则上集满足最小数据模型需要最低规格
- 压测环境
- 压测目的:①找出系统瓶颈;②压出系统容量。建议以目标①优先
- 尽量在测试环境完成压测,有需要临时升规格,原则上使用不超过2周
- 生产环境压测应做好隔离,周知基础架构和上下游
核心成本指标
- 公共平台:
- 支撑成本:每百万请求公共平台成本(除去大数据、gitlab、wiki、jira、sso之外分摊成本)
其他
角色定位
- 技术委员会:标准制定
- 公共平台:指标监控
- 业务方:成本第一责任人