MEC中Docker开销表征

移动边缘计算场景中的Docker开销表征

1 引言

预计5G网络将需要处理大量具有多样化需求的应用程序。除了移动网络运营商外，“5G革命”的主要参与者还包括垂直行业，例如娱乐/媒体公司、汽车制造商、电子健康服务提供商等。这些垂直行业可能部署的应用程序和服务将具有高可用性可靠性要求，并且通常需要在低功耗的情况下提供，同时满足严格的延迟要求。必须满足此类高要求服务的5G平台的设计与实现，以及在其上运行的网络和IT相关功能，将需要高度创新。至少，它必须支持新颖的功能拆分和部署方法，以实现IT和网络资源的联合优化，并有效满足垂直行业的需求。

在此场景下，移动边缘计算（MEC）范式将发挥关键作用。以去中心化方式在边缘部署服务，能够实现服务提供与终端用户之间更紧密的交互，显著降低延迟并提升服务可用性。然而，服务分发的去中心化也带来了代价：资源重复和开销增加，这需要根据所选平台进行准确量化。目前，IT行业正致力于采用虚拟机和轻量级容器来提供服务。其中，最广泛使用的容器框架无疑是Docker，它承诺可确保高可移植性、可扩展性以及开发人员和运维人员之间的高效协作[1]。

在MEC场景中可提供的众多服务中，我们选择了视频流和多人游戏，因为这两者呈现出持续增长的趋势并具有重要影响。众所周知，视频流是互联网流量的主要贡献者之一：其涉及的数据量远大于图片或网页，并且每天都有大量视频通过互联网进行传输（包括YouTube视频、嵌入式Facebook视频片段、Netflix剧集，以及Skype、Join.me或Google Hangouts等视频会议工具）。根据思科最新的统计数据，视频已占所有互联网流量的70%，到2020年这一比例可能达到90%[2]。在线游戏产业也在持续增长：2016年其收入已达1000亿美元，其中超过37%来自平板电脑或智能手机。此外，预计到2020年，游戏产业规模将突破1200亿美元，这意味着在移动游戏相关的新应用程序和技术开发方面，极有可能投入大量资金和资源[3]。

除了它们的流行度和广泛应用外，我们选择视频流和游戏是因为它们代表了具有显著不同需求的服务模型。视频流在服务器端通常需要较低的计算开销，但传输的数据量较大，主要沿一个方向传输。而游戏则意味着对CPU资源的更高利用率，以及较少的数据包传输（这取决于游戏会话中玩家之间的交互程度），数据在两个方向上传输。

以这些服务为案例研究，本工作的目标是测量并表征在移动网络基础设施边缘部署的容器中实现这些服务所涉及的Docker开销。具体而言，通过在真实硬件上部署流行的服务，我们研究了Docker运行容器时记录的CPU消耗，并讨论了影响CPU消耗的各种因素，例如服务器数量和客户端数量。此外，我们将Docker的CPU开销与容器化应用的CPU消耗进行比较，以深入了解实现视频流和游戏服务容器化的代价。

2 相关工作

在5G网络中用于服务交付的容器化系统是一个被广泛研究的主题。特别是，诸如[4]之类的研究评估了Docker作为边缘计算平台的可行性，并得出结论：它提供了快速部署、小的占用空间和良好的性能。其他研究，例如[5]，声称分布式服务交付将成为5G网络中最热门的话题之一，并展示了Docker作为容器化系统在实现虚拟网络功能方面的高效性。此外，Linux容器已在多个方面被广泛分析并与虚拟机进行了比较：[6]探讨了传统虚拟机部署的性能，并将该方法与使用Linux容器的方法进行对比。与我们的结果一致，[6]还表明，在所有情况下，容器的性能均等于或优于虚拟机。

其他研究，例如[7]，侧重于在云游戏部署中使用Docker容器而非虚拟机的优势，即游戏在远程云服务器上渲染，并将生成的视频流发送回用户。我们强调，在本研究中，分析的是一个基于Docker的多人客户端‐服务器架构。[8]的作者研究了Docker在覆盖网络模式和主机网络模式下用于大规模流媒体系统的部署，发现主机模式在延迟方面的优势与覆盖网络更高的稳定性相平衡。尽管与他们的研究相关，但我们的工作重点是表征容器化解决方案在不同应用程序中的开销成本。

3 系统场景与方法

