嘉宾 | 吕亚霖
编辑 | 张诚
本文整理自作业帮基础架构研发团队的负责人吕亚霖在WOT2024大会上的主题分享。
2024年6月21日-22日，以“智启新纪，慧创万物”为主题的“WOT全球技术创新大会2024·北京站”正式召开。在《云原生时代的成本优化》专场，来自作业帮基础架构研发团队的负责人吕亚霖带来了《作业帮基于云原生的降本之路》的主题分享，详细介绍了作业帮基础架构如何基于云原生技术，在满足业务快速迭代和稳定性基础上，实现系统化周期性的成本降低。
以下内容，根据吕亚霖老师的演讲实录整理而来。
一、云原生降本背景和目标
在实现降本的过程中，大家普遍面临来自于三种场景的挑战：
场景一：短期运动化降低了成本，一年后成本反弹反而更高了；
场景二：通过舍弃稳定性来降低成本，遇到了大的事故，得不偿失；
场景三：在大型复杂系统内，各个团队降本往往聚焦自身一点，无法整体统筹，甚至把成本转移给其他部门。
吕亚霖认为，通过合理的云原生架构来找到一条体系化持续的降低成本路线，这就是云原生降本的目标。
作业帮的技术现状主要分为以下四个方面。
- 服务模块：数千个业务模块，数十万计算核心，全球多云多地域多活；
- 多语言栈：golang、C++、python、node、java等；
- 场景多样：工具化服务、教育类应用、智能硬件场景、AIGC场景；
- 团队规模：拥有上千人的产研团队。
吕亚霖表示，这四个方面是大多数具备相同体量公司目前的主要技术现状，因此作业帮的云原生降本路线对大多数具有相同体量的公司有着一定的参考意义。
吕亚霖强调，云原生降本路线的关键点有两点。一是要熟练掌握业务特征以及技术组件的各种特征，通过云原生架构来适配底层的基础设施；二是基础设施要向上反馈架构的适配性，尽量能够满足云原生架构，即业务、中间件和基础设施都向云原生架构靠拢，实现双向奔赴。
二、应用：流媒体和serverless的最佳组合
作业帮有一个比较典型的业务场景是流量的时间周期特别明显，例如主要集中在下午3点、4点、5点这几个小时内。开始的一瞬间，流量达到峰值，之后几乎没有流量。
吕亚霖表示，针对作业帮的业务特点，我们使用了Serverless的VNode节点开源方案进行了改造，在一个 Service中包括很多Node物理节点和虚拟节点，虚拟节点VNode可以看成是一个无限扩展的物理节点，这样的方案使得在上层业务中看不到任何差异。因此，我们可以把VNode当成一个无限的扩展节点，它的Pod会横向扩容到VNode上，当流量高峰到来时。正常的服务也能够正常调用。
吕亚霖通过一组数据，展示了流媒体服务serverless架构成本优势。
假设：包年包月服务器每小时成本为C，使用serverless每小时成本为1.5C。全部使用包年包月服务器的总成本为 C * 24 = 24C，serverless成本为1.5C * 5 + 10% * C* 19 = 8.4C。
最终得出的结论是，使用serverless可降低成本：(24C – 8.4C) / 24C = 65%。
虽然serverless能够显著降低成本，但在技术架构的改造过程中，也会面临如下几个方面的挑战。
1.稳定性挑战
作业帮采用了调度器和分流机制来解决这一挑战。
在调度器方面，一是采用预测式扩缩容YHPA，预测业务流量高峰来临前半个小时提前调度扩容；二是兜底扩缩机制DHPA，当预警流量进入，全量急速拉起全容量服务。
在资源保证方面，一是通过与厂商商谈资源的预留，让我们想要的资源不要快速释放，确保一定的资源预留量。二是就近地域IDC分流，比如北京IDC需要一万核，厂商只能提供八千核，差的两千核容量就要分流给河北的IDC，这就需要直接在端上进行分流。当然，也可以通过直接采购云上SaaS产品，在端上进行自研和Saas产品分流。
2.观测性挑战
主要通过日志采集组件DS注入POD、追踪组件上报collector、监控支持Prometheus、支持与kubelet通信，获取运行POD的信息等技术来解决这一挑战。
对于网络挑战，作业帮通过Serverless支持指定公网EIP进行解决。在安全挑战上，作业帮通过注解的方式把安全组下放，快速启动并通过底层sanbox复用进行解决。
三、基础组件：服务观测基础组件的云原生架构改造
吕亚霖以日志服务为例，介绍了基础服务成本之殇。
“假设每日产生1PB日志，存储&检索一个月的日志，需要多少成本。” 吕亚霖以一道数字题，介绍了日志服务的成本。他表示，如果使用ELK，只算ES的话，按照官方介绍测算写入和查询需要的算力，大概需要上百台96C物理机器。在极端计算下只算磁盘成本，1TB磁盘需要350元/月，30PB则需要350*1000*30 = 1000万/月。监控、日志追踪同理。
吕亚霖表示，大部分互联网企业，服务观测成本占在线业务总体成本（不包含大数据）的15%，甚至更高。但是，只有在5%以下才是合理区间，因此有大量的优化空间。
在观测体系的改造上，作业帮采用将容器产生的日志，通过输出到logagent传输给Kafka，最终通过日志的存储和检索、日志监控、日志追踪分发给大数据。大多数观测数据来自于服务网格上报，例如每次过网格时就会把分布式追踪的上下文报下来，但实际上网格是没有覆盖到底下的各种存储、MySQL、Redis或者其他存储，这类数据是通过解析日志上报上来的。
在检索存储系统的改造上，由于Ingester是一个订阅Kafka系统，它会以块（一个块大概几十兆）的形式写到本地化存储中，并且对块上的pod信息、日期、服务建立索引。这时，它就会自动进行冷热沉降，例如本地有一个7T存储盘，它将预留80%，如果超过7T容量，就自动开始往对象存储上沉降，并把最热的数据放在本地，历史数据放到对象存储中。然后，在对象存储中把超过30天的数据归档到冷存储中。当需要查询数据时，就会对下边所属的集群同样发出Query请求，并通过数据找到这个块所在的位置，对块进行查询。
吕亚霖表示，这并不是一个检索系统，而是分布式计算系统。其优势在于按块存储当数据写入时吞吐量非常高，因此我们并不需要建立索引，只需要建立一个简单的基于块的索引信息就可以了。另外，由于采用了归档沉降，将超过30天的数据进行三级归档后进入冷存储，冷存储的成本就会比较低。进行数据查询时，采用了全量的并发查询，只需要通过简单的命令就能够能够拿到结果。
通过日志云原生改造，作业帮将1%的数据存储在本地盘，实现了0.35元/GB/月；5%的数据经过90%的压缩后存储在对象存储中，实现了0.12元/GB/月；94%的数据经过90%的压缩后存储在深度归档存储中，实现了0.03元/GB/月，参考自腾讯云厂商目录价。
在监控云原生改造上，作业帮采用了Prometheus体系，通过将VictoriaMetrics替换到Prometheus内部的TSDB。除此之外，还在VictoriaMetrics之前加上了Remote-write组件，支持所有Prometheus远程写入，同时通过写入一个VM标准集群和降准集群来进一步降低成本。通过改造，标准集群的高精度只会保留半年，降准可以保留到三年以上。
在分布式追踪云原创改造过程中，作业帮使用CK替代ES，写入提升了40%，CPU下降了80%，磁盘下降了50%。另外，还实现了服务网格、日志分析上报，业务无感全覆盖全采集。
四、基础设施多云多地域融合
在IT基础设施中，使用GPU算力所带来的成本非常高。吕亚霖以GPT-4为例，通过一组数据详细介绍了GPU带来的高算力成本。
以GPT-4当前的价格做一个简单的估算，假设日活跃用户达到1000万DAU，5000token / DAU，并且不考虑其他的费用，每天产生的费用为：10M * 5000 tokens * $15 / 1M tokens = $75万，非常昂贵。
另外，受用于大模型的GPU价格昂贵、以LLM为代表的大模型参数规模变大、业务场景下的推理算力利用率不足三个方面因素的影响，使用自有服务器的成本也比较高。
吕亚霖认为，容器化是解决高算力成本的基石。他表示，容器化能够使资源透明地、快速地部署到各个IDC，打平计算、存储、网络等IaaS底层资源，实现资源的透明部署，并同时支持服务观测、服务网格、服务注册发现等上层服务的治理。
为了解决GPU高算力所带来的成本问题，作业帮进行了GPU推理容器化的改造，并通过GPU算力网络多地域的融合，实现了动态流量调度、传输协议自动切换、超高压缩率、动态容量调度和密集部署，算力和显存使用率提升30%。
演讲最后，吕亚霖指出，在云原生成本优化中，要首先发现浪费，然后再制订合理的成本优化方案。在成本优化时，要坚持自上而下，先易后难的原则。此外，要从平台系统化、面向应用服务的成本中心、面向基础架构的成本中心三个方面出发，要持续进行优化，才能更好地降低成本。
嘉宾介绍
吕亚霖，2019年加入作业帮，作业帮基础架构-架构研发团队负责人，主导了作业帮多云云原生架构演进，负责作业帮容器化建设、服务治理体系建设、多云建设、应用框架&中间件升级适配、服务稳定性保障。对容器化、微服务框架、服务治理、DevOps等有大量一线实践。
