[Paper] Metronome:差异化延迟调度用于 Serverless Functions
发布: (2025年12月5日 GMT+8 21:30)
8 min read
原文: arXiv
Source: arXiv - 2512.05703v1
概览
无服务器平台(FaaS)承诺“按需付费”计算而无需自行配置服务器,但底层调度器仍难以高效地放置函数。论文 Metronome: Differentiated Delay Scheduling for Serverless Functions 探讨了为什么 Hadoop 风格集群中的经典延迟调度技巧不能直接套用到无服务器工作负载,并提出了一种基于机器学习的调度器,能够为每个函数自适应延迟,以在满足 SLA 的前提下降低延迟。
主要贡献
- 无服务器延迟调度的实证研究 – 系统评估现有技术,揭示了无服务器工作负载的三条不明显特性(输入依赖的局部性收益、数据 + 基础设施双重局部性、以及执行时间的异构性)。
- 差异化延迟概念 – Metronome 不采用“一刀切”的延迟阈值,而是对每个函数决定等待“更好”节点的时长。
- 在线随机森林回归模型 – 使用轻量级运行时特征预测函数在每个候选节点上的执行时间,使调度器能够选择最小化整体延迟的节点。
- SLA 感知的延迟控制 – 模型输出安全边界,保证所选延迟不会导致函数超过截止时间。
- 在 OpenLambda 上的原型实现 – 真实环境实验显示,与原生 OpenLambda 及其他基线相比,平均执行时间降低 64.9 %–95.8 %,即使在高并发情况下亦如此。
方法论
- 工作负载特征化 – 作者在 OpenLambda 上运行多种基准函数(CPU 密集、I/O 密集、数据密集),记录当函数等待“本地”节点时延迟的提升位置。
- 观察提取 – 归纳出三种模式:
- (a) 局部性收益随输入大小而变,
- (b) “本地”既可以指数据存储在同一存储节点,也可以指运行在同一物理主机上(基础设施局部性),
- (c) 执行时间差异极大,导致静态延迟阈值失效。
- 预测调度器设计 – Metronome 维护一个在线随机森林模型,输入包括:
- 函数元数据(输入大小、语言运行时、内存请求)
- 节点状态(CPU 负载、网络带宽、缓存数据是否命中)
- 该节点上的历史执行时间
模型输出每个候选节点的预计运行时长。
- 延迟决策逻辑 – 对于新到达的函数,Metronome:
- 计算当前可用节点的 预期 完成时间;
- 检查等待模型认为的“更好”节点是否能更早完成且仍在 SLA 范围内;
- 若满足条件,则延迟调度;否则立即调度。
- 实现与评估 – 将调度器集成到 OpenLambda 的调度器中,测试不同并发水平(最高 500 并发调用),并与以下基线比较:
- 无延迟(立即调度)
- 固定阈值延迟调度(经典方法)
- 随机放置基线
结果与发现
| 指标 | Metronome | 固定延迟 | 立即调度 | 随机 |
|---|---|---|---|---|
| 相对于立即调度的平均执行时间降低 | 64.9 % – 95.8 % | 12 % – 28 % | – | 5 % – 10 % |
| SLA 违规率 | 0 %(95 % 置信区间内) | 3 % – 7 % | 0 %(但延迟更高) | 0 %(但速度更慢) |
| 高并发下的吞吐量(500 req/s) | 比固定延迟提升 +22 % | – | – | – |
| 开销(模型推理 + 记录) | 大约 2 ms/请求 | 可忽略 | – | – |
关键要点
- 预测延迟优于静态阈值,因为它根据每个函数的特性和当前集群状态定制等待时间。
- 双重局部性重要——数据缓存 以及 与同一物理主机共址能够显著降低数据密集函数的网络延迟。
- SLA 安全得到保障——模型的置信区间用于限制最大允许延迟,防止错过截止时间。
实际意义
- 无服务器提供商可以在调度器中嵌入轻量级预测器,在不增加硬件投入的情况下获得延迟提升。
- 开发者只需开启平台的“局部感知”模式,即可获得数据密集函数更低的冷启动时间,无需修改代码。
- 面向边缘的 FaaS(如 Cloudflare Workers、AWS Lambda@Edge)可以采用差异化延迟思路,决定是在就近边缘节点运行函数还是回退到中心数据中心,以在延迟与资源可用性之间取得平衡。
- 成本优化——更短的执行时间直接转化为更低的计费计算秒,尤其对高频微服务影响显著。
- 可观测性工具——用于预测的运行时特征(输入大小、缓存命中等)同样是调试和容量规划的宝贵信号。
局限性与未来工作
- 模型新鲜度——随机森林会定期重新训练,工作负载快速变化时可能暂时降低预测精度。
- 特征集平台依赖;将 Metronome 移植到其他 FaaS 堆栈(AWS Lambda、Azure Functions)需要重新设计遥测收集。
- 预测器的可扩展性——虽然推理开销低,但在大规模(数万节点)环境下维护每节点模型可能需要层次化或联邦学习方案。
- 安全与多租户隔离——向调度器暴露节点级负载信息可能引发隔离问题,未来设计必须防止跨租户信息泄露。
- 作者建议探索 强化学习 调度器,直接优化复合目标(延迟 + 成本 + SLA),并研究 异构硬件(GPU/FPGA)场景下更为细致的局部性决策。
作者
- Zhuangbin Chen
- Juzheng Zheng
- Zibin Zheng
论文信息
- arXiv ID: 2512.05703v1
- 分类: cs.SE, cs.DC
- 发布日期: 2025 年 12 月 5 日
- PDF: Download PDF