Improving Robustness of Heterogeneous Serverless Computing Systems Via Probabilistic Task Pruning

TL;DR

This paper introduces a probabilistic task pruning method to enhance the robustness of heterogeneous serverless computing systems, significantly improving their ability to meet QoS deadlines under uncertainty and oversubscription.

Contribution

It proposes a novel task pruning mechanism that can be integrated into existing heuristics to improve system robustness without redesigning the entire scheduling approach.

Findings

Up to 35% improvement in system robustness.

Effective in both heterogeneous and homogeneous systems.

Enhances QoS by reducing deadline misses.

Abstract

Cloud-based serverless computing is an increasingly popular computing paradigm. In this paradigm, different services have diverse computing requirements that justify deploying an inconsistently Heterogeneous Computing (HC) system to efficiently process them. In an inconsistently HC system, each task needed for a given service, potentially exhibits different execution times on each type of machine. An ideal resource allocation system must be aware of such uncertainties in execution times and be robust against them, so that Quality of Service (QoS) requirements of users are met. This research aims to maximize the robustness of an HC system utilized to offer a serverless computing system, particularly when the system is oversubscribed. Our strategy to maximize robustness is to develop a task pruning mechanism that can be added to existing task-mapping heuristics without altering them. Pruning tasks with a low probability of meeting their deadlines improves the likelihood of other tasks meeting their deadlines, thereby increasing system robustness and overall QoS. To evaluate the impact of the pruning mechanism, we examine it on various configurations of heterogeneous and homogeneous computing systems. Evaluation results indicate a considerable improvement (up to 35%) in the system robustness.

Figures

Equations

$$PCT(i,j)=PMF(i,j)\ast PCT(i-1,j)$$

$$S(i,j)=\mathbb{P}(PCT(i,j)\le {\delta }_i)$$

$$U_{ij}=\frac{1}{{\delta }_i-\mathbf{E}[C(t_{ij})]}$$

$$\text{vspace}-3px{\delta }_i=ar{r}_i+av{g}_i+(\beta \cdot av{g}_{all})$$

Full text

I Introduction

The cloud-based serverless computing paradigm abstracts away the details of resource provisioning and deployment [1]. A user only needs to define the required services (aka functions or tasks) and their QoS expectations within the serverless platform. The user is only charged for the actual resource usage and not for the idle times or under-utilized provisioned resources [2]. Because of its ease-of-use and cost-efficiency, serverless platforms have gained popularity over the past few years, specifically for micro-service deployments [1, 3].

As a general computing system, on the back-end, the serverless platform receives service requests from multiple users. Each service request implies executing one or more tasks that potentially have diverse computing and memory demands. This diversity justifies the use of Heterogeneous Computing (HC) systems to improve both QoS satisfaction and incurred cost [1, 4]. Heterogeneity of an HC systems can be divided into qualitative and quantitative differences. Differences in architecture can be described as qualitative (*e.g., *GPU-based versus CPU-based architecture) whereas differences in performance within a given architecture can be described as quantitative (*e.g., *one computer has a faster CPU speed than the other). A system with both qualitative and quantitative differences between machines is described as inconsistently heterogeneous while a system with only quantitative difference is described as consistently heterogeneous [5, 6, 7, 8].

Arriving service requests (also, termed tasks) can also be qualitatively and quantitatively heterogeneous. A qualitative heterogeneity refers to different types of tasks in the workload (*e.g., *compressing a video segment versus changing its spatial resolution [8]) whereas quantitative heterogeneity can refer to characteristics such as variety in data size within a certain task type (*e.g., *compressing video segments with different lengths). Qualitative heterogeneity among tasks leads to differences in execution times on different machine types in an HC system [9], known as task-machine affinity [8]. For instance, embarrassingly parallel tasks (*e.g., *image filtering) perform faster on (*i.e., *have higher affinity with) GPU-based machines whereas data-intensive tasks with many branching paths have higher affinity on CPU-based machines with large memory [9]. Quantitative heterogeneity within a given task type causes variation (uncertainty) in the execution time of tasks of that type for each machine type within the HC system. In an inconsistently heterogeneous system, making optimal mapping of arriving tasks on HC systems is desirable, but not practically feasible [10, 11] owing to the high level of uncertainty and a large decision space.

