lzjzx1122 / pagurus

Help Rather Than Recycle: Alleviating Cold Startup in Serverless Computing Through Inter-Function Container Sharing

Pagurus

Introduction

  Pagurus is a container management system for serverless computing. It targets on reusing idle containers to help other functions alleviate the system-level cold startups. In Pagurus, contaienrs that created by it owner function is called Executor Container. Once the executor containers are identified as idle (e.g., not serving queries for 5 minutes), Pagurus will replace it with a Zygote Container. The Zygote Container is created from an image that installs the shared packages of all the to-be-helped functions. Once the to-be-helped function would experience the cold startup, Pagurus will fork a zygote container for it and avoid the time-consuming container creation, software environment setup, and dependencies preparation. The forked container in Pagurus is called Helper container.

Getting Started

  We provide a quick setup script to deploy Pagurus in your machine. To deploy Pagurus and prepare the related software dependicies:

git clone https://github.com/lzjzx1122/Pagurus.git
./install.sh

  This shell script will install all dependencies and prepare the run-time environment. Then start Pagurus by the following command

• Run the inter_controller:

python3 inter_controller/inter_controller.py bench

, where the bench can be aws or azure.

• Run the intra_controller:

python3 intra_controller/intra_controller.py net_port max_lender_num default_zygote_time option bench 

For example, python3 intra_controller/intra_controller.py 5001 1 60 pagurus aws.

  Now Pagurus is successfully started and ready for serving function queries.

Run Aws and Azure Benchmark.

You can enter aws or azure directory to run the experiments in our paper:

python3 run_experiment.py <test_number>

This script will help you open the intra_controller and inter_controller, and send some function invocations to inter_controller. Therefore, you don't need to open intra_controller and inter_controller with this script.

Applications and Functions

  We already provide several function benchmarks in Pagurus, such as FunctionBench, FaaSProfiler, simple version of aws-example-applications, and Azure trace mapping.

  Each function should be define with a entry point with "def main(param):" . The packages needed for the function should also assigned in a requirements.txt along with the main.py or .zip file. These assigned packages and versions are maintained here in the json format like:

"cer_lambda": {
        "requests": "2.25.1",
        "xlsxwriter": "1.4.0",
        "pandas": "0.24.2",
        "numpy": "1.16.6"
    },

  Besides the functions, Pagurus also support the invocation of an application. The application contains several functions and follow a sequence or parallel logic to construt a complex business. It should be noticed that the functions and applications must be created and defined before being invoked in Pagurus.

Detailed Concepts and Related Components

  Pagurus contains three main components as shown in the figure: intra-function container manager, inter-function container scheduler, and sharing-aware function balancer. Serverless functions are running in Docker containers. The communication between them are thruogh REST APIs.

• Proxy in Docker Container
• Inter-Function Container Scheduler
• Intra-Function Container Manager
• Sharing-aware Function Balancer
• CouchDB Server

  Besides these components of Pagurrus, we also provide two additional prewarm-based policy in Pagurus: OpenWhisk-based Prewarm and SOCK-based Prewarm. You can find their prewarm manager here.

pagurus's Issues

如何与sock对比？

您好，我想问一下prewarm_manager = SockPrewarmManager(2, pm, pc) # sock style 是通过这个管理类来对比的吗？还是与https://github.com/open-lambda/open-lambda 这个实现对比的？

All actions are time.sleep functions

Is it appropriate to use time.sleep functions to mimic the behaviors of real applications? How could you justify the amount of sleeping time? How to evaluate the memory consumption and utilization? For example, any memory waste? A forked Zygote container might stay in memory for a while before the next invocation hit it.

Part of actions does not `import` the right packages

In the interaction_controller/aws_actions/ directory, there are three actions related to aws-etl-orchestrator (eo_athenarunner, eo_gluerunner, and eo_ons3objectcreated).

However, in the 'import' sections of these codes, the correct packages are not imported.

For example, in the three actions (in the Pagurus repository), they only import the time package, but in the original repository (aws-etl-orchestrator), they actually import some boto3 and botocore packages.

If a large part of the actions actually doesn't import the right package, then how can Pagurus be evaluated in a real-world scenario?