边缘计算:WASM容器运行环境

@李彪  June 30, 2021

WebAssembly在ServerLess的优势

Serverless计算已经成为云计算领域中很热的组成成分,这种模型允许开发者编写可以自动扩容的函数函数,并且只需要支付消耗的计算时间。这个模型非常适合处理物联网中不可预测和突发的工作负载。然而,即使由于在物理距离上很靠近边缘计算机从而具备很低的网络延迟、也无法解决巨大的性能损失。

第一次执行函数时需要创建相关的运行环境 - 通常是Docker容器。这种冷启动能够在任何一个当前请求中产生几百毫秒甚至数秒的延迟,这使得Docker运行的服务器不适合这些用例。在CPU、内存资源有限的边缘设备上,会进一步增加这些情况的发生率、严重性。

为了缓解这个问题,WebAssembly可以用来替换Docker,同时它具备和Docker相似的安全性、语言无关性、高性能、同时还有标准的WebAssembly文件格式。在这项工作中,我们检验了WebAssembly在Apache OpenWhisk中使用无服务容器运行时的适用性,OpenWhisk是个专注于边缘计算的ServerLess框架。我们选择了三个WebAssembly运行时来构建我们的容器环境,并给出了设计实现快速冷启动、同事保持高性能。

我们针对基于Docker的OpenWhisk、基于WebAssembly容器运行时,围绕冷启动时间、执行性能、内存使用进行了比较。在树莓派上,这是一种非典型边缘计算机设备,我们发现WebAssembly容器运行时比Docker快99.5%,比服务器级别的硬件快94% 。 Docker的执行性能与冷启动时间密切相关,而WebAssembly容器的吞吐量对于冷启动没有明显的敏感度。在CPU和IO混合的工作负载中,WASM的容器吞吐是Docker容器的2.4到4.2倍。总的来说,我们发现WebAssembly非常适合在ServerLess平台中使用,因为它的轻量级隔离机制、支持快速启动、并且支持通过提前编译来快速生成原生代码。WASM为低延迟无服务计算迈出伟大的一步。

一. 介绍

1.1 动机

伴随着大量增长的网络边缘设备,今天的云计算模型的局限性已经越发明显。低延迟和数据密集型的使用情况无法通过云来简化,因为物理距离和这些边缘设备传输的数据量超过了有限的带宽。因此,涉及数据分析、机器学习或者增强现实的应用场景需要从云中心模型中删除。为了解决这些问题,边缘计算范式应运而生。然而,将传统的云模型应用到边缘并不是一个有效的解决方案,由于可用资源的有限,以固定的方式分配虚拟机甚至容器等资源被证明非常低效。相反,需要一个具有更高资源弹性的模型,它可以快速伸缩,从而有效地使用可用的资源。实现这一点的一种方法是ServerLess计算—通常以功能及服务(FaaS)的形式出现。这此计算模型中,开发人员可以执行函数,而不必指定必要的基础设施是如何设置的。首先,计算资源的分配是自动化的,这使得高弹性成为可能。它的特性很好的适应了边缘设备的资源与能源受限环境,考虑到这种过度供应甚至比云模型中更不可取。因为资源可以在任何需要时使用,因此此模型非常适合事件驱动架构,比如那些在物联网场景中常见的,设备需要计算资源的时间是不可预测的,例如:当传感器接收到输入、用户按下按钮。因此,有时候ServerLess框架只接收少量的请求,有时候它又需要同时处理大量的请求。为了实现这种弹性,一个用户的函数可能与另外一个用户函数运行在同一个主机上。为了隔离这些实例,ServerLess框架利用OS级别的通过容器的虚拟化—通常是Docker。除了安全性之外,它还支持发包语言运行时,开发人员可以语言无关的方式编写函数,由于创建、销毁的操作成本很低,因此可以实现无状态。但是,廉价是相对的。从历史上看,容器与更重的虚拟机比起来,其创建确实需要更多的时间。在无服务器的时间范围内,其传入的请求应该尽快完成,但是容器需要首先创建,所以容器最终不是那么便宜。不预先分配资源以避免过度供应是无服务器的目的,但这些的前提是能够及时的分配本身。


评论已关闭