In this study, we consider the case where each arriving task has an individual hard deadline that has to be met to fulfill the task’s QoS requirement. That is, there is no value in executing a task after its deadline, therefore, a task that is past its deadline must be dropped from the system [12, 13, 14]. As an example, live video streaming tasks that miss their presentation times (*i.e., *deadlines) must be dropped [15] to catch up with the current live video contents. As tasks’ deadline violations often occur when the system is heavily loaded, we particularly study circumstances in which the HC system is oversubscribed. That is, the intensity of arriving workload is such that it is impossible to finish all the tasks by their deadlines [16].

Robustness of a system is defined as its ability to maintain a given level of performance in the face of uncertainty [16]. The main goal in this study is to maximize the robustness of an inconsistently HC system used for processing tasks of a serverless computing platform. The performance metric to measure robustness of the HC system is based on the number of tasks completing before their deadlines. To achieve the robustness, we harness two sources of uncertainty that exist in HC systems, namely uncertainty in tasks’ execution times and uncertainty in tasks’ arrival rate [17, 18].

To attain the robustness goal, our hypothesis is that the resource allocation of an HC system should not map tasks that are unlikely to complete on time (*i.e., *before its individual deadline). In fact, such mappings just increase the incurred cost [19] without improving the robustness of HC system. More importantly, executing unlikely-to-succeed tasks postpones the execution of other pending tasks, that subsequently miss their deadlines. Therefore, our strategy is to avoid executing unlikely-to-succeed tasks. The existing resource allocation systems of an HC system in a serverless computing platform operate either in the immediate- or batch- modes. In the former, as shown in Figure 1LABEL:sub@fig:ImmSchedule, the mapper makes mapping decision immediately upon task arrival. In the latter, as shown in Figure 1LABEL:sub@fig:BatchSchedule, arriving tasks are batched in a queue awaiting mapping to a machine at a later mapping event. Although both of these approaches are being utilized, prior studies suggest that batch-mode mapping yields to a higher overall robustness [16, 8, 20].

We design a pruning mechanism that is plugged into the resource allocation system (as shown in Figure 1LABEL:sub@fig:BatchSchedulePrune) and improves the robustness of the HC system. The mechanism receives tasks’ meta-data from the mapper and prune unlikely-to-succeed tasks. The pruned tasks are either deferred to a later mapping event or dropped to alleviate the oversubscription of the HC system.

Assume that there are a few pending tasks in a machine queue awaiting execution ahead of an arriving task. Each one of the pending tasks has uncertainty in its execution time; collectively, they introduce compound uncertainty for the arriving task’s execution time. We need to calculate the impact of this compound uncertainty on the likelihood of success for an arriving task. Then, the pruning mechanism should determine if the arriving task is worth assigning to the machine. In an HC system, for an arriving task that has a low chance of success (*i.e., *chance of meeting its deadline), deferring its assignment to the next mapping event can potentially increase its chance of success. This is because such deferment provides the opportunity for the arriving task to be assigned to a machine with a higher affinity that may become available in a later mapping event. Furthermore, when the system is heavily loaded (*i.e., *oversubscribed), it is possible to take an even more aggressive approach and drop (*i.e., *discard) pending tasks with low chance of success to increase the likelihood that other pending tasks succeed.

We note that, making task mapping decisions only based on chance of success can potentially impact fairness of the system. In this case, the pruner consistently favors tasks with short execution time, while pruning other longer tasks. To avoid this problem, we equip the pruning mechanism with a method to achieve fairness across various types of tasks exist in an HC system. The advantage of our proposed pruning mechanism is that it does not require making any change in the existing resource allocation and mapping heuristic of the systems. Instead, the pruning mechanism is plugged into the existing mapping heuristic that best suites to the system and improves its robustness.

To evaluate the proposed pruning mechanism, we plug it into various widely-used mapping heuristics [21, 22] that are used in batch- and immediate-mode resource allocation systems. In addition to HC systems, we study the impact of applying pruning mechanism on mapping heuristics of resource allocations in homogeneous computing systems.

In summary, the contributions of this paper are as follows:

• •

Proposing a probabilistic task pruning mechanism within resource allocation system to enable robust heterogeneous serverless computing.

• •

Extending pruning mechanism to enable fairness across various task types in the system.

• •

Plugging the pruning mechanism into popular mapping heuristics used in resource allocation systems.

• •

Analyzing the impact of task pruning mechanisms on the robustness of various types of computing systems and under varying workload characteristics.

Extensive simulation results on various workloads demonstrate that our proposed mechanism increases robustness remarkably (by up to 35 percentage point). More importantly, the impact of this pruning mechanism is more substantial in HC systems that are highly overloaded.

