动态闲置资源租赁系统论文Note

论文标题：Dynamic Idle Resource Leasing To Safely Oversubscribe Capacity At Meta
会议：ACM SoCC 2024（11月）

背景

Meta 自家私有云集群，为了应对负载峰值、故障恢复和未来增长，会大量预留资源。
这些预留资源大多数时间都是闲置的，造成了浪费（成本 + 碳排）。

那能不能“安全地”利用这些dark capacity？比如给不重要的任务临时用一下？但关键是要保证不能影响到正式服务的 SLO（Service-Level Objectives）。

论文核心贡献

1. 被动缓冲区（Passive Buffers）回收机制

把资源分两类：

  • 主动 buffer：活跃服务器中的空余 headroom
  • 被动 buffer：完全没被用的服务器（最容易被浪费）

他们把被动的这一块提取出来，放进“弹性资源池”（elastic pool）里让其他任务租用。

2. 动态资源租赁平台（Leasing Platform）

  • 提供两类租用服务：
    • **High-Availability (HA)**：保证 95% 的时段能获取资源
    • **Best-Effort (BE)**：完全不保证，资源充足才给
  • 用的是 SpotVM 类似的“整台服务器”抽象，几乎不需要用户改代码

3. 大规模落地效果

这个系统在 Meta 内部跑了 3.5 年，成功 oversubscribe 数百万台主机，减少了大约 25% 的物理部署量（超省硬件 & 电力）

识别 Passive Buffer

  • 每个区域的 auto-scaler 会预留一些服务器用于单区故障（Worst-case region failure）
  • 这些预留的但当前没用到的服务器，就变成了被动 buffer
  • 然后统一汇总进资源池中，用于弹性租赁

动态租赁平台怎么设计？

资源请求

  • 用户通过 portal 填表：需要什么 tier（HA/BE）、多少台、多久、什么硬件类型

Admission 控制逻辑

  • 系统用 Prophet 模型预测供应量（MAPE 小于 5%）
  • 给 HA 请求留 buffer 后再发配额（HA ≤ 预测 - buffer）

分配器（Allocation Solver）

  • 每 5 分钟跑一次 MILP 算法，做区域内的 bin-packing，把空闲主机分配给需求

回收机制

  • 如果要回收被租出去的主机，会先发 SIGTERM（30 秒），再发 SIGKILL 彻底终止，让任务有机会优雅退出

效果

资源利用率

  • 每天有 22~30% 的请求通过弹性租赁满足
  • 大幅减少了基础设施投入和碳足迹

故障恢复能力

  • 某个区域故障后，其他区域可额外扛 9% 的 CPU 负载
  • 作业 size 增加了 3%（基本可控）

回收延迟

  • 中位数 1.75 分钟
  • P99 延迟 6.2 分钟

性能影响

  • 排序服务（ranking）：HA 租赁和保底资源表现几乎一样，tail 有轻微影响
  • 实时日志读取服务：HA 情况下 tail latency 高出 2–6%

服务满足率和连续运行时间

  • HA 类型平均满足率 >99.5%（σ = 0.3%）
    • 90% 的主机能持续运行至少 1 小时
  • BE 类型也有 97% 满足率，70% 主机能稳定用一段时间

经验教训

  • Best-Effort 滥用：有些服务偷偷太依赖 BE 容量，建议定期做“资源断电演练”
  • 硬件可替换性问题：误把存储服务器当成计算服务器用了，结果电力热热点过高，触发断电限电
  • 调度配置出错：有次把 scheduler 的保底资源也当作闲置捐出去了，后来加了安全机制防止