INFOCOM'22：面向最大边缘吞吐量的层感知协作微服务部署 - 网安

如今，轻量级的基于容器的微服务被广泛提出，以提升边缘云的弹性。而容器所固有的分层结构提供了一种引人注目的方法来解决边缘服务器的资源稀缺问题，即通过层共享来应对，这可以显着提高存储利用率并提高边缘吞吐量。最近的研究表明，不仅可以在同一台服务器内可以实现层的共享，而且可以在服务器之间进行。因此，在微服务部署时可以充分利用这一点。在本文中，我们研究了如何通过结合服务器内和服务器间两种层共享模式来协同部署微服务，以最大化边缘吞吐量的问题。我们将这个问题表述为整数线性规划形式，并将其证明为 NP难问题。我们提出了一种基于随机舍入的启发式算法，并对其具有合理的近似比进行形式化分析。通过大量的实验，我们验证了我们提出的算法的效率，结果表明，和当前最先进的两种策略相比，它可以分别多部署6倍和12倍微服务实例，并且边缘吞吐量分别提高了27.74%和38.46%。

该结果“Layer-aware Collaborative Microservice Deployment toward Maximal Edge Throughput”发表在IEEE Infocom 2022，是实验室分布式系统组在微服务部署领域的研究成果。

背景与动机

通过在网络边缘提供计算资源，边缘云已成为一个与云系统互补的有前途的平台。由于具有终端用户距离近的优势，边缘云非常适合许多对延迟敏感的应用，例如自动驾驶、医疗保健、增强现实、智能制造等。但是，与大型数据中心赋能的中心云相比，边缘云资源比较稀缺。因此，如何最有效地利用边缘资源便成为近来的主要研究热点之一。另一方面，基于容器的微服务被提倡作为一种边缘服务提供范式，这要归功于它的轻量级优势，与传统的虚拟机 (VM) 相比具有更好的灵活性和弹性。

虽然容器相对较轻量级，但它们所占的空间仍远不能忽略不计。例如，Docker Hub中下载次数最多的134个镜像的大小从109MB到2045MB不等。这给存储带来了沉重的负担，严重限制了边缘服务器的服务能力。同时也会导致图片下载流量大，微服务启动慢。最近的一项研究表明，在100Mbps网络上，单个微服务的平均启动时间高达20.7秒，其中72.4%的启动时间用于镜像下载。为了克服这个问题，现有研究已经尝试缩小容器镜像大小，启用部分镜像下载，预导入所需库或重新设计容器镜像等方法。

通过仔细检查容器架构，可以观察到像Docker的容器镜像具有内在的分层结构。可以适当地利用这样的特征来减少镜像存储需求、下载流量以及微服务启动时间，而无需重构容器镜像。基于容器的微服务将其容器镜像中所需的所有内容打包并存储在多个层中，包括运行时工具、系统工具和系统依赖项。因此，在服务器上部署微服务本质上相当于将所有需要的层加载到服务器中。幸运的是，已经指出一些公共层（尤其是那些只读层）可以在同一服务器上的不同微服务之间共享（即服务器内共享）或通过分布式文件系统跨不同服务器共享（即服务器间共享）。最近的一项研究表明，57个具有代表性的微服务镜像具有19个公共基础层。以Cassandra、JAVA、Python和gcc的微服务为例，它们的镜像都需要一个非最新的Debian Linux分布层。通过共享公共层，可以显着降低微服务的存储需求。这不仅减少了镜像下载流量和启动时间，而且潜在地扩展了资源受限的边缘服务器的服务容量。

在边缘云系统中，考虑到边缘服务器的资源稀缺性，在微服务部署过程中自然会考虑层共享。现有研究在很大程度上将容器视为轻量级VM。最近有学者提出一种层共享微服务部署解决方案来提高边缘吞吐量（定义为边缘云满足的请求数）。但是，本研究仅关注服务器内层共享。在考虑跨服务器层共享的情况下，只要启动时间可以接受，本地没有存储的层可以从另一台服务器加载。这实质上扩大了层共享范围并提高了资源利用率以实现更高的边缘吞吐量。到目前为止，还没有系统的研究可以定量地描述吞吐量的提高，而这项工作试图填补这一空白。

