面向QoS的边缘计算容量规划

面向服务质量的边缘计算容量规划

摘要

越来越多的在线服务托管在公共云上。然而，由于集中式云架构会带来较高的网络延迟，研究人员建议将对延迟敏感的应用（如虚拟和增强现实应用）迁移到网络边缘。尽管如此，针对边缘层容量估算的研究仍然较少，迫切需要实用工具和技术来支持初始容量规划。本文提出了一种面向分层边缘云的新颖容量规划方案，该方案考虑了响应延迟方面的服务质量要求，以及对中央处理器、图形处理器和网络资源的多样化需求。我们的方案通过整合互补的资源需求，在满足服务质量要求的同时提高了边缘利用率。我们通过一个案例研究验证了该方案的有效性，该案例研究中我们为部署增强现实导航与信息系统进行了边缘容量规划。

索引术语

容量规划，边缘计算，实时应用

一、引言

云计算彻底改变了我们部署和管理应用程序的方式。在引入按需计算、透明可扩展性和按使用付费选项后，公共云服务得以广泛普及。然而，公共云服务采用的集中式架构带来了较高的网络延迟。为了满足实时应用在响应延迟方面对服务质量（QoS）的要求，已提出将计算资源部署在网络边缘，并将延迟关键型计算迁移至此。此类实时应用的示例包括基于增强现实（AR）的导航和虚拟现实（VR）游戏。

由分布式边缘节点和中心云组成的混合边缘云架构，兼具边缘计算的敏捷性能和云计算的巨大可扩展性。边缘节点可以是例如与无线接入点共址的小型数据中心。迄今为止，针对混合云的卸载机制和任务调度算法已开展了大量研究工作。然而，面向混合边缘云的容量规划方法与工具仍然缺乏。

一个好的容量规划方案应基于对工作负载和不同容量配置下可实现的服务质量的准确估计，而工作负载因应用程序而异。如今，典型的实时应用不仅会产生中央处理器的工作负载，还会产生其他资源的工作负载。其他硬件组件，如图形处理器和网络接口。然而，以往基于仿真的容量规划解决方案并未涵盖中央处理器以外组件的工作负载。此外，大多数容量规划解决方案仅关注公共云基础设施，而这些基础设施在特性和使用方法上与边缘或分层云不同。

在本研究中，我们探讨了混合边缘云容量规划的原则，并提出了用于估算满足实时应用服务质量要求所需的最小容量的实用方法和工具。换句话说，在给定可容忍响应延迟等服务质量要求的情况下，我们的方案能够估算出服务不同数量同时连接客户端所需的最小容量。我们的方案涵盖了多样化的应用需求，包括中央处理器和图形处理器性能，以及网络带宽和延迟。我们分析了资源使用模式对服务质量的影响，并识别出具有互补资源需求的任务。通过任务的智能组合，我们的解决方案在不降低服务质量的前提下提高了资源利用率。我们使用基于增强现实的导航与信息系统（AR NIS）对方案进行了评估。结果表明，我们的方案有助于在维持所需服务质量的同时，最小化边缘云的采购成本。

II. 参考场景

在本节中，我们使用一个参考场景来说明容量规划的预期输入。在我们的参考场景中，考虑了一个博物馆，现场管理人员计划为参观者部署一个实时增强现实网络信息系统。该增强现实NIS采用客户端‐服务器架构实现，应用服务器将部署在与博物馆内Wi‐Fi接入点共址的边缘节点上。根据预期的服务质量要求，容量规划的结果应指明需要多少容量才能满足这些要求。我们将在第五节中使用相同的场景来评估容量规划解决方案的有效性。系统仿真将在第二节‐B中进行描述。

A. 容量规划的输入

典型的用于博物馆的增强现实NIS实现以下应用场景。爱丽丝到达博物馆并打开移动应用。该应用立即定位到爱丽丝，并在小地图上显示她的位置。爱丽丝搜索并找到她最感兴趣的展览，标记出想要参观的展台，应用则为她规划一条贯穿整个博物馆的游览路线。在博物馆内行走时，她可以使用移动应用的增强现实模式，查看规划的导航路径以及附近展览的增强信息，例如描述、图片和视频片段。除了增强现实模式外，爱丽丝也可以选择浏览博物馆网站上的信息。

上述场景包含四项任务，即定位、增强现实导航、视频流和网页浏览。随着室内导航和增强现实领域的进步，我们假设定位任务将通过计算机视觉技术来执行。此外，增强现实导航涉及在应用服务器上进行增强内容生成，以及从客户端到服务器的视觉数据流。

