【论文】略读笔记45-前沿-字节跳动统一调度架构

📖《Gödel: Unified Large-Scale Resource Management and Scheduling at ByteDance》

🎯需求

• 在过去几年中，由于业务增长迅速，ByteDance 的计算基础架构规模显著扩大。
  • 在字节跳动，为了满足豆瓣和 TikTok 等快速增长的业务需求，我们在全球范围内运营着由数十个大型集群组成的超大规模计算基础设施。此外，每天都有数以亿计的容器化任务在这些集群中提交和执行。
  • 因此，如何及时调度这些任务并充分利用高弹性的底层计算资源，是我们近年来面临的一个日益严峻的挑战。
• 我们的生产环境在数据中心拥有异构的机器和不同的工作负载，它们有着不同的资源需求和服务水平协议（SLA）。例如，
  • 1）微服务、在线推理和数据库等关键业务服务；
  • 2）大量数据分析或机器学习（ML）模型训练等低优先级工作。
  • 值得注意的是，这些工作负载对拓扑结构的偏好也各不相同。以我们业界领先的生态推荐系统为例，
    • 该在线推荐服务依赖于一系列预先训练好的 ML 模型，这些模型始终存储在内存中，以降低获取延迟。
    • 因此，这类工作负载通常需要专门占用专用的 NUMA 节点，或者与其他非内存密集型任务共享一个 NUMA 节点。
• 因此，在集群中调度任务时，我们必须考虑到所有要求。遗憾的是，我们发现在现有的协调平台上，要满足所有约束条件并同时保持较高的资源利用率相当具有挑战性。

🚧现状

• 我们对生产调度系统的主要要求是在异构机器上调度各种工作负载（如表 1 所列），提高资源利用率，跟上每个计算集群不断增长的机器规模，并实现高吞吐量。
• 使用事实上的开源调度器并不能满足我们的所有要求，例如
  • 1）Kubernetes，它能为微服务提供灵活的资源分配/亲和性，但存在可扩展性问题；
  • 2）YARN，更适合需要复杂调度语义（即 Gang 调度）的批处理作业，但缺乏对微服务的支持。
• 学术界研究了不同的调度系统，如单体调度器、两级调度器和分散式多调度器，但每种调度系统在实现我们的生产目标方面都有不足之处。
  • 3）单体调度器面临高吞吐量的挑战，而且难以添加定制的调度策略。
  • 4）两级调度器采用资源管理器在不同调度器之间划分资源，但这种悲观的锁定方式会损害资源间的资源弹性。
• 为了满足超大规模的增长，一些业务部门采用了运行不同调度系统（如 Kubernetes、YARN）的方式来管理自己的计算基础架构堆栈，这造成了两大痛点：不同业务部门之间的资源日益分散，不同业务优先级的工作负载之间的资源弹性不足。不同业务群组之间的隔离（及其计算基础设施管理）导致计算资源利用效率低下，无法长期满足业务增长需求。
  • 5）在 ByteDance，在 Gödel 之前，我们在同一个计算集群上同时运行 Kubernetes 和 YARN，由资源管理器在它们之间调度资源。
    • 这种方法提高了我们的资源利用率，但在调度器之间转移资源会降低弹性，影响吞吐量。
  • 6）Borg、Omega 及其开源实现 Kubernetes 提出的分散式多调度器可以使用不同的调度器，每个调度器都可以访问整个计算集群，并使用乐观并发控制解决调度冲突。
    • 然而，Kubernetes 解决节点级冲突是为了防止资源过度投入，这在调度周期中为时已晚，会降低吞吐量和集群规模。
• 从我们之前的经验和学术研究中，我们发现需要建立一个统一的调度器，它可以为不同的工作负载及其调度策略提供丰富的语义支持，可以横向扩展以满足我们的吞吐量和可扩展性需求，还可以共同定位工作负载以提高资源利用率。
  

🛩创新

• 为了应对这些挑战，我们提出了一个名为 Gödel 的资源管理和调度系统。
  • 它为所有业务部门提供了一个统一的计算基础设施，以便在统一的资源池下运行各种工作负载。它将各种工作负载集中在每台机器上，以实现更好的资源利用率和弹性。
  • Gödel 基于 Kubernetes（事实上的开源容器编排系统）构建，但其核心调度器使用全局共享状态调度器进行了重新发明。相应地，我们还大幅增强了其周边组件。通过替换或增强重要组件，实现适应大规模的各种工作负载。