值得注意的是，通过启用服务器间层共享，微服务部署和层存储不再紧密耦合，因为微服务所需的层可以独立于微服务之外存储。因此，微服务部署不可避免地变得更加复杂，因为边缘服务器现在可以相互协作以平衡存储和计算资源的使用，以便处理边缘云上的更多请求。这项工作侧重于以最大化边缘吞吐量为目标的分层感知协作微服务部署，这被证明是NP难的。为解决计算复杂度问题，本文提出了一种基于随机舍入的启发式算法。

设计与实现

层共享有利于提高资源有限边缘服务器的吞吐量。我们以三个常用的微服务MySQL、Nginx和Cassandra为例，他们的最新版本分别为 443MB、109MB 和 323MB，且都基于CentOS的同一个大小为55MB的非最新Linux分布层。将这三个微服务的镜像放置在同一个边缘服务器之上时，这个基于CentOS的Linux基础层可以被所有镜像使用，因此在保证计算资源、通信资源充足时，考虑层共享结构，一方面可以避免重复多次下载，有效降低微服务放置的下载流量，另一方面可以减少重复放置基础层带来的存储容量开销。一旦微服务放置成功，它们就会投入运行以处理用户请求。无法在本地处理的请求会被卸载到另一个放置有该微服务的边缘服务器或云端进行处理，最终达到最高的吞吐量。由于减少了从仓库下载到带宽有限的服务器的镜像总大小，层共享在一定程度上可以加速微服务启动。以上优势都是不考虑MySQL、Nginx和Cassandra的层共享性质，将他们的镜像分别视为一个整体所不能实现的。上面的例子告诉我们层共享确实有利于降低微服务放置的下载流量和存储开销。同时，请求调度应与层感知微服务放置一起考虑，以提高资源受限边缘服务器的服务提供能力。服务器间层共享解耦了微服务部署和层存储，并使服务器协作能够平衡它们的存储和计算资源使用。这就提出了一个新问题，即如何制定微服务部署和分层存储决策，以更好地利用边缘资源实现最大边缘吞吐量。

在本文中，我们考虑以最大化边缘吞吐量为目标的协作层感知微服务部署和层存储问题（JMDLS）。通过利用服务器内和服务器间的层共享，我们共同平衡存储和计算资源的使用，以最大限度地提高边缘云的服务能力。我们将问题表述为 ILP 形式，并通过将其简化为联合背包问题来证明它是NP难的。

我们提出了一种基于随机舍入的启发式算法，且该算法具有合理的近似比。为了解决计算复杂性，我们结合了JMDLS公式并提出了一种基于随机舍入 (RR) 的算法来寻找解决方案。该算法通过将二进制变量放宽为 [0,1]，整数线性规划形式的原始JMDLS公式首先被松弛为可以在多项式时间内求解的线性规划问题。通过求解松弛JMDLS得到的实数解可以被认为是做出决策的概率。因此，部署和存储决策分别按照概率进行对应设置。由于松弛和随机舍入的解决方案可能违反资源容量限制，因此，我们检查是否违反了任何存储资源、计算资源或通信资源的容量限制，如果是则对放置决策进行合理地修正。

为了验证算法的有效性，我们分别在小规模的模拟场景和大规模的实际场景中评估我们提出的基于随机舍入的启发式算法的性能。小规模的模拟场景中，我们利用Gurobi计算最佳放置策略，将其与我们的算法进行比较，验证相比于其他放置策略，我们的算法与最佳放置策略足够接近，有着良好的性能。在大规模的实际场景中，我们设计由14个分布式边缘服务器组成的边缘云，其存储容量、计算能力、上行链路容量、下行链路容量和数据访问速率范围为分别为109~1045MB、8~12GHz、320~2400Mbps、1280~1920Mbps和100~400Mbps。考虑了来自Docker Hub的80个微服务。每个微服务的层数在6~13之间，镜像大小在109~2045MB 之间，计算资源需求在1~5MHz之间。在具体实验时，我们在不同的请求分布情况下，在保持其他条件不变的前提下，分别增加存储资源、计算资源和带宽资源，统计所有边缘服务器上的吞吐量，与当前最先进的两种策略LA-MPRS和JSPRR进行对比，从而等到最终实验结果。我们提出的算法的效率通过大量实验得到验证，实验结果（图1和2）表明和当前最先进的两种策略相比，它可以分别多部署6倍和12倍微服务实例，并且边缘吞吐量分别提高了27.74%和38.46%。