Faastlane: Accelerating Function-as-a-Service Workflows

简介

原文链接

摘要

在 FaaS 工作流中，一组函数通过相互交互和交换数据来实现应用程序逻辑。现代 FaaS 平台在单独的容器中执行工作流的每个函数。当工作流中的函数交互时，产生的延迟会减慢执行速度。

Faastlane通过努力将工作流的函数作为线程在容器实例的单一进程中执行，从而最大限度地减少了函数交互延迟，这通过简单的加载/存储指令简化了数据共享。对于操作敏感数据的FaaS工作流，Faastlane使用英特尔内存保护密钥（MPK）提供轻量级的线程级隔离域。虽然线程便于共享，但Python和Node.js等语言的实现（广泛用于FaaS应用程序）不允许线程的并发执行。Faastlane动态地识别FaaS工作流中的并行机会，分叉进程（而不是线程）或产生新的容器实例，以并发执行工作流的并行功能。

我们在Apache OpenWhisk上实现了Faastlane，并表明它将工作流实例的速度提高了15倍，与OpenWhisk相比，将函数交互延迟降低了99.95%。

1. 背景

Faas正在成为首选的基于云的编程范式，当代的Faas Application 是由一组function组成的 workflow，workflow是一个有向无环图，指定一组function处理应用程序的顺序。

FaaS 将管理计算资源的责任从开发人员转移到云提供商。对于开发人员来说，随着工作负载（即请求数量）的增加，云提供商会生成更多的工作流实例。

现代 FaaS 产品中，每个功能，即使是属于同一工作流实例的功能，都在单独的容器上执行。这种设置不适合其中工作流由多个交互功能组成的 FaaS 应用程序（例如，图像或文本处理）。一个关键的性能瓶颈是函数交互延迟

ASF 将可以跨函数传递的参数大小限制为 32KB，许多应用程序（例如，图像处理）可能需要有更大的要求。被迫通过云存储服务（例如 Amazon S3）跨工作流实例的功能传递状态
函数交互延迟可能占 ASF 和 OpenWhisk 上工作流实例执行时间的 95%（图 6）。

我们观察到，如果同一工作流实例的函数在容器内的单个进程线程上执行，则 function 可以通过对包含进程的共享虚拟地址空间进行 load/store 来相互通信。使用 load/store 可通过避免任何额外的软件开销来最小化函数交互延迟

考虑到Azure函数的最近一项研究观察到，95％的FaaS工作流程仅包含十个或更少的函数[50]，这种选择非常适合。Faastlane也保留了FaaS的自动扩展好处。响应每个触发器生成的工作流的不同实例仍在单独的容器上运行

function 的线程执行简化了FaaS工作流中的状态共享，但它引入了两个新挑战：

1. Isolated execution for sensitive data（对于敏感数据的隔离执行）

   一些FaaS用例处理敏感数据。在这种情况下，即使在工作流实例内部没有限制地共享数据，也会引起隐私问题。线程共享一个地址空间，不支持在工作流实例内部隔离执行函数。因此，Faastlane利用Intel Memory Protection Keys （MPK）实现敏感数据的轻量级线程级隔离。

   Faastlane使用MPK确保在单独的线程上执行的工作流实例中的函数对地址空间的不同部分具有不同的访问权限。同时，它通过将其放置在函数之间共享的页面中，实现了非敏感数据的高效共享。

2. Concurrent function execution（并发的function执行）

   某些工作流结构允许在一个实例内并行执行许多函数。 Python和Node.js，它们的流行运行时通过获取全局解释器锁（GIL）来阻止线程的并发执行 。即使工作流和底层硬件允许并行处理，线程执行也会防止工作流实例中函数的并发执行。

   Faastlane通过其自适应工作流编排器（adaptive workflow composer）解决了这个问题，该编排器分析工作流的结构以识别并发执行的机会，并分叉进程（在同一容器内）以执行工作流的并行部分。具体而言，当工作流结构要求函数的顺序执行时，Faastlane使用线程，当存在并行性时则使用进程。多个进程之间（同一容器）使用python多处理模块中提供给的管道共享共享状态。

   同时希望container 能够得到更多的vcpu，实现工作流可以在一个容器实例中执行，使得Faas能在单个容器中高效通信。（理解：利用多个vcpu，在一个容器内，用进程实现多个function的并行执行，避免多个容器之间的function的交互延迟，利用线程完成高效的function交互。）

   有些工作流的实例有过多的并发function，即使container中有足够多的vcpu，但可能还是不能满足工作流的使用。一个容器没有足够多的vcpu fork进程，faastlane的自适应工作流编排器可以做一个权衡：function利用冰箱的好处是否可能超过在一个容器执行所有工作流function而减少的交互延迟的好处。是的话，回退到传统的方法，启动多个容器，运行并行的function。

讨论的三个工作流程说明了FaaS工作流程中的三种设计模式：