The rest of this paper is organized as follows. Section II establishes the problem statement and provides mathematical background required in this study. Then, Section III introduces commonly used mapping heuristics. Next, Section IV details task pruning mechanism and Section V describes and analyzes evaluation results. In Section VI, we highlight some prior works related to this study. Finally, Section VII concludes the paper and offers direction for potential future works.

II System Model

This research is motivated by a serverless computing platform with heterogeneous machines, such as those used in edge computing [23]. Another motivation is a cloud-based serverless platform where the service provider has budget constraints [19, 24]. In these scenarios, the service provider aims to maximize the number of service requests meeting their deadline constraint within their limited resources. Users issue independent service requests (termed tasks) from a set of offered service types (termed task-types). A task in our study is modeled as an independent video segment in the form of Group Of Pictures (GOPs) that is sequentially processed (*e.g., *transcoded [17]) within a deadline constraint. Each task has an individual hard deadline, which is the presentation time of that video segment [25, 15]. As there is no value in executing a task that has missed its deadline, the task must be dropped from the system.

In the described scenario, both inconsistent task heterogeneity, in form of different task-types (*e.g., *transcoding types), and inconsistent machine heterogeneity, in form of different machine types, can be present. In serverless computing, mapping tasks to machines is hidden from the user and is carried out using mapping methods of the resource allocation system.

In our system model, tasks dynamically arrive into the resource allocation system. Their arrival rate and pattern is unknown in advance. In particular, we are interested to study robustness of the system when there is a surge in demand. We define oversubscription as a situation in which task arrival is so intense that it is impossible to complete all tasks within their deadlines.

Due to variations in tasks’ data sizes, the execution time of each task type on each machine type is stochastic [9]. For instance, the execution time to change the resolution depends on the size of the GOP to be processed [17]. The stochastic execution time of each task type on each machine type is modeled as a Probability Mass Function (PMF) [16]. In an inconsistently HC system, a Probabilistic Execution Time (PET) matrix is used to represent execution time distribution of each task type on each machine type [9]. For an arriving task, based on the PET matrix, we can calculate its Probabilistic Completion Time (PCT) distribution on a given machine. As shown in Equation 1, the PCT of arriving task $i$ on machine $j$, denoted $PCT(i,j)$, is calculated by convolving PET of task $i$ on machine $j$, denoted $PMF(i,j)$, with PCT of the last task already mapped to machine $j$, denoted $PCT(i-1,j)$.

[TABLE]

Figure 2 shows an example for calculating PCT of arriving task $i$ on a given machine $j$ based on its PET on this machine convolved with PCT of the last task already assigned to machine queue $j$. Once we calculate PCT for arriving task $i$ on machine $j$, we can obtain its chance of success (denoted as $S(i,j)$), which is defined as the probability that task $i$ completes before its deadline. Equation 2 formally represents the chance of success for task $i$ with deadline $\delta_{i}$ on a given machine $j$.

[TABLE]

Since PCT of task $i$ relies on the PCT of tasks ahead of it in the machine queue, as the queue length grows, the compound uncertainty in task’s completion time grows too. Conversely, when the queue length is shortened because of task dropping, the PET of the dropped task is no longer used in the convolution process to calculate PCT of tasks behind the dropped one. Hence, their PCT is changed (as explained in [16, 26]) in a way that their compound uncertainty is reduced and the chance of success for the affected tasks is increased.

Our proposed pruning mechanism operates in coordination with a mapping method at each mapping event and decides to either drop or defer tasks with a low chance of success. A mapping event occurs when a task completes its execution or when a new task arrives into the system. Before any mapping decision is confirmed, the system drops any task that has missed its deadline. Due to the overhead of data transfer, we assume that a task cannot be remapped once it is mapped to a machine. After mapping, tasks assigned to a machine queue are processed in a First Come First Serve manner. Each task is executed in isolation on the machine without preemption or multitasking [27, 28].

III Mapping Heuristics

III-A Overview

Although this study concentrates on the performance of pruning in HC systems, to conduct a comprehensive analysis, in addition to HC systems, we study the performance of pruning both on homogeneous systems as well. In both types of systems, optimal task-machine mapping is proven to be an NP-complete problem [10, 11]. Therefore, a large body of mapping heuristics (*e.g., * [7, 11, 21]) have been developed for these systems. Figure 3 provides an overview of mapping heuristics commonly used in heterogeneous and homogeneous systems. In particular, mapping heuristics of HC systems can be further categorized based on those operate in immediate-mode and in batch-mode resource allocation systems.