我们考虑一种MEC场景，其中面向移动用户的服务由部署在网络基础设施边缘的服务器提供，即靠近Wi‐Fi接入点（AP）或蜂窝基站（eNodeB）。作为具有不同特性和需求的服务代表，我们选择了视频流和在线游戏——前者是一种已经非常流行的应用程序，而后者正在稳步获得越来越大的市场份额。

然后，我们研究通过Docker容器提供此类服务的开销成本。为此，我们采用实验方法部署如图1所示的测试平台，其中包含一个网络边缘节点以及数量可变的服务器实例。接着，通过大量测量，我们分析了Docker表现出的开销及其在应用比特率和客户端数量变化时的行为。

3.1 测试平台描述

我们测试中的视频服务器是FFserver（版本 3.1.3）[9]，属于FFmpeg框架。FFserver是一个支持实时和非实时内容的多媒体流媒体服务器；此外，它支持在多个平台上运行的客户端，因此其提供的内容可以由任何类型的设备播放，无论是台式机、笔记本电脑还是移动设备。我们在客户端使用的软件是VLC[10]。如图1所示，服务器实例通过Wi‐Fi接入点运行，该接入点将视频流量传输到运行在Linux机器上的VLC实例，该Linux机器与AP 1相关联。

关于容器化游戏服务器，我们使用我的世界手机版（版本 0.10.5）[11]。为了测试移动客户端的行为，我们采用Android模拟器来模拟Android移动客户端。所选用的模拟器是Genymotion，这是一个功能强大的虚拟化平台，能够模拟多种Android设备[12]。为了尽可能严谨，在每个模拟器中都安装了Android应用程序FRep[13]。该工具可记录屏幕上的一系列点击操作，并允许在每个模拟器上精确复制相同的操作模式，从而在每个Minecraft客户端上实现一致的操作。这是必要的，因为我们的测量结果显示，不同玩家的移动模式会导致不同的CPU负载。

此外，由于Android模拟器在计算资源消耗上比简单的VLC实例更重，因此在游戏用例中，客户端最多会使用两台不同的Linux机器。

在视频流和游戏测试中，我们使用不同数量的客户端和服务器组合，每种数量均在1到8之间（例如，1个服务器 ‐ 4个客户端，4个服务器 ‐ 8个客户端等）。

4 Docker开销

我们首先在第4.1小节列出构成Docker开销的进程，然后在第4.2小节描述用于监控这些进程的方法论。

4.1 Docker进程树

Docker开销是由于多个进程造成的，其数量会根据不同的因素而变化，例如在后台或前台运行的容器数量、暴露的端口数量。

1请注意，我们可以将Wi‐Fi替换为任何其他无线接入技术，例如LTE，而不改变我们测试平台的架构。

Docker进程树示意图)

pstree输出的屏幕截图)

图2：Docker进程树

最上面的两个进程是持久性的，即无论是否有运行中的容器，它们都始终保持活跃；其他进程是非持久性的，一旦启动Docker容器便会创建。这些持久性进程如下：

• dockerd ：它是Docker守护进程。它管理所有镜像、容器和整个Docker框架。一旦守护进程启动，它就会派生第二个持久性进程，即docker-containerd。
• docker-containerd ：它在Docker主机上独立于Docker守护进程管理容器的生命周期，使用shim进程（见下文）。它的引入是为了在不影响正常容器执行的情况下对Docker守护进程执行特定的维护操作，例如重启或升级。

非持久性进程是：

• docker-containerd-shim ：它由docker-containerd创建，并作为容器进程的父进程，以促进以下操作。首先，它允许运行时底层组件（例如runC）在容器启动后退出。这样，我们不需要长时间运行的运行时进程来管理容器，同时还能将容器化应用与shim进程隔离开来。其次，当docker-containerd和/或dockerd终止时，它会保持容器的标准输入输出（STDIO）和其他文件描述符处于打开状态。这意味着如果shim进程未运行，则管道的父端将被关闭，导致容器退出。最后，它允许将容器退出状态报告给高层工具（即Docker守护进程）。
• docker-proxy ：对于容器暴露的每个端口，都会创建一个docker-proxy进程。docker-proxy在用户空间运行，接收到达指定主机端口的任何数据包（内核未丢弃或转发的数据包），并将该数据包重定向到容器端口。实际上，此进程现在已不再使用，因为它最初是为了克服旧内核表现出的限制而引入的，仅为了向后兼容而保留。由于我们的Docker主机配备了更新的内核，因此我们关闭了此进程。
• docker ：仅当容器在前台运行时存在，因为它负责管理容器的用户界面。而在我们的测试中，容器是在后台运行的，因此我们并未观察到该进程。