• 并行模式（Financial industry regulation.），如FINRA中所见，其中不依赖数据的功能可以并发执行；
• 顺序模式（ML prediction service），如ML预测服务中所见，其中依赖数据的功能必须按顺序执行；
• 选择模式（Healthcare analytics），如Healthcare Analytics中所见，其中工作流程中的功能根据用户输入或工作流程中功能的输出有条件地执行。

相同点：

• 有对敏感数据的处理要求
• 工作流要在function之间通信大量的状态

2. 设计目标

• 最小化function交互延迟，不牺牲并行性工作流的并发现
  尽可能的在function之间共享状态（将function尽量映射到共享地址空间的线程上）（一个进程执行一个线程，一个线程执行一个function？）
  load/store ————>共享地址空间，是共享数据的最低的延迟操作。

  Faastlane中自适应工作流编排器（adaptive workflow composer）（静态工具，分析工作流中的function结构，）遇见并发的function，fork出进程（而不是线程，虽说线程一般是并发功能的载体）

  超过单个容器的vcpu的规模时（并行性太大），adaptive workflow composer做一个权衡：所有的function在一个容器中 or 传统的方法（启动多个容器）

  adaptive workflow composer会定时分析容器的并行度，只要遇到了大量的并行性，多个容器中部署工作流的方式是否更有利。

• function当线程运行时，Faastlane控制工作流中的数据共享。
  某些重要工作流的敏感数据必须收到保护，即使是同一个工作流中的function。

  Faastlane使用MPK为共享虚拟地址空间的Faas函数提供线程粒度的内存隔离。

• 不同Faas开发者向Faas平台提供更多的信息。对用户和提供商透明。

3 实现

Faastlane的主要任务：

1. 产生线程、进程、容器来执行function，在不牺牲并行性的情况下减少交互延迟。
2. 线程执行function时，保护function之间的敏感状态（数据）的隔离

3.1 最小化的 function 交互延迟

Faastlane的 workflow composer 为在Faastlane的运行时中执行而定制JSON工作流描述和函数代码。workflow composer 首先分析工作流结构（JSON描述）以确定它是否允许在实例的函数执行中并发。如果工作流是顺序的，workflow composer 将工作流的所有函数打包到一个名为 Orchestrator 的统一函数中。对于FaaS平台上的调度程序，统一工作流提供了单个函数应用程序的假象。

Orchestrator 函数指定调用线程的顺序，从而执行工作流的数据共享策略。作为线程执行的工作流实例的函数，通过使用向共享进程堆进行加载/存储以共享数据，最小化了函数交互延迟。

workflow composer创建一个Function wrappers（如图3中的PStateWrapper），标识可以并发执行的工作流的部分，Function wrappers具有关联的内置 start() 方法，在Faastlane的运行时中实现。调用 start() 方法会生成一个新的进程来执行相应的函数。

对vcpu数量 的计算;
容器可能没有足够的虚拟CPU来并行运行工作流中所有函数的部分,FaaS平台提供商甚至可能不会公开容器中部署工作流实例的虚拟CPU数量。因此，Faastlane在FaaS平台上部署一个简单的计算密集型微基准测试，并观察其可扩展性，以推断平台部署的容器中的虚拟CPU数量。这种分析通常只需要很少（例如，每天一次）

不提供MPK（或类似MPK）的硬件：
检查/ proc / cpuinfo /中的pku和ospke标志，以确定FaaS平台是否支持MPK。如果没有，则工作流组合器仅使用进程来执行函数。这种回退选项牺牲了线程提供的降低函数交互延迟。

3.2 Isolation for Sensitive Data

当函数在不同的进程中执行时，数据隔离不是一个问题。每个进程都有自己的独立地址空间，工作流中使用线程以实现有效的状态共享与保护敏感数据的目标存在根本冲突，Faastlane利用现有的硬件功能(MPK)来强制实施线程级别的数据隔离

目标：Faastlane 保证每个线程都有一个私有的/隔离的地址空间，还有一个共享分区来load/store 瞬态

MPK：为进程地址空间的每个页面提供硬件支持（4bit密钥————>16组页面），使用PKRU寄存器位每组页面指定访问权限。PKRU寄存器指定当前的线程对每组页面的访问权限。

使用MPK：

• 进程启动时，所有的page 都有默认密钥，PKRU允许所有的页面进行读写访问。
• 进程使用系统调用为page分配保护密钥。
• 使用WRPKRU指令指定有该保护密钥的页面的访问权限。（WRPKRU是一个用户态指令，必须保证WRPKRU在一个可信的代码——thread gate 中使用

thread gate分为entry gate 和 exit gate

• entry gate ：将保护密钥附加到线程上； 将保护密钥传给内存管理器； entry gate 使用WPRKRU指令写入PKRU寄存器。
• exit gate： 释放保护密钥； 将存放保护密钥的地址空间清空（可能是为了下次的再分配）

3.3整合(总结)

图4总结了Faastlane中FaaS工作流程的生命周期

