Cross-Edge Orchestration of Serverless Functions With Probabilistic Caching

分享一篇发表于2024年，CCF A类，SCI 2区Transactions on Services Computing(TSC)的一篇关于无服务器函数容器缓存的文章Cross-Edge Orchestration of Serverless Functions With Probabilistic Caching，于2023年10月4日投稿，2024年5月1日返修，2024年5月6日录用。

Authors

• Chen Chen：剑桥大学计算机科学与技术系研究助理，个人主页为：https://www.cst.cam.ac.uk/people/cc2181，谷歌学术主页为：https://scholar.google.com/citations?hl=zh-CN&user=fNcWdsIAAAAJ&view_op=list_works&sortby=pubdate。其研究方向为无服务器计算，云/边计算，网络资源编排，在网计算，分布式系统及移动网络。
• Manuel Herrera：剑桥大学高级研究员，关注交通、电信和水务等智能且具有弹性关键基础设置的预测分析和复杂科学的发展。
• Ge Zheng：剑桥大学研究助理，研究边缘计算，供应链风险预测，模式识别/分类，智能交通系统。
• Liqiao Xia：香港理工大学博士研究生，研究边缘计算，知识图，可靠性分析。
• Zhengyang Ling：剑桥大学研究助理，研究边缘计算，无线传感器和执行器，光测量及应用。
• Jiangtao Wang：考文垂大学助理教授，研究移动和普适计算。

Background

随着通信技术和物联网技术的发展，越来越多的IoT应用连接到网络，如智能工厂，在线游戏，增强现实和虚拟现实等。这些应用会在终端设备持续收集数据，为处理这些数据，边缘计算广为采用。

近期，无服务器计算在边缘计算中得到广泛关注，无服务器使IoT应用运行在轻量的容器中，在服务结束后容器销毁，释放资源，大大提升了资源效率和响应时间。

Motivation

如图1，当用户请求无服务器函数时，在数据源（Edge Node 1）服务用户请求可能会导致很大的时延，这是因为创建容器会经历冷启动过程。然而，由于节点2已经缓存了容器，我们可以让节点2服务用户请求以避免冷启动时延，但需要以更大的传输时延为代价。

图1

与传统的云数据中心不同，其具有同构的算力和存储，在分布式的边缘节点支持无服务器函数可能会无法完全发挥其潜力。

在跨多个地理分布的边缘节点上部署各种无服务器函数，以完全发挥无服务器容器的非常具有以下挑战：

1. 现有工作忽略了边缘计算的异构网络拓扑，比如，用户可能离缓存了容器的节点远，因此在调度容器时如何综合考虑数据源和容器以优化传输时延比较困难。

2. 与似乎有无穷算力资源的云计算不同，边缘设备很容易到达容量，且内存容量昂贵。频繁创建和销毁容器很容易造成系统花销，因为创建容器需要下载代码并在服务请求前创建运行环境。因此，在没有函数调用统计信息的前提下优化容器编排具有挑战性。尽管缓存函数可以解决这一问题，但缓存函数需要花销。无服务器计算中，用户只需按实际使用的计算量付费，因此需要服务提供者及无服务器平台承担缓存的花销，即缓存函数会降低服务提供者的长期收益。

因此，平衡容器切换（创建新容器）、通信及缓存成本对边云系统的有效性至关重要，同时，这一权衡（trade-off）尚未被明确研究。

System Model & Problem

系统模型

边缘服务提供者在地理分布的边缘节点 V = { 1 , 2 , . . , V } \mathcal V = \{1,2,..,V\} V={1,2,..,V}上部署无服务器计算服务，每个节点具有一定的硬件资源（如，内存），表示为$U_v^t$，用 E = { 1 , 2 , . . , E } \mathcal E = \{1,2,..,E\} E={1,2,..,E}表示边缘节点之间的连接，将用户的请求表示为 R = { 1 , 2 , . . , R } \mathcal R = \{1,2,..,R\} R={1,2,..,R}。

系统设计

图2为文章pCache的架构，其基于Knative，Kubernetes和Kourier工具构建。系统整体流程为：
用户首先将请求发送Ingress gateway，然后请求被发至Scheduler，Scheduler根据算法1和算法2决策，Scheduler中也存储了缓存信息（包含了运行但没有服务任何请求的容器），依据缓存的容器和到来的请求进行决策，决策结果通过Kubernetes的API服务器发送给Knative的端点。API服务器在有需要时创建容器，与此同时，放置决策也被发送至Ingress gateway，Load balancer则将函数分配到函数pod上，最终，函数pod处理请求流并将结果返回给用户。当完成请求后，Scheduler基于算法2决策是否终止容器。
图2

问题描述

文章考虑创建容器的成本、节点之间的通信成本（正比于通信时延）以及缓存（运行容器）的成本，并最小化这三者的加权和。通过将该优化问题规约到一般指派问题（Generalized Assignment Problem，GAP），证明文章的问题为NP难的。

Method

算法1 – 请求分布

输入：用户请求、计算节点，计算节点间的通信成本，每个计算节点缓存的容器，每个计算节点的内存容量
输出：每个请求分配到哪个计算节点
流程：

1. 当请求到达节点v时，首先看节点v缓存的容器能否处理，如果能处理，则全部分配到节点v处理；否则转2
2. 对所有节点v’依据v和v’的通信成本升序排序，对剩下的无法通过v缓存的容器处理的请求，如果节点v的切换成本高于将请求发送到v‘的成本，则将请求发送到v’处理；
3. 2结束后，如果请求没有被服务完，则调用算法2，在节点v上创建新容器。

算法2 – 概率函数缓存

输入：节点v
输出：容器列表
流程：

1. 如果缓存的容器容量大于内存，则依据下列公式计算容器n的概率，并依据概率选择一个容器并销毁
   
2. 创建一个新容器

Evaluation

文章采用了仿真和Knative真实部署两种评估方式，所有的实验重复10次并使用平均值作为结果。这里只提一下一些关键的数据集和评估指标，具体结果可阅读原文。

• 拓扑：文章采用了EUA数据集：https://github.com/PhuLai/eua-dataset，该数据集用于边缘计算，包含Melbourne CBD 区域的125个边缘服务器（基站）和一些用户数据。
• 请求：使用了Azure数据集：https://github.com/Azure/AzurePublicDataset/tree/master，包含了微软Azure 14天的函数调用数据。
• 容器：构建了4种容器

应用名称	内存大小(MB)
Web 服务器	55
文件处理	158
Supermarket Checkout	332
图像识别	92

• Baseline： LRU，FC（Fixed Caching）
• 性能指标：平均成、系统成本、冷启动频率

想知道更多请看原文：https://ieeexplore.ieee.org/abstract/document/10528903，欢迎通过留言等方式讨论，一起进步！