Immediate-mode mapping heuristics do not hold tasks in an arrival queue and they are simpler to develop. In batch-mode heuristics, however, mapping occurs both upon task arrival (when machine queues are not full) and upon task completion. Batch-mode heuristics generally use an auxiliary structure, known as virtual queue, where arriving tasks are examined on different machine queues. These heuristics commonly use a two-phase process for decision making. In the first phase, the heuristic finds the best machine for each task, by virtue of a per-heuristic objective. In the second phase, from task-machine pairs obtained in the first phase, the heuristic attempts to choose the best machine-task pairs for each available machine queue slot. After all slots are filled, or when the unmapped queue is emptied, the virtual mappings are pushed (assigned) to the machine queues, and the mapping method is complete.

Although mapping heuristics used in homogeneous computing systems are of batch nature, their logic is simpler than those used in batch-mode of HC systems. In the rest of this section, we review widely-used heuristics in both heterogeneous and homogeneous computing systems.

III-B Immediate-Mode Mapping Heuristics for Heterogeneous Systems

III-B0a Round Robin (RR)

In RR [29], incoming tasks are assigned in a round robin manner to an available machine, from Machine 0 to Machine $n$.

III-B0b Minimum Expected Execution Time (MET)

In MET, the incoming task $i$ is assigned to the machine that offers the minimum expected execution time (*i.e., *the average of the $PET(i,j)$ for task $i$ on machine $j$).

III-B0c Minimum Expected Completion Time (MCT)

In MCT, the incoming task is assigned to the machine that offers the minimum expected completion time. The completion time is obtained based on the accumulated expected execution time of tasks queued in a given machine.

III-B0d K-Percent Best (KPB)

KPB is a combination of MCT and MET. It only considers MCT amongst the $K$ percent of machines with the lowest expected execution times for an incoming task.

III-C Batch-Mode Mapping Heuristics for Heterogeneous Systems

III-C0a MinCompletion-MinCompletion (MM)

MM is a popular mapping heuristic widely-used in the literature [30, 31, 22, 16]. The PET matrix is used to calculate expected completion times. In the first phase of this two-phase heuristic, the virtual queue is traversed, and for each task in that queue, the machine with the minimum expected completion time is found, and a pair is made. In the second phase, for each machine with a slot in its machine queue, the provisional mapping pairs are examined to find the machine-task pair with the minimum completion time, and the assignment is made to the virtual machine queues. The process repeats itself until all virtual machine queues are full, or until the unmapped queue is exhausted.

III-C0b MinCompletion-Soonest Deadline (MSD)

MSD is a two-phase process, first selecting the machine which provides the minimum expected completion time (using the PET matrix) for each task under consideration. In second phase, from this list of possible machine-task pairs, the tasks for each machine with the soonest deadline are chosen, and in the event of a tie, the task with the minimum expected completion time breaks the tie. As with MM, the process is repeated until either the virtual machine queues are full, or the unmapped task queue is empty.

III-C0c MinCompletion-MaxUrgency (MMU)

MMU is a two-phase process. The first phase is identical to MM and MSD. The second phase select task based on their urgency. Urgency for task $i$ on machine $j$ is defined as the inverse of the difference between the task deadline ($\delta_{i}$) and the expected completion time of the task on machine $j$ ($\mathbf{E}[C(t_{ij})]$). Equation 3 formally shows the urgency definition.

[TABLE]

As with MM and MSD, this process is repeated until either the temporary batch queue is empty, or until the virtual machine queues are full.

III-D Mapping Heuristics for Homogeneous Systems

III-D0a First Come First Served - Round Robin (FCFS-RR)

In FCFS-RR, a task is selected in first come first serve manner and is assigned to the first available machine in a round robin manner, from Machine 0 to Machine $n$.

III-D0b Earliest Deadline First (EDF)

EDF is functionally similar to MSD heuristic for HC systems. The first phase finds the machine with the least expected completion time. Then, the second phase sorts the arrival queue in an ascending order based on tasks’ deadlines. Next, the task in the head of the arrival queue is assigned to the machine with minimum expected completion time. This process is repeated until all task are mapped or the machine queues are full.

III-D0c Shortest Job First (SJF)

SJF is functionally similar to MM heuristic for HC systems. The first phase finds the machine with the least expected completion time. Then, the second phase sorts the arrival queue in an ascending order based on tasks’ expected execution time. Next, the task in the head of the arrival queue is assigned to the machine with minimum expected completion time. This process is repeated until all task are mapped or the machine queues are full.

