论文阅读《HiveMind：A Hardware-Software System Stack for Serverless Edge Swarms》

HiveMind: 一个针对无服务器边缘集群的硬件-软件系统堆栈

摘要

自主设备的数量不断增加，这使得重新考虑其硬件-软件系统堆栈的必要性至关重要。我们提出了HiveMind，这是第一个群协调平台，使云和边缘资源以可编程的方式在云和边缘资源之间可编程执行复杂任务工作流。HiveMind是一个软硬件平台，包括一个特定领域的语言，用于简化云边缘的应用程序可编程性，一个自动探索任务放置策略的程序综合工具，一个利用无服务器计算来弹性地扩展云资源的集中控制器，以及一个用于网络和远程内存访问的可重构硬件加速结构。

我们在无人机和智能汽车这两个真实的边缘系统上应用了我们的端到端的HiveMind系统，量化了无服务器引入到边缘应用程序中的机遇和挑战，以及集中式和分布式协调之间的权衡。HiveMind实现了更好的性能可预测性和电池效率，以及更低的网络流量。经过真实和模拟器的验证，我们的系统可以在不损耗性能的前提下扩展到上千个边缘系设备，证明了可扩展性和高性能。

关键词

无服务器，边缘群，物联网，云计算，硬件加速，领域特定语言

引言

边缘设备群在数量和尺寸上都在增长，这些群支持具有间歇性的活动特点的应用程序，从统计灾区人口，到监控农作物，以及驾驶自动驾驶车辆。这些设备本身的功耗低、适度的资源，而且容易出现不可靠的网络连接。

随着设备群规模的增加，设计一个硬件-软件系统堆栈，使跨云和边缘设备的资源能够进行可编程和高性能的操作，这成为一个迫切的需要。之前的工作研究了集中式和分布式的特点，分布式中大多数决策都发生在后端的云基础设施中，而分布式中每个边缘设备是自主的，本地执行并传输结果。但这两种方法都不是最优的。集中式虽然有全局可见性，但是很容易遇到设备上限的瓶颈，分布式虽然规模更大，但是设备间协调出现障碍，特别是有冗余计算时。

HiveMind依赖于三个主要的组件：

1. 提出了一种高级声明式编程模型，供用户表达其应用程序的任务图，抽象化了显式管理云和边缘资源的复杂性。

2. 使用一个集中的、云驻留的控制器，对群的状态和可用资源具有全局可见性。

3. 在硬件层面提出了一种可重构的、基于FPGA的加速结构，用于边缘和云资源之间以及云服务器之间的远程内存访问和网络访问。

HiveMind实现了最好的集中和分布式协调，同时减轻了用户管理云边缘资源的负担。

我们在真实环境中实验了我们的系统，包括16架无人机和12台机器的后端服务集群，也移植在14个机器人上。实现了一个基准，包含广泛的边缘应用程序，例如SLAM（同时定位与地图构建），图像识别和天气分析等。下图所示为一个无人机定位网球场景下的与完全集中式和分布式相比下，HiveMind表现出的性能和能源效率。

HiveMind中的每个软硬件组件对于实现这些好处都是必不可少的，尽管它的机制也可以独立使用，例如，云中没有FPGA加速的情况。

群体协调设计的权衡

我们首先量化了群协调中集中式方法和分布式方法之间的权衡，以确定可以在硬件中加速的开销，以及可以通过更好的软件接口来解决的可编程性瓶颈。所有的实验都是在一个真正的无人机群上端到端完成的，用一个服务器集群作为云后端。

方法

单阶段场景：S1:使用FaceNet来进行人脸识别，S2:使用CNN来识别树，S3:无人机识别，S4:障碍回避，S5:重复人物删除，S6:迷宫算法，S7:天气分析，S8:土壤分析，S9:文本识别和S10:SLAM。

多阶段场景：除了之前的应用外，我们还构建了两个端到端场景，每个场景都有多个计算阶段和I/O阶段，以检查无人机群更有代表性的用例，如图所示。

• A场景下的任务是定位一个棒球场中的15个网球。在开始时，无人机之间平均分配在场地内，其中每个无人机都试图最小化旅行的总距离。除了收集图像，每架无人机还运行一个车载避障引擎，基于SVM分类器的无人机自主识别树木、人、无人机和建筑物。

