阿里妈妈技术 稿

丨本文作者： 木行、相遇、冰瞳、堇华、子瑞、叶卿等

动态算力系列文章：

🏷 动态算力起源-阿里妈妈展示广告引擎的“柔性”变形之路 [2020] https://www.infoq.cn/article/wEaIlWl7076Id2bQptAq

🏷 阿里妈妈展示广告引擎新探索：迈向全局最优算力分配 [2021]

🏷 阿里妈妈展示广告引擎动态算力再探索：面向业务收益的机器自适应调配 [2022]

在绿色计算和高质量发展的大背景下，算力的使用将朝着更加高效和智能的方向持续演进。 本文将介绍阿里妈妈广告引擎在优化算力使用方向上的最新实践 ，欢迎留言一起讨论。

写在前面

在追求绿色技术的大趋势下，充分利用好算力资源实现系统的高效运行，尤其是在阿里妈妈广告引擎这种使用近百万core的系统中，就显得尤为重要。动态算力正是基于这个背景开始探索和建设起来用于优化算力使用效率的技术。它始终围绕让系统更加高效智能，充分合理的使用算力这个目标进行。今年通过跟业务方的紧密合作，也落地了多个有代表性的功能，主要包括潮汐算力，同城互备以及大促快恢等。经过几年的探索和积累（可参考文章[1][2][3]），动态算力技术已经逐步形成自己的体系，具体如下：

图1 动态算力技术体系

图中标黑色字体的部分是前两年建设的，红色字体是今年新增的部分，灰色字体是持续推进建设的部分。

本文将分别从应用层，通用层和基础层展开介绍动态算力技术的新变化，以及动态算力在阿里妈妈统一广告系统开发框架EADS中的接入方式，最后会对现阶段的工作进行总结并概述未来发展方向。

一、应用层

1.1 日常应用

1.1.1 潮汐算力

1）离在线潮汐算力

展示广告引擎召回阶段日常存在两条链路，分别是在线和离线，离线负责全量标签召回，在线因RT限制负责实时增量标签召回。离在线潮汐算力的目标是通过实时调配离在线的机器比例，来提升资源使用率，从而节省机器资源。示意图如下：

图2 在离线潮汐算力原理示意图

在不影响离线任务实效性的前提下，节省整体机器资源。

基于动态算力的实时调控能力，技术架构图如下：

图3 在离线潮汐算力方案

图中oops动态分组可以实现10秒内完成分组机器比例的调整。

整个功能经过与业务同学的多轮调优最终得以顺利上线，整个召回系统机器节省数万core，比例接近20%，全链路RT均值下降2ms。日常调控图如下：

图4 真实在离线容器调整图

说明：红框处波动原因是早上6点定时切数据引起

2）在线潮汐算力

广告引擎的四大核心链路包括召回，排序，策略和创意均已接入动态算力，原有功能里动态算力只能降档，在系统容量不足的情况下调整档位以增加系统容量。虽然有离线混部提升晚间集群cpu水位，但是考虑到在线服务稳定性，混部拉升水位有严格的限制，并未充分使用空闲算力。在线系统水位仍然存在着比较明显的日间高，夜间低的潮汐现象，如下图某服务的夜间CPU低于10%。

图5 某核心服务一天CPU使用图

某场景夜间平均RT，比日常低20ms。

图6 某核心场景一天响应时间图

这些都意味着在凌晨还有空闲的算力并未得到充分利用，而且混部占用的资源带来的收益跟业务收益无法直接度量。基于上述情况结合动态算力实时调整的能力，完全可以实现日常低峰时对某些功能点进行升档，这样可以直接利用空闲CPU升档带来业务上的收益，也是一种在混部之上贴近业务层的充分精细化利用空闲算力的能力。

🏷 技术方案：

图7 在线潮汐算力方案

****🏷 实验效果： 小流量上实验情况，检索+粗排+精排 相比日常满档升档20%，多天累计实验效果cost + 0.8%, pv+0.6%, rpm + 0.2%。

1.1.2 同城互备

展示引擎经过多年发展，系统已经非常庞大。在线机器资源使用了近百万core CPU，随着集团对机器资源的控制， 增量机器资源有限 ；另外核心场景的 可用RT也到达上限 。因此不管是机器还是可用RT，展示引擎都没有空闲。这种情况下在线引擎机房间无法实现互备，线上一旦某个机房异常，无法即时切流止损，因为切流到另外一个机房，该机房因算力不足会出现大量超时甚至服务雪崩。展示引擎机房分布图如下：