IV Pruning Mechanism

IV-A Overview

In this section, the probabilistic task pruning mechanism (also termed Pruner) is described. Figure 4 shows a pruning mechanism that can be plugged into any resource allocation system and work in conjunction with any mapping heuristic to increase the robustness of the HC system. The Accounting module is in charge of gathering tasks’ information (*i.e., *meta-data) from the resource allocation system. The Toggle module measures the oversubscription level of the HC system based on the collected information and decides whether the task dropping has to be engaged. Aiming at maximizing robustness, the Pruner module, first, calculates the chance of success for all tasks, then, enacts the pruning decision on tasks whose chance is lower than a user-defined threshold, specified in Pruning Configuration. The Fairness module keeps track of the suffered task types (*i.e., *those that are consistently dropped) and adjust the Pruner to avoid biasness against them.

In the rest of this section, we first elaborate on each of these modules and their interactions. Then, we explain the overall pruning procedure.

IV-B Task Deferring

Within a mapping event, task deferring is defined as the act of postponing assigning a task, whose chance of success is low, to a machine. In an HC system, such deferment can be beneficial both to the deferred task and to the overall system robustness. For the deferred task, it is possible that its likelihood of success increases over the next mapping event(s), as a machine that offers a lower completion time (*i.e., *a higher chance of success) can potentially become available. In addition, deferring unlikely-to-succeed tasks can possibly improve the chance of success for other waiting tasks which ultimately enhances the overall system robustness. We note that, task deferring is applied in every mapping event and only on tasks waiting in the arrival queue.

Effectively, task deferring limits mapping heuristics to only map tasks whose chance of success is higher than a user-defined (*i.e., *service provider) threshold, called Pruning Threshold. By setting the threshold, a service provider can manage his/her incurred cost of using cloud-based serverless platform wasted to process tasks that are unlikely to succeed.

IV-C Task Dropping

Task dropping is defined as the act of evicting a task from the system. Task dropping can occur in two manners, namely reactive and proactive dropping. Reactive task dropping occurs when a task has already missed its deadline. Proactive task dropping, however, predictively drops tasks whose chance of success is low, before their deadline is reached. Proactive dropping is considered a more aggressive pruning decision and should be enacted only under high levels of oversubscription. Such task dropping does not only increase the chance of success for the tasks behind the dropped one, but also reduces the compound uncertainty in their completion time, which yields more informed/accurate mapping decision. Hence, task dropping in a sufficiently oversubscribed system potentially improves the overall system robustness.

Toggle module is in charge of determining when the system is sufficiently oversubscribed to shift to a more aggressive pruning via triggering task dropping. The current implementation of Toggle checks the number of tasks missing their deadlines since the previous mapping event and identifies the system as oversubscribed if the number is beyond a configurable Dropping Toggle.

IV-D Fairness Preservation

Aiming at maximizing robustness, pruning can get biased to task types with shorter expected execution time, because such tasks generally provide a higher chance of success. The pruning unfairness can be harmful, as it consistently violates deadlines of certain task types. To avoid such a bias, the Accounting module keeps track of tasks that are dropped or completed. Then, the Fairness module utilizes the tasks’ information to calculate the sufferage score of each task type.

Each on-time completion of a task of type $k$ reduces the sufferage score of task type $k$ by a configurable constant value ($c$), whereas dropping a task of type $k$ increases the sufferage score of its type by $c$ value. The constant value $c$, termed fairness factor, can be adjusted to determine how aggressively the sufferage score changes. The sufferage score of task type $k$ is then used as a probability offset to the Pruning Threshold of such task type.

IV-E Pruning Procedure

Detailed procedure of the pruning mechanism is explained in form of a pseudo-code in Figure 5. At the beginning of each mapping event, tasks that have already missed their deadlines are dropped (Step 1). The Fairness module uses the information collected by the Accounting module about tasks completed since the previous mapping event to update the sufferage score (Step 2). If the the system is identified as oversubscribed by the Toggle module (Step 3), the Pruner is engaged to drop tasks that are unlikely to succeed from machine queues. For that purpose, the chance of success for each task is calculated (Step 5) and those whose chance is less than the Pruning Threshold are dropped (Step 6). After mapping decisions are made (and before dispatching tasks to machines), the pruner defers assigning tasks whose chance of success is less than the Pruning Threshold ($\beta$) to the next mapping event (Step 10). The remaining tasks are dispatched to their assigned machines (Step 11). Steps 7—11 are repeated until there is no remaining task in the batch queue or machine queues are full.