• 本文的贡献如下：
  • （1）我们引入了一种统一异构资源的新模式（？），以共同定位在线和离线工作负载，从而在超大规模上提供更好的拓扑亲和性、更高的资源弹性和更低的运营开销。
  • （2）我们在 Kubernetes 的基础上设计并实现了名为 Gödel 的新型资源管理和调度系统。我们对 Kubernetes 进行了多项优化和增强，以提高调度性能。
  • (3) 我们在 ByteDance 的多个数据中心部署了 Gödel，这些数据中心拥有数万台机器，除了在模拟环境中进行密集测试外，我们还在实际工作负载下进行了评估。对 Gödel 的详细评估证明了它的实用性以及如何实现我们的目标。我们的结果表明，Gödel 在各种调度方案中都实现了卓越的性能和效率。
• 本文报告了我们使用 Gödel 的设计和实施情况。此外，本文还讨论了我们在 ByteDance 大规模生产中开发和运行 Gödel 的经验教训和最佳实践。

📊效果

• 在 Bytedance 的生产环境中构建一个新的调度程序，以适应超大规模的异构资源和工作负载，是一个极具挑战性的过程。
• 在生产中，它可以管理拥有数万台机器的集群，总体资源利用率超过 60%，调度吞吐量高达每秒 5000 个 pod。
  • 自2021年以来，Gödel已被部署到字节舞团的多个生产集群中，每个集群都有数万个节点。
  • 它的性能符合预期，并表现出良好的稳定性、可扩展性和弹性。
  • 我们在模拟测试平台和生产环境中对其进行了评估。评估结果表明，Gödel 在持续处理在线和离线作业方面优于 vanilla Kubernetes，同时提供了更高的调度吞吐量。
    • 具体来说，我们可以在单个哥德尔集群上实现高达 5000 pods/second 的吞吐量，同时保持约 60% 的总体资源利用率。
    • 对于内存敏感型工作负载，在哥德尔启用的拓扑感知调度的帮助下，数据获取延迟降低了 20% 以上。
    • 此外，与我们的传统部署模式相比，Gödel 可以在几分钟内（而不是几小时或几天）在关键业务服务和低优先级工作之间转移计算资源，以应对突发的流量变化，无需人工干预。

⛳️未来机会

• 未来还有很大的改进空间。
• 1）目前，调度器、调度程序和粘合剂所使用的过渡阶段都持久存在 ETCD 中（通过 API 服务器）。我们正在研究使用内存中缓存来处理过渡状态，预计其扩展能力将超过 ETCD，吞吐量也将提高近一倍，达到每秒 10,000 个 pod。
• 2）此外，哥德尔调度程序的设计基于乐观并发控制，降低冲突率对提高吞吐量至关重要。目前，我们观察到的冲突率平均为 1%，而在最糟糕的情况下（集群分配率超过 90%）则为 5%。我们的目标是实现 0.1% 的冲突率。
• 3）此外，我们还在努力将节点和 pod 智能调度到不同的调度器（？），以减少冲突并更好地平衡各调度器之间的负载。
• 4）最后，我们正在积极研究并在生产中部署哥德尔重调度程序。重调度器用于监控正在运行的 pod，并采取抢占式行动来减少碎片和资源争用，从而为关键工作负载实现更高的服务质量。重调度程序中实施的一些措施包括对突发工作负载的 CPU 和内存利用率进行节流，平衡集群以实现统一的网络和功耗，以及减少高分配集群中的碎片问题。

🧠疑问

1. 该场景中也提到“复杂拓扑”的困难，但它的角度是“ML工作流结构下前后任务可以利用 NUMA 架构降低传输延迟”。这和以往的工作流调度有什么区别？有什么特殊难点？
2. 本文对于难点的总结似乎不够精炼。每一种调度架构的缺点之间有什么逻辑关系（乍一看很乱）？和我们以前总结的是否有不同？带来了什么独特的挑战？
3. “共同定位”工作负载的意思是什么？是指迁移吗？还是伸缩？还是迁移+伸缩？

---

---

• 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
• 如果你喜欢这篇文章，欢迎动动小手 给我一个follow或star。

🗺参考文献

[1] Gödel: Unified Large-Scale Resource Management and Scheduling at ByteDance