简单几步提升cpu性能(CPU利用率从10)(1)

在互联网早期迅速发展时,相关领域企业更多注重于扩展业务,为了迅速占领市场,往往会投入较高的成本。然而,随着互联网人口红利逐渐消退,以及近几年的疫情影响,越来越多企业开始重视成本管理,从“粗放式经营”转变为“精细化运营”模式,成本优化成为企业重点关注事项。

本文将从一位中型企业运维总监的视角来展现一个较完整的成本优化实战案例,希望为读者提供可参考借鉴的成本优化思路。

降本实战案例背景

本文的主人公小王(化名)在某电商公司担任运维总监,他所在公司自建 IDC 机房,其中总共 1000 台业务服务器(在线 离线),由 3 名运维人员管理。机器规格大部分为 8 核 32G,整体 CPU 利用率仅 10% 左右,每年花销在 1000 万以上。

CTO 希望在现有业务市场条件不变的情况下,以业务稳定性为基本前提,将 IT 成本降低至少 30%,且将此定为小王今年的 KPI。

第一阶段上云 公有云厂商 / 算力品牌对比选择

收到任务后,小王先将 IT 成本拆解为算力成本和人力成本两个部分。

目前 IT 成本主要由自建 IDC 机房承载,存在如下问题:

基于以上分析,考虑到公有云机型更新便捷、基本免维护、可弹性的特点,小王计划先将业务迁移上云。

目前云厂商主要提供了预留实例(包年包月)、按需实例(弹性)、竞价实例三种方式:

为确保系统稳定且尽量减少研发感知,小王先后采取了以下几项措施:

  1. 将大部分无状态在线服务和一部分离线服务所在的大概 800 台机器,以包年包月的形式迁移到同等配置的公有云机器上;
  2. 腾退相应私有机房机器,并将公有云与私有机房通过专线打通。这样既能保证在线服务上云之后的快速伸缩,又能兼顾数据传输成本及安全方面的考量;
  3. 接入公有云相应的部署发布、监控告警、限流自愈等附属功能,从而节省出一个运维的人力。

在上云过程中,小王一方面根据公司需求对比多家公有云厂商后选择最匹配的云资源,另一方面将 CPU 品牌从 Intel 换成 AMD,两者叠加后,降低了 7% 左右的成本。

系统指标描述服务算力特征

完成混合云改造后,小王进一步将算力成本拆解为服务算力成本和基础设施资源成本:

结合公司目前的成本占比情况,服务算力成本占了其中的 60% 以上。

算力成本来源占比如下图所示:

简单几步提升cpu性能(CPU利用率从10)(2)

图 1 算力成本来源占比

基于二八原则,小王决定以运维第三方视角,本着少侵入业务的前提,集中精力节省服务算力成本。

小王首先检查公司已上云的典型业务的算力特征。由于公司业务偏计算型,所以他选择通过常见性能指标 CPU 利用率来观察算力消耗情况,发现公司业务常在中午 12 点左右和晚上 8 点左右迎来算力消耗高峰。

如下图所示:

简单几步提升cpu性能(CPU利用率从10)(3)

图 2 CPU 利用率指标算力图

优化低频冗余算力

根据上面的业务算力模型,小王发现即使业务完全处于高峰,所需要的机器数也不到现有数量的 80%。在公有云弹性的保证下,小王分阶段释放了历史高峰未触及的 200 多台 8 核 32G 包年包月冗余机器,节省了 20% 左右成本。

压测 公有云机型规格降配

在粗略去除明显冗余算力后,小王观察到业务算力即使在忙时利用率也不高,尤其是内存闲置较为严重。

接下来小王和业务一起进行了一次压测,最后得出业务机器规格保持在 8 核 3G 的配比,使用率相对均衡。而公有云机器 CPU 核数和内存配比一般是 1:2 或 1:4 的固定比例,所以小王按照公有云厂商的标准配置先将机器规格从 8 核 32G 降为 8 核 16G,节省了 20% 的成本。