V Performance Evaluation

V-A Experimental Setup

To evaluate the impact of pruning mechanism on a variety of widely-used mapping heuristics, we conducted a simulation study under various configurations of heterogeneous (in both immediate- and batch-modes) and homogeneous computing systems. For the experiments, Pruning Configurations are set to use Pruning Threshold of 50% and Fairness factor of 0.05, unless otherwise stated. To accurately analyze the impact of dropping and deferring, we evaluate them both individually and together.

For each set of experiments, 30 workload trials were performed using different task arrival times built from the same arrival rate and pattern. In each case, the mean and 95% confidence interval of the results are reported. The experiments were performed using the Louisiana Optical Network Infrastructure (LONI) Queen Bee 2 HPC system [32].

While the task completion time estimation involves multiple convolutions which impose calculation overhead, there are multiple implementation techniques that can minimize the overhead of repeated calculation, such as task grouping and memorization of partial results. Moreover, all the task pruning decisions are made by a dedicated machine which reserved for resource allocation. Therefore, pruning mechanism does not add extra overhead to each HC resources in our experiments.

V-B Workload Generation

Twelve SPECint benchmarks were run numerous times on a set of eight machines which were used to generate probabilistic execution time (PET) PMFs [16]. The PMFs were generated by creating a histogram on a sampling of 500 points from a Gamma distribution formed using one of the means, and a shape randomly chosen from the range [1:20]. This was done for each of the twelve benchmarks, on each of the eight machines111The 8 machines are: Dell Precision 380 3 GHz Pentium Extreme, Apple iMac 2 GHz Intel Core Duo, Apple XServe 2 GHz Intel Core Duo, IBM System X 3455 AMD Opteron 2347, Shuttle SN25P AMD Athlon 64 FX-60, IBM System P 570 4.7 GHz, SunFire 3800, and IBM BladeCenter HS21XM., resulting in the eight by twelve machine type to task type PET matrix. The PET matrix remains constant across all of our experiments.

In each experiment, a determined number of tasks per time unit is fed to the system within a finite time span. For each experiment, the system starts and ends in an idle state. As such, The first and last 100 tasks in each workload trial are removed from the data to focus the results on the portion of the time span where the system is oversubscribed.

To conduct a comprehensive evaluation, two sets of workload were examined: (A) Constant rate arrival pattern: a Gamma distribution is created with a mean arrival rate for all task types. The variance of this distribution is 10% of the mean. Each task type’s mean arrival rate is generated by dividing the number of time units by the estimated number of tasks of that type. A list of tasks with attendant types, arrivals times, and deadlines is generated by sampling from each task type’s distribution. (B) Variable rate (spiky) arrival pattern: In this case, tasks arrive with variable rates, as shown in Figure 6, to mimic arrival patterns observed in HC systems (*e.g., * [33]). The spike times were determined uniformly, from the constant arrival workload, by dividing the workload time span to the number of spikes we want to create. During each spike, task arrival rate rises up to three times more than the base (lull) period. Each spike lasts for one third of the lull period. Since the spiky arrival pattern is frequently observed in real systems, it is our default workload arrival pattern in the experiments. For each task, as noted in Equation 4, the deadline is calculated by adding the mean duration for that task type ($avg_{i}$) to the arrival time ($arr_{i}$), and then adding in a slack period based on the mean of all task type’s duration multiplied by a tuning parameter ($\beta\cdotp avg_{all}$). This slack allows for the tasks to have a chance of completion in an oversubscribed system. In the workload trials, the value of $\beta$ of each task is randomly chosen from the range of $[0.8,2.5]$.

[TABLE]

We carried out experiments under a variety of task arrival rates (oversubscription levels), however, the default rate used for plotting graphs includes 15K tasks that represents a moderately oversubscribed system. All the workload trials are publicly available from git.io/fhSZW for reproducing purposes.

V-C Impact of Toggle Reacting to Oversubscription in HC Systems

In this experiment, our goal is to evaluate the impact of Toggle module within the pruning mechanism. Recall that the Toggle module is in charge of triggering task dropping operation. As such, we evaluate three scenarios: First, when there is no Toggle module in place and dropping operation is never engaged (referred to as “no Toggle, no dropping”); Second, when Toggle module is not in place and task dropping is always engaged (referred to as “no Toggle, always dropping”); Third, when the Toggle module is in place and is aware of (*i.e., *reactive to) oversubscription (referred to as “reactive Toggle”). In this case, the Toggle module engages task dropping only in observation of at least one task missing its deadline, since the previous mapping event.