• B场景下的任务是需要识别和统计一个棒球场上的人数，由于人们可以移动，所以还需要消除不同无人机拍下的同一个人引发的歧义，基于FaceNet 人脸识别框架来进行识别。

网络开销

图a显示了我们检查的网络处理，任务执行和管理操作的时间占比，这里的服务没有以最大负载运行，因此网络不会超过最大负载。

图b显示了人脸识别中无人机收集高分辨率图像的带宽和尾延迟，对于少于4架无人机，尾部延迟仍然很低，即使是最大分辨率（800万像素）。随着无人机数量的增加，网络达到饱和，延迟也急剧增加。

集中式执行与分布式执行之间的对比

我们研究了集中式执行与分布式执行之间的权衡，集中式即所有的计算和数据聚合都发生在服务器集群中，而不是完全分散的环境；分布式即在边缘设备上进行计算，只有最终的输出被传输到云中。

上文提到了一共S1-S10十个任务，这10个作业中的每一个运行120秒，重复10次，每个端到端场景运行到完成，重复50次。下图a显示了10个单层作业中的任务延迟分布，图b显示了两个端到端场景中的任务延迟分布。

对于大多数任务来讲，集中执行比分布式执行获得了更好的，可预测的性能。这种差异即来自于服务器节点更高的计算和内存能力，还源于serverless更高的并发性。但是可见S3（无人机识别）、S4（障碍回避）、S7（天气分析）三个样例，差异并不大，这是因为适度的资源需求，它们通过避免数据传输，就地调整路由，而不是更新路由，所以导致的边缘分布式获得了较好的性能。尽管云服务器有性能优势，但也造成了网络流量的增加，损害了最后的性能。

除了性能比较之外，机载执行会迅速耗尽无人机的电池，由于一些无人机耗尽了能量，导致第二种情况不完整。

无服务器在边缘群中的作用

从之前的研究可以看出，集中控制在性能和资源方面比较有优势，但存在较高的网络开销和可伸缩性的瓶颈，所以我们采用了serverless的方式为云后端提供服务。

serverless背景

serverless或功能即服务（FaaS）计算最近已成为一种经济有效的替代方案，用于具有高数据级并行性、间歇性活动、波动负载和大多数无状态操作的应用程序，对于这些程序，维护长时间运行的资源是低效的，所以按照需要进行运行减少了过度的资源浪费。

物联网（IoT）应用程序特别适合serverless，因为它们断断续续，以及仅需要少量的机载资源。

serverless机遇

并发性：下图a显示了在容器数据中心中使用固定数量的云资源，以及在使用serverless和没有任务内并行时，在恒定加载下所有10个应用程序的任务延迟分布。可以看出即使没有任务内并行，serverless也比普通的固定分配要性能更好。

只要边缘应用程序具有足够的并行性（数据、任务或请求级），serverless就提高性能。但是也引入了两个问题，一是函数之间的干扰会或使用同一个物理节点，导致延迟稍高，二是并行性并非是免费的，分发和聚合依旧导致数据共享和同步的开销。

弹性：下图b显示了在波动负载情况下的人脸识别的延迟，首先有一个无人机低帧率发送，然后更多的无人机以高帧率发送，再慢慢降低为一个无人机发送。经过我们的比较，发现虽然serverless密切关注负载，但是平均负载很快就达到饱和，影响延迟，不过由于边缘设备的间歇性活动，静态配置云资源仍旧是低效的。

容错性：下图c显示了相同的波动负载场景下，当许多功能在执行过程中出现故障时，随时间变化的任务数。OpenWhisk能够隐藏增加的工作负载，通过在新核上降低端到端执行时间之前快速重组任务。这对于边缘服务很重要，因为有故障或丢失的传感器数据可能会导致任务失败。

serverless挑战

性能可预测性：下图a表示出了与云资源相比，serverless具有更高的性能。对于所有10个作业，我们展示了在保留云资源部署和serverless部署上的任务延迟分布图，serverless的延迟可变性始终较高，类似的差异在保留云资源中不那么明显。这是由于serverless的实例化开销，确定任务分配时的开销，以及依赖函数之间的数据共享开销。大多数的商业serverless平台都不允许函数之间直接通信，而是使用数据库（CouchDB）或中间数据的持久存储来通信。

