随着计算机视觉技术的发展，视频分析已经被广泛应用到日常生活中，例如行人识别，车辆统计等。对于视频分析应用，终端用户可以通过将模型计算卸载到附近的边缘服务器来获得高的服务质量。然而，当终端用户远离附近的边缘服务器时，由于网络连接的恶化，视频分析应用的服务质量将会显著下降。理想情况下，视频分析应用应该从其源边缘服务器实时迁移到新的附近的边缘服务器。
由于容器技术的简单性和低开销，所以该技术被广泛应用到边缘计算场景下。容器使用镜像(image)来打包所有与应用程序相关的文件。当源边缘服务器收到一个应用程序的迁移请求时，我们需要将相应的镜像从源服务器迁移到目的服务器。表1显示了当两个边缘服务器之间的网络带宽为25 Mbps时，利用现有迁移方案迁移视频分析应用的迁移性能，例如迁移OpenFace容器需要1000秒以上，传输了2.5GB的数据。很明显，这些应用的迁移时间是不可接受的。我们发现造成这种不良性能的关键因素之一是传输的镜像过大。
表1 迁移视频分析应用的性能(边缘服务器间的网络带宽为25Mbps)
每个边缘服务器可能为多个应用提供服务，因此每个边缘服务器通常存储着多个镜像（以下称为缓存镜像）。由于镜像的分层结构，因此每个边缘服务器可能会存储着很多的镜像层。如果一个被迁移的镜像和目标服务器中的缓存镜像具有相同的层，那么当一个镜像从源服务器迁移到目标服务器时，我们可以直接复用目标服务器中缓存的相同的层。我们把被迁移镜像中可以直接复用的层称为共享层（shared layers），把被迁移镜像中不能复用的层称为唯一层(unique layers)。图1展示了被迁移镜像和缓存镜像之间的共享层和唯一层的示意图。
图1 被迁移镜像和缓存镜像间的共享层和唯一层的示意图
目前还没有利用容器的分层结构进行视频分析应用的迁移工作。因此，我们希望进行详细的测量，加深对分层结构的了解，以指导视频分析应用迁移的设计。我们的测量主要想回答以下3个问题：
现有的容器迁移工作可以在几分钟内完成边缘场景下普通应用的迁移。但是，迁移视频分析应用时将会花费巨长的时间，迁移性能极低。因此，我们想知道，视频分析应用相关的镜像和普通应用的镜像之间有什么区别？
我们可以复用被迁移镜像和目标服务器中的缓存镜像之间的相同层，传输唯一层，以减少视频分析应用的迁移时间。因此，我们想知道，这种方法能在多大程度上提高迁移性能？
在迁移过程中复用相同的镜像层后，唯一层的数据大小将会决定镜像的迁移时间。因此，我们想知道，在迁移的镜像中，唯一层的数据有多大，如果唯一层的数据仍然很大，我们如何进一步优化迁移性能？
为了回答以上3个问题，我们首先需要构建我们的镜像测量数据集。我们使用Docker作为容器引擎，使用与视频分析应用相关的关键词在Docker hub中搜索。我们所用的关键词主要分为两类：
例如Yolo、ResNet、RCNN、Inception、MobileNet等;
例如目标检测（object detection）、目标分类（object classification）、目标跟踪（object tracking）和人脸识别（face detection）等。
此外，我们还从Docker Hub中提取了视频分析相关运行库的镜像，即Nvidia CUDA Toolkit、PyTorch和TensorFlow。虽然运行库镜像中不包含应用程序代码，但是用户或平台可以根据运行库镜像构建自己的视频分析应用，例如AWS Lambda。在迁移这些应用容器时，我们必须将运行库镜像发送到目标服务器。
为了比较视频分析应用镜像和普通应用镜像的区别，我们还从Docker Hub Library拉取了1650个普通应用的镜像。Docker Hub Library是Docker官方的镜像子仓库，包含了165种当前最为流行的运行库或者应用，例如Storm、Spark、WordPress等。我们为每个运行库（应用程序）拉取了最近的10个不同发行版本。
表2描述了我们测量数据集的组成。我们拉取了2085个视频分析应用相关的镜像，1650个普通应用镜像，总计3735个镜像用于分析。
表2 镜像数据集的构成
在获取到测量的镜像后，我们需要了解每个镜像的层信息，用于匹配镜像之间是否存在相同的层。当我们测量镜像的分层结构时，我们发现Docker为每一层随机分配了一个layer ID，而我们无法使用这个layer ID来获得该层的数据大小以及匹配镜像层是否相同。通过调查Docker的源代码和Docker的存储驱动，我们理解了映射的细节并实现了一个镜像层的映射器(layer mapper)，在我们的实现中每个镜像层用唯一的diff id索引，用于匹配镜像层是否相同 (具体实现参见参考文献[1])。
我们分析了镜像的大小和层的深度回答我们关心的第一个问题：视频分析相关的镜像和普通应用的镜像之间有什么区别？
图2展示了不同镜像类别大小的分布。从图中可以看出，视频分析应用相关镜像的数据量大小大约是普通应用的6.35倍(2.73GB vs. 0.43GB)。为了避免过度离群值的影响，我们计算了不同类别的四分位数。75%的视频分析应用相关的镜像大小大于1.17GB,而75%的普通应用的镜像大小大于0.12GB。图3展示了不同镜像类别的镜像深度。从图中可以看出，视频分析应用相关的镜像平均深度为15.74，而普通应用镜像的平均深度为8.96。
图2 不同类别的镜像大小
图3 不同类别的镜像的层深度
总而言之，视频分析应用相关的镜像比普通应用的镜像具有更深的层结构，更多的数据。因此，现有的一些工作可能满足一般应用的迁移性能要求，但不适用于边缘计算中视频分析应用的迁移。
我们分析了视频分析应用相关镜像的分层结构，回答我们关心的第二个问题：复用相同层这种迁移方法能够为迁移带来多大的性能提升？
每个边缘服务器为多个视频分析应用提供服务，因此每个边缘服务器都会缓存着多个镜像。由于边缘服务器的存储资源不是无限的，所以一个边缘服务器只能缓存有限的镜像数量。哪些镜像被边缘服务器缓存应该根据镜像的流行程度(popularity)来决定。在我们的测量中，我们使用从Docker Hub获得的下载次数来模拟镜像的流行度。我们假设边缘服务器缓存的镜像的流行度符合标准正态分布或者Zipf分布，并对此分别进行了实验。在我们的测量中，目的地服务器存储缓存镜像的存储空间设为128GB、256GB、512GB和1024GB。
我们实现了两种迁移方案，其中一种是我们只传输被迁移镜像中的唯一层的数据（表示为TUL），另一种是我们在迁移过程中传输完整的镜像（表示为TCI）。我们将源边缘服务器和目的边缘服务器之间的网络带宽设置为50Mbps。
图4展示了在流行度符合标准正态分布下的不同方案的平均迁移时间和性能提升。从图中可以看出TUL这种复用相同层的迁移方案确实能够提升迁移性能，但是优化过后的迁移性能仍然不理想。大部分情况下，平均迁移时间仍然大于300秒。
图4 在不同存储空间下的平均迁移时间和性能提升
我们分析了被迁移镜像中唯一层的数据大小，回答我们关心的第三个问题：基于复用相同层的方案下，在迁移的镜像中，唯一层的数据量有多大？
图5展示了唯一层的数据量大小。从图中可以看出唯一层的数据量仍然很大，例如在缓存镜像的存储空间是512GB和1024GB，唯一层的平均数据量大小分别为2.20GB和1.67GB。尽管共享相同层已经减少了待迁移的数据，但是被迁移镜像中的唯一层数据量仍然很大，这将导致次优的迁移时间。
图5 在不同存储空间下的唯一层的数据量大小
直观地说，我们可以利用压缩来减少唯一层的数据大小，提高迁移性能，但压缩数据会引入压缩时间。图6（a）显示了一个带压缩的迁移方案（以下称之为串行迁移）的工作流程。在串行迁移方案中，我们需要将被迁移镜像的diff ID与目的地缓存镜像的diff ID进行比较，找出出现在被迁移镜像中的唯一层（layer diff），然后压缩这些唯一层（compression），并将它们传输到目的地（transfer）。最后，压缩后的数据被解压（decompression）并重新加载到目的地的Docker守护进程当中。
在串行迁移方案中，由于压缩计算属于计算密集型任务，压缩计算会导致很大的延迟。在这个延迟期间，网络不会收到任何要传输的数据，因此网络是空闲的。在源服务器和目的服务器之间的带宽较低的情况下，尽早让网络传输压缩数据对取得良好的性能至关重要。
我们设计了一个流水化迁移(pipelined migration)方案，以利用网络来尽可能快地传输压缩数据。图6(b)显示了流水化迁移的工作流程。我们首先执行layer diff来发现被迁移镜像中的唯一层，然后将这些唯一层的数据分成多个块并依次压缩。每个数据块一旦被压缩完，就立刻发送出去。目的地服务器完成最后一个数据块的解压后，就会获得完整的镜像，然后将镜像重新加载到Docker守护进程中。在这种方法中，我们可以保持计算和网络资源一直被利用，实现流水化并行，以加速镜像迁移。
图6 串行迁移 vs. 流水化迁移
我们评估了流水化迁移方案的性能。图7展示了当目的地的缓存镜像大小为1024GB时，不同迁移方案下平均迁移时间。从左图中我们可以看到流水化迁移的表现明显好于其他方案。随着可用CPU核数的增加，串行迁移和流水化迁移的迁移时间都有所下降。由于TCI和TUL对计算资源量不敏感，它们的性能没有变化。右图显示了划分块的数据块大小对流水化迁移性能的影响。随着分块大小的增加，迁移时间略有增加，流水化迁移表现出了比较稳定的迁移性能。我们评估了流水化迁移方案的性能。图7展示了当目的地的缓存镜像大小为1024GB时，不同迁移方案下平均迁移时间。从左图中我们可以看到流水化迁移的表现明显好于其他方案。随着可用CPU核数的增加，串行迁移和流水化迁移的迁移时间都有所下降。由于TCI和TUL对计算资源量不敏感，它们的性能没有变化。右图显示了划分块的数据块大小对流水化迁移性能的影响。随着分块大小的增加，迁移时间略有增加，流水化迁移表现出了比较稳定的迁移性能。
图7 不同迁移方案的迁移性能
现有边缘计算场景下基于容器的应用迁移的工作，由于没有很好地利用容器的分层结构，导致视频分析应用的迁移时间过长。在本文中，我们有选择地从Docker Hub抽取了3735个有代表性的镜像来测量应用镜像的分层结构。通过分析镜像的分层结构，发现对于视频分析应用而言，复用相同层能够带来迁移性能提升，但是迁移时间仍然很长。在复用相同层的基础上我们进一步优化，提出了流水化迁移方案，避免网络资源的等待，显著提升了镜像迁移的性能。
参考文献
[1] Rong, C., Wang, J. H., Liu, J., Yu, T., & Wang, J. (2022, April). Exploring the Layered Structure of Containers for Design of Video Analytics Application Migration. In2022 IEEE Wireless Communications and Networking Conference (WCNC) (pp. 842-847). IEEE.
[2] M. Sindi and J. R. Williams, “Using container migration for hpc work- loads resilience,” in 2019 IEEE High Performance Extreme Computing Conference (HPEC). IEEE, 2019, pp. 1–10.
[3] “Live migration using criu,” https://github.com/checkpoint- restore/p.haul.
[4] L. Ma, S. Yi, and Q. Li, “Efficient service handoff across edge servers via docker container migration,” in Proceedings of the Second ACM/IEEE Symposium on Edge Computing, 2017, pp. 1–13.
[5] S. Fu, R. Mittal, L. Zhang, and S. Ratnasamy, “Fast and efficient container startup at the edge via dependency scheduling,” in 3rd USENIX Workshop on Hot Topics in Edge Computing (HotEdge 20), 2020.
[6] T. Harter, B. Salmon, R. Liu, A. C. Arpaci-Dusseau, and R. H. Arpaci- Dusseau, “Slacker: Fast distribution with lazy docker containers,” in 14th USENIX Conference on File and Storage Technologies (FAST 16), 2016, pp. 181–195.
原文始发于微信公众号（风眼实验室）：利用容器镜像的分层结构进行视频分析应用的迁移
图1 被迁移镜像和缓存镜像间的共享层和唯一层的示意图
