paint-brush
How DeFaaS Uses Randomized Load Balancing for Decentralized API Callsby@blockchainize

How DeFaaS Uses Randomized Load Balancing for Decentralized API Calls

by Blockchainize Any TechnologyJanuary 29th, 2025
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

DeFaaS implements decentralized scheduling and randomized load balancing for API calls, using public blockchain-based randomization for verification and providing trust management for gateway nodes. The system incentivizes gateway providers while ensuring load distribution across multiple cloud providers.
featured image - How DeFaaS Uses Randomized Load Balancing for Decentralized API Calls
Blockchainize Any Technology HackerNoon profile picture
0-item

Abstract and 1 Introduction

2 Background and Motivation

2.1 Decentralized Computing Infrastructure and Cloud

2.2 Advantages of DeFaaS

2.3 System Requirements

3 Overview of DeFaaS

4 Detailed Design of DeFaaS and 4.1 Decentralized Scheduling and Load Balancing

4.2 Decentralized Event Distribution

4.3 API Registration and Access Control

4.4 OAuth2.0 Support

4.5 Logging and Billing and 4.6 Trust Management

4.7 Supporting Multi-Cloud Service Mesh

5 Implementation and Evaluation

5.1 Implementations

5.2 Experiments

5.3 Evaluation

6 Related Work

7 Conclusions and References

4 Detailed Design of DeFaaS

In this section, we describe the details of the main components of the system.

4.1 Decentralized Scheduling and Load Balancing

Different from the conventional multi-cloud deployment of FaaS, DeFaaS avoids any centralized component as a front-end for scheduling API calls. A user can make API calls to any API gateway. The management blockchain can keep track of the reputation and support trust management of the gateway nodes. Each API gateway needs to be registered with the management blockchain. The system can require a minimal stake to be deposited for the gateway providers. To avoid fragmentation, the system can enforce certain policies like enforcing maximal number of gateways for each cloud, minimal setting of a gateway like types of instances, memory size and the number of vCPUs.


To dispatch the API calls across cloud data centers, the system applies randomized load balancing (e.g., [Mitzenmacher(2001a)]) to avoid scenarios that all the API calls are sent to a single cloud provider. In randomized load balancing, when a gateway receives an API call, depending on the policy setting for the dApp or Web3 application, the gateway randomly routes the call to one of the available cloud service providers. For instance, the popular power of two heuristic [Mitzenmacher(2001b)] can achieve good performance with very low overhead.


A unique characteristic of our design different from all the prior work in randomized load balancing is that scheduling outcome must be publicly verifiable. This is a fundamental difference between distributed system vs. decentralized system. To support public verification, randomization by the gateway nodes must use a random source that can be verified publicly. A simple approach is to use an on-chain random source like block hash. Using block hash like Bitcoin block hash as publicly verifiable random source is a common practice [Bonneau et al.(2015)]. In this work, gateway node applies block hash from a reference chain like Bitcoin or the management blockchain as the random source for randomized load balancing.


Gateway providers are compensated based on the number of successfully handled API calls. To provide incentives for the gateway providers, payments to the gateways are weighted. This means that if the number of API calls handled by a gateway is skewed from the prediction based on the randomized load balancing and target distribution, its received payment will be reduced. As an example, for a dApp, the system may require all the calls be evenly distributed among three cloud providers. Gateway nodes that cheat the system can be punished, for instance receiving negative payment for the handled API calls that exceed a limit. Scheduling policies are recorded on the management blockchain. Depending on the utility of the use cases, scheduling policies can be configured to achieve proper trade-offs among requirements such as decentralization, cost, performance. For instance, policies prioritizing decentralization may reward distribution of the API calls to multiple clouds.


To provide scheduling assistance, the system employs Oracle providers who send gateway load data feed to the management blockchain. The Oracle providers estimate gateway load by sending testing API calls and measure performance metrics like the completion time. It is important to mention that the API gateways only query the management blockchain periodically to read other gateways’ load status. The gateway load status is cached locally and used for randomized load balancing. There is no on-chain update for viewing gateway load status.


Authors:

(1) Rabimba Karanjai, Department of Computer Science, University of Houston (rkaranjai@uh.edu);

(2) Lei Xu, Department of Computer Science, Kent State University;

(3) Lin Chen, Department of Computer Science, Texas Texh University;

(4) Nour Diallo, Department of Computer Science, University Of Houston;

(5) Weidong Shi, Department of Computer Science, University Of Houston.


This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license.