我们从响应延迟的角度考虑增强现实NIS的服务质量，该延迟必须足够短，以确保多个同时连接的客户端获得流畅的体验。阿布拉什指出，增强现实应用的最大帧绘制延迟应为20毫秒，甚至低至7毫秒。即使采用最先进的硬件和软件，实现这一目标也非常困难。我们的容量规划解决方案允许用户为每个任务配置预期的响应延迟。表I 中给出的数值是在我们的案例研究中用于容量规划的输入值。

表I 典型增强现实NIS的资源需求和服务质量要求。中央处理器与图形处理器低/中/高利用率：<20%/20‐70%/>70%；网络低/中/高带宽：<128KBPS/128‐1024KBPS/>1 MBPS；网络低/中/高延迟：<500MS/500MS‐2S/>2S

任务	CPU	GPU	网络延迟	网络带宽	执行时间	响应延迟/任务 运行时间
定位	high	high	low	low	（短连续）	5s
AR导航（AR）	low	high	low	high	（短连续）	250毫秒
从服务器到客户端的视频流 （流媒体）	low	-	中	high	long	1秒 / 3分钟
浏览	中	中	短	-	-	1秒 [14]

B. 系统仿真

由于我们的参考增强现实NIS是假设的，我们通过现实可行的实现方式对表I中列出的4项任务进行模拟。对于定位任务，我们采用iMoon ——一种基于图像的室内地图构建与定位系统——作为参考实现。我们通过传输控制协议以2500kbps的速率发送视频流来模拟视频流媒体。假设每个流媒体视频片段的平均长度为3分钟。增强现实导航通过持续向服务器发送图像数据进行模拟。一旦服务器接收到数据，我们便在已接收的图像帧上运行特征提取算法，以模拟真实系统确定当前场景的一种方式。参数并估计增强现实（AR）中的相机位姿。我们通过提供静态存储的1.5MB网页来模拟浏览。

III. 容量规划框架

我们提出了一种在分层云基础设施上部署应用的容量规划框架。在本例中，分层云由边缘节点和地理位置上更远的公共云组成。我们假设待部署的应用采用微服务架构实现，不同的微服务可部署在任意计算节点上。每个微服务实现不同的任务，而传入的用户请求由不同的微服务处理。

我们根据以下列出的假设设计容量规划的原则。这些假设将在第四节中进行验证。

• A1：对于执行对延迟敏感的任务，边缘节点比公共云更合适。
• A2：在同一个计算节点上执行具有不同资源需求的组合任务，可实现更高的利用率。
• A3：即使多个性能较弱的计算节点的处理能力总和等于单个服务器的处理能力，这些性能较弱的计算节点的整体表现仍可能超过单个服务器。

A. 工作流程

我们建议按照图1所示的6个步骤实施容量规划。

1) 识别系统任务，确定任务的服务质量要求，并找出对延迟最敏感的任务。
2) 对系统任务进行性能分析，并研究其资源使用模式。这些模式揭示了任务所需的资源类型、资源需求的高低以及任务执行时间的长短。示例见表I。
3) 确定需要在边缘节点上运行的任务以及可以在公共云上执行的任务。前者包括具有最短可容忍响应延迟的任务，而后者包括长时间运行的任务和对延迟不敏感的任务。
4) 通过分析先前生成的资源使用情况，识别具有互补资源需求的任务模式。此类任务将被捆绑在一起并同时执行，以提高资源的整体利用率。在单台机器上运行的一个典型组合是任务A需要高图形处理器但低中央处理器利用率，以及任务B需要高中央处理器利用率。我们应用背包算法来寻找任务的最佳组合。
5) 根据每个单一边缘节点支持的最大用户数估算值，估算所需边缘节点的数量。
6) 在云模拟器或小规模公共云配置上部署并测试系统，以验证最终的部署方案。

为了实现流程自动化，我们开发了一个性能分析器，用于分析步骤2期间的资源使用模式，以及一个基准测试工具用于步骤5。这些工具的实现将在第三节‐B中进行描述。遵循上述6个步骤，可以清楚地了解如何部署微服务，以及在执行不同任务组合时应使用哪一层（边缘或公共云）。

图1. 所提出的容量规划框架的工作流程

在接下来的章节中，我们将验证框架设计假设，并通过案例研究展示该框架的适用性。

B. 性能分析器和基准测试工具

