广告业务机器资源成本优化思路及建议
一 背景
当前互联网发展已经渡过了早期的快速扩张期，商业模式创新的空间变小，现存成熟商业模式的市场份额也逐渐被各领域头部公司瓜分。在这样的环境下，互联网公司以模式创新、资本规模、技术优势作为核心竞争力的逻辑链条被打破。同时，最近三年中美贸易战、芯片战、疫情等因素削弱了市场整体活跃程度，即使是头部互联网公司的盈利模式也不断面临挑战。
因此，近三年各公司在技术的主张思路也做出了很大的调整，技术主线由“扩市场”逐渐向“优化成本”转变。广告业务时互联网领域成本需求较高的业务之一，理所当然首当其冲受到较大的影响。广告业务的主要成本由人力成本和机器成本两部分组成，本文仅重点讨论这机器成本优化的一些思考。
二 机器成本构成
机器成本 = 业务实际使用量 / 资源利用率 * 机器资源单价
机器成本由三部分组成，即业务实际使用量、机器资源的利用率和机器资源单价。业务实际使用量指的是在处理业务逻辑时所消耗的必要资源，如存放一份数据需要10GB的内存、机器学习inferance需要占用1000个CPU时钟周期等。资源利用率是指实际使用的资源与真实持有的资源之间的比例，如一台拥有256GB内存的机器中实际使用了128GB内存，那么利用率即为50%，这也表示另外50%内存被浪费了，至少是闲置了。机器资源单价指的是单位计算/存储单元的价格，如PMEM的存储单价低于DRAM，HD的存储单价低于SSD。
通过上述分析可以基本的出优化机器成本的三种途径：一是降低业务实际使用量，二是提高资源利用率，三是降低机器资源单价。
三 优化思路
在实际工作中，“降低业务实际使用量”和“提高资源利用率”往往没有经过严格的划分，导致优化目标的混乱。比如通过删除无效逻辑进行性能优化，本质上不是“提高资源利用率”，而是“降低业务实际使用量”；再比如通过并行降低响应时间，从而在给定的超时约束下提高了吞吐量，本质上不是“降低业务实际使用量”，而是“提高资源利用率”；平时谈到的容器混部，是“提高资源利用率”；最近比较流行的“计算与存储分离架构”，是“降低业务实际使用量”。
这里希望读者深入理解这两个概念的区别，并在思考、讨论时严格区分，这样才能得出正确的分析结论。
3.1 优化业务实际使用量
广告系统的核目标是通过平台提供的算力为平台创造收入，而收入能力与所投入的算力之间存在正相关的关系，因此理论上，只要“收入-机器成本ROI”大于1，就应该无限投入新的机器资源，以此来博取利润增长。但是伴随着机器资源的增加、业务线的增加，附加的运维成本、管理成本会急剧上升，造成隐形成本。同时，人为因素也会导致一些潜在问题。机器资源配给政策的过分充裕会让技术人员失去成本意识，导致人为资源滥用；组织分工引入的竞争可能会导致重复建设。这些现象都会最终造成业务实际使用量虚增。
总结上文，优化业务实际使用量的几个主要考量方面是收入-机器成本ROI、运维管理成本和人为因素。下面介绍下针对这三方面考量因素的一些思考。
3.1.1 控制收入-机器成本ROI
在理想的理论模型下，我们可以计算出平均每一个时钟周期、每一Byte内存为业务带来了多少收入；同时，公司内部都有自身的资源成本核算体系，如核算结果为CPU成本1元/（核*天）。有了这些数据，就可以计算一个项目的ROI是否大于1，从而“优胜劣汰”，让系统的ROI良性发展。
但是这个策略在实际执行时并不容易。首先，业务上的收入往往是长期获得的，但是机器资源的投入却是瞬时的，决策发生在“投入机器资源”的时刻，此时很难合理预估出业务上的收入。其次，业务收入上涨或下降的因素有很多，很难从整体的数据中抽离出由具体项目发布导致上涨或下降的部分，项目负责同学往往会夸大自身的收入影响。最后，ROI是变化的，发布时大于1不代表永远大于1，如何实现“劣汰”值得讨论。
这里建议几种可行的方案：
- 建立ROI追踪机制
长期追踪ROI是一种可行的机制。技术上，可以比较容易的通过技术手段分别获取实际占用CPU、内存的业务方，并统计长期平均值；效果上，长期的平均值可以降低短期波动对项目ROI衡量结果带来的偏差，避免“冤假错案”的出现；管理上，放弃难以客观计算的“项目维度ROI”，而折衷到“业务维度ROI”，有利于明确责任，避免对立与冲突。 - 收入责任与成本责任保持一致
在当前广告业务的普遍组织架构中，产品/策略团队为收入负责，工程团队为成本负责。这种责任划分将ROI中的I与O的责任划分给两个独立责任方，会导致整体调优的对立冲突。解决这个问题的主要思路是打破收入责任和成本责任的独立划分，即让产品产品/策略团队也为部分成本负责，或者让工程团队也对部分收入负责。由于互联网业态下工程团队数量总是少于产品/策略团队数量，由此引出两种组织模式：一种是将工程团队按照业务线打散，分到各个业务团队中，专门负责某个业务线的成本问题，但这种方式会引入重复建设；另一种是各个产品/策略团队需要对自身的ROI负责（而不是仅对收入负责），工程团队负责提供区分业务线的成本统计能力。
我个人建议采用第二种方式，这种模式不仅可以打破“收入”与“成本”之间的对立，促成产品/策略与工程团队在成本优化领域的自发合作，还可以从技术、意识维度推动产品/策略利用他们自身的专业知识自发提升ROI，而ROI最终就是公司的利润，最终可以达成多方共赢。
3.1.2 降低运维管理成本
运维管理成本体现在两个方面：一方面是在发布、扩缩容环节，需要用自动化的手段去调度机器，其中隐含了“调度集群”的机器成本；另外一方面是当业务线繁多时，出于风险隔离、责任隔离、发布周期博弈等考虑因素，会导致信息或计算的冗余，如同一份数据在两个业务集群中反复存放两次、同一个计算逻辑在一个流程中被计算两次等。
为了解决上述问题，提出几个建议：
- 考量“管理机器-业务机器比例”
这个指标的含义是，平均每新增一台“业务机器”，要配套增加多少用于调度的“管理机器”。基础设施团队应在保证效率的基础上，持续优化这一指标。 - 业务资源合并
为了避免信息或计算的冗余，需要统筹各业务线之间的“可复用”资源，并加以优化。但是这个过程可能会面临一些矛盾，如计算与存储分离架构本质上是合并了存储资源，降低了存储使用量，但是由于引入了网络IO和序列化计算，可能难以满足严苛在线响应时间约束。一个可行的方案是通过智能化部署系统，自动分析多业务集间数据、计算的复用情况，并在部署环节加以优化。最近提出的“图引擎”概念就可以解决这一问题。
3.1.3 合理的组织管理模式
人的因素始终是事情能否按照合理方向演进的关键因素，也是“管理”存在的必要性。若想“降低机器使用量”，就要激发人的积极性，去自主优化成本；或者至少，在制度上不要阻碍人们自发的优化成本。
关于如何激发产品/策略、工程团队自发优化成本的建议已经在3.1.1节中讨论过了，本节重点讨论平级竞争给成本带来的影响。“多业务线”、“多策略团队”划分模式的主要优点是可以促进各团队深度挖掘各自场景中的个性化特点，保证各领域的收入最大化。但是这个优点存在的合理性仍然需要回答两个关键问题：
- 各领域的收入最大化是否等价与整体收入最大化？
- 各领域的收入最大化是否一定能保证ROI最优？
随着业务进入深水区，在互联网行业整体饱和的背景下，对于这两个问题，我的答案都是否定的。首先，当增长停滞，进入残酷的零和博弈后，各业务线之间不可避免的出现“争抢”，此时以挤占其他业务线收入而创造的自身业务线收入增长对整体收入没有贡献。以广告为例，广告主整体预算池不增涨的前提下，任何一个产品形态带来的预算增长都是以挤压其他产品线为代价的，此时各产品线只是在进行无意义的竞争，大家好像都做了很多，但实际上什么也没做。其次，各产品线之间始终反复上演“创新、抄袭”的循环，乐此不疲。从全局视角来看，真正创新的业务团队没有享受到激励，反而增加了反复开发同样功能的负担，徒劳增加机器成本。
在当前行业的大背景下，这里提出一点建议：在合理的范围内，各业务线之间应统一规划，通过整合、协作、分工创造新的增量，避免重复建设，消除无效竞争。
3.2 优化资源利用率
优化资源利用率特指现有机器资源中被有效利用资源的比例。提高资源利用率主要有几种思路：第一，利用规模效应化零为整，压榨出机器资源中空闲的“水分”。第二，优化基础设施消耗资源的占比，所谓基础设施指的是网络IO、操作系统内核计算等。第三，也是常被人们忽略的一点，就是在既有约束条件限制下，尽可能提高单机的最大吞吐量。下文分别介绍下这三种思路的具体应用。
3.2.1 利用规模效应化零为整
现在应用比较广泛的“混部”技术就是这一思路的最直观应用。“混部”的本质就是在时间、空间两个维度上整合资源开销互补的容器，使之能最高效率的在物理机上运行。“时间混部”体现在当A容器很繁忙时，B容器总是很空闲，且反之亦然，可以通过“CPU超卖”让A和B跑在同一台物理机上，让物理机的CPU利用率始终保持在较高水位，同时各容器可用性不受影响。“在线与离线资源混部”就遵循了这一思路，这是普遍认为离线计算的运行时间可以人为控制，可以人为创造时间混部的前提条件。“空间混部”体现在让两个内存开销为128GB，CPU开销为16核的容器部署在一台256GB内存、32核CPU的物理机上，提高内存/CPU的的利用率。当前比较流行的智能混部概念，就是从空间混部概念中延伸而来。
深入思考这一理论后可以发现现在主流技术产品发展趋势大都基于规模效应所带来的红利。“公有云”的利润空间存在于规模效应带来的低成本和与各小公司独立维护“私有云”带来的高成本之间。当“公有云”发展到一定规模，对技术市场具有一定影响力后，“云原生”就应运而生，希望未来应用都面向云来设计。我个人认为这些技术路线的锚点就在于通过规模效应拉开与中小公司的成本，从而各云厂商才有盈利空间。
“计算与存储分离”本质上是“降低资源使用量”，让一份数据只存放一次（不考虑读写分离以及灾备副本），无需受到计算节点扩缩容的干扰。这种方案的底层逻辑是打破内存资源和CPU资源上的部署耦合，使得CPU和内存可以各自独立“化零为整”提高利用率。
3.2.2 优化基础设施消耗资源的占比
即使是在同一个业务容器内，也并非所有的计算成本都是业务计算在使用，类似于网络IO、路由器转发、内核拷贝等计算均是基础设施的行为。如果能降低基础设施消耗资源，就可以提高业务资源占用-总资源的利用率。
最近比较流行的零拷贝技术、DMA、RDMA，都是这一思路的具体应用。在基础组件优化中，将同步等待IO模型改为异步通知IO模型，或者引入协程，用轻量级的“线程切换”替代“进程切换”，本质上也是降低基础设施消耗资源。
3.2.3 提高单机的最大吞吐量
提高单机的最大吞吐量是人们常忽略的一种优化资源利用率思路。在在线业务场景中，计算服务是否可用的衡量标准往往是超时率而不是CPU利用率。在超时率小于一定值的约束下，CPU可能还没有达到很高的负载机器就已经被标记为不可用了。引发这种问题的深层次原因是针对超时率的软件设计不合理，导致CPU资源没有被充分利用。常见的优化思路是通过加大并行处理度，降低响应时间，从而提高超时率约束下的CPU最大利用率，进而提高单机的最大吞吐量。
影响超时率约束下单机吞吐量的非线性因素还有很多，如Java的GC、线程切换、Cache Miss等等。本质上都是软件上的设计不合理导致CPU没有被充分利用。
3.3 降低机器资源单价
随着硬件技术发展，在硬件资源上我们有了更多的选择，如SSD、PMEM等等。在满足业务需要的前提下，合理选择不同成本的硬件，可以进一步优化成本。同时，这对技术人员提出了更高的要求，如何充分利用各种硬件特性、降低使用成本将是下一个阶段的重点话题。
四 总结
本文围绕第二章开头提到的核心公式，分析了机器成本优化的思路，并举出了具体事例，给出了一些的建议。文中所列出的思考可能不是最全面的，但是在成本问题上也许能提供一些可参考的分析方法，抛砖引玉，望大家能做出更全面的分析。