图8 展示引擎机房分布图

但是日常高频的业务迭代，又无法避免线上偶尔会出现单机房异常(coredump或者数据异常导致客诉)，需要将流量切到正常的机房，此时需要接流的机房能够快速自动的调整扛住一倍的流量，并要求效果损失低于目标值10%，从而为定位并修复问题争取更多的时间。

🏷 落地过程

第一步 ：梳理所有流量场景，保障各流量场景核心服务均能被调控和切流。

第二步 ：单机房切流演练，通过优化调控策略以加快调控速度，另外重新分配各阶段均值RT以避免前端超时且降低效果损失。对于算力有明显瓶颈的模块(0档仍然无法满足RT要求)，进行适当的机器腾挪以满足稳定性和效果目标。

****🏷 技术方案

图9 同城互备功能方案

当需要机房切流时，对于接流的机房，人工打开该机房的同城互备功能：先关潮汐算力，将离线机器给在线用；然后通过全链路均值RT控制(自动化降各模块档位，优先降边际收益低的档位)，避免前端超时增加。

第三步 ：同城机房互切演练，拿到每个机房的效果损失数据形成报表。

****🏷 最终结果

切流后可以在3分钟内完成所有核心档位收敛，并在前端超时率增加低于1%的前提下，最差机房cost下跌低于7%，其他机房下跌均低于5%。

未来同城互备能力还需要进一步优化，包括自动化的去适应业务引擎的变更，日常定期产出切流后效果折损的预估报告，保障系统随时可以以预期的效果损失实现快速切流，成为保障线上系统稳定性的一个基础可靠的系统工具，先卡大故障，再卡小故障，最终实现无故障。

1.1.3 RT控制

展示引擎接入了数十个业务场景的流量，不同的场景前端给的可用RT不一样，但是又共用了一套引擎，那么当流量增加导致系统水位上升时，可用RT少的业务场景流量会先出现超时（现实中，虽然不同场景在不同阶段使用的策略有差异，可用RT少的场景策略会相对简单些，但存在有的模块在RT体现上差异不大，比如某场景A和某场景B的模型召回和精排）。今年新接入的场景B前端只给200ms，而其他核心场景均在300ms甚至更多。为了保证该场景的可用性，在高峰的时候就要自动降档实现RT的控制以避免超时。结合动态算力的RT控制功能，具体的技术方案如下：

图10 RT控制功能方案

在全局RT控制中，档位下调时会优先下调边际收益低(可参考[2][3])调控点的可用RT(均值)，该调控点可用RT下调后进而触发其档位下调，直到满足RT要求。

****🏷 实战效果

当该场景某机房前端超时率上升超过1%时，那么该场景对应机房的全局RT控制档位将逐步下调，保证前端超时率低于1%。超时率变化图：

图11 日常场景B na61机房前端超时率

****🏷 对应档位变化图

图12 日常场景B na61机房全局RT控制档位

今年在备战双十一压测过程中，前期未接入RT控制功能时，因为各场景流量都是数倍的增长，峰值附近系统水位非常高，部分机房场景B有几十个点的超时率。后面通过接入RT控制，超时率稳定在1%附近，顺利度过今年大促高峰。今年11.10大促高峰期间场景B控制效果图如下：

图13 大促高峰期间场景B na61机房前端超时率

图14 大促高峰期间场景B na61机房全局RT控制档位

另外全局RT控制有严格的实时报警以及档位波动记录，保障调控都在预期之内。

1.2 大促应用

1.2.1 大促峰值预调与快恢

功能描述：19:59:00定时生效峰值档位集合以应对10倍的峰值流量，20:01:00开启自动调控，进入快速恢复模式。随着流量下降，档位快速回升。所有功能点3分钟完成收敛。

****🏷 实战情况

1）峰值实际流量

图15 20:00附近流量图

2）档位回升：3分钟内基本恢复到满档

图16 20:00附近检索档位

3）核心模块cpu回升

图17 20:00附近air cpu使用情况

4）展示整体cpu（20:01后开启自动调,快速恢复,cpu3分钟内完成快速拉升）

图18 展示引擎整体CPU使用率

展示引擎CPU使用率长时间排名前列。

图19 AIOS在线CPU利用率排名

说明：该功能只针对流量大边际收益低的场景，边际收益高的场景完全自动调控。

1.2.2 定时设置档位上限