Figure 7a shows the results for the immediate-mode mapping heuristics and Figure 7b shows them for the batch-mode. In both cases, we can observe that when Toggle functions in reaction to oversubscription, the overall system robustness is improved, regardless of the mapping heuristic deployed. The only exception is RR immediate-mode heuristic. The reason is that RR does not take execution time or completion time into account and it continuously maps tasks with a relatively low chance of success. These mapped tasks are subjected to be removed by task dropping. Without probabilistic task dropping, some of those low-chance tasks can complete on time. We can also observe that in immediate-mode, KPB provides the highest robustness (percentage of tasks completing on time) and also benefits the most from task dropping. This is because it makes more informed mapping decisions after dropping underperforming tasks.

The experiment testifies that our hypothesis in removing tasks with low chance of success in favor of other tasks is true and can significantly improves robustness—by up to 12% in immediate-mode and 19% in batch-mode.

V-D Impact of Task Deferring on Batch-Mode Heuristics

In this experiment, we evaluate the impact of task deferment within the pruning mechanism. As deferring operation works on the arrival (batch) queue, it can only be enabled for batch-mode heuristics. We conducted the experiment for task pruning threshold set to 0% (no task pruning), 25% , 50%, and 75%. As the results of this experiment is more prominent under high level of oversubscription, we set the task arrival to 25K tasks in the workload trials.

Figure 8 shows that, without task deferring (*i.e., *when Pruning Threshold is zero), MM, MSD, and MMU’s robustness are the lowest (between 5% to 23%). However, as task deferring is employed, all mapping heuristics can attain more than 44% robustness. This is because pruning mechanism delays mapping of tasks with low chance of success until a more suitable machine becomes available. Hence, machines are utilized only to execute promising tasks, thereby increasing the robustness. Our observation also implies that, for these widely used batch-mode mapping heuristics, by limiting the selection-pool of a mapping-heuristic to likely-to-succeed tasks, task deferring can reduce the performance differences of the heuristics to offer similar robustness, regardless of their algorithmic logic.

In Figure 8, we can see that, in all heuristics, the robustness does not improve for Pruning Thresholds higher than 50%. In fact, a high Pruning Threshold makes the system conservative in allocating tasks and defers tasks whose completion can improve overall robustness. Therefore, setting Pruning Threshold to 50% is a proper configuration for the pruning mechanism.

V-E Impact of Pruning Mechanism on Batch-Mode Heuristics

In this experiment, our goal is to evaluate the impact of the pruning mechanism holistically under various oversubscription levels. We evaluated the system robustness when mapping heuristics are coupled with and without the pruning mechanism. The pruning mechanism is configured with Pruning Threshold of 50% and Toggle is set to engage task dropping reactively.

Figure 9 shows that, for all heuristics under both constant and spiky arrival pattern, pruning mechanism improves the robustness. Pruning mechanism makes the largest impact for MSD and MMU. These heuristics attempt to map tasks with short deadlines and, thus, low chance of success. By limiting these heuristics to map tasks whose chance is beyond a certain threshold, their overall system robustness is improved.

V-F Impact of Pruning Mechanism on Homogeneous Systems

In addition to mapping heuristics for heterogeneous system, we also conduct experiments on homogeneous mapping heuristics to evaluate the impact of pruning mechanism. Pruning configurations are set to use reactive Toggle and Pruning Threshold of 50%.

Figure 10 shows that, in all levels of oversubscription, applying pruning mechanism to homogeneous systems significantly increases system robustness (by up to 28%) for all mapping heuristics on both constant and spiky arrival pattern. Importantly, as the oversubscription level increases, the impact of pruning mechanism is more substantial. With 25K tasks arrival rate, in constant arrival pattern, EDF and SJF can only achieve 4% and 10% robustness, respectively. Coupling pruning mechanism into these heuristics raises both the robustness to more than 30%. The reason is that, similar to heterogeneous systems, pruning mechanism allows the system to avoid mapping unlikely-to-succeed tasks, which appear more often under higher levels of oversubscription.

Based on the observations of this experiment, we can conclude that, pruning mechanism works equally as well and provides as much benefit to homogeneous systems as to the heterogeneous systems.

VI Related Works

Mapping tasks in HC systems has shown to be an NP-complete problem [10, 11]. Multiple research works have been undertaken that try to maximize robustness of the HC systems. In this section, we review research works closely related to this study.

