MCCS: A Service-based Approach to Collective Communication for Multi-Tenant Cloud

研究背景

集体通信在支持许多分布式计算工作负载中起着至关重要的作用。目前有多种广泛使用的集体通信库，如NVIDIA的NCCL、Intel MPI库、OpenMPI和Gloo等。这些库提供了常用的集体通信原语（如AllReduce和AllGather），开发者可以通过将这些库直接链接到其应用程序中来使用。在这些库的高级API之下，集体通信原语通过各种算法（例如基于环或树的AllReduce）实现，并且通常针对硬件进行了高度优化（如NVIDIA的SHARP）。

聚焦问题

在多租户的云环境中，现有集体通信方法的局限性：

  1. 缺乏物理网络拓扑信息：在公有云环境中，云租户（使用云服务的用户）通常无法获取底层物理网络的拓扑结构和链路利用率信息。而这些信息对选择高效的通信算法非常重要，比如在分布式训练中经常使用的环形算法（ring-based algorithms）和树形算法（tree-based algorithms）。由于租户没有这类信息，可能会在算法选择或配置上做出次优决策。例如，在环形算法中，不同节点参与的顺序会影响通信的效率，但如果不了解物理网络的信息，可能会选择不理想的节点顺序，从而影响性能。
  2. 通信策略不可动态调整：现有的通信库通常在初始化时就决定了通信的策略，并且一旦工作负载开始，策略就不会再调整。这种方法在单租户环境（如超级计算机）中是可以接受的，因为单租户的工作负载和通信模式在运行期间是相对稳定的。然而，在多租户环境（如公有云）中，多个租户同时共享相同的网络资源，而不同租户的通信模式会影响最佳的通信策略。例如，如果其他租户的通信模式发生变化，最初选择的算法可能就不再是最佳选择，导致性能下降。
  3. 与物理网络配置无关的优化假设：现有的通信库通常会在不了解底层物理网络配置的情况下做出一些优化选择，这些优化往往依赖于对网络配置的假设。例如，NCCL会在节点之间建立多个TCP或RDMA连接，试图通过并行利用多个网络路径来提高吞吐量。然而，这些连接可能会被路由到相同的物理路径上，从而共享带宽，而不是增加总带宽。换句话说，虽然理论上这些优化能够提高性能，但如果底层网络并不支持这种优化（如多连接走同一路径），那么这种优化实际上可能无法发挥作用，甚至可能带来额外的开销。

本文工作

  1. MCCS的核心思想： MCCS将传统的集体通信抽象暴露给应用程序，但它的实现方式与应用程序本身解耦。这意味着云服务的租户（用户）不再需要负责自己实现这些集体通信操作，而是将其交给云基础设施提供者管理。这解决了前面提到的租户缺乏物理网络信息、无法做出最佳通信算法选择的问题。云服务提供者掌握物理网络的详细信息，因此可以做出更智能的优化决策。
  2. 解决信息不可见性的问题：由于MCCS不再要求租户来选择和实现集体通信，租户不需要再依赖那些他们无法获得的信息（如物理网络的配置、其他租户应用的通信模式等）。这种责任转移给云服务提供者，后者可以利用其对网络和其他租户工作负载的全局视图来优化集体通信的实现。
  3. 云服务商获得了更大的灵活性： MCCS不仅将实现控制交给了云提供者，还让他们有更大的灵活性，带来了几个好处：
    • 定制化集体通信：云提供者可以在不需要更改用户应用程序的前提下，采用定制的或专有的集体通信实现方式。这样可以在保障现有应用兼容性的同时，利用特定的优化方法提升性能。
    • 细粒度的服务质量（QoS）控制：云提供者可以在集体通信操作的层面上执行更加精细的服务质量策略。例如，提供者可以为某些通信操作分配更多的网络带宽或优先级，从而优化通信性能，这在多租户环境中尤其重要。
    • 兼顾性能和保密性：在传统方法中，云提供者在提供高性能和保护其专有基础设施机密性之间往往需要权衡。MCCS允许云提供者同时保证这两者，因为集体通信的细节实现对用户是不可见的，云提供者可以在不暴露专有基础设施细节的情况下进行优化。

实现细节

  1. 为MCCS实现了一个轻量级的shim库，这个库的作用是充当应用程序与MCCS系统服务之间的桥梁。Shim库是位于应用程序和系统服务之间的一层“中间件”，它将应用程序的集体通信请求转发给MCCS的系统服务，而应用程序无需直接修改代码或底层实现。这使得MCCS可以与现有的应用程序无缝集成，同时替换底层的集体通信机制。
  2. 集成NCCL中的现有算法： MCCS能够集成NCCL（NVIDIA Collective Communications Library）中的现有集体通信算法，尤其是那些基于CUDA内核实现的算法。这意味着MCCS可以利用现有的GPU集体通信能力，而无需从头实现所有算法。通过集成这些已有算法，MCCS可以直接支持广泛应用于GPU集群中的常用集体通信操作（如all-reduce、broadcast等）。
  3. 支持自定义算法：除了集成现有的NCCL算法，MCCS还支持自定义的集体通信算法。这使得MCCS不仅能够适应现有算法的工作负载，还可以为云服务提供者或开发者提供定制优化的空间。通过支持自定义算法，MCCS能够在特定网络和工作负载场景下进行更深入的优化。

贡献

  1. 多租户集体通信架构：一种新的架构，用于支持多租户场景中的集体通信，将控制权从应用程序转移到云网络以提高性能。

  2. 动态重配置集体实现的方案：意味着MCCS能够在运行时对集体通信操作进行重新配置。在传统系统中，集体通信的算法和策略通常在初始化时确定，之后不会改变。而MCCS引入了一种机制，允许在任务执行的过程中根据当前网络状况或工作负载需求，动态调整集体通信的实现，以提高性能。

    举个例子，假设在分布式训练过程中，某些节点的网络负载突然增加，传统的集体通信算法可能会因此性能下降。但有了MCCS，这些通信策略可以动态调整，从而避免性能瓶颈。例如，它可以在执行过程中从环形通信（ring-based）切换到树形通信（tree-based），根据当前的网络条件和负载做出最优选择。

    同时，他们还利用这种动态重配置来展示强大的策略支持，如跨应用的协作传输调度。这意味着MCCS不仅仅为单个应用程序优化通信，还能在多租户（多个应用程序同时运行）的环境下，协调不同应用程序的通信任务，避免资源冲突，提升整体性能。

  3. MCCS的原型实现：第二段谈到的是MCCS的原型实现，专门针对分布式机器学习工作负载。它的设计概念是作为NCCL的一个“即插即用替代品”。这意味着，对于使用NCCL的应用程序，MCCS可以无缝替换NCCL，而无需对应用程序本身做出太多修改。这种设计使得用户可以继续使用现有的应用代码，只需替换通信库，便能享受MCCS带来的性能优化和灵活性。