我们开发了一个性能分析器（Profiler）来分析每个任务的资源使用模式。该性能分析器在客户端和服务器端均运行，从客户端节点发起请求，并在服务器端执行任务时测量资源使用情况。性能分析器采用Python实现。我们使用 Python的psutil包采样当前中央处理器（CPU）使用率，并使用nvidia‐smi命令采样图形处理器（GPU）使用率。通过分析Linux /proc/net/dev文件中的读数来记录网络上传和下载速率。采集到的使用数据在采样期间存储在设备内存中，采样结束后保存至文件。随后，通过为每种不同任务绘制散点图来可视化这些使用模式。

表II 不同客户端‐服务器配置下AR任务的响应延迟。

服务器 location	（中央处理器核心/频率，图形处理器核心 频率/内存带宽）	特征提取（秒）	响应延迟（秒）
边缘节点A	8核/3.2GHz，1.3GHz/41.7GB/s	0.065	0.080
边缘节点B	32核/2.6GHz，2.6GHz/208GB/s	0.044	0.070
云节点C	16核/2.6GHz, 2.5GHz/160GB/s	0.041	0.314

我们开发了一种基准测试工具，用于确定在给定任务组合和预期响应延迟的情况下，一个计算节点能够支持的同时连接的客户端数量。该工具使用Python实现，向服务发送请求，测量最大响应延迟，并将测量结果与预期值进行比较。它会快速增加客户端数量，直到服务质量被违反，然后逐步减少客户端数量，直到满足预期的响应延迟要求。基准测试工具所用算法的伪代码如算法1所示。其中，STABLE_ITER_COUNT定义了稳定迭代次数（即客户端数量未发生变化的次数），达到该次数后返回结果。在本例中，我们将该值设为5。

算法1 基准测试工具算法
输入：要运行的任务 T，可容忍响应延迟 Q
输出：同时连接的客户端数量 N

C = []  // 运行任务的客户端 T
Dmax = []  // 每个任务的最大延迟
stable = 0, increase = 1, N = 1
Th = Q · 0.1  // 响应延迟的阈值数组，10% 可容忍响应延迟的

while stable < STABLE_ITER_COUNT do
    C ← 并行运行 N 个客户端，每个客户端运行 T 个任务
    for t ∈ T
        Dmax ← 在所有 C 中查找 t 的最大执行时间
    if ∀Dmax[i] < Qi - Thi and increase > 0
        N = N + increase
        increase = increase · 2  // 为了快速收敛
    else
        if ∃Dmax[i] > Qi
            increase = 0  // 切换到递减模式
            stable = 0
            N = N - 1
        else
            stable = stable + 1
return N

IV. 设计假设验证

在本节中，我们验证了设计容量规划原则时所做的假设（A1、A2和A3），以验证所提出框架的可行性。

我们首先证明了具有低延迟要求的任务更适合在边缘节点上执行。在我们的参考场景中，AR任务的可容忍响应延迟最为严格（见表I），因此我们通过在3种不同配置上运行AR任务来分析其执行情况（见表II）。所有配置均采用客户端‐服务器方法，其中客户端为本地机器，服务器分别为两个边缘节点（A和B）以及一个远程云节点（C）。实验结果显示，尽管云节点C的中央处理器和图形处理器性能优于边缘节点A，但由于网络延迟较高，其整体响应延迟显著高于边缘节点。具体而言，边缘节点A和B的响应延迟分别为0.080秒和0.070秒，而云节点C的响应延迟高达0.314秒，远超AR任务250毫秒的容忍上限。这验证了假设A1：对于延迟敏感任务，边缘节点比公共云更合适。

接下来，我们验证假设A2：在同一个计算节点上执行具有互补资源需求的任务可以提高资源利用率。我们选取定位任务（高CPU、高GPU）和浏览任务（中等CPU、中等网络）进行组合测试。单独运行时，定位任务导致CPU和GPU利用率均超过70%，而浏览任务使CPU维持在中等水平。当两者并发执行时，资源使用呈现互补特性：定位任务主要消耗GPU资源，而浏览任务更多占用网络带宽和适度CPU资源。结果表明，在同一节点上并行执行这两个任务，系统整体资源利用率提升了约38%，且未违反各自的服务质量要求。因此，假设A2成立。

最后，我们验证假设A3：多个性能较弱但分布式的边缘节点可能优于单一高性能服务器。我们比较了两种部署方式：一是使用一台高性能云服务器处理所有AR导航请求；二是使用多台低功耗边缘节点协同处理相同负载。测试结果显示，在高并发场景下（>10个客户端），尽管单台云服务器的理论计算能力更强，但由于网络往返延迟累积，实际响应时间超出服务质量阈值。相反，分布式边缘节点因靠近客户端，平均延迟更低，能够稳定支持更多并发用户。这表明在延迟敏感应用中，边缘分布式的架构整体表现更优，从而证实了假设A3。

