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

SAND:A high-performance serverless computing platform

这是一篇来自ATC18的文章。这篇文章主要，介绍了一种高性能无服务器计算平台。有关Serverless的文章之前就有同学进行过介绍。

这是Serverless Computing最简单的一个计算模型。我们看到开发者和平台进行了分工合作。开发者只需要定义触发事件，同时上传函数代码。同时，Serverless 平台将负责计算资源的分配，响应用户的请求，完成用户函数的计算，将计算完成之后的结果返回给用户。

这样的计算模式带来了几条好处。首先，由于用户不用管理后端的服务器，不用管理程序的依赖，不用管理操作系统等等。可以享受云平台提供的连续可扩展性的计算服务。此外，由于用户可以专注于代码逻辑，而不是运维，所以能提升生产效率。开发者可以更快地让自己的产品上线。因此，从开发者的角度来看，Serverless Computing是很好的。

 作为开发者，开发应用，就会利用这个Serverless平台，建立很多的应用的计算函数。这里以图像处理应用为例，开发者创建了四个函数，第一个是提取图片的元数据信息，第二个是信息处理，第三个是物体识别，第四个是resize图片大小。函数之间信息传递。形成一个workflow。

这里作者，将这个图像处理的应用，部署在了现有的三大Serverless平台上。通过对比总运行时间，以及任务计算时间，我们不难发现，真正处理计算任务的时间，占比总运行时间的大小，只有一半左右。这就说明，由于Serverless带来中间传递信息，以及函数启动时间等等开销，也就是平台带来的开销时间比较大。这样的结果，不利于应用进行频繁调用计算。会拖累应用的性能表现。

 这里，作者提出了SAND，一个高性能无服务计算平台。主要实现的目标是，达到减少应用延迟的效果，同时高效利用资源。

这里先介绍一下背景，主要是现有的一些平台的情况，以及一些普遍的做法。

  现有的一些平台，通常是使用容器来进行函数的运算和隔离；容器被安排在具有可用资源的宿主机上；容器处理完成任务之后，经过了一段时间之后，就会回收资源；容器与容器之间是通过一个消息总线来进行通讯。消息总线，可以是分布式的消息传递，或者是通过存储服务来实现消息传递。

这些是我们发现的常见做法。其中大多数功能，大多数服务都利用容器来隔离功能，这对功能执行以及这些系统实际处理并发性有一些影响。每当有新请求时，必须从头开始初始化容器，都可以从头开始创建新容器，这被称为冷启动。这不可避免地会导致较长的启动延迟。 当然这样不是最好的做法，我们可以实现热启动，启动了容器之后，继续运行它。这样我们就可以重复利用那些空闲的容器。这是热启动的做法。只要收到请求，我们可以将它们导向已经启动好的容器上运行。

但是，这种方式，不适合处理并发的请求。因为如果我为每一个并发的请求，都实现容器的热启动，那么我们提前保留的资源就会很多，这样不能达到资源的充分利用。如果不能保留热启动的容器，则会带来很长的应用响应延迟。这两点都是我们不希望看到的。

此外，我还发现，Function与Function之间的消息传递，以及数据交换，是通过相同的一个message bus的。总线效率的地下，也导致了系统性能表现的不佳。

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