4.2 测量Docker开销

为了研究上述进程消耗的CPU资源，我们解析/proc/PID/stat文件。通过获取我们感兴趣的进程标识符，可以收集大量信息。特别是我们关注两个字段：utime（用户时间），即进程在用户模式下被调度的时间长度；以及stime（系统时间），即进程在系统模式下所花费的时间。这两个字段报告的测量值均以CPU时钟周期为单位。通常，在Linux系统中，1个CPU时钟周期表示进程占用CPU核心时间为10毫秒[14]。为了记录整个CPU使用情况随时间的变化，我们每秒对stat文件采样一次。

另一个重要元素是每个容器化应用处理的数据量。主机网卡交换的数据量存储在文件/proc/net/dev中：该文件包含每块网卡的若干信息，例如发送和接收的数据包数量以及传输和接收的字节数。此外，由于Docker为每个容器创建一个虚拟以太网卡（veth），因此可以监控每个容器传输的数据。

总之，每秒采样一次stat和dev文件，对于每次测试，都可以逐秒监控每个进程的CPU消耗以及每个容器处理的数据。

5 实验结果与讨论

在我们的测试平台中，容器化服务器托管在一台配备32GB内存、八核Intel Core i7-4790@3.60GHz处理器并运行Ubuntu 14.04的机器上。每次测试持续300秒。在视频流情况的研究中，每台服务器流式传输相同的视频，具有以下特征：

• 格式：mpeg；
• 平均比特率：4215 kbps；
• 分辨率：1280x720 (720p)。

用于构建两个容器的镜像已发布在Docker Hub的以下仓库中：
https://hub.docker.com/r/giuseppeav/ffmpeg/，
https://hub.docker.com/r/marcomali/minecraft/。

在游戏场景中，Android模拟器被部署在用于测试的笔记本电脑上，并连接在同一子网下。

5.1 客户端数量固定

在固定客户端数量（即8个客户端）的情况下，直观上可以预期Docker开销几乎与服务器数量呈线性关系。图3展示了在测试结束时针对视频流和游戏应用计算的8个客户端的Docker开销CPU消耗，以及无运行中容器情况下的结果（即仅Docker守护进程处于活动状态）。

随着服务器数量的变化，有两个事实引起了我们的注意。

首先，对于FFserver而言，dockerd和docker-containerd的CPU利用率不受容器数量的影响（始终保持在约40个tick），并且与没有任何服务器时观察到的情况基本相同；此外，shim进程不消耗任何CPU。这意味着运行Docker化的FFserver实例的唯一开销来自于容器的创建和终止。其次，对于Minecraft，dockerd、docker-containerd和shim进程都会消耗CPU，且shim进程和dockerd所使用的CPU量取决于正在运行的服务器数量，即容器的数量。

两种应用程序的shim进程在CPU消耗上的差异可能与应用程序自身的行为不同有关。一个典型的例子是日志操作：Minecraft游戏服务器产生的日志远多于视频服务器，这给相关的shim进程带来了更大的负担，因为shim进程还需要管理标准输出（STDOUT）和标准错误（STDERR）流。

接下来，我们查看表1，并比较视频流和游戏应用所导致的CPU消耗。我们注意到，视频流的CPU消耗远低于游戏应用，约为其十分之一。事实上，为了传输视频流，视频服务器只需读取数据并发送，而无需进行任何编码。

应用程序	服务器数量	CPU 使用率 [ticks]
FFserver	1个服务器 2个服务器 4个服务器 8个服务器	392 399 391 365
Minecraft	1个服务器 2个服务器 4个服务器 8个服务器	3751 5130 8055 10860

因此，Docker开销在这两种场景下的影响差异很大。这一效应在图4所示的曲线中表现得非常明显，图中描绘了8个客户端和4个服务器情况下，应用程序和Docker开销导致的CPU消耗的时间演化情况。

FFserver)

Minecraft)

图4：在8个客户端和4个服务器的情况下，应用程序和Docker开销导致的CPU消耗的时间演变