生命周期始于应用程序开发人员提供函数和连接它们的工作流描述。客户端将这些实体提供给Faastlane的workflow composer。workflow composer分析工作流并生成统一描述，捕捉工作流中可用的并行性。根据可用的并行性（如果有）和容器中的vCPU数量（通过分析确定），工作流在FaaS平台上部署.

Faastlane的工作流程在没有或有限并行性的情况下，提供一个单一的顶层函数，称为Orchestrator，封装整个工作流描述。客户端将这个统一的工作流描述提供给FaaS平台，给平台以单一函数FaaS工作流的假象。平台在单个容器中安排整个FaaS应用程序的执行。如果工作流的并行性超过了容器中估计的vCPU数量，则composer会创建多个Orchestrator函数。每个Orchestrator都包含一个子工作流，其中的函数可以在单个容器中并发运行。FaaS平台通过在不同的容器中调度每个Orchestrator来处理这些函数。
在容器内部，Faastlane的运行时组件接受统一的工作流描述，并对其进行分解以确定工作流中的函数。根据Orchestrator，它启动线程（每个函数一个）或派生进程来执行工作流函数。当函数作为线程执行时，每个线程执行指令以识别进程堆的一个分区，该分区仅对该线程可访问（使用MPK原语）。它使用此分区来存储仅对函数私有的数据。运行在线程上的函数可以通过对指定共享堆的加载/存储来共享状态。当线程完成时，函数的输出仅对消费该输出的工作流中的函数可用（通过Orchestrator方法）。

当Faastlane派生进程时，它仅通过Python管道将父进程的最后一个方法的输出传递到子进程的Orchestrator方法中。对于大型并行工作流，不同容器中的函数通过网络堆栈进行通信，与当代FaaS平台一样

4. 评估

我们衡量Faastlane如何提高函数交互延迟、端到端延迟、吞吐量，并减少美元成本,这些Faastlane可以将一个工作流实例的所有函数打包到单个容器中。

在第5.4节中，我们还展示了在工作流结构中存在大量并行性时Faastlane如何扩展使用多个容器

4.1 Function Interaction Latency

图5展示了四个应用在不同FaaS平台下的函数交互延迟

Faastlane在所有四个应用程序中，每个应用程序具有不同的函数交互模式下，函数交互延迟最低。对于FINRA、ML预测服务、医疗保健分析和情感分析，Faastlane分别将延迟降低了52.3％、95.1％、95％和98％，从而优于其最接近的竞争对手。

4.2 End-to-End Application Performance

一个应用程序的工作流端到端执行延迟是从工作流的第一个函数开始执行到最后一个函数完成之间的时间。我们将端到端延迟分解如下：

• 外部服务请求的耗时
• 计算时间
• FaaS平台上的函数交互延迟

图6展示了端到端延迟分解为以上三个组件。对于每个应用程序，我们报告ASF、OpenWhisk、SAND和Faastlane上的中位数和99%分位数延迟

总体而言，我们发现Faastlane将端到端延迟提高了40.5%，分别比OpenWhisk和SAND提高了23.7%。

4.3 Throughput

图7显示了在不同FaaS平台上测量的应用吞吐量，以每分钟服务的应用请求数量表示。我们使用第一个请求被调用和收到最后一个请求响应的时间来测量吞吐量.

Faastlane为所有应用提供最佳吞吐量。对于FINRA应用程序，Faastlane比其最近的竞争对手（SAND）提高了28.6%的吞吐量。对于ML预测服务和情感分析，Faastlane分别提高了15.6％和49.7％的吞吐量，分别比SAND高出16倍和2.4倍。对于医疗保健分析应用程序，Faastlane相对于SAND提供了6％的适度吞吐量改进。

4.4 Scalability with Multiple Containers

到目前为止，所有实验都限于一个服务器，底层容器有足够多的vCPU来同时运行像FINRA这样的应用程序中的所有并行函数。现在，我们将探讨如果底层容器的vCPU数量有限，并且需要部署多个服务器来满足单个工作流实例中的并行性，Faastlane将如何扩展。为此，我们将FINRA工作流中并行步骤中的函数数量从50个增加到200个。我们还将每个容器中的vCPU数量从4个变化到50个。

y轴报告了工作流实例的平均执行时间，作为并行函数的数量增加（x轴）

当生成多个容器时，Faastlane会回退到基于网络的容器之间的通信。随着每个容器的vCPU数量增加，Faastlane启动的容器数量减少，表现更好。

化到50个。

[外链图片转存中…(img-zH3mSpEI-1685449475344)]
y轴报告了工作流实例的平均执行时间，作为并行函数的数量增加（x轴）

当生成多个容器时，Faastlane会回退到基于网络的容器之间的通信。随着每个容器的vCPU数量增加，Faastlane启动的容器数量减少，表现更好。

简而言之，Faastlane在能够利用容器内快速通信的情况下最有效，尤其是对于顺序工作流和具有有限并行性的工作流。然而，即使面临大量工作流的并行性，以及底层容器的有限并行性，Faastlane的扩展能力至少与当前的服务一样好。