功能描述： 为避免快速恢复模式下，部分模块出现超时率毛刺，将边际收益低的场景和模块，在快恢阶段设置档位上限(设置了档位上限，但仍然会根据目标自动调整，所以会在局部波动)。实战情况如下：

图20 20:00附近购后粗排档位变化图

二、通用层

2.1 调控策略

1）dynamic container group regulator : 动态容器分组调控器，支持通过oops http接口调整各分组机器比例，支持多目标设置，支持每个目标不同收敛区间

2）multi goal negative feedback regulator : 基于反馈的多目标流量调控器，支持多目标设置，支持不同机房设置不同目标。

2.2 metric输入

新增Metric支持配置化接入，源头目前支持包括：黄金眼相关指标，blink任务相关指标，tpp相关指标，Eads引擎kmon指标和one-engine khronos指标。

2.3 metric处理策略

1）支持不同metric使用不同采集频率和采集时间段

2）均值策略，多路并发取最大均值策略等

2.4 灵活的定时功能

1）支持秒级别定时的功能，不同时间生效不同的max档位，不同的fix档位，不同的调控目标以及不同的档位模版。充分匹配广告业务场景的特点，如0点检索深度突增，大促整点流量突增等。

三、基础层

3.1 管控升级

1) 增加发布diff功能

图21 版本对比功能

2）调控策略模版化

图22 版本对比功能

3.2 视图升级

1）档位支持明细显示

图23 档位明细图

2）档位历史曲线

图24 档位历史曲线图

3）支持档位快照功能，用于记录档位数据

图25 档位快照功能

四、新的接入方式

4.1 整体介绍

下图蓝色部分是动态算力系统组成部分，绿色部分是业务方需要接入动态算力的服务。

图26 业务App接入

动态算力系统分两部分，分别是：

1）client端(agent)

以sdk形式提供给接入方(支持c++,java)，主要负责跟controller交互，获取当前调控点（由controller计算的）最大档位，支持本地个性化调控策略(个性化算力dcaf，qscore以及用户自定义策略实现不同用户不同档位)。

图27 功能集合

2）server端(controller + 管控 + 视图)

server负责接收用户在管控上选择的调控策略以及档位模版，并实时运行选择最优档位(当前算力资源下该调控点整体的档位)，将档位数据下发给agent，另外视图负责展示整个调控状态。

4.2 EADS服务的接入

动态算力的Agent已经合并到Eads框架中，相比之前接入更加简便，并且配有详细的接入手册，接入内容上的变化如下：

项名	旧版	新版
配置文件	两个	无
机房zk配置	明确指定	通过环境变量自动渲染
ID配置	每个应用需要单独申请APPID	同业务线所有服务共享APPID
参数获取代码	8行	1行
参数传递	不支持	支持op间和服务间传参
流控&RT控制	需要6行代码调用	配置化

五、总结与展望

经过几年的发展，动态算力在算力分配策略上更加全面，在度量上也逐步精细化，应用的场景也渐多元化。相应的应用则可以总结为下图：

图28 动态算力的应用

通过抽象封装，将常用的算力分配能力功能化，再加上轻简的使用方式，目前动态算力已具备平台化接入的能力。不过动态算力技术虽然已初成体系，但其离真正实现全局(跨场景，跨业务线，跨模块)最优算力分配和智慧引擎还有很长的一段路要走。未来希望继续探索算力、容量和效果之间的关系，尝试更优的决策算法进行算力的分配。另外在技术的通用性上，我们也会持续优化，进一步提升用户体验。

绿色智能技术方向上的探索在业界已然兴起，如何把有限的算力资源用好，利用通用的效率模型和体系化的方案解决好这个问题是一件非常有挑战且有价值的事情。而动态算力始终朝着让系统更加稳定，更加高效和智能的方向持续演进，期待未来在线引擎能够像变形金刚一样动起来。

关于我们： 我们是阿里妈妈工程平台-引擎服务团队，致力于打造绿色智能的在线引擎。动态算力是一个共建项目，它是在各兄弟团队的通力合作下不断成长起来的，包括广告算法，业务引擎，引擎平台以及技术质量等团队。

参考

[1] 动态算力起源-阿里妈妈展示广告引擎的“柔性”变形之路：https://www.infoq.cn/article/wEaIlWl7076Id2bQptAq

[2] 阿里妈妈展示广告引擎新探索：迈向全局最优算力分配

[3]阿里妈妈展示广告引擎动态算力再探索：面向业务收益的机器自适应调配