尽管视频流的开销远低于游戏，但后者相对于应用程序CPU负载的开销可忽略不计，而在视频流的情况下，该开销占CPU负载的10%以上。

5.2 服务器数量固定

我们现在使用单个服务器，并将客户端数量在1到8之间变化，以评估服务流数量对Docker进程CPU消耗的影响。

图5展示了我们两个案例研究中由于Docker开销导致的CPU利用率。具体而言，对于FFserver，我们再次注意到docker-containerd-shim（现在只有一个服务器，因此仅有一个shim进程）不消耗CPU，且dockerd和docker-containerd的CPU利用率与服务的流数量无关。Minecraft也是如此。

表2报告了当服务1、2和4个客户端时，两个容器化服务器消耗的CPU。对于FFserver而言，在每次测试中，Docker开销约为40个ticks。因此，由于服务的客户端数量越多，CPU消耗越大，随着客户端数量的增加，Docker开销的影响明显减小。特别是图6显示，在单个客户端的情况下，FFserver的开销影响接近45%，而当客户端数量达到八个时，该影响降至10%以下。对于游戏应用也观察到了类似的行为，尽管这种趋势不太明显，因为在Minecraft中，即使只有1个客户端，Docker开销的影响本身就已经非常低。

应用程序	客户端数量	CPU 使用率 [ticks]
FFserver	1个客户端 2个客户端 4个客户端	49 87 188
Minecraft	1个客户端 2个客户端 4个客户端	1744 2508 4569

两个案例研究以及不同类型的测试之间有一个共同点：docker-containerd所使用的CPU始终约等于每秒0.05 CPU时钟周期。我们还观察到，该进程的执行与正常容器执行无关，实际上，终止docker-containerd过程并不会影响容器化服务器的活动。

5.3 处理的数据和Docker开销

最后，我们确定了两个容器化服务器处理的数据量（即传输或接收的数据量）是否会影响Docker开销的CPU消耗。

图7展示了在“4个客户端 ‐ 1个服务器”场景下，视频流和游戏应用中客户端与服务器之间交换的数据量（对数尺度）。正如预期，FFserver处理的数据远多于Minecraft传输的数据，因为在我们的测试中，视频大小约为160 MB，并传输给四个客户端。还有两点值得强调：首先，由于FFserver主要用于直播且不进行缓冲，因此视频服务器发送的数据量随时间呈线性增长；其次，Minecraft服务器在测试初期处理的数据量最大，因为服务器最初需要向所有玩家提供他们将要活动的虚拟世界的相关信息。后续的数据交换则是由于玩家移动过程中与服务器之间的游戏内交互所导致。在“4个客户端 ‐ 1个服务器”的案例中，300秒后FFserver传输的数据约为638 MB，而Minecraft为8 MB。我们还注意到，Docker CPU消耗随时间保持不变，且等于之前观察到的值，其中Minecraft的Docker CPU消耗高于FFserver（图5）。因此我们可以得出结论：服务器处理的数据量不会影响Docker CPU消耗。

核心信息 我们的结果突出了三个重要方面：
（1）在整个实验过程中，Docker开销介于可忽略和中等之间，从而验证了其作为轻量级容器化解决方案的声明；
（2）这种行为在两种服务中均被观察到，分别是视频流和在线游戏，它们在CPU负载和生成数据方面具有相反的需求；
（3）在两个案例研究中，Docker开销似乎与服务的客户端数量无关，而服务器数量被观察到会影响Minecraft的开销，但不会影响FFserver。

6 结论

我们的分析聚焦于典型MEC场景中Docker的开销，涉及两种不同的容器化服务器：视频流服务器和多人游戏服务器。最初，我们考察了不同数量的服务器和客户端组合；随后，我们分析了容器处理的数据量对开销的影响。

在运行容器化服务器时，每个相关进程表现出不同的行为：在视频流情况下，dockerd的CPU消耗始终保持恒定，而其消耗情况则取决于在同一硬件上运行的游戏服务器数量。docker-containerd的行为有所不同：在两个案例研究中，其CPU消耗均与客户端和服务端的数量无关。至于docker-containerd-shim，每个正在运行的Minecraft服务器（无论服务的客户端数量如何）对应的CPU消耗为每秒0.033 tick数。相反，FFserver的shim进程始终处于空闲状态。最后，我们观察到每个容器处理的数据对总体Docker开销CPU消耗没有任何影响。