小结

第一阶段的优化手段较为常规,取得了一些效果,小王总共节省了 40% 左右的成本,以较低成本吃到了第一波降本红利。

基于第一阶段的优化经验,小王总结出以下待改进点:

  1. 根据 CPU 消耗所衡量出的算力消耗情况和业务的实际情况之间仍有一定差距。比如,经常会出现 CPU 消耗偏高但实际业务依然稳定、无需扩容的情况,这说明需要更加精准的算力度量指标。
  2. 业务算力模型明显有波峰波谷,但是资源消耗的模型并未较好匹配,虽去除了未触达的冗余算力,但仍是以最高峰配置全时段占用算力,导致闲时浪费明显。
  3. 公有云机器规格中,CPU 与内存的比例有明显限制,导致算力资源使用无法进一步均衡,造成浪费。

基于上述分析,小王分析出需要依次解决的三个问题:

  1. 以更精准的业务指标,替代以 CPU 消耗为核心的物理指标;
  2. 持续采集该指标,精准匹配算力波动曲线并实时联动扩缩容;
  3. 获得更匹配实际业务的机器算力规格,提高资源利用率。

针对以上问题,小王对业界现有解决方案进行了调研,发现并无能直接借鉴的普适方法和经验,大部分实现方式都与特定业务场景绑定且需要研发深度参与。

为了能按期实现目标,小王尝试使用云原生基础治理平台 SchedulX 开始第二阶段的深入优化。

第二阶段MetricsQPS 指标代替 CPU 指标精准衡量算力

小王借助 SchedulX 系统,在不让业务大规模改造的前提下,引入了 MetricsQPS 指标。该指标将 QPS 中不同请求对机器资源占用的时长纳入了考量,通过对 QPS 按时长进行分段并配以相应的权重最终拟合而成。相对于普通 QPS 指标,MetricsQPS 更能精确地反映出业务实际负载情况。该指标基本计算公式如下:

简单几步提升cpu性能(CPU利用率从10)(4)

图 3 MetricsQPS 公式

小王利用这一指标执行了第一阶段的“优化低频冗余算力”操作,再次下线 60 台机器,节省约 10% 成本。

用弹性伸缩替换包年包月短时高峰算力

接下来,小王比较了公有云 8 核 16G 包年包月价格(约 600 元 / 月)与弹性机器价格(约 1.20 元 / 小时),发现包月机器 1 天的费用是弹性机器 30 天费用的 70% 左右。

由此推断,对于每天峰值时长低于总时长 30%(约 8 小时)的机器,可以用弹性代替包年包月。

如下图所示:

简单几步提升cpu性能(CPU利用率从10)(5)

图 4 短时高峰弹性代替包年包月

对于其它规格的服务器,小王延伸推导如下:

设弹性扩容一台同规格机器 1 小时的成本为 Y 元,高峰时总机器数为 K1 台,高峰时段为 H 小时,包年包月合理机器数为 K2 台,则从省成本角度考虑,需要保证满足以下条件:

(K1-K2)* H * Y < (X / 30)*(K1 -K2) => H * Y < (X / 30)

由于 X、Y 均为相对固定值,所以按照此不等式可计算出适合弹性的业务峰值理论时长。于是,在留出一定的安全边际的前提下,小王借助 SchedulX 的度量和弹性能力再下线 50 多台机器,节省约 10% 成本。

包年包月算力低峰共享

面对剩余的包年包月机器,小王发现还是有优化空间的。从波形覆盖面积上来看,空洞波形面积(蓝色阴影面积)至少占到红框中矩形面积的 1/3 以上,如图所示:

简单几步提升cpu性能(CPU利用率从10)(6)

图 5 包年包月算力低峰共享

小王计划将这部分机器利用起来,作为公司整体的共享资源池,供公司其它周期性及离线任务进行错峰使用。因为涉及面较广,小王请 CTO 一起出面推动协调,最终借助 SchedulX 系统贴合业务算力模型曲线实时扩缩容,共节省了 10% 的成本。