实例化开销：下图b显示了serverless环境中在实例化开销、函数之间的数据共享和有效计算等方面的延迟分解，非阴影条显示中位数，阴影条表示尾延迟。考虑到边缘任务通常是短暂的，系统应该在不牺牲资源效率的情况下最小化实例化开销。

函数通信：下图c深入研究了依赖函数之间在数据交换方面的开销，OpenWhisk和其他serverless框架中，默认情况下，函数之间不直接通信。在OpenWhisk中，用于通信的“第三方”是一个CouchDB实例。在AWS Lambda中，函数通过AWS的远程持久存储结构进行通信。我们分别使用OpenWhisk中的默认的CouchDB系统，以直接RPC通信和内存内通信三种情况比较了任务延迟。CouchDB的延迟最高，因为对于两个要交换数据的函数，它们必须通过OpenWhisk控制器来获得对数据库对象的句柄。直接RPC通信要快得多，但它仍然优于不涉及任何数据交换的内存内通信（为什么原文是这个意思，但是图不是这个意思）。

虽然serverless有可能启用可伸缩的后端计算群协调，但是依旧有一些挑战需要解决，包括为用户提供一个高级编程接口来表达他们的计算，而不需要管理低级部署细节，如任务调度和放置，并发配置、函数实例化和数据共享。

HIVEMIND设计

HiveMind在不牺牲性能或效率的情况下，尽可能多地从用户那里抽象出操作云边缘系统的复杂性，如下图所示为概述图。

HiveMind做出了以下五个关键贡献：

1. 声明式编程模型，在不暴露部署的复杂性的前提下，只需要让用户表达计算的高级结构。

2. 集中控制器，自动决将计算放置在云或边缘资源中。

3. serverless云的调度程序，处理任务放置和功能实例化。

4. 快速远程内存访问加速器，使依赖函数之间进行数据交换。

5. 一个可重构的网络加速结构，减少了云和边缘之间的通信开销。

HiveMind DSL和编程模型

HiveMind遵循领域特定语言（DSL）的方法，它抽象了大部分的系统复杂性，允许用户专注于其计算的高级目标，而不是实现它们所需的低级系统细节。它针对复杂的、多阶段的作业，并自动合成跨任务api、数据共享和任务分配。

HiveMind使用Python公开了一个声明性编程接口，供用户表达他们的任务图的高级描述，并导入根据不同执行步骤相关的逻辑，类似于PyFlow但是显著增强，以支持边缘应用程序的跨任务依赖关系。用户可以指定是否允许任务并行运行、部分重叠或需要串行执行。HiveMind还提供了一些管理指令，例如schedule，isolate，place，restore，learn和persist等等。用户可以利用这些指令来指定特定任务的调度约束，设备故障时的容错策略，某些任务输出的数据持久性要求，以及在应用程序执行期间启用或禁用任何ML模型的再训练。用户还指定了应用程序必须满足的性能指标，包括执行时间、延迟或吞吐量。云资源成本的上限也可以表示出来。HiveMind使用这些度量值来确定如何在云资源和边缘资源之间划分计算。

一旦用户表达了他们的应用程序的任务图，HiveMind编译器和程序合成工具就会组成端到端应用程序，包括自动合成所需的用于计算步骤之间的数据通信的api。HiveMind生成两种类型的跨层api；一种基于rpc，使用Apache Thrift来进行可能运行在边缘的计算，另一种使用OpenWhisk的函数接口，用于在serverless集群上运行的任务。

混合执行模型

之前提到过将所有计算量传输到云中会导致网络拥塞，限制了可伸缩性。另一方面，在边缘运行所有任务会迅速耗尽设备的电池，而且容易出现不可预测的性能。

在云资源和边缘资源之间划分工作是一个具有挑战性的、长期存在的问题。在将计算传输到后端云方面已经做了大量的工作，要么通过手动标记要在云中运行的任务，要么通过自动化卸载过程。在边缘群的上下文中，手动分区工作很有问题，原因有几个:首先，用户不会对不同分区策略的性能和功耗进行良好的评估，且边缘应用程序也容易出现负载波动和故障。第二，改变计算运行的位置会影响所需的软件基础设施例如，在我们的无人机群中通信就需要确定位置。在后端云中使用serverless改变了以前的权衡，因为它的实例化开销比传统云资源更高，并且主要是优化功率效率，而不是优化多层作业的性能可预测性。

