【2021 USENIX ATC CCF A】Faastlane: Accelerating function-as-a-service workflows

[penghuima]

文章及ppt获取地址 https://www.usenix.org/conference/atc21/presentation/kotni

[penghuima]

前言描述

在 FAAS 工作流中，一组函数通过交互及数据交换实现应用程序的逻辑。但由于 FAAS 本身的无状态特性，需要为函数之间的状态通信付出昂贵的时间延迟（一般做法是一个函数的状态存入第三方云存储产品，然后另一个函数再访问云存储产品获取上一个函数的状态），且当前各FAAS平台的处理方式是将一个工作流实例中每一个函数分别部署在独立的容器中。这种部署方式带来的后果就是需要忍受函数间跨容器复制瞬时函数状态的交互延迟。而且有的平台会限制函数间直接管道通信的状态大小（比如几十K),像机器学习这类数据密集型应用（处理的图像集大小上几十M级别），就不得不通过云存储服务（如 Amzzon S3）实现函数间的状态传递。

[penghuima]

论文主要贡献

在这篇论文中，Faastlane 努力做到在一个容器内的单个进程内以线程的形式执行工作流。通过共享进程内存地址空间来最大限度地减少了函数间地状态传输延迟。即通过最简单的 load/store 指令来实现数据共享。

但这种做法会带来新的挑战 ：

• ​如何实现线程级别的隔离，来保护敏感数据
• 函数的并行执行又如何实现

应对挑战的解决办法：

• 众所周知，进程级别的隔离已经有前人做了大量研究，在本文中作者通过应用 Intel Memory Protection Keys(MPK) 硬件技术实现了线程级隔离。
• 在工作流中，有一种结构是允许并行执行实例中的多个函数，然而一些FAAS应用程序是由一些解释型语言如 Nodejs 、Python等编写的，这类语言存在全局解释器锁（global interpreter lock (GIL)），从而阻碍函数的并发执行。因此 Faastlane 当检测工作流存在并发执行的机会，就会在同一容器内 fork process 来实现函数的并发执行。这时候函数间通过管道来共享状态（如Python语言提供的管道通信，管道内部使用共享内存通信）

毫无疑问，将一个工作流中函数组尽可能地运行在一个容器内部，这显然容器需要更多地资源，比如（vcpu），但是当一个容器内部的vcpu资源不够时，工作流的端到端执行时间可能会加长（函数间交互延迟时间的缩短可能不及函数并发执行带来的作用大），因此 Faastlane 还需要检测当容器 vcpu资源不够的时候，需要多起几个容器，在每一个容器内以最大化利用资源的方式起线程跑函数。此时跨容器的函数间状态传递就需要通过网络了，就像当代FASS平台目前所作的这样