裸金属切割,精准适配规格

小王在完成以 MetricsQPS 指标按横向时序的算力优化后,再次将注意力集中到机器规格对业务需求的精准匹配上。

小王采用了公有云上的高规格裸金属服务器,借助 SchedulX 对公有云裸金属原材料进行了二次切割。虽然公有云上的裸金属也是按固定算力资源比例售卖,但是经过切割后的算力规格能够精准匹配业务 8 核 3G 的规格需求。同样是 500 台机器,相对原来的 8 核 16G 云主机,经过切割得出的 8 核 3G 机器能节省超过 15% 的成本。

利用算力地域价格差省成本

做完机器规格的精准裁剪匹配后,现在基本上单体算力规格和时序算力数量与类型都已经完成了优化,小王又将目光放到了算力的地域差异方面。他了解到公有云上西部机房同规格的算力比东部机房更便宜,通过将近 100 台离线服务器迁移到西部机房,同时借助 SchedulX 快速大批量数据迁移的能力实现东数西算,节省成本 10%。

总结

第二阶段基本解决了第一阶段遗留的精准度量算力、精准匹配模型、精准切割规格三大问题。两阶段下来,CPU 利用率上升至 60%,总共节省成本将近 70%,实现并超出 CTO 预期。

综合两阶段,小王的整体优化流程如下图所示:

简单几步提升cpu性能(CPU利用率从10)(7)

图 6 降本流程图

降本配套设施

为了顺利推进成本优化,小王除了设计操作各种算力增减外,还借助了以下一些配套措施和系统:

  1. 需要明确算力衡量指标体系,前期可以粗略使用 CPU 利用率等系统指标,后期需要借助精准的业务指标,比如 QPS 及单请求的耗时结合的复合指标。
  2. 降本过程需要有较完备的监控告警系统及容灾 SOP,防止在优化过程中出现意外情况。比如在优化低频冗余算力环节,小王在下机器的时候,提前根据 CPU 等指标设置好了扩缩容策略,在系统保持一周无异常后才将下线的机器清退。
  3. 为了精准量度业务算力,需要搭配压测系统及方案。前期为尽量减少业务投入成本,主要是基于以下思路来操作:测试环境 ->线上日志回放 ->mock 调用接口 ->采集算力衡量指标 ->逐步放大调用压力 ->响应超时的服务器达到一定比例时结束压测。后期可以逐步迭代为全链路压测,从网关到调用链路到存储全隔离的形态,衡量效果会更精准,当然相应研发成本和投入也会更重。
  4. 为了充分体现每一步的优化成果,需要有成本看板,对每一阶段优化前后的机器资源和成本消耗进行环比或横比展示。成本看板主要针对中高层人群,所以信息要简明扼要,成本信息突出。
降本遇到的非技术问题

小王在推进降本过程中,还总结了一些遇到的非技术问题及主要解法:

结语

回顾整个降本之路,除了之前总结的执行中技术 / 非技术的问题外,还有以下几个点值得提出:

在互联网下半场的今天,降本增效作为企业大势所趋,甚至上升到了公司核心竞争力的层面。在林林总总的成本优化路径和手段面前,谁先朝正确的方向踏出一步,谁就有可能领先对手占据先机。本文综合讲述了一个典型腰部企业的降本之路,希望能对读者有所启发。如果读者有成本优化技术手段相关的需求,可以联系我们共同探讨。

本文大部分内容摘自《星汉未来云原生 IT 成本优化白皮书》,其中提到的 SchedulX 是由星汉未来打造的一站式云原生基础治理平台,目前已推出社区版,通过此链接即可获取白皮书、免费试用 SchedulX 社区版。

作者介绍

舒超,星汉未来 CTO。前美团基础研发负责人,存储中心总架构师,负责美团公司级云原生服务治理系统的开发及演进;前腾讯微博微群及消息流广告负责人。

,