HiveMind可以将性能和功率结果呈现给用户，用户选择满足其性能或效率约束的初始工作划分方案。用户可以根据性能、成本或这些指标的组合来指定约束条件。在运行时，如果用户提供的目标没有得到实现，HiveMind可以更改其任务映射。目前对任务放置的更改只发生在任务粒度上，即HiveMind不会在运行时在云和边缘之间迁移单个的、部分完成的任务。

为了保持对所有资源的全局可见性，HiveMind使用了一个驻留在集群中的集中式控制器。该控制器包括一个负载平衡器，它参与所有设备分区可用的工作，一个到负责serverless任务放置的调度器的接口，一个与边缘设备通信的接口，以及一个从云和边缘资源收集跟踪信息的监控系统。

serverless云调度程序

对于集群中的每台服务器，HiveMind部署一个工作监视器，一个轻量级进程，定期监视活动功能的性能和服务器的利用率。使用这些监视器，调度器可以识别具有足够资源来托管新函数的节点。

调度程序执行两种优化：首先，在连续托管在serverless上的多层作业上，调度程序试图将子函数放在与其父函数相同的容器中，以避免通过CouchDB进行昂贵的数据交换。HiveMind实现了一个新的远程内存协议，允许函数之间快速交换内存数据，可以将父任务的输出数据放置在子任务可见的虚拟内存区域中。调度程序的第二个优化是为了减少实例化开销。HiveMind不会立即终止空转容器，如果一个新函数到达，HiveMind会将它安排在该容器中，这样对于在不久的将来可以使用它的新函数的事件就可以利用现有的启动的容器，如果没有，它将终止它。这个等待时间跟据经验来设定，范围在10-30ms。最后，为了避免函数之间的干扰，两个容器可以共享一个物理服务器，但从不共享一个逻辑核心，所以HiveMind将容器固定到核心上，以避免来自操作系统调度器决策的干扰。

我们在之前研究了集中式调度器的可伸缩性。虽然系统可以扩展到许多边缘设备，就像任何集中式系统一样，但它可能成为一个瓶颈。在这种情况下，HiveMind使用多个调度器，每个调度器负责任务的一个子集，但对所有云和边缘资源具有全局可见性。这种共享的状态集群管理器已经证明了在不影响云环境中的决策质量的情况下，具有可伸缩性。

快速远程内存访问

将子函数与其父函数放在同一个容器中并不总是可能的。在这些情况下，OpenWhisk的默认数据交换涉及到对控制器和CouchDB的请求，其中存储了以前函数的结果。这是非常昂贵的，特别是当许多函数试图并发地访问数据时。所以HiveMind使用了一个基于Intel Broadwell 的支持FPGA架构的硬件加速平台。传入的请求由FPGA直接处理，遵循聚合以太网（RoCE）风格的RDMA协议，消除了在应用程序内存和操作系统中的数据缓冲区之间复制数据的需要，并通过内存互连传输到运行函数容器的CPU。

基于FPGA的实现通过绕过主机的网络堆栈显著提高了性能，并且主机和FPGA之间的紧密集成避免了PCIe接口的开销。HiveMind直接利用处理器的缓存一致性协议来处理脏数据及跟踪，并不涉及软件层次的分页，从而减少了远程内存访问开销。虽然这样偏离了serverless的默认策略——不允许依赖函数之间的直接通信，但它不会打破函数可以对用户透明地运行在集群中的任何地方的serverless抽象。

基于硬件的网络加速技术

因为边缘设备使用RPCs将数据从云传输出去，所以仍然需要加速传统的基于RPC的网络。下图显示了紧密耦合的FPGA是如何连接到主机服务器和网络上的，并在网络加速和远程内存加速之间进行分区的。我们在FPGA上卸载整个RPC堆栈，并使用内存互连（UPI总线）将FPGA视为另一个NUMA节点，并使用零复制快速地与主机CPU传输数据，支持异步（非阻塞）rpc的多个线程。

