FaaSFlow: enable efficient workflow execution for function-as-a-service

Abstract

Serverless computing (Function-as-a-Service) provides fine-grain resource sharing by running functions (or Lambdas) in containers. Data-dependent functions are required to be invoked following a pre-defined logic, which is known as serverless workflows. However, our investigation shows that the traditional master-worker based workflow execution architecture performs poorly in serverless context. One significant overhead results from the master-side workflow schedule pattern, with which the functions are triggered in the master node and assigned to worker nodes for execution. Besides, the data movement between workers also reduces the throughput.To this end, we present a worker-side workflow schedule pattern for serverless workflow execution. Following the design, we implement FaaSFlow to enable efficient workflow execution in the serverless context. Besides, we propose an adaptive storage library FaaStore that enables fast data transfer between functions on the same node without through the database. Experiment results show that FaaSFlow effectively mitigates the workflow scheduling overhead by 74.6% on average and data transmission overhead by 95% at most. When the network bandwidth fluctuates, FaaSFlow-FaaStore reduces the throughput degradation by 23.0%, and is able to multiply the utilization of network bandwidth by 1.5𝑋 -4𝑋 .

BriskChain: Decentralized Function Composition for High-performance Serverless Computing

“…It relies on a powerful workflow engine to manage tasks and resources. Due to high scheduling overhead and frequent data movement, this pattern does not perform well in serverless environments 2 . This is because each task in a workflow is a serverless function that needs to interact with the remote master frequently.…”

“…A decentralized worker-side pattern can be utilized to improve performance. The main idea is to offload the overhead from a central master to the workers 2 . A few studies have emerged that utilized this idea in recent years.…”

“…Also, their internal data can be transmitted and preprocessed by the local gateway, without relying on a remote workflow engine. While Nightcore seems to utilize worker-side pattern, Li et al 2 argues that Nightcore is still based on a master-side pattern because its gateway serves as the centralized manager to assign tasks and allocates execution states. They proposed FaaSFlow which is closer to a worker-side design.…”

“…Specifically, the user invokes the first function of a workflow with a predefined workflow schema. NGINX forwards the requirement to the controller with the function parameters, function ID and the workflow schema ID ( 2 ). The controller uses this information to obtain the function source code and detailed workflow definition from CouchDB ( 3 ).…”

“…In addition, cloud vendors typically impose quotas on the input and output data size of each function. Users often have to make use of additional database storage services for temporary data storage and delivery 2 . Therefore, this pattern is not very suitable for applications that require intensive interactions between smaller tasks 3 .…”