【论文总结】[ATC '18] SAND:A high-performance serverless computing platform

SAND:A high-performance serverless computing platform

这篇文章源自ATC18期刊。它重点阐述了一种高性能的云原生无服务器架构。已有针对Serverless技术的综述文章。

该模型是Serverless Computing中最简单的计算方案之一。在这一模型中可以看出, 开发人员与平台之间实现了分工协作, 开发人员只需设置触发事件并上传相应的函数代码。与此同时, 服务器侧则会处理资源分配, 按时响应客户端请求, 执行用户提供的功能, 最终将处理结果返回给客户端使用者。

这种计算模式带来了诸多优势。首先，在使用该模式时无需操心后端服务器、程序依赖以及操作系统的管理等问题。通过这种方式可以充分享受云平台提供的弹性扩展的服务能力。此外，在这种模式下由于开发者能够专注于代码逻辑而非运维工作本身因此能够显著提升生产效率。综上所述，在开发者眼中Serverless Computing无疑是一种非常理想的选择。

对于开发者来说，在开发应用时就会利用这个Serverless平台来建立很多的应用计算功能。以图像处理应用为例，在这里 开发者创建了四个计算模块 分别用于元数据提取、信息处理、物体识别以及缩放图片尺寸 这些模块之间存在数据传输关系 形成了一个完整的 workflow

作者提出了一种将该图像处理应用部署方案应用于现有的三大Serverless平台的技术方案。通过对比实测数据发现，在实际承担计算任务的时间仅占约一半左右的情况下就出现了明显的性能瓶颈问题。这种现象的主要源于Serverless平台带来的中间信息传递以及函数启动等额外开销相对较大导致的应用频繁调用性能表现受限这一现象不利于提升系统的吞吐能力并进而影响整体服务效能

在该研究中, 作者开发了一个高性能无服务计算平台SAND. 其主要目标是降低应用延迟的目的之一, 同时充分利用资源.

首先介绍背景，主要是现有的多个平台的现状以及一些常见的做法。

现有的一些平台多采用容器作为执行计算任务并实现资源隔离的技术架构。将容器部署到具备可用计算资源的宿主节点上后，在完成计算任务后会等待指定时间后自动释放资源。消息总线既可采用分布式传输也可借助存储服务实现消息传递。

这些是我们总结出的一些常用做法。其中大部分功能与服务都采用了容器来隔离功能这一方式，在这种情况下会对功能执行以及这些系统在处理并发性时产生一定的影响。每当遇到新请求时都需要从头开始初始化容器并进行创建这称为冷启动过程必然导致较长的启动延迟因此这种方法并不是最优的选择我们可以采用热启动的方式来优化这一过程在容器已经处于运行状态的情况下继续让它运转这样就能有效地复用那些空闲状态下的容器从而实现了资源的最佳利用这就是热启动的具体实施方法一旦收到请求就可以将它们分配到已经准备好的空闲容器上以便于提高系统的运行效率

然而，在这种情况下，并不建议为每一个并发请求都实现容器的热启动操作。原因在于，在对每个并发请求实施热启动时会提前保留大量资源，这可能导致资源利用率低下。如果不保留这些热启动的容器，则会导致应用响应延迟较长，并且这也是我们所不愿意看到的结果。

此外，在深入研究后我发现：不同Function之间通过同一个message bus实现了信息交互和数据共享；而由于通信线路的效率低下直接引发了系统的性能瓶颈问题

两个核心Idea，是应用沙盒和分层消息总线。