Fusionize++: Improving Serverless Application Performance Using Dynamic Task Inlining and Infrastructure Optimization

TL;DR

Fusionize is a framework that automates optimizing for this trade-off by automatically fusing application code into an optimized multi-function composition, while developers only need to write fine-grained application code following the serverless model.

Abstract

The Function-as-a-Service (FaaS) execution model increases developer productivity by removing operational concerns such as managing hardware or software runtimes. Developers, however, still need to partition their applications into FaaS functions, which is error-prone and complex: Encapsulating only the smallest logical unit of an application as a FaaS function maximizes flexibility and reusability. Yet, it also leads to invocation overheads, additional cold starts, and may increase cost due to double billing during synchronous invocations. Conversely, deploying an entire application as a single FaaS function avoids these overheads but decreases flexibility. In this paper we present Fusionize, a framework that automates optimizing for this trade-off by automatically fusing application code into an optimized multi-function composition. Developers only need to write fine-grained application code following the serverless model, while Fusionize automatically fuses different parts of the application into FaaS functions, manages their interactions, and configures the underlying infrastructure. At runtime, it monitors application performance and adapts it to minimize request-response latency and costs. Real-world use cases show that Fusionize can improve the deployment artifacts of the application, reducing both median request-response latency and cost of an example IoT application by more than 35%.

Figures (18)

• Figure 1: Fusionize takes existing, unchanged FaaS tasks and optimizes their performance and cost-efficiency by iteratively modifying their deployment configuration and inlining tasks based on monitored performance. The developer-written tasks are deployed inside multiple FaaS functions, where they can be inlined instead of called remotely.
• Figure 2: Synchronous invocations of functions can lead to double billing in the duration-based billing model of FaaS: While ${\lambda}_{1}$ calls ${\lambda}_{2}$, both functions incur costs.
• Figure 3: Cold start cascades occur when a series of function instances is executed for the first time, e.g., when load changes. The cold start overhead incurred for each execution increases the overall end-to-end latency and wait times in synchronous executions paper_bermbach_faas_coldstarts.
• Figure 4: Overview of the Architecture of Fusionize: Within a FaaS function, the fusion handler is responsible for interactions between tasks. Tasks can call other tasks, which are inlined if the task is in the same fusion group, or remotely handed off to the function responsible for another fusion group. The Optimizer regularly analyzes function logs to update the fusion setups.
• Figure 5: Example call graph that could benefit from function fusion: Task T1 and T2 need to finish before a response can be sent, and could thus be fused to reduce costs. T3 is only called asynchronously, and should thus be moved to another fusion group.