一种消除无服务器计算容器冷启动的方法

1.本发明涉及无服务器计算架构技术领域，具体涉及一种消除无服务器计算容器冷启动的方法。


背景技术：

2.无服务器计算(serverless computing)架构是数据中心部署大规模分布式应用的首选方式。无服务器计算主要运用函数即服务(function-as-a-service,faas)模型为开发人员提供便捷的部署方式、提高应用程序的扩展能力。然而，在faas平台侧却存在许多亟待改进的问题，特别是函数的冷启动优化问题。
3.当faas平台首次接收到函数的调用请求时，需要为该函数请求准备对应的容器运行时环境。通常，构建一个容器运行时环境包括：(1)创建并启动一个基础的运行环境；(2)拉取函数代码并安装函数相应的依赖项。这个构建阶段称为冷启动阶段。只有在冷启动阶段完成后，函数才能执行。
4.相关研究表明，容器启动时间的大致在1秒左右，而每个函数的执行时间通常分布在毫秒到秒级中。相对于函数较短的执行时间，上述提到的冷启动阶段可能会花费大量的时间，从而增加函数调用时的延迟，降低faas用户的使用体验。另外，在多个函数组成函数链部署应用时，冷启动问题会加剧，因为函数链可能会导致级联冷启动。因此，函数的冷启动是faas提供商需要克服的问题，降低冷启动问题的影响对faas平台来说是一个关键挑战。


技术实现要素：

5.本发明的目的是为了解决现有技术中的上述缺陷，提供一种消除无服务器计算容器冷启动的方法，在函数调用请求到达无服务器平台时通过基于分类处理的思想，针对不同类型的函数提供不同的冷启动优化策略，旨在降低冷启动开销和端对端延迟情况下，减少物理服务器的资源开销。
6.本发明的目的可以通过采取如下技术方案达到：
7.一种消除无服务器计算容器冷启动的方法，应用于无服务器计算系统上，无服务器计算系统在现有无服务器平台的基础上加入了函数映射器、行为监控器和i/o转发器，以下无服务器计算系统简称系统。
8.系统接受函数调用请求后对所调用函数对应元信息做预处理操作，首先根据元信息在函数映射器中判断该函数的计算结果是否已缓存。若缓存未命中，则正常执行函数。在函数执行过程中，行为监控器监控所运行函数产生的系统调用，并判断函数的类型。最后，将函数所需的计算结果或请求的外部文件按函数类型分别存储于函数映射器和本地文件系统中。
9.该方法中，无服务器平台接收函数调用请求后分别经由函数映射器、行为监控器和i/o转发器三层处理逻辑，具体包括以下步骤：
10.s1、当系统接收到函数调用请求后，将所调用的函数的输入参数进行哈希操作，并根据函数名称以及对应参数的哈希值初始化一个嵌套的键值对数据结构，其最终的“值”为函数对应的输出，函数名、函数输入的哈希值和函数输出以嵌套键值对映射的形式存储于函数映射器中；
11.s2、在函数执行时，通过在行为监控器监控函数运行时产生的系统调用，根据监控信息将函数分成三种类型，分别为计算型函数、i/o相关函数和环境相关函数，函数映射器根据函数的类型决策是否缓存对应的计算结果；
12.s3、分别为计算型函数和i/o相关函数设立缓存条件，对于计算型函数，设立缓存条件用于消除函数调用时的冷启动开销；对与i/o相关函数，设立缓存条件用于降低函数执行时因对外访问对象存储文件造成的端对端延迟。
13.进一步地，所述步骤s1中，系统接收到函数调用请求，对所调用函数对应的元信息进行哈希预处理一方面是为了快速检测函数计算结果的缓存状态；另一方面是为了降低缓存计算结果的内存开销；其过程如下：
14.s11、解析函数名以及调用函数所携带的输入参数param，将输入参数进行哈希计算，保留其计算后的哈希值hash(param)；
15.s12、利用上述函数输入参数的哈希值hash(param)为键，初始化一个空键值对{hash(param):value}，以函数名func为键，以上述空键值对为值初始化一个嵌套键值对{func:{hash(pram):value}}，其中value为待填入的函数计算结果；
16.s13、当函数请求被系统接收后，首先判断函数名是否存在嵌套键值对中，然后判断是否存在对应函数输入参数所映射的计算结果；若存在函数所需的计算结果，则将其直接返回给函数调用方；若不存在对应的计算结果，则转至步骤s2、s3，正常执行函数。
17.进一步地，利用哈希计算将函数、函数输入和函数计算结果联系起来，在消除容器启动开销的情况下加速函数映射器的检索速度。同时，对函数的输入参数做哈希处理可以将输入参数转化为定长的字符串，降低函数映射器保存函数映射信息所需要的内存空间。
18.进一步地，所述步骤s2中，行为监控器在函数执行过程中监控函数发出的系统调用信息，根据监控信息将函数分成三种类型的过程如下：
19.s21、对于i/o相关函数，在类unix操作系统中，许多不同类型的i/o操作都由文件描述符做统一标识，文件描述符对打开的文件实例有间接引用作用，文件描述符可以通过open()系统调用来获取，即i/o操作需要通过open()系统调用做支撑，内嵌于函数容器内的行为监控器根据函数是否产生open()系统调用来判断是否属于i/o相关函数；
20.s22、对于环境相关函数，系统在t次执行阈值中判断函数调用对应的输出是否一致，若函数输出在t次执行中不一致，则将该函数分类为环境相关函数；
21.s23、对于计算型函数，若上述步骤s21、s22都未命中，则将目标函数归类为计算型函数，对于计算型函数，其每一个输入都对应着唯一的一个计算结果。
22.进一步地，将无服务器函数分成计算型函数、i/o相关函数和环境相关函数，函数映射器和i/o转发器根据函数的类型确定函数的优化策略，其中，计算型函数是函数映射器缓存计算结果的目标，而i/o相关函数所请求的外部文件是i/o转发器维护的对象。
23.进一步地，所述步骤s3过程如下：
24.s31、当系统接收到已缓存计算结果的计算型函数请求时，直接前往函数映射器根
据函数名以及输入参数获取其计算结果，省去容器启动以及函数重复执行的开销；
25.s32、当系统接收并执行i/o相关函数时，对外部对象存储发出的文件请求首先被i/o转发器拦截，然后判断本地文件系统是否存在所请求文件；若本地文件系统不存在，则向外部获取文件请求，在传送给函数的同时保存一份至本地文件系统中；
26.其中，i/o转发器在实际系统中作为一个外部请求代理发挥作用，当函数对外请求文件时，i/o转发器首先会拦截对应的文件请求，再判断本地文件系统是否已经缓存了函数所请求的最新版文件；若本地缓存未命中则请求远程文件并保存至本地中。
27.上述步骤s31、s32中根据其监控信息对函数分类后的优化目的如下：
28.对于每一个单独的无服务器函数，将其视为执行过程中的分类问题，分类目标在于根据函数的不同特点寻找一种优化方式，降低无服务器平台的冷启动和端对端延迟开销。
29.进一步地，对计算型函数和i/o相关函数二者分别进行消除容器冷启动和降低端对端调用延迟的优化，对于计算型函数平均降低了81.93％的端对端延迟，对于i/o相关函数平均降低了67.49％的端对端延迟。
30.进一步地，所述函数映射器保存了计算型函数输入参数对应的计算结果，当无服务器平台接收到相应的请求时可以直接由函数映射器返回计算结果，绕过了容器初始化和函数启动执行的开销，降低了26.23％的物理资源开销。
31.本发明相对于现有技术具有如下的优点及效果：
32.(1)本发明根据无服务器函数执行时的不同特性，将其分为三个类别，分别是计算型函数、i/o型函数和环境相关函数，根据函数的划分类别采取不同的优化方案。
33.(2)本发明对于计算型函数，通过直接缓存其计算结果，避免了函数的重复执行，从而消除容器冷启动的开销；对于i/o相关函数，采用本地文件系统为缓存，将函数所请求的外部文件的最新版本保存在本地缓存中，降低了因访问外部文件带来的较高端对端时延。
34.(3)本发明在消除计算型函数容器冷启动和降低i/o相关函数调用延迟的情况下，考虑了降低无服务器平台的物理资源开销。
附图说明
35.此处所说明的附图用来提供对本发明的进一步理解，构成本技术的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
36.图1是本发明公开的一种消除无服务器计算容器冷启动的方法的应用架构图；
37.图2是单步函数在不同策略下产生的端对端延迟对比图；
38.图3是单步函数在不同策略下产生的另一端对端延迟对比图；
39.图4是多步函数在不同策略下的调用延迟示意图；
40.图5是执行单步函数过程中物理资源利用情况示意图；
41.图6是执行多步函数过程中物理资源利用情况示意图。
具体实施方式
42.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例
中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
43.实施例1
44.如图1所示，是一种消除无服务器计算容器冷启动的方法的应用架构图，应用在无服务器计算架构下，针对调用函数时产生的容器冷启动和函数执行过程造成的高延迟问题进行优化。对于计算型函数通过缓存计算结果来绕过函数的冷启动；对于i/o相关函数通过缓存外部请求到本地文件系统来降低函数执行的端对端延迟。本发明对这种优化策略进行对比测试，从多角度评估本发明对无服务器平台的冷启动优化效果。
45.为了更清晰地阐明本发明的应用场景，以下结合应用架构图再作详细分析，主要分为三个步骤：
46.1)检查计算型函数的计算结果。函数映射器在接受到用户的函数请求后，首先将函数的输入进行哈希计算，再根据计算后的哈希值结合函数名查询是否已经缓存了对应的函数计算结果。具体过程如下，假设当前请求的函数名为func，输入参数为param，通过哈希计算后的输入参数为hash(param)。在函数映射器中，首先查找是否有键为func的值func
→
v。若存在，则在func
→
v中查找是否存在键hash(param)，函数对应的计算结果为func
→v→
hash(param)。若上述过程有一步不命中，则说明所请求函数对应的缓存尚未保存在函数映射器中。
47.2)函数行为监控。在函数映射器未命中的情况下，本发明通过在函数执行过程中监控函数所产生的系统调用信息，进而判断函数的类型。具体来说，本发明将函数分为计算型函数、i/o相关函数和环境相关函数。本发明在容器运行时中加入行为监控模块，用于捕获函数的系统调用。其中，若函数在执行过程中发起open()系统调用，则说明函数需要访问外部文件。此时函数被分类为i/o型函数。另外，本发明通过对比函数过去连续t次的计算结果来区分计算型函数和环境相关函数。记函数func在第i次的计算结果为resulti。若有resulti＝resultj,1≤i＜j≤t，则说明函数func在过去连续t次的计算结果都一致，该函数可判定为计算型函数。否则，该函数为环境相关函数。基于以上分类，函数行为监控器会将计算型函数的计算结果以键值对的形式缓存到函数映射器中。
48.3)i/o拦截器。i/o拦截器旨在降低i/o相关函数的端对端延迟。i/o拦截器与函数监控器互相配合，函数监控器监控函数运行过程中产生的i/o系统调用。当拦截器捕捉到i/o相关函数对外的文件请求时，首先根据请求的文件名判断本地文件系统是否存在相应的最新版文件。若本地文件系统已缓存函数请求的文件，则直接从本地加载；若本地文件系统不存在函数所请求的文件，或者文件版本不是最新时，才会发出远程文件i/o请求。i/o拦截器从远程获取文件之后更新一份到本地缓存，以方便后续函数请求。
49.综上所述，本实施例提一种无服务器计算架构下消除冷启动的方法，该方法利用无服务器函数的特性将其分为三类。对计算型函数通过缓存其计算结果以绕过函数的重复执行和容器的启动，进一步降低无服务器平台因启动容器所需的物理资源开销；对i/o相关函数提供一个本地文件系统作为远程文件的i/o缓存，降低函数调用的端对端延迟。
50.实施例2
51.本实施例从单步函数和多步函数两种函数负载对所提技术做函数端对端延迟和
资源使用情况两方面的测试，其中单步函数指的是只包含一个函数的应用，如表所示；而多步函数指的是包含多个函数的应用，如表2所示。本发明利用学术界公开的函数数据集进行效果测评。本发明在运行过程中涉及到一个参数t，即通过函数连续t的执行后的数据来判断函数属于计算型函数或环境相关函数，实验测评中t参数设置为3。
52.表1单步函数类别及描述
[0053][0054]
表2.多步函数描述
[0055]
函数描述finra银行审计应用，包含5个单步函数prediction图片分类应用，包含3个单步函数set computation集合相关计算应用，包含三个单步函数
[0056]
在无服务器平台中，函数执行需要一个容器作为载体，平台在启动容器时需要为其分配一定的物理资源，例如cpu核心数、内存等。平台在接收到用户请求即刻起到用户接收到回应的时间间隔为函数的端对端调用延迟。本发明通过重复执行函数10次的方式来测试函数的端对端延迟以及物理资源的利用情况，测试平台包含2个intel(r)xeon(r)silver 4216处理器(每个处理器包含32个处理核心)、128gb内存、centos 8系统。在以下对比中，本发明命名为hashcache，用作对比的策略为faascache。
[0057]
图2和图3是单步函数在不同策略下产生的端对端延迟对比图。图2中，本发明下的计算型函数相对于faascache优化了39.05％到66.78％。实际上，本发明由于在缓存计算型函数的输出之前通过连续比对函数输出在t次的结果后，决定是否缓存其输出。因此，图2中关于计算型函数的端对端延迟包括了hashcache未激活时的数据。在移除了这部分数据之后，图3展示了hashcache激活之后对函数端对端延迟的优化值。由图3可得，hashcache相对于faascache，在计算型函数延迟上最高优化了94.8％，平均优化了81.94％；在i/o相关函数延迟上平均优化了67.4％。以上实验结果证实了本发明提出的hashcache能够有效缓存计算型函数的计算结果，同时能够缓存i/o型函数向外请求的远程文件，从而降低其端对端延迟。
[0058]
图4展示了多步函数在不同策略下的调用延迟，从图中可以看出，hashcache相对于faascache在finra、prediction和set computation三个应用中分别优化了34.6％、54.26％和53.9％。
[0059]
总的来说，本发明提出的hashcache在单步和多步函数的端到端延迟方面都有更好的性能。这是因为有了hashcache,faas平台可以在缓存相应的输出数据后返回函数的计
算结果。此外，hashcache维护一个本地文件系统缓存层来存储每个i/o相关操作的最新外部请求。
[0060]
图5和图6描述了执行单步函数和多步函数过程中的物理资源利用情况。平均上，hashcache在内存使用量上相对于对比策略faascache降低了26.23％。同时，hashcache产生的cpu峰值远远少于faascache策略下产生的cpu峰值。以上结果证实了本发明能够有效通过缓存计算型函数的计算结果，来绕过容器的启动和函数的执行。绕过容器的启动避免了内存的分配，绕过函数的执行避免了消耗cpu资源。
[0061]
上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。