HiveMind的网络加速支持客户端和服务器之间的多连接设置，当对数据包的处理完成时，FPGA将RPC有效负载放在共享内存缓冲区中。数据包由单个线程处理到完成。使用NUMA内存互连来连接主机CPU和FPGA，以优化小型RPC的传输，这在边缘设备中很常见。

为了允许网络结构的可重构性，适应边缘应用程序的各种需求，重新配置被分为硬重新配置和软重新配置，前者仅用于粗粒度的控制决策，如选择CPU-NIC接口协议或传输层（TCP或UDP）。软重构是基于主机CPU通过PCIe访问的软寄存器文件及其相应的控制逻辑。它用于配置CCI-P传输的批处理大小、配置传输和接收队列、配置队列数量和大小、配置活动RPC流的数量，以及选择负载平衡方案。HiveMind的网络加速在连接到相同ToR交换机的云服务器之间实现了2.1us的往返延迟，并且对于64B RPCs的单个CPU核心的最大吞吐量为12.4Mrps。这提高了系统的性能可预测性，并释放了大量可用于函数执行的CPU资源。

其他功能

持续学习：集中协调的一个好处是，来自所有设备的数据可以集体用于提高群体的学习能力。用户可以在其应用程序描述中启用或禁用连续学习。如果启用，HiveMind不只使用一个设备的决定来进行再训练，而是利用整个群体的决定来共同对所有设备进行再训练，这大大加快了它们的决策质量。

容错性：边缘设备容易发生故障。所有的设备都会向HiveMind发送一个周期性的心跳（每秒一次）。如果控制器接收心跳超过3秒，则假定设备发生故障。HiveMind通过在剩余的设备中重新分配负载来处理此类故障。用户也可以自己指定容错策略。

拖尾任务缓解：HiveMind有一个监控系统，可以跟踪函数的进展，并标记潜在的掉队者。如果一个函数花费的时间超过该作业函数的90𝑡ℎ百分位数，那么OpenWhisk将在新服务器上返回它，并使用第一个完成的任务的结果。拖尾任务的具体百分位数阈值可以根据作业的重要性进行调整。如果多个性能低下的任务都来自同一物理节点，则该服务器将暂时被隔离几分钟，直到其表现恢复。OpenWhisk还默认会重新启动任何失败的任务。

论述

HiveMind中的技术是模块化的，如果没有完全的系统控制可用，则可以单独使用。如果云提供商另外支持网络连接的FPGA，HiveMind可以利用网络和远程内存加速的好处。然而，它将失去控制物理任务分配的优势。或者，如果没有FPGA支持，HiveMind仍然会提供可编程性和任务分配的好处，但是应用程序将容易产生高网络开销和serverless框架的默认数据交换协议（CouchDB for OpenWhisk）的开销

评估

性能分析

我们首先研究了HiveMind的性能可预测性。下图显示了与集中式和分散式平台相比，所有使用HiveMind的应用程序的性能。受益最大的应用程序是计算和内存密集型服务，如迷宫遍历、图像到文本识别和移动人员识别。

下图显示了集中式系统和HiveMind的尾部延迟分解，HiveMind中的网络加速对延迟有巨大的影响，网络运行的时间从平均33%下降到9.3%。其次，与管理操作相关联的时间，如容器实例化和调度，也会显著减少。大多数好处来自于HiveMind避免实例化开销，且拥有快速的远程内存访问机制，内存访问大大减少了数据交换延迟。最后，与集中式系统相比，HiveMind中用于执行时间的端到端延迟的比例增加了。这是因为HiveMind在较慢的边缘设备上映射了一些任务。然而，通过消除所有其他系统开销，HiveMind的端到端性能平均比集中式高56%，是集中式的2.85倍，同时也使用了更少的电池和带宽。

我们还将HiveMind与分别具有网络加速、具有远程内存访问加速的集中式系统进行了比较，一个有网络加速的分布式系统，一个无网络加速的分布式系统以及一个无加速但混合执行的HiveMind系统。下图显示了所有10个作业和两个端到端场景的中位数（条形）和尾延迟（标记）方面的比较。

在具有网络加速的集中式系统中，性能受益于改善边缘和云资源之间的网络，但即使启用了远程内存访问加速，HiveMind的性能仍然优于集中式系统，因为它允许一些边缘计算，不会超载云资源。另一方面，分布式系统几乎没有从硬件加速中获益，因为大多数计算都发生在边缘，只有结果会传输到云。没有加速的HiveMind仍然受益于混合执行，但很容易产生较高的网络和数据传输开销。