In [9], Shestak *et al., *present the use of probability density functions (PDF) and mass functions (PMF) to capture uncertainty in task execution time. The authors use the robustness metric to showcase the effectiveness of the model using static resource allocation techniques. Their work lays out the method of convolving PMFs to estimate chance of success. We extend their approach to dynamically calculate task completion PMFs via convolution and to handle the case of probabilistic task pruning.

In an early work investigating heterogeneous scheduling [20], Malone *et al., *found out that lazy assignment, *i.e., *deferring task scheduling to the latest possible, improves the performance of HC systems. They show that outperformance in comparison with eager assignment increases, both as heterogeneity increases and as error in run-time estimation increases. We use this lazy assignment as a foundation for probabilistic task deferring.

Malawski *et al., *evaluate dynamic scheduling of constrained tasks in clouds [34]. Their work concerns with the cost of provisioning homogeneous virtual machines (VMs) to process workflows, which is different to our focus on meeting deadlines of independent tasks on heterogeneous machines. The authors introduce workflow-aware algorithms that drop workflows result in the loss of high-priority tasks, to increase the performance.

Khemka *et al., *investigate oversubscribed heterogeneous system resource management in [12]. They propose and investigate a parameterized method of utility function creation using priority, utility class, and urgency. They track execution times using an ETC matrix with deterministic scalar execution times, whereas we model the times via PMFs to accurately capture the uncertainty in task completion, especially in the presence of task-dropping. Tasks are dropped from their system after a task has reached a certain utility threshold, as opposed to our probabilistic deadline-focused approach.

Li *et al., *propose a task scheduling method for a live video streaming using cloud service [15]. Their video segment transcoding system consider tasks with a hard deadline and drops those that miss their deadline. However, there is no probabilistic task pruning in place. Although the mechanism described herein uses live video streaming as a motivation, the mechanism can be applied to any system with hard deadlines.

Delimitrou and Kozyrakis propose and explore Paragon [35], an immediate-mode scheduling system for heterogeneous systems. Historical task execution information are used by singular value decomposition to classify incoming tasks based on their heterogeneity and potential co-location interference. These classifications are used to select mappings based on interference and heterogeneity [36]. The mapping heuristics use scalar execution times to make decisions, whereas we focus on the uncertainty that is captured by modeling execution times via PMFs, and consider both immediate- and batch-mode heuristics. Another difference is in the performance metrics. Paragon tasks have no deadlines and its goal is to maximize speedup.

The act of proactive task dropping is similar to network packet queuing policy (*e.g., *RED [37]) in dropping network packets. However, there are key differences: (1) Our problem is dealing with big tasks that are less delay sensitive than network packets, therefore, more sophisticated consideration task deferring and dropping decision is allowed; (2) We prioritize task deferring that offers more chance to tasks to get scheduled later; (3) Our performance metric is the number of tasks meeting their deadlines, rather than latency or throughput. Hence, we believe this research is more closely related to HC systems but results can potentially be useful and applied to other domains as well.

VII Conclusion and Future works

In this research, our goal was to enhance robustness of an HC system, deployed for serverless computing, via pruning task requests with low chance of success. We introduced a stand alone pruning mechanism that can be plugged into any task mapping heuristic without requiring any change in the resource allocation system. Evaluation results of applying the pruning mechanism on widely-used mapping heuristics in both homogeneous and heterogeneous systems showed that probabilistic dropping and deferring of unlikely-to-succeed tasks can increase the overall system robustness. The improvement was more remarkable (up to 35 percentage point) for heuristics with far-from-optimal mapping decisions (*e.g., *MMU and EDF). Even in the case of MinMin mapping heuristic, the pruning mechanism led to 15 percentage point increase in robustness. We can conclude that, regardless of the underlying mapping heuristic, probabilistic task pruning can effectively improve robustness of serverless computing platforms, particularly when the system is oversubscribed.

From the system perspective, we believe that, probabilistic task pruning improves energy efficiency by saving the computing power that is otherwise wasted to execute failing tasks. Such saving in computing can also reduce the incurred cost of using cloud resources for the serverless computing provider. In the future, we plan to measure such improvements in energy and incurred cost. Another future plan is to work on pruning methods that incorporate cost/priority of tasks, when considering dropping each individual task.

Acknowledgments

We would like to thank the reviewers for their time and comments. Portions of this research were conducted with high performance computational resources provided by the Louisiana Optical Network Infrastructure (http://www.loni.org) [32]. This research was supported by the Louisiana Board of Regents under grant number LEQSF(2016-19)-RD-A-25.