V. 案例研究：增强现实NIS容量规划

我们在一个真实的增强现实导航与信息系统（AR NIS）场景中应用所提出的容量规划框架，以评估其有效性。

A. 任务分类与部署决策

根据表I中的服务质量要求，我们将四项任务划分为边缘执行与云端执行两类。AR导航和定位任务因其严格的延迟要求（分别为250毫秒和5秒）被部署在边缘节点上；视频流媒体虽然带宽需求高，但其延迟容忍度为1秒，且执行时间较长，适合在公共云上处理；网页浏览任务延迟要求为1秒，考虑到其计算负载较低且对实时性要求不高，也安排在云端执行。

B. 任务组合优化

基于性能分析器采集的数据，我们识别出AR导航任务（高GPU、低CPU）与定位任务（高CPU、高GPU）存在部分资源竞争，但通过合理调度可在短时间内交替执行。进一步分析发现，浏览任务与定位任务在资源使用上具有较强互补性：前者主要消耗网络带宽，后者集中在CPU/GPU处理。因此，我们将定位任务与浏览任务捆绑在同一边缘节点上并发执行，利用背包算法求解最优任务组合，最大化资源利用率。

C. 容量估算与验证

使用基准测试工具，我们测算出单个边缘节点在满足服务质量前提下可支持的最大并发用户数。测试设定AR导航任务的最大响应延迟为250毫秒，定位任务为5秒。测试过程从1个客户端开始逐步增加，直至响应延迟超标，再反向调整至稳定状态。结果表明，单个边缘节点最多可支持7个同时连接的客户端而不违反AR任务的延迟约束。

为进一步验证规划结果，我们在分层边缘云基础设施上运行系统，以测试规划的部署。根据该框架的建议，我们在一个边缘节点上并行执行了AR任务、定位任务和浏览任务，并在公共云实例上执行了视频流任务。在这个小规模测试中，我们使用了1个边缘节点和1个公有云节点。我们将同时连接的客户端数量从1变化到25。各项任务的响应延迟结果如图5所示。结果表明，基准测试工具提供的估算结果是准确的，因为当同时连接的客户端达到7个时，AR任务违反了允许的最大延迟，而就定位任务而言，15个用户对于单个云节点来说过多。

为了进行对比，我们在公共云上单独执行了相同的设置（见图6）。结果清楚地表明了公共云网络延迟所带来的问题。公共云实例无法为AR任务提供所需的服务质量，并且当并发用户数超过7时，也无法为浏览任务提供可接受的延迟。因此，我们得出结论：与仅部署在公共云上的激进策略相比，所提出的部署方案更具优势。

VI. 相关工作

许多研究致力于为公共云提供商提出最优的容量规划方案。江等人提出了一种基于预测的云容量规划和虚拟机配置解决方案，同时考虑了资源供给不足的机器的维护成本以及因违反服务级别协议(SLA)而产生的费用。坎戴亚等人提出了在公共云基础设施上托管应用的长期容量规划模型。贡萨尔维斯等人利用不同层级工作负载在不同基础设施即服务(IaaS)提供商实例上的基准测试，确定针对特定工作负载的最优IaaS虚拟机配置。他们提出了一种方法，用于为给定工作负载寻找可最小化所需实例数量的云配置，并在亚马逊公共云EC2实例上测试了该方法。Brunnert等人利用应用程序的资源使用概况来估算所需的服务器容量，要求这些概况在软件开发生命周期中就已构建完成。张等人提出了一种工作负载管理系统，该系统利用私有云和公共云提供视频流服务。在其方案中，私有云节点负责处理最多95%的请求，而在峰值负载期间将5%的“突发”请求转发至公共云。

然而，大多数研究仅关注大型数据中心或公共云。其他研究仅评估中央处理器密集型任务，例如运行WordPress应用程序，但未考虑图形处理器处理等其他资源。在本研究中，我们提出了一种针对分层云基础设施的容量规划方案，该方案综合考虑了中央处理器、图形处理器利用率以及网络上传和下载速率。

VII. 结论

在本研究中，我们提出了一种新型的边缘容量规划方法，有助于在满足所需服务质量的同时最小化初始部署成本。我们的方案考虑了响应延迟方面的服务质量要求，以及对中央处理器、图形处理器和网络资源的多样化需求。我们通过一个案例研究验证了该方案的有效性，在该研究中分析了增强现实NIS并估算了系统所需的容量。结果表明，我们的方案能够生成满足所需服务质量的同时最小化边缘云采购成本的容量规划。