总的来说，HiveMind中没有任何一种技术足以单独地解决边缘应用程序的性能和功率需求，而共同设计软件和硬件堆栈是至关重要的。

能量消耗和网络带宽

下图a显示了无人机在执行结束时平均消耗的电池；10个作业每个运行120秒，两个端到端场景运行完成，重复20次。与分布式系统相比，HiveMind消耗的电力要少得多，因为它将需要资源的计算转移到云中。它也比集中式系统消耗更少的电力，避免了过多的数据传输。

有两个工作（𝑆3和𝑆4），HiveMind消耗的功率略比集中式系统高，是因为这些作业不能从云和边缘的执行中获益。最后，端到端场景的效率的提高很大程度上是由于HiveMind能更快地完成场景。

下图b显示了三个平台之间的网络带宽使用情况。条形图显示平均和标记90𝑡ℎ百分位数。虽然HiveMind通过将一小部分数据卸载到云中比分布式系统消耗更多的带宽，但它的使用比集中系统低得多，并且避免了将所有数据卸载到云中的网络拥塞。

持续学习

下图显示了在两种端到端场景中，无人机群在正确识别网球和人的准确性。如果识别模型从未被重新训练过，即使识别在云端运行，也会有大量的错误，仅使用每个设备决策反馈定期对模型进行再训练，可以提高准确性，但仍显示出一些不正确的检测。最后，利用整个群体的决定对模型进行全局再训练，快速解决任何剩余的错误，这表明集中控制能够使设备比在分散的系统中学习得更快。

其他集群适用性

HiveMind的设计并不是专门针对无人机设计的。我们现在将HiveMind移植到14辆机器人汽车中，每辆车都配备了高清晰度前摄像头，树莓派开发板，GPS，加速度，温度和高度传感器。我们探索了两种场景；一个“寻宝”，机器人在一个空间中导航，面板指示他们下一步去哪里，直到他们到达最终目标，还有一个“迷宫”，在那里他们必须导航一个未知的迷宫。第一个场景涉及到图像到文本的转换来解释所提供的指令。用户在HiveMind的DSL中再次表达每个场景的任务图，并提供必要的任务逻辑，系统决定如何放置任务。这些汽车比无人机的动力限制更小，所以避障和传感器分析几乎总是在车上运行。

下图a显示了HiveMind上的中位数（条形）和尾作业延迟（标记），以及集中式和分布式系统的对比。下图b显示了相应的平均（条形）和最坏情况（标记）电池消耗。与HiveMind相比，性能更好、更可预测，特别是与分布式系统相比。与无人机群一样，汽车从网络加速中显著收益，它们也受益于将昂贵的计算卸载到serverless集群中，而没有很高的实例化开销。

可测量性

下图a显示了随着图像分辨率的增加，两种情况下的带宽使用和尾延迟。即使是对于最大分辨率和帧率（32帧/秒），HiveMind也不会饱和网络链接，保持低延迟。相比之下，在集中式系统中，网络很快就变得拥挤起来，只支持适度的分辨率和低帧率。

由于用数百架无人机进行实验是不切实际的，我们还建立了一个经过验证的模拟器，可以准确地捕获真实集群的性能、电池消耗和网络带宽。我们也用我们之前的16架无人机的真实集群导入模拟器进行验证，发现与我们的得到的结果误差不超过5%。下图b显示了两种场景下的网络带宽使用情况和尾延迟。我们根据实际实验的比例扩大了网络链接。尽管对于较大的集群，带宽使用增加，但与集中式系统的线性增加相比，设备的增长率要慢得多，特别是对于第一个场景，它可以容纳更多的计算。

结论

我们提出了HiveMind，一个用于边缘集群的硬件-软件系统堆栈，它弥补了集中协调和分布式协调之间的差距。HiveMind实现了一个DSL来提高这些系统的可编程性，自动处理云资源和边缘资源之间的任务映射，并提出了用于远程内存访问和网络的硬件加速结构。在拥有16架无人机和14辆机器人小车的真实群体中，HiveMind的性能明显优于之前的系统，减少了开销，并将复杂逻辑抽象成简单化。