高效的serverless计算中的挑战与机遇
论文原文
概述
无服务计算框架允许用户在不处理操作问题的情况下执行小型应用程序（专心特定的任务），如服务配置，资源管理和负载增高情下的资源缩放。serverless计算最初出现云计算框架下，但是它可能与物联网完美匹配在边缘计算的数据处理方面。但是现在的serverless方案是基于VM和容器的，他对于边缘计算的操作效率和弹性伸缩来说太重了（更大的内存占用和更高的函数调用时间）。此外，更多新奇的IOT应用包含低延迟数据处理和准实时的响应。这使得基于云的serverless方案不合适。不久前wasm作为一种以原生速度运行serverless应用的备选方案被提出了，同时具备小内存占用和最优的执行时间。在这个文章中，我们讨论一些现在serverless的环境，它们的设计详情，未解决的性能挑战在边缘进行高效的无服务管理。我们概述了我们的无服务框架，叫做aWsm，基于webassmbly的方式，讨论机会使用根据aWsm设计，包含功能剖析，SLO（service level objective）驱动的用户功能性管理。最后我们给出了初步评估，以平均启动时间为特征的性能(12μs to 30μs)和用于用作函数的MiBench微基准标记的子集的经济内存占用（从10s到100s的kB）。
引言
工业物联网的激增和下一代技术（自动驾驶，智能城市，智能电网等）使越来越多的新应用程序成为可能。它们包含了数据处理系统在新性能特性于低执行延迟和高质量服务（Qos）
- 想象一个智能城市自动化街道和红绿灯，他感知交通流量和聚焦于优化整个系统的效率，也明智的响应医疗和消防部门的紧急请求，以满足他们的需求和服务水平目标（Service level Objectives SLOs）。
- 想象一个通信汽车和相关数据服务的世界，可以提醒驾驶员危险道路通知：再你前面的录上有黑冰
这俩个应用程序需要从多样的设备源处理大量新的数据在几乎实时的方式支持所需的功能。实时性能是许多工业和企业中的控制和检测所预期的。一些方案需要在10ms内响应。如果数据分析和控制逻辑实现在云端，这样的系统无法满足实时服务的要求。时间敏感的应用有车机系统，根本无法依赖和云端的连接。这样的程序必须在设备上本地的运行。
多种最近的趋势和相关的技术挑战激发了我们的兴趣：优化serverless的边缘计算。尽管云计算为以人类感知速度设计的应用程序提供了一个很好的解决方案，他变得不适合对延迟敏感的IOT应用上它们依赖速度，自动化决策无需人工参与。为了满足工作负载的性能需求，我们必须提供一个新方式更接近源头的去处理这些数据。换而言之，在边缘提供云计算。此外，这种方法将有助于支持数据安全和隐私问题。没有人希望他们的数据被破坏，当数据在云和设备不断转移时，这种风险更高。用户对于隐私和数据控制的要求越来越高，边缘计算能够解决这些多重问题。关键的区别和挑战，当边缘计算和云计算进行比较时，边缘表示资源受限的环境因此，边缘资源需要谨慎共享在多租户和高效管理，以支持所需的物联网数据处理功能。
serverless计算，也成为fuction-as-a-service（Fass）函数即服务。提供了新的执行模型，这使得用户运行他们的代码。不用担心操作问题。这种方式，用户不用担心的从多个参与的服务配置和资源管理。serverless应用亦在事件驱动和无状态。比如Fass可以实例化去执行预定义的函数和再他们完成的时候终止执行。在商业化系统中，用户按调用次数计费，不支付未使用或闲置资源的费用。通过无限的云端资源。serverless计算代表了一种效用计算形式，通过可用的按需计算资源访问弹性伸缩。自亚马逊lambda提供以来，大量主要的云提供商提供了serverless平台，包括谷歌云函数，微软Azure函数和IBM云函数。
现在的serverless框架主机函数实例在短周期虚拟机或容器，它支持应用处理隔离和资源提供。这些框架有重中在边缘计算系统，并且在提供低延迟方面效率低下，尤其是函数第一次实例化时。例如从aws lambda的125毫秒到microsoft Azure functions的一秒。为了获得更好的效率，这些平台缓存和重用容器在多个方法在给定的时间窗口内调用。例如五分钟，一些用户发送认为请求以避免容器关闭。在边缘环境下，使用长就存活或者过度供应的容器或者虚拟机会加速耗尽有限的节点资源同时让服务大量的IOT设备变得不切实际。因此，支持大量serverless函数提供低响应时间，是资源受限的边缘计算节点主要的性能挑战之一。
wasm是一个新生的技术，它提供了强大的内存隔离（通过沙盒）和接近原生的性能与具有更小的内存占用空间。wasm通过用户编写程序在不同的语言上，它们被编译成独立于平台的字节码。wasm运行时有能力利用多样的硬件硬件和软件技术去提供隔离和完成所需的资源分配。
在这篇文章中，我们讨论现在serverless技术和他们相关的性能挑战，并强调利用wasm方式，在边缘实现高效无服务器计算的趋势。我们概述wasm的设计：一种新的基于Wasm的边缘无服务器执行框架，我们正在努力。所提供的设计精心分析和SLO驱动性能管理提供了一系列有趣的机会。最后，我们给出了aWsm的初始性能表征，其平均函数启动时间（12μs至30μs）及其用作函数的MiBench微基准[9]子集的经济内存占用（10s至100s KB）
SERVERLESS
在这部分我们描述了俩个现状，传统的serverless实现方法：VM和基于容器框架。
以VM为基础的方法
虚拟化利用软件从客户操作系统中抽象物理硬件。管理程序或者虚拟机监视器（VMM）通过创建和销毁VM和复用硬件资源以及在这些虚拟机之间多路复用硬件资源。基础实施即服务（IaaS）是一个云框架，他提供虚拟机，存储，网络和及其他计算资源为客户提供服务。这些客户只管理他们的操作系统，存储网络和应用，而不是Laas底层云硬件的基础设施。通过类似虚拟机的隔离是当前多租户硬件共享的标准，虚拟机在serverless函数执行中是重量级的。
图示了serverless函数在虚拟机环境中的执行。函数的实例是其代码，内存（堆栈）的，语言运行时和依赖库组合（如图中黄色方框所示）。函数占用明显比提供VM的占用更小，其中包含了用户操作系统，虚拟硬件资源（先验地提供给VM，这不是功能所必须的）。
图中（a）中所有的黄色方框构成了vm环境中的一个函数。serverless函数是临时和短暂的。它们通常用较小的内存占用。而虚拟机往往相反--需要超GB的内存，和显著的启动时间以及停止时间。此外，客户操作系统和系统管理程序之间的传输控制以及支持分层调度（图中（a）里橙色的盒子）的额外虚拟化开销也相当大。
由于虚拟机的提供可能需要数十秒，serverless提供商使用创造性优化技术来更快地供应功能执行环境。通过维护不同的VM池
- vm的wasm池（已经实例化的VM），可以分配给新的租户和他的函数。
- 动态的vm池，最近用于执行的函数，并保存为将来调用函数。
微软Azure函数为客户提供了多个serverless托管计划，并可以选择在虚拟机中的函数。在基于VM的托管中，客户每小时都要为运行VM实例而收费-有些类似于传统的IaaS计费方式。
亚马逊的Firecracker和Kata Containers等努力,提供了比传统虚拟机更轻量级以及启动时间显著更快的虚拟机。亚马逊的Firecracker是极简的虚拟机监视器，他使用了linux 内核为基础的虚拟机（KVM）去管理他的轻量级vm，这些虚拟机内存占用仅5MB，启动延迟约为125毫秒。它是领先的无服务器云平台AWS Lambda背后的使能技术之一。
AWM-lambda有俩种serverless功能的隔离沙盒模型
- 使用专用AWS EC2实例去隔离不同的AWS账户，同时个别函数调用会使用传统容器方法进行沙箱隔离。
- 使用Firecracker 微虚拟机，去提供沙箱环境以执行不同函数调用。
容器为基础的方法
容器给用户应用的代码提供了标准的打包方式，配置，以及将所有依赖项合并到单个对象中。容器共享安装在服务器硬件上面的操作系统图中的（b）容器运行在资源隔离的进程中。容器是隔离的在底层系统使用了安全的方式比如linux chroot，cgroups和命名空间。linux容器，docker和windows 容器是不同的容器运行时，它将应用程序包含在具有专用文件系统的经常中，提供全部执行环境，同时在适当的情况下共享主机二进制文件和库。在适当的情况下共享热禁止文件和库。许多头部的云厂商，比如亚马逊，哥哥，微软，IBM和其他使用了这个技术实现Paas和最新的Faas。
如（b）中所示，serverless函数执行在容器环境下。每个函数（黄色的盒子）都打包到一个容器镜像中，其中包含了运行库在内的依赖项。语言运行时和依赖库是不在多个函数之间或者多个容器沙盒中共享的，甚至不是在单个函数的多个容器之间共享的。从而影响每个函数的内存占用和函数延迟。在这个框架中，不同的功能和底层操作系统控制容器/功能调度之间共享绿色层。容器管理控制创建，销毁，启动会和暂停容器在serverless的环境中。在一些实例中，实现客户之间的强大隔离，这些容器托管在每个客户专用的VM中。
我们相信现在的容器在实现低延迟功能并节约的利用有限的边缘资源这件事上是非常低效的。
性能管理挑战
启动延迟（即启动函数实例的延迟） 在faas平台，甚至对于相同的功能也有很大的差异，从几毫米到几秒钟，取决于多种因素。函数执行可能是一个热启动，重用VM和容器从以前的事件和相同的函数，或者是个冷启动，在新的VM容器开始，需要启动函数主机进程，等。当需要支持可预测的功能性能时，冷启动延迟是主要问题之一。此外，冷启动延迟依赖很多额外的因素：英语对函数进行编程的语言，分配的内存大小，代码量，库的数量类型以及他们的依赖关系，函数环境本身的配置，等。虽然这些因素中的许多都在开发人员的控制之下，并被考虑优化，唯一能做的只有让冷启动延迟有限的减少。
下一个挑战问题是选择正确数量的资源（内存和算力）去执行用户的函数。请求正确的数量的计算量不总是可行的。举个例子，当前的AWS lambda，用户只能提供内存设置。最小分配的数量内存是128M，增量是64MB（最大内存为3GB）。一旦用户选择了内存大小，aws就会按比例分配CPU配额。函数运行时性能是否与内存设置成比例缩放？多项论文和实验表明，通常功能性能随内存大小而变化，但它经常表现出不一致的行为。如果你的函数需要更少的内存占用，但是你需要他运行的很快呢？当前的资源供应是不灵活的，低效的，并且导致一些不可预测的结果。
许多当前的serverless计算平台，功能之间缺乏性能隔离，这使得它们的性能可能和预测的不那么一致。
此外，功能性能取决于用于部署的功能实例的硬件类型。云基建通常是多种多样的，由于数据中心基础设施的升级，它们不一样的环境可能显著的影响在不同调用运行同一个函数的性能。
为了实现高效的serverless边缘计算，serverless框架需要支持高性能的管理能力比如
- 解析函数的性能和他们需要的资源（在他们依赖的硬件上）去支持可取的函数响应执行时间。
- 保证可以预测函数性能
- 有效率的使用硬件的多核
- 智能调度提交的函数请求:分配和管理恰当数量的计算资源,可能会抢占已在系统中运行的函数,以实现指定的函数 SLO（服务级别目标），例如以软执行截止日期的形式。
在下一章我们会概述我们的serverless设计方案以提供这些理想的能力。
利用wasm在边缘进行serverless
使用wasm进行serverless计算
当今可行的基于云计算环境的serverless，在资源受限的边缘环境和提供低延迟的serverless函数计算中通常效率低下。在这个例子中我们描述了近代的趋势：使用wasm在serverless计算使函数更快的启动，调用处理更有效率，最小化内存消费，和提供最强大的安全。同时提供精细和准确的账单给客户。
介绍wasm
wasm是一个语言，架构，和平台无关的低级字节码旨在提供编译目标给编写的多种高级语言，比如c++，rust和一些部署在客户端和web服务器应用的语言。Wasm旨在作为JavaScript的另一个选择，用于web浏览器执行，同时提供强大的内存安全性，沙盒执行环境。wasm目标是接近原生的应用速度，通过广泛平台上可用的通用硬件功能。谷歌V8和Emscripten通过使用基于JavaScript虚拟机的沙箱和执行环境，将以Wasm支持的语言或WebAssembly Text Format]编写的程序编译到JavaScript解释器，在浏览器中启用Wasm执行。
使用了jsvm的wasm
一个serverless框架基于V8，Emscripten，和VM2展示了wasm在边缘进行serverless函数执行的能力。通过js后端框架展示了重要的wasm函数的启动延迟，整体函数明显较慢（俩倍到五倍于原生的时间）。这是由于js虚拟机后端和沙盒机制的开销和复杂性。serverless功能通常注册一次，并且每天都有数千次调用，因此使用jit汇编使用在每个函数调用的执行时间引入了额外的（显著的）开销。
原生的wasm运行时：
在采用wasm作为本地执行封面已经做出了极大的努力，因为它是各种高级语言编译的可移植目标。WASM标准不一定做出特定于web的假设，而且在标准化wasm系统接口在web之外运行wasm已经做了大量的工作。wasm的目标是创建系统接口，他使用wasm二进制去真正的独立于平台。（能够运行在不同的原生平台上）
有许多Wasm运行时用于用不同语言编写的程序:所有这些都能使原生运行wasm程序。fastly（www.fastly.com）宣布了lucet，他提供了编译和运行原生执行于wasm应用，Lucet可以实例化wasm某块在50微妙以内，只需要几kb的内存开销。Fastly的Terrarium项目提供多语言，基于浏览器的编辑器和基于Lucet的部署平台。
这些现存的系统演示了wasm运行实现serverless函数在轻量级沙盒中隔离和推送到边缘计算的能力，超越了现有rverless实现的限制之外。
如图C所示，执行wasm函数使用原生wasm运行时。wasm函数使用了提前（AOT）编译技术去使用编译器和语言运行时影响平台软件和硬件机器提供强大的沙盒之间与沙盒内部的内存安全。AOT编译汇编到共享的对象显著提高了原生wasm函数的启动延迟，并实现了代码共享在不同的wasm调用中。
应用管理者通常是分开的进程，他在系统上使用了多种基于wasm的函数运行时与隔离的经常。这些原生wasm运行时使在单个进程中支持一个函数的多个沙箱环境，相比于容器和虚拟机，它们的重量明显要轻很多。（c的黄色盒子）。本地语言运行时，运行库和os是在多个函数和沙盒中共享的。（图C中的绿色盒子）在这些现有的wasm一小时中，不同函数性能和执行特性是不受控制的。系统接口提供了运算wasm一小时如图c，使得serverless函数可以去影响操作系统的功能。然而，需要注意的是操作系统程序可以控制（c中的橙色盒子）作为独立进程执行的功能，因此也会影响到不同函数的性能表现。
新的wasm框架和他在serverless的性能管理方法
awsm是原生的wasm编译器和运行时框架。aWsm编译器是基于rust和使用LLVM的中间表示形式来使用基于硬件或软件的沙箱隔离检查。aWSM运行时利用AoT编译的wasm隔离对象在单进程内部使用多函数和他们的调用。如图d展示了wasm一小时和他的沙盒机器。多函数（例如A.so和B.so）是动态加载到wasm运行时。如图d的黄色盒子是一个不同的函数实例在分开的轻量级的wasm沙盒中。语言运行时，库依赖，和系统功能是隔离的可用于aWsm运行时中运行的不同系统。运行时绕过linux内核完全控制执行特性和不同的函数调用。异步的、基于事件的I/O用于使沙盒能够等待I/O完成，同时允许不同的沙盒有效利用CPU。
函数执行控制在aWSM中：Linux 内核的复杂性随时间呈二次函数增长，它对于应用性能和系统的安全性有重大的影响（增加攻击面）。IOT设备的普遍集成使得边缘设备的流量明显更高，并且容易受到边缘处理延迟的影响。linux内核交互中的开销显著影响了serverless计算和端到端的延迟于每一个调用。这就形成了aWsm运行时采取极端方法的强烈动机和提供有资源隔离和调度工具在管理和维护函数执行。
提供请求和函数执行的调度以及基于沙盒的隔离有很多好处。其中一些好处包括：
- 弹性的调度策略：在调度的沙盒中运行时具有计算能力，aWsm运行时调度是可配置的（独立于底层的系统调度器）以促进对各种重要性和关键性需求不同的时间保证。橙色的盒子SCHED如图d是区分aWsm运行时不同于a，b，c，其中OS调度器控制着函数沙盒的执行属性。
- 快速的沙箱切换：aWsm的沙盒机制允许用户态下，进行快速的上下文切换，从而去掉了系统的调用开销。例如，与 M:1 用户态线程类似,这种沙箱切换是协作式的。
- 抢占控制权：运行时调度程序利用POSIX信号来控制沙盒中的抢占执行。这使得运行时系统能够对函数的执行过程进行细粒度的控制。在多种函数和他们的调用中提供精确的统计和性能概述。系统级别的软中断（如SIGALRM和SIGUSR1）来实现aWsm运行时的抢占式调度。
- 多核心执行控制：资源共享和锁定在linux内核可能引起明显的缓存一致性这些和处理器中断（IPI）干扰，在多核的执行环境下，可能直接影响函数的执行延迟。aWsm运行时划分了函数跨核心的执行负载，从而限制了共享资源和提供的更好的可预测特性。
- 管理控制：一个共享的aWsm运行时获得了性能特征和不同的函数执行性能分析（图d中的profiling框）
我们认为,性能分析和对多个函数执行属性的控制能力,将使得WebAssembly运行时能够为边缘功能提供强有力的SLO驱动的延迟和可预测性保证。
最初的wasm性能评估：启动时间和内存占用
评估函数启动的性能和内存占用特征在aWsm运行中，我们使用了MiBenc 基准测试套件中的一个子集以及一个空函数作为测试案例。
空函数是简单的c程序，从main中返回同时没有其他库依赖。
基准测试应用使用了serverless函数代理，请求和响应没有外部接。我们从具有相同输入数据集的不同类别中随机选择MiBench基准测试的子集。
- basicmath测试使用包含固定常数集的输入数据进行简单的数学计算。
- bitcount测试位运算能力通过计算整数数组中的位数来测试位运算能力，输入数据是一个整数数组，其中0和1的数量是相等的
- cr3 执行32位的循环冗余检查（CRC）在文件中。输入的文件是大型语音文件
- qsort 排序是大String数组进行升序排序使用快排算法，他的输入数据包含了一个小的单词表
- sha基准测试是SHA安全哈希算法，他给输入的信息产生160bit的信息摘要。输入的数据是大的ascii编码文本文件的一篇文章。
- stringsearch 基准测试使用不区分大小写的比较算法查询给定的单词在短语中的出现。
- susan基准测试是一个图像识别软件包,它是为了识别脑部磁共振成像(MRI)中的角点和边缘而开发的。输入的数据是复杂的图片。
实验环境使用了 Intel i5-5200U CPU运行在2.20GHz和8G物理内存单核上（所有的实验都是在一个核心上进行的）
在不同基准测试的上千次迭代中,对Awsm中的内存占用和函数调用启动时间的测量
表I显示了不同基准测试的平均启动成本以及在aSM中编译和执行的这些基准测试的内存占用。每个基准测试的启动延迟是创建沙盒花费的时间，分配固定大小的堆栈（32mb），线性的内存（最初为16mb，最大是4gb），和填充线性的内存。函数的沙盒是专用的栈内存他保留了一个连续的虚拟地址空间进行最大4GB的线性内存使用mmap。线性存储器最初被分配16MB，并在保留的连续虚拟地址空间内扩展。
讨论：如表格所示内存占用在null函数测试是18KB，所选基准测试的内存占用范围在90KB到180KB之间。这反映出和需要所有必要依赖关系的VM容器执行环境的大小相比，无服务功能的内存占用要小很多。
null函数的平均启动延迟在10微妙，对于其他的基准测试在20微妙-30微妙内。 除了平均启动延迟之外，表中还显示了95%启动时间，对于其他的基准测试，落在22-39微妙之间。这个狭窄的延迟范围反应了aWsmserverless框架提供的功能中的更高的性能可预测性。
在边缘环境中，aWsm运行时负载是预定义的函数集合和他们的启动时库依赖。所以函数执行只将只需要一次冷启动的延迟：开始后第一次aWsm运行时。冷启动延迟在wasm函数中显著的更短（0.2ms-0.4ms）于传统的虚拟机容器冷启动。
这些数字反映出执行aWsm运行时的性能。我们认为 aWsm 运行时和可定制的性能分析，建模和智能调度，将为边缘的高效无服务器执行提供一个有吸引力的实现选项。
结语和将来的工作
serverless计算是刚出现的一个新引人注目的计算空间在边缘的IOT数据处理。在这篇论文中，我们讨论了最先进的serverless平台，它们基于虚拟机和容器，并列出与在Edge上运行这些解决方案相关的挑战数量。然后我们分析了基于最新的基于wasm的serverless实现。它提议了另一个方式去运行serverless应用以接近原生的速度，同时有了低内存占用和最佳的执行时间。我们概述我们的aWsm设计--一个新兴的以awsm为基础的用于在边缘进行serverless执行。aWsm绕过linux内核和使用了完全控制函数执行和他们的管理：包含分析，调度和资源分配。所提出的设计为用户函数的精心设计和易于定制的SLO驱动的性能管理提供了一系列有趣的机会。
在未来的工作中我们计划进一步使用这些机会构建一个分析模块来跟踪和分析函数的性能，尝试在不同的调度策略去支持SLO为基础的函数类，提供客户接口以进行各种函数调度和许可控制策略，利用ARM硬件功能提高内存--函数沙盒的安全性及其执行性能。