Xiaohu Wu
email: xiaohuwu@fbk.eu

Patrick Loiseau
email: patrick.loiseau@inria.fr

Esa Hyyti

Towards Designing Cost-Optimal Policies to Utilize IaaS Clouds with Online Learning

Keywords: On-demand instances, spot instances, cost efficiency, online learning

Many businesses possess a small infrastructure that they can use for their computing tasks, but also often buy extra computing resources from clouds. Cloud vendors such as Amazon EC2 offer two types of purchase options: on-demand and spot instances. As tenants have limited budgets to satisfy their computing needs, it is crucial for them to determine how to purchase different options and utilize them (in addition to possible self-owned instances) in a cost-effective manner while respecting their response-time targets. In this paper, we propose a framework to design policies to allocate self-owned, on-demand and spot instances to arriving jobs.

In particular, we propose a near-optimal policy to determine the number of self-owned instances and an optimal policy to determine the number of on-demand instances to buy and the number of spot instances to bid for at each time unit. Our policies rely on a small number of parameters and we use an online learning technique to infer their optimal values. Through numerical simulations, we show the effectiveness of our proposed policies, in particular that they achieve a cost reduction of up to 64.51% when spot and on-demand instances are considered and of up to 43.74% when self-owned instances are considered, compared to previously proposed or intuitive policies.

INTRODUCTION

Infrastructure-as-a-Service (IaaS) holds exciting potential for users to elastically scale their computation capacity up and down to match the time-varying demand. This eliminates the need of purchasing their own servers to satisfy the peak demand, without causing unacceptable latencies. The global cloud IaaS market grew to $34.6 billion in 2017, and is projected to increase to $71.6 billion in 2020 [START_REF]Gartner Says Worldwide IaaS Public Cloud Services Market Grew 29.5 Percent in 2017[END_REF]. Main IaaS service providers include Amazon, Microsoft, Google, etc. Amazon is the most popular and represents 51.8% of the global market share in 2017; here, two typical purchase options are on-demand and spot instances (i.e., virtual machines). Recently, the issue of cost-effectively utilizing these two types of instances has received significant attention [START_REF] Kumar | A Survey on Spot Pricing in Cloud Computing[END_REF].

On-demand instances are always available at a fixed price and tenants 1 pay only for the period in which instances are consumed at an hourly rate. Users can also bid a price for spot instances and successfully get them only if their bid is above the spot price. However, spot instances will get lost once the spot price becomes higher than their bid. Here, spot prices usually vary unpredictably over time and users will be charged the spot prices for their use. Compared to on-demand instances, spot instances can reduce the cost by up to 50-90% [START_REF]Amazon EC2 pricing[END_REF]. Users that purchase cloud instances may also have their own instances, referred to as self-owned instances, which can be used to process jobs but are insufficient at times (hence the need to purchase extra IaaS instances). They may also not have any self-owned instances (e.g., in the case of startups) and therefore need to buy from the cloud all necessary computing resources.

Tenants' jobs arrive over time. We focus on processing a type of embarrassingly parallel workloads/jobs [START_REF] Gunarathne | Cloud computing paradigms for pleasingly parallel biomedical applications[END_REF], [START_REF] Fox | Data intensive applications on clouds[END_REF]. Each job can be separated into a large number of small tasks. These tasks are independent and can be executed on multiple machines simultaneously. Completing a job means completing all its tasks and the maximum completion time of all tasks is the job's completion time. This type of jobs accounts for a significant proportion in cloud market; examples include 3D video rendering, BLAST searches, data cleaning and pre-processing. Such job is also called malleable job [START_REF] Jain | Near-Optimal Scheduling Mechanisms for Deadline-Sensitive Jobs in Large Computing Clusters[END_REF], [START_REF] Wu | Algorithms for scheduling deadlinesensitive malleable tasks[END_REF], [START_REF] Loiseau | Greedy and Dynamic Programming Algorithms for Scheduling Deadline-Sensitive Parallel Tasks[END_REF], [START_REF] Viswanath Nagarajan | Flowflex: Malleable scheduling for flows of mapreduce jobs[END_REF] and it has a parallelism bound specifying the maximum number of instances that it can utilize simultaneously. Each job also has constraint on timing, i.e., a deadline by which to complete all tasks of a job. Subject to the parallelism constraint, an arriving job will be allocated instances of different types (selfowned, on-demand and spot) and the allocation can be updated at most once every hour (since billing is done per hour). Our problem is then to find an allocation that minimizes cost while satisfying the deadline constraint. Challenges. In this paper, we make a natural assumption that the costs of utilizing self-owned, spot and on-demand instances are increasing. To be cost-optimal, an allocation policy should sequentially maximize the utilization of self-owned and then spot instances. This is, however, a difficult task. For instance, a naive policy would be, whenever a job arrives, to assign as many remaining self-owned instances as possible to it. However, this policy turns out not to be good wrt cost. Indeed, it ignores the difference of jobs and treats all jobs equally when assigning instances, whereas we find that a good policy wrt cost needs instead to determine the allocations of self-owned instances to jobs according to their capabilities of utilizing spot instances. In particular, subject to the parallelism constraint of a job j, the availability of spot instances varies in the period between its arrival and deadline and determines the maximum workload of j that could be processed by spot instances. If the workload of j is large, j has to utilize some stable self-owned or on-demand instances in order to finish itself by the deadline; such job is said to have poor capability of utilizing spot instances alone to finish itself by its deadline (also called poor jobs). If the workload of j is small, finishing j by its deadline only needs to utilize spot instance alone, with no need of self-owned or on-demand instances; such job is said to have strong such capability (called rich job).

A better policy would then be as follows. When self-owned instances are inadequate, actively assign self-owned instances to poor jobs and assign nothing to rich jobs; otherwise, such poor jobs will have to consume costly on-demand instances, and it also causes a waste of other rich jobs' capabilities to utilize spot instances. When self-owned instances are adequate, assign a proper amount of self-owned instances to every job with either poor or strong capability such that after the allocations all jobs are expected to be completed by utilizing spot instances alone, eliminating the need of consuming costly on-demand instances. After allocating self-owned instances, the remaining question is to identify a job's capacity to utilize spot instances for processing its workload, and propose an expected optimal policy to achieve the capacities of jobs, further escaping unnecessary consumption of on-demand instances. Our Contributions. In this paper, we propose a framework to design policies to allocate various instances. Based on the two principles that (i) self-owned instances should be allocated to maximize their utilization while maximizing the opportunity of all jobs utilizing spot instances and (ii) on-demand instances should be allocated to maximize the opportunity to utilize spot instances, we propose parametric policies for the allocation of self-owned, on-demand and spot instances that achieve near-minimal costs. To cope with the cloud market dynamic and the uncertainty of job's characteristics, we use the online learning technique in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF] to infer the optimal parameters. More specifically:

•

We propose a cost-effective policy for allocating selfowned instances that is smarter than the naive allocation mentioned above and hits a good trade-off between the utilization of self-owned instances and the opportunity of utilizing spot instances. We show in our numerical experiments that this policy improves the cost by up to 43.74% compared to the naive policy.

•

We propose a cost-optimal policy for the utilization of ondemand and spot instances, based on a formulation of the original problem as an integer program to maximize the utilization of spot instances. This policy can be used both when the tenant has self-owned resources and when he does not. Our simulation results show that it improves the cost of previous policies in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF] by up to 64.51%.

We note that the paper [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF] also appears in [START_REF] Jain | Allocation of Computational Resources with Policy Selection[END_REF] as a U.S. Patent.

The rest of this paper is organized as follows. We introduce the related works in Section 2 and describe the problem formally in Section 3. In Section 4, we propose scheduling policies for selfowned, on-demand and spot instances. In Section 5, simulations are done to show the effectiveness of the solutions of this paper. Finally, we conclude this paper in Section 6. The proofs of all propositions are omitted and can be found in the appendix. We note that a part of results of this paper also appeared at the 2017 IEEE International Conference on Cloud and Autonomic Computing [START_REF] Wu | Towards designing cost-optimal policies to utilize IaaS clouds with online learning[END_REF].

RELATED WORK

In this paper, we use the online learning technique to learn the most effective parametric policy for utilizing various instances. Jain et al. were the first to consider the application of this approach to the scenario of cloud computing 2 [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF]. However, they do not consider the problem of how to optimally utilize the purchase options in IaaS clouds and self-owned instances are also not taken into account. This approach is interesting because it does not impose the restriction of a priori statistical knowledge of workload, compared to other techniques such as stochastic programming. However, it can achieve good performances only if the potentially optimal scheduling policies are identified among all possible policies. Similar to our paper and [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF], cost-effectively executing deadline-constrained jobs in IaaS clouds is also studied in [START_REF] Zafer | Optimal Bids for Spot VMs in a Cloud for Deadline Constrained Jobs[END_REF], [START_REF] Yao | Cutting Your Cloud Computing Cost for Deadline-Constrained Batch Jobs[END_REF]. In particular, Zafer et al. characterize the evolution of spot prices by a Markov model and propose an optimal bidding strategy for utilizing spot instances to complete a serial or parallel job by some deadline [START_REF] Zafer | Optimal Bids for Spot VMs in a Cloud for Deadline Constrained Jobs[END_REF]. Yao et al. study the problem of utilizing reserved and on-demand instances to complete online batch jobs by their deadlines and formulate it as integer programming problems; then heuristic algorithms are proposed to give approximate solutions [START_REF] Yao | Cutting Your Cloud Computing Cost for Deadline-Constrained Batch Jobs[END_REF].

There have been substantial works on cost-effective resource provisioning in IaaS clouds [START_REF] Sunilkumar | Resource Management for Infrastructure as a Service (IaaS) in Cloud Computing: A Survey[END_REF], and we introduce some typical approaches. Built on the assumption of a priori statistical knowledge of the workload or spot prices, several techniques could be applied. For example, in [START_REF] Hong | Dynamic Server Provisioning to Minimize Cost in an IaaS Cloud[END_REF], [START_REF] Chaisiri | Optimization of Resource Provisioning Cost in Cloud Computing[END_REF], the techniques of stochastic programming is applied to achieve the cost-optimal acquisition of reserved and on-demand instances; in [START_REF] Zheng | How to Bid the Cloud[END_REF], the optimal strategy for the users to bid for the spot instances are derived, given a predicted distribution over spot prices. However, a high computational complexity arises when implementing these techniques, though the statistical knowledge could be derived by the techniques such as dynamic programming [START_REF] Shi | Cost-Minimizing Online VM Purchasing for Application Service Providers with Arbitrary Demands[END_REF].

Wang et al. use the competitive analysis technique to purchase reserved and on-demand instances without knowing the future workload [START_REF] Wang | Optimal Online Multi-Instance Acquisition in IaaS Clouds[END_REF], where the Bahncard problem is applied to propose a deterministic and a randomized algorithm. In [START_REF] Vintila | Fast (Re-) Configuration of Mixed On-demand and Spot Instance Pools for High-Throughput Computing[END_REF], a genetic algorithm is proposed to quickly approximate the pareto-set of makespan and cost for a bag of tasks where on-demand and spot instances are considered. In [START_REF] Shi | Cost-Minimizing Online VM Purchasing for Application Service Providers with Arbitrary Demands[END_REF], the technique of Lyapunov optimization is applied and it's said to be the first effort on jointly leveraging all three common IaaS cloud pricing options to comprehensively reduce the cost of users; however, a large delay will be caused when processing jobs; in order to achieve an O( ) close-to-optimal performance, the queue size has to be Θ(1/ ) [START_REF] Huang | The Power of Online Learning in Stochastic Network Optimization[END_REF]. Gao et al. proposed a two-timescale markov decision process approach by jointly considering resource provisioning and task scheduling in public clouds to maximize the profit of a multimedia service provider [START_REF] Gao | Resource provisioning and profit maximization for transcoding in clouds: A twotimescale approach[END_REF]. In [START_REF] Daniel | Autonomic provisioning and application mapping on spot cloud resources[END_REF], [START_REF] Daniel | OptiSpot: minimizing application deployment cost using spot cloud resources[END_REF], Dubois and Casale propose a heuristic to help cloud users decide what type of spot instances should be rent and what bid price to use to minimize their cost while maintaining an acceptable level of performance.

PROBLEM DESCRIPTION AND MODEL

In this section, we introduce the cloud pricing models, define the operational space of a user to utilize various instances, and characterize the objective of this paper.

2. The objective of this paper corresponds to a special case of [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF] where the value of each job is larger than the cost of completing it.

Pricing Models in the Cloud

We first introduce the pricing models in the cloud. The price of an on-demand instance is charged on an hourly basis and it is fixed and denoted by p. Even if on-demand instances are consumed for part of an hour, the tenant will be charged the fee of the entire hour, as illustrated in Fig. 1. Furthermore, tenants can bid a price for spot instances and spot prices are updated at regular time slots (e.g., every L = 5 minutes in Amazon) [START_REF] Zheng | How to Bid the Cloud[END_REF], [START_REF] Wu | A Framework for Allocating Server Time to Spot and On-demand Services in Cloud Computing[END_REF]. Spot instances are assigned to a job and continue running if the spot price is lower than the bid price. Spot prices usually change unpredictably over time [START_REF] Orna Agmon Ben-Yehuda | Deconstructing Amazon EC2 Spot Instance Pricing[END_REF]. Once the spot price exceeds the bid price of a job, its spot instances will get terminated immediately by the cloud, as illustrated in Fig. 2; here, the termination occurs at the very beginning of a time slot. The tenant will be charged the spot prices for the maximum integer hours of execution. A partial hour of execution is not charged in the case where its instances are terminated by the cloud; in contrast, if spot instances run until a job is completed and then are terminated by the tenant, for the partial hour of execution, the tenant will also be charged for the full hour. Finally, a user might have its own instances, i.e., self-owned instances. The (averaged) hourly cost of utilizing self-owned instances is assumed to be p 1 . It is the cheapest to use selfowned instances so that p 1 is without loss of generality assumed to be 0, which implies that a user always prefers to first utilize its own instances before purchasing instances from the cloud. An example of self-owned instances is academic private clouds, which are provided to researchers free of charge.

Jobs

Our paper focuses on processing a type of embarrassingly parallel computations, also called map-only jobs; see [START_REF] Fox | Data intensive applications on clouds[END_REF] for the classification of big-data applications on clouds. Each job can be separated into a large number of small tasks. These tasks are independent and can be executed on multiple machines simultaneously; completing a job means completing all its tasks, and the maximum completion time of all tasks is the job's completion time. Examples of such computations include parallel rendering in computer graphics, BLAST searches and CAP3 in bioinformatics, large scale facial recognition systems that compare thousands of faces, grid and random search for hyperparameter optimization in machine learning, data cleaning and pre-processing and so on. A task is the minimum running unit and should be processed continuously without preemption until its completion.

For example, in CAP3, the data are divided into many files and each task finishes reading a file; if each file has 458 reads, it may take about 7 seconds to process a task when two high CPU extra large instances are used with 8 workers per instance [START_REF] Gunarathne | Cloud computing paradigms for pleasingly parallel biomedical applications[END_REF]. For each job j, its size/workload is defined as the time when finishing it on one instance, denoted by z j , and can be estimated by the input data size or the number of small tasks. While executing a job, the remaining workload can also be estimated by the remaining input data to be processed. Such jobs can be formally modeled as malleable jobs in literature [START_REF] Jain | Near-Optimal Scheduling Mechanisms for Deadline-Sensitive Jobs in Large Computing Clusters[END_REF], [START_REF] Viswanath Nagarajan | Flowflex: Malleable scheduling for flows of mapreduce jobs[END_REF]. Each job j has a parallelism bound δ j that limits the maximum number of instances that it could utilize simultaneously. While executing a job, the number of instances assigned to a job could change over time.

The job arrival of a tenant is monitored every time slot of L minutes (i.e., at the time points when spot prices change) and time slots are indexed by t = 1, 2, • • • . Each job j has four characteristics: (i) an arrival slot a j : If job j arrives at a certain continuous time point in [(t -1) • L, t • L), then set a j to t; (ii) a relative deadline d j ∈ Z + : it is a time constraint on completing a job, that is, every job must be completed at or before time slot a j + d j -1; (iii) a job size z j (measured in the instance time slots (CPU time) that need to be utilized): the workload to complete j; (iv) a parallelism bound δ j : the upper bound on the number of instances that could be simultaneously utilized by j. The tenant plans to rent instances in IaaS clouds to process its jobs and aims to minimize the cost of completing a set of jobs J (that arrive over a time horizon T ) by their deadlines.

Rules for Allocating Instances to Jobs

The pricing models define the rules of allocating instances to jobs and also the operational space of a user, i.e., (a) when the allocation to a job is done and updated, and, (b) how various instances are utilized by a job at every allocation update.

On-demand and spot instances

We first consider the allocation of on-demand and spot instances alone, ignoring self-owned instances temporarily.

To meet deadlines, (i) whenever a job j arrives at a j , the allocation of spot and on-demand instances to it is done immediately. The following rules apply to the case where j has flexibility to utilize spot instances. Given the fact that the tenant is charged on hourly boundaries, (ii) the allocation of on-demand and spot instances to each job j is updated simultaneously every hour. The i-th allocation occurs at the beginning of slot t = a j +(i-1)•Len where Len = 60/L is the number of slots per hour; the number of on-demand instances allocated to j is denoted by o i j and they can be utilized for the entire hour; (iii) the tenant will bid a price b i j for a fixed number si i j of spot instances. At the i-th allocation of j, b i j together with the spot prices determines whether j can successfully obtain spot instances and how long it can utilize them. Usually, spot instances are on average cheaper than on-demand instances, and (iv) at every allocation the tenant will bid for the maximum number of spot instances under the parallelism constraint, i.e., si i j = δ j -o i j . While j is utilizing the instances of the i-th allocation in the period of [a j +(i-1)•Len, a j +i•Len-1], we say that j is in the i-th execution.

At the i-th allocation, we use z i j to denote the remaining workload of j to be processed, i.e., z j minus the workload of j that has been processed. We define the current slackness of j as

s i j = (d j -(i -1) • Len) • δ j /z i j . (1)
The slackness can be used to measure the time flexibility that j has to utilize spot instances.

Definition 3.1. During the i-th execution where i ≥ 1, if spot instances get lost at the beginning of some slot t and are not utilized for the entire hour, we say that, at the next allocation, 1) j has flexibility to utilize spot instances, if s i+1 j ≥ 1; 2) j does not have such flexibility, otherwise.

Here, we know the values of s i+1 j and z i+1 j since we then know the value of z i j and the workload processed in the i-th execution. In Definition 3.1, if s i+1 j < 1 and the (i + 1)-th allocation is still taken at slot a j +i•Len, we have by the definition of s i+1 j that j cannot be completed by its deadline even if j totally utilize δ j on-demand instances in the remaining period; we use i j to index the last (or such i-th) allocation after which j has no flexibility to utilize spot instances. We illustrate this by Fig. 3. At the first allocation, z 1 j = z j = 132 and o 1 j = si 1 j = 2. At the second allocation, z 2 j = 132 -2 • 12 -2 • 8 = 92, and o 2 j and si 2 j are still 2. In the second execution, when spot instances are terminated at the end of slot 20, we have z 3 j = 92 -2 • 12 -2 • 8 = 52, and

s 3 j = Len•δj z 3 j < 1;
thus, there is no flexibility for j to utilize spot instances at the third allocation. In Fig. 3, i j = 2. The decision on how to determine the (i j + 1)-th allocation of instances to j has to be done earlier (than the beginning of slot a j + i j • Len = 25), since there exists an on-demand instance that has to be utilized for Finally, the instance allocation is generally divided into two phases. In the first phase, j has flexibility to utilize spot instances at every i-th allocation and

• the instance allocation is updated every hour (i.e., every Len slots).

In the i-th execution of j, the workload processed by on-demand instances is Len • o i j ; as time goes by, there are three possible states while utilizing spot instances: (i) z i j -Len • o i j workload of j has been processed by spot instances; (ii) j utilizes spot instances for Len slots; (iii) the spot instances of j are interrupted by the cloud and utilized for partial hour.

With the first state, the spot instances will be terminated by its user and j will be finally completed in the i-th execution. With the second state, since j has flexibility for spot instances at the i-th allocation (i.e., s i j ≥ 1), so does it at the (i + 1)-th allocation. With the third state, if s i+1 j ≥ 1, the (i + 1)-th allocation of j is still in the first phase; otherwise,

• the (i + 1)-th (i.e., (i j + 1)-th) allocation of j needs to be done immediately after the spot instances get lost, which is referred to as the second phase of instance allocation; then, only stable on-demand instances will be used to meet the deadline.

Self-owned instances

When self-owned instances are also taken into account, we assume that (v) the allocation of self-owned instances to a job can be updated at most once at every allocation of j. We denote by r i j the number of self-owned instances assigned to j at the ith allocation; the parallelism constraint further translates to o i j + si i j + r i j = δ j . In this paper, o i j and si i j denotes the numbers of on-demand and spot instances acquired at the i-th allocation and will be used to track the cost of completing j. As we will see in Section 4.2, the acquired on-demand instances may not be fully utilized for an entire hour in the (i j + 1)-th execution, and, we use o j (t), si j (t) and r j (t) to denote the numbers of ondemand, spot and self-owned instances that are actually utilized by j at every slot t ∈ [a j , a j + d j -1], where r j (t) = r i j for all t ∈ [a j + (i -1) • Len, a j + i • Len -1]; then the parallelism constraint translates to o j (t) + si j (t) + r j (t) = δ j .

As shown later, allocating properly self-owned instances enables escaping unnecessary consumption of on-demand instances that are more expensive than the others, which can be achieved by simply allocating j the same number of self-owned instances at every time slot, i.e., r j (t) = r j . So, the allocation of self-owned instances is done only once upon arrival of j; after the allocation, the job can could be viewed as a new job with a parallelism bound δ j -r j , a size z j -r j • d j , and the same arrival time and deadline as j , and it will be completed by utilizing spot and on-demand instances alone.

Scheduling Objective

We refer to the ratio of the total cost of utilizing a certain type of instances to the total workload processed by this type of instances as the average unit cost of this type of instances. As described in Section 3.1, we assume that Assumption 1. The average unit costs of self-owned instances is lower than the average unit cost of spot instances, which is lower than that of on-demand instances.

Accordingly, to be cost-optimal, we should consider allocating various instances to each arriving job in the order of self-owned, spot and on-demand instances. Further, in Principles 3.1 and 3.2, we give the objectives that should be achieved when considering allocating each type of instances to the arriving jobs.

Principle 3.1. The scheduler should make self-owned instances (i) fully utilized, and (ii) utilized in a way so as to maximize the opportunity that all jobs have to utilize spot instances. Principle 3.2. After self-owned instances are used, the scheduler should utilize on-demand instances in a way so as to maximize the opportunity that all jobs have to utilize spot instances.

Decision variables

Our main objective of this paper is to propose scheduling policies that can realize Principles 3.1 and 3.2. To do so, we will first determine the allocation of self-owned instances and then the allocation of on-demand and spot instances for every arriving job j. For every arriving job j, it will be first allocated r j self-owned instances in [a j , a j + d j -1]. Then, as described in Section 3.3, the allocation of spot and on-demand instances will be updated per hour in the first phase and we need to determine the number of spot instances to be bid for and the number of on-demand instances to be purchased (i.e., si i j and o i j ); once there is no flexibility for j to utilize spot instances, we need to determine the allocation of on-demand instances alone in order to complete j by deadline. Hence, the main decision variables of this paper are r j , si i j , and o i j where o i j + si i j + r j = δ j . In this paper, we apply the online learning approach and it does not require the exact statistical knowledge on jobs and spot prices. At every allocation update of j in the first phase, only the current characteristics of j (i.e., z i j , δ j , a j , and d j ) and the amount of available self-owned instances are definitely known for a user to determine o i j and si i j . The value of spot price is jointly determined by the arriving jobs of numerous users and the number of idle servers at a moment, usually varying over time unpredictably. In this paper, it is assumed that the change of spot prices over time is independent of the job's arrival of an individual user [START_REF] Zafer | Optimal Bids for Spot VMs in a Cloud for Deadline Constrained Jobs[END_REF], [START_REF] Zheng | How to Bid the Cloud[END_REF]. In the i-th execution of j, when a user bids some price for si i j spot instances, without considering the case where the spot instances of j is terminated by a user itself, the period in which j can utilize spot instances is a random variable and we assume that the expected time for which j could utilize spot instances is β • Len where β ∈ [0, 1]. Finally, Table 1 summarizes the main notation of this paper.

THE DESIGN OF NEAR-OPTIMAL POLICIES

In this section, we propose a theoretical framework to design (near-)optimal parametric policies, aiming at realizing Principles 3.1 and 3.2. Facing diverse users, the proposed policies should have good adaptability against the unknown statistics of the spot prices and each individual user's job characteristics; then, by applying the online learning technique, the best configuration parameter that corresponds to each user could be inferred to minimize its cost of processing jobs.

Upon arrival of a job j, the scheduler first considers the allocation of self-owned instances to it, aiming to realize the two goals in Principle 3.1. Next, as described in Section 3.3.1, the allocation of spot and on-demand instances is updated on an hourly basis.

Self-owned Instances

In this subsection, we study the allocation of self-owned instances.

Challenge

We first show the challenges in cost-effectively utilizing selfowned instances by an example. Initially, there is a fixed number R of self-owned instances. Upon arrival of a job j, it is allocated a fixed number of self-owned instances, and these instances will be reserved for this job in the period [a j , a j +d j -1] and released by j after the slot a j + d j -1. As time goes by, when time is at the ]. An intuitive policy would be, whenever a job j arrives, to allocate as many self-owned instances to j to make self-owned instances fully utilized, i.e.,

r j = min{m aj (a j + d j -1), z j /d j }. (2)
However, this intuitive policy may not maximize the opportunity that all jobs have to utilize spot instances as illustrated in the following example.

There are two self-owned instance available, and two jobs whose have the same arrival time, relative deadline of 2 hours and parallelism bound of 4. Jobs 1 and 2 have a size of 4 × Len and 6 × Len, respectively. It is expected that a job can utilize spot instances for β = 1 2 hour (β •Len slots) at every allocation update. In Fig. 4, the area of diagonal stripes, the area of vertical stripes, and the dotted area denote the workload respectively processed by spot, self-owned and on-demand instances. Using the policy (2), the whole process of allocating instances is illustrated in Fig. 4 (left), where the user has to utilize two on-demand instances for 0.5 hour; however, it is not necessary to purchase more expensive on-demand instances if the allocation process is like Fig. 4 (right). In Fig. 4 (left), the cost of completing jobs 1 and 2 is 2 • p while it is zero in Fig. 4; here, on-demand instances are charged on an hourly basis, and the fee of utilizing spot instances is zero when they are terminated by the cloud. The above example reveals some challenges in designing costeffective policies for allocating self-owned instances. For example, the policy should have the ability of (i) identifying the subset of jobs that can be expected to be completed by utilizing spot instances alone even if they are not allocated any self-owned instance, e.g., the job 1 in Fig. 4 (right), and (ii) properly allocating self-owned instances to the rest of jobs, when self-owned instances are inadequate. All in all, our aim is to realize Principle 3.1.

Policy Design

In the following, we propose a policy that has the abilities described above. In the subsequent analysis, the issue of rounding the allocations of a job to integers is ignored temporarily for simplicity; in reality, we could round the allocations up to integers, which does not affect the related conclusions much as shown by the analysis.

Recall the meaning of β in Section 3.4. For every job j, we will go to find a function g j (x) ∈ [0, zj dj ] that satisfies the following properties where zj dj ≤ δ j : Property 4.1. g j (x) is non-increasing as x increases in [0, 1). Property 4.2. g j (β) is the minimum number such that when a job j is assigned r j self-owned instances in [a j , a j + d j -1] where r j ≥ g j (β), it could be expected that • job j could be completed by its deadline by utilizing spot instances alone if δ j -r j spot instances are bid for at every allocation update of j, where no on-demand instances is acquired.

The value of g j (β) is an indicator of the capability that j has such that it can be completed by utilizing spot instances alone. By Property 4.2, if g j (β) ≤ 0, it is expected that no self-owned or on-demand instances is needed in order to complete j and such jobs have strong capability to feed themselves with spot instances. Otherwise, g j (β) self-owned instances are needed, or j has to consume some amount of expensive on-demand instances in order to be completed by its deadline; for a job j, the larger the value of g j (β), the weaker its capability to feed itself with spot instances.

Let κ 0 = dj Len -1, and we set

r j (x) = r j (x) if d j -κ 0 • Len > x • Len, r j (x) if d j -κ 0 • Len ≤ x • Len,
where

r j (x) = δ j - d j • δ j -z j d j -(κ 0 + 1) • Len • x , and
r j (x) = 0 if κ 0 = 0, δ j - dj •δj -zj (1-x)•κ0•Len if κ 0 ≥ 1.
We further set g j (x) = max {r j (x), 0} .

(

When x = 0, g j (x) = max{r j (x), 0} = zj dj . When x → 1, g j (x) = max{r j (x), 0} and we have that (i) if κ 0 = 0, g j (x) = 0, (ii) if κ 0 ≥ 1 and d j • δ j = z j , g j (x) = zj dj , and (iii) if κ 0 ≥ 1 and d j • δ j > z j , g j (x) = 0 since r j (x) → -∞. Now, we proceed to show that the particular g j (x) in (3) satisfies Properties 4.2 and 4.1. In this paper, we consider a set of jobs T that arrive over time and can have diverse characteristics. When x ranges in [0, 1), we illustrate the function g j (x) in Fig. 5 where z j = 240, L = 5, δ j = 20, and Len = 12. The job's minimum execution time is zj δj = Len where j is assigned δ j instances throughout its execution. The job's deadline reflects its ability to utilize spot instances and in Fig. 5 the solid curves from left to right represent g j (x) where d j is respectively 5, 3, 2.1, 1.47, 1.25, 1.11, and 1.02 times Len: under the same x, the larger the deadline, the smaller the value of g j (x). Given z j , δ j and d j , we can see in Fig. 5 that the function g j (x) is non-increasing as x ranges in [0, 1). Proposed Policy. Based on Propositions 4.1 and 4.2, we propose the following policy for allocating self-owned instances. Upon arrival of every job j, it is allocated r j (β 0 ) self-owned instances where

r j (β 0 ) = min {g j (β 0 ), m t (a j + d j -1)} , (4)
where β 0 ∈ [0, 1) is a parameter to be learned. This policy achieves more cost-effective resource allocation as illustrated in Fig. 4 (right) where β 0 is set to β = 1 2 . Furthermore, this policy is also adaptive. For example, given another user who owns more instances (e.g., 5 instances), β 0 can be set to a value < β (e.g., 0); then, both jobs are allocated more self-owned instances: r 1 = 2, and r 2 = 3. As a result, self-owned instances are fully utilized and there is no need purchasing spot or ondemand instances.

Explanation

Now, we further explain that the policy (4) has desired properties to realize Principle 3.1, which will also be validated by the simulations.

Fig. 6. As the (relative) deadline d j increases from 12 to 48, the function g j (β 0 ) decreases respectively under β 0 = 31 64 , 5 16 , 1 16 , where z j = 240, δ j = 20, and Len = 12.

The allocations of self-owned instances to all jobs are based on the same function (4) whose value depends on a single parameter β 0 . Together with Properties 4.2 and 4.1, the power of the proposed policy can be achieved by setting β 0 to a value properly small in [0, 1). Now, we explain this. High Utilization. As illustrated in Fig. 5, the function g j (x) is non-increasing; no matter how many self-owned instances a user possesses, a high utilization of them is achieved after

• we set β 0 to a small enough value in [0, 1). This is because every arriving job will be assigned a large number of self-owned instances when β 0 is small, as illustrated in Fig. 6. Fair Allocation. Fair allocation means that the allocations of selfowned instances among jobs need to be balanced according to their capabilities of utilizing spot instances. Fair allocation avoids ignoring the difference among jobs and treating them equally where a policy like (2) is used; together with Property 4.2, the latter can lead to that "rich" jobs (i.e., jobs with strong capabilities where g j (β) is small) are consuming unnecessary self-owned instances, i.e.,

• r j > g j (β), where r j denotes the number of self-owned instances allocated to a job; the job's remaining z j -r j •d j workload is expected to be processed by spot instances alone; whereas the others (with large g j (β)) are allocated poorly and still starving for more self-owned instances, i.e.,

• r j < g j (β); here, on-demand instances are expected to be consumed.

Indiscriminate allocations of instances to jobs do harm to the process of achieving the capacity that jobs have for utilizing spot instances, causing unnecessary consumption of more on-demand instances and a higher cost of completing all jobs. In particular, for every rich job, only g j (β) self-owned instances are needed to complete its remaining workload without on-demand instances; the saved r j -g j (β) self-owned instances can be used for those poorly allocated jobs so as to reduce their consumption of ondemand instances, which improves the cost-efficiency of instance utilization. Now, we explain that the proposed policy achieves fair allocation by properly setting the value of β 0 . The cost-optimal β 0 , denoted by β * 0 , depends on the statistics of jobs and the amount of self-owned instances available; the online learning technique will be used subsequently in Section 4.4 to infer β * 0 . When β * 0 = 0, self-owned instances themselves are enough to complete all jobs by their deadlines where g j (β 0 ) = zj dj . When there are adequate self-owned instances such that β * 0 ∈ (0, β], every arriving job j will be allocated ≥ g j (β) self-owned instances whenever the amount of idle self-owned is large (i.e., m aj (a j + d j -1) ≥ g j (β 0 )), according to the policy (4); this is illustrated in Fig. 6 where β = 5 16 and β * 0 = 1 16 . Afterwards, the job j is expected to be completed by utilizing spot instances alone. No job will be allocated < g j (β) self-owned instances whenever possible, and fair allocation is achieved. Furthermore, the arriving jobs are allocated on a first come first served basis and we note that β 0 should be properly small but cannot be set to a value too small. If β 0 is too small, jobs that arrive earlier might consume too many self-owned instances and then the jobs that arrive late have less opportunity to get ≥ g j (β) self-owned instances subject to the availability of these instances (i.e., the value of m aj (a j +d j -1)).

When self-owned instances are deficient such that β * 0 ∈ (β, 1), every arriving job will be allocated < g j (β) self-owned instances; this is illustrated in Fig. 6 where β = 5 16 and β * 0 = 31 64 . Afterwards, the job j is expected to have to utilizing some amount of on-demand instances to meet its deadline. No job will be allocated > g j (β) self-owned instances, achieving fair allocation among jobs: if there exists such allocation, a waste of self-owned instances is caused since we can reduce this allocation to g j (β) and allocate these saved instances to other jobs to reduce the consumption of on-demand instances.

Spot and On-demand Instances

As described in Section 3.3.1, the instance allocation process is divided into two phases. Now, we analyze the expected optimal strategy to utilize spot instances.

First phase

In the first phase, the allocation of j is updated per hour and there is flexibility for j to utilize spot instances. Now, we analyze the expected optimal policy in the first phase. One of the following two cases will happen: (i) the job j is completed in the first phase, and (ii) in the i j -th execution of j, after spot instances are terminated by the cloud, there is no flexibility for j to utilize spot instances.

In this paper, the value of β is inferred by the online learning technique. If the previous allocation of self-owned instances r j is ≥ g j (β), it is expected that the first case will happen; then, by Property 4.2, we conclude that Proposition 4.3. An expected optimal strategy is to bid for δ j -r j spot instances at every allocation of j.

Next, we analyze the optimal strategy when the second case happens. Job j is allocated r j self-owned instances at every t ∈ [a j , a j + d j -1]; afterwards, it can be viewed as a new job with a workload z j -δ j •d j and a parallelism bound δ j -r j , as described in Section 3.3.2. So, without loss of generality, we just analyze the optimal strategy in the case where a job j is completed by utilizing on-demand and spot instances alone.

Our decision variables are o i j and si i j where o i j +si i j = δ j . Let κ 1 denote the total number of allocation updates in the first phase where j has flexibility for spot instances; let κ 0 = d j /Len denoting the maximum possible number of allocation updates of j and we have

κ 1 ≤ κ 0 . (5)
In the i-th execution of j where i ∈ [1, κ 1 ], it is expected that the workloads processed by spot and on-demand instances are respectively (δ j -o i j )•Len•β and o i j •Len. By Definition 3.1, j has flexibility to utilize unstable spot instances at the κ 1 -th allocation, i.e.,

s κ1 j = δj •(dj -(κ1-1)•Len) zj - κ 1 -1 i=1 (o i j •Len+(δj -o i j )•Len•β) ≥ 1,
and has no flexibility to utilize spot instances at the (κ 1 + 1)-th allocation, i.e.,

s κ1+1 j = δj •(dj -κ1•Len) zj - κ 1 i=1 (o i j •Len+(δj -o i j )•Len•β) < 1.
They are respectively equivalent to the following relations:

κ1-1 i=1 (δ j -o i j ) • Len • (1 -β) ≤ d j • δ j -z j , (6)
κ1 i=1 (δ j -o i j ) • Len • (1 -β) > d j • δ j -z j . (7)
For the condition that s κ1+1 j < 1, a special case is κ 1 = κ 0 where this condition holds trivially since d j -κ 1 • Len ≤ 0; since s κ1 j ≥ 1, the κ 1 -th allocation of j is still in the first phase. In this subsection, our objective is to maximize the total workload processed by spot instances at the first κ 1 allocations, i.e., maximize

κ1 i=1 (δ j -o i j ) • Len • β, (8)
subject to the constraints ( 5), ( 6), [START_REF] Jain | Allocation of Computational Resources with Policy Selection[END_REF], and the constraint that o i j is an integer in [0, δ j ]. Our decision variables are o 1 j , • • • , o κ1 j . Now, we give an optimal solution to (8). Proposition 4.4. An solution to ( 8) is optimal if it is of the following form: (i)

κ1-1 i=1 (δ j -o i j ) = min{ν(z j , d j ), (κ 0 -1) • δ j }, and (ii) o κ1 j = 0, where ν(z j , d j ) = dj •δj -zj
Len•(1-β) . Proposition 4.4 indicates the maximum number of spot instances that can be bid for in the first phase, i.e., the maximum value of κ1 i=1 (δ j -o i j ). As a corollary of Proposition 4.4, we conclude that Proposition 4.5. Given a job j, the expected maximum workload that can be processed by spot instances is

(min {ν(z j , d j ), (κ 0 -1) • δ j } + δ j ) • Len • β.
Proposition 4.4 also implies an expected optimal strategy for spot instances. . To maximize the total workload processed by spot instances, if (κ 0 -1) • δ j ≤ ν(z j , d j ), we can set κ 1 = κ 0 and an expected optimal strategy is to • bid for δ j spot instances at each allocation update of j.

If ν(z j , d j ) < (κ 0 -1) • δ j , in the case that κ 2 (z j , d j ) = κ 3 , we can set κ 1 = κ 2 (z j , d j ) + 1 and an expected optimal strategy is to • bid for δ j spot instances at each of the first κ 1 allocations of j, i.e., o 1 j = • • • = o κ1 j = δ j ; in the case that κ 2 (z j , d j ) < κ 3 , we can set κ 1 = κ 2 (z j , d j ) + 2 and an expected optimal strategy is to

• bid for δ j spot instances at the 1st, • • • , (κ 1 -2)-th, κ 1 -th allocations of j, i.e., o 1 j = • • • = o κ1-2 j = o κ1 j = δ j , • bid for ν(z j , d j ) -κ 2 (z j , d j ) • δ j spot instances at the (κ 1 -1)-th allocation of j, i.e., o κ1-1 j = ν(z j , d j ) - κ 2 (z j , d j ) • δ j .
We illustrate Proposition 4.6 in Fig. 7 where the area of diagonal stripes and the dotted area denote the workload processed respectively by spot and on-demand instances; in the blank area, no workload of j is processed. We assume that β = 1 2 and L = 5 where Len = 12; job j has d j = 42 (3.5 hours), z j = 122 and δ j = 4. Here, we have ν(z j , d j ) = 7 and κ 2 (z j , d j ) = 1. From the left to the right, the first four subfigures illustrate the expected optimal allocation. At the first allocation of j, δ j = 4 spot instances are bid for and the expected execution time of spot instances is β • Len = 6. At the second allocation of j, (ν(z j , d j ) -δ j • κ 2 (z j , d j )) = 3 spot instances are bid for and one on-demand instance is purchased. So far, ν(z j , d j ) = 7 spot instances have been bid for. At the third allocation of j, δ j spot instances are bid for and after the execution of spot instances, j has no flexibility to utilize spot instances and it turns to totally utilize on-demand instances as illustrated by the fourth subfigure. In contrast, we also use the last three subfigures to illustrate an intuitive way to utilize spot instances where δ j instances are bid for at every allocation of j when there is flexibility for spot instances. After the execution of spot instances at the second allocation of j, it has no flexibility and turns to utilize on-demand instances since s 3 j < 1.

As illustrated in Fig. 7, the strategy in Proposition 4.6 can be explained as follows. Whenever possible, bid for the maximum number of spot instances (i.e., δ j instances). An exception happens only at the second allocation of j where little flexibility is remaining, and we need to properly manage the instance allocation to ensure that there still exists flexibility to utilize spot instances at the third allocation of j: then, if δ j spot instances are bid for at the second allocation, it is expected that there will be no flexibility for j to utilize spot instances at the third allocation; by bidding for less, it could be expected that the allocation will not get into the second phase and there will still be the last flexibility/opportunity at the third allocation of j.

Based on Proposition 4.6, we propose Algorithm 1 to dynamically determine the numbers of on-demand and spot instances allocated to j at every i-th allocation update when there is flexibility to utilize spot instances. At every allocation of j that occurs at slot t, the remaining workload of j to be processed could be viewed as a new job with the arrival time t, workload z j , parallelism bound δ j , and relative deadline a j + d j -t; we always use Proposition 4.6 to determine the first allocation of this new job whose arrival time is t. / * At the i-th allocation of j, its remaining workload is viewed as a new job with an arrival time t, and a relative deadline

a j + d j -t * / 1 κ 0 (t) ← aj +dj -t Len / * the case (κ 0 -1) • δ j ≤ ν(z j , d j ) in Proposition 4.6 * / 2 if (κ 0 (t) -1) • δ j ≤ ν(z j , a j + d j -t) then 3 si i j ← δ j , o i j ← 0; 4 else / * both cases κ 2 (z j , d j ) = κ 3 and κ 2 (z j , d j ) < κ 3 where κ 2 (z j , d j ) ≥ 1 * / 5 if κ 2 (z j , a j + d j -t) ≥ 1 then 6 si i j ← δ j , o i j ← 0; / * the case κ 2 (z j , d j ) < κ 3 where κ 2 (z j , d j ) = 0 * / 7 if κ 2 (z j , a j + d j -t) = 0 ∧ ν(z j , a j + d j -t) > 0 then 8 si i j ← ν(z j , a j + d j -t), o i j ← δ j -si i j ; / * the case κ 2 (z j , d j ) = κ 3 = 0 * / 9 if ν(z j , a j + d j -t) = 0 then 10 si i j ← δ j , o i j ← 0;
11 b i j ← b; 12 at the i-th allocation, bid a price b i j for si i j spot instances;

Second phase

As described in Section 3.3.1, once spot instances get lost at every allocation of j, the scheduler uses Definition 3.1 to check the flexibility to utilize spot instances. In the i j -th execution, when spot instances get lost at the beginning of some slot t 1 , there is no such flexibility; then, the instance allocation enters the second phase where only on-demand instances are utilized. Now, we analyze their optimal utilization.

As shown in Algorithm 2, at every allocation of j in the first phase (including the i j -th allocation), the number of on-demand instances allocated to j is either 0 (see lines [START_REF]Amazon EC2 pricing[END_REF][START_REF] Fox | Data intensive applications on clouds[END_REF][START_REF] Wu | Algorithms for scheduling deadlinesensitive malleable tasks[END_REF] or > 0 (see line 8). Let t 2 = a j + i j • Len, d j = a j + d j -1, and we define two parameters that represent the maximum multiple of an hour (containing Len slots) respectively in time intervals [t 1 , d j ] and [t 2 , d j ]:

κ1 = d j -(t 1 -1)
Len

, and κ2 = d j -t 2 +1 Len ; Fig. 8. The second phase of allocation where i = i j : the area of waves denotes the available space in the second phase; the area of diagonal stripes and the dotted area respectively denote the workload processed in the i j -th execution by spot instances and on-demand instances that are utilized for an hour.

Let

t i = d j -κi • Len + 1 (i ∈ {1, 2}
), and after deducting κ1 and κ2 hours respectively from the two intervals, the numbers of remaining slots in [t 1 , t 1 -1] and [t 2 , t 2 -1] are denoted by φ 1 and φ 2 :

φ 1 = t 1 -t 1 , and φ 2 = t 2 -t 2 ,
where 0 ≤ φ 1 , φ 2 < Len. The related notation is also illustrated in Fig. 8. Let

m 0 = si i j • κ1 + o i j • κ2 , m 1 = si i j
, and m 2 = o i j , where i = i j . In Fig. 8, the available space in the second phase is the area of waves and m 0 represents the maximum integer of instance hour that can be utilized by j.

Since every on-demand instance is charged on an hourly basis, a cost-optimal strategy in the second phase is to minimize the integer instance hours (i.e., the number of on-demand instances × the time for which they are utilized). The following conclusion possibly is intuitive although a formal proof is also provided: whenever an instance is purchased for an hour, it should be utilized as long as possible with the space constraint. Proposition 4.7. Let y = y 0 + y 1 + y 2 be the minimum such that y 0

• Len + y 1 • φ 1 + y 2 • φ 2 ≥ z ij +1 j
subject to y 0 , y 1 , y 2 are non-negative integers and

y 0 ∈ [0, m 0 ], y 1 ∈ [0, m 1 ], y 2 ∈ [0, m 2 ].
In the second phase, a cost-optimal strategy is to purchase on-demand instances for y instance hours 3 .

Scheduling Framework

As described above, a general policy is defined by a tuple {β 0 , β, b} and determines the amounts of self-owned, spot, and on-demand instances allocated to a job, and the bid price. The instance allocation process has been described in Section 3.3. Based on this, at every slot t, if a job j just arrives or it has arrived before but not been completed yet, we propose a framework, presented in Algorithm 2, to determine the action of allocating instances to j after checking the state of j. Actions are needed in the following three states: (i) t is the arrival time of j, determining the allocation of self-owned instances, (ii), t equals a j + (i -1) • Len where the i-th allocation update of spot and ondemand instances needs to be done, (iii) the spot instances of j get lost at t where we need to check whether j still has flexibility for spot instances. In Algorithm 2, z j denotes the remaining workload of j to be processed after deducting its current allocations from z j ; upon arrival of j, z j = z j .

3. The specific value of y is given while proving this proposition, which can be found in the appendix.

The Application of Online Learning

Whenever a job j arrives, the instance allocation process at every slot t ∈ [a j , a j +d j -1] is regulated by Algorithm 2 and the specific amounts of various instances allocated to j is determined by β 0 , β, b. To learn the most cost-effective parameters, we apply the online learning algorithm (TOLA) in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF]. We present here its main idea; a formal description can be found in the appendix.

There are a set of jobs J that arrive over time, indexed by j = 1, 2, • • • , and a set of n parametric policies P each specified by {β 0 , β, b} and indexed by π = 1, 2, • • • . Let d = max j∈J {d j }, i.e., the maximum relative deadline of all jobs, and J t ⊆ J denote all jobs j arriving at slot t, i.e., a j = t. There is a weight distribution w over n policies whose initial value is {1/n, • • • , 1/n}. Time goes from slot 1 towards later slots. At every slot t, TOLA randomly picks for a job j ∈ J t a policy π j from P according to the current w and bases the allocation of instances to j on that policy. In the meantime, the distribution w will also be updated at every t > d. At such t, we have the knowledge of spot prices in [t -d, t -1] and can derive the cost of completing a job j ∈ J t-d under every policy π ∈ P; the distribution is updated such that the lowercost (higher-cost) polices of this job are re-assigned the enlarged (resp. reduced) weights. Thus, as time goes by and more and more jobs are processed, the most cost-effective policies of P will be identified gradually, i.e., the ones with the highest weights. When t is large, TOLA will choose the most cost-effective policy for every arriving job and the actual cost of completing all jobs is close to the cost of completing all jobs under a specific policy π * ∈ P that generates the lowest total cost.

Extension to Microsoft Azure Cloud

Above, we are essentially studying the following question. On-demand instances are always available and charged a fixed unit price. The availability of spot instances is uncertain over time; intuitively, it is the probability that a user successfully gets spot instances and we denote by β its average value. There is a fixed number of self-owned instances. The costs of utilizing selfowned, spot and on-demand instances are increasing. Our question is about the cost-effective strategy to utilize these instances. Our intuition is to maximize the utilization of self-owned instances; when they are not adequate for completing a job, we aim to minimize the utilization of costly on-demand while maximizing the utilization of spot instances. The availability β and the job characteristics (deadline, workload, parallelism bound) determine the unique capability of each job j to utilize spot instances, i.e., the maximum workload that could be processed by spot instances. We also give the minimum amount r min j of self-owned instances that each job j needs to complete itself without utilizing any costly on-demand instances. Based on this, related policies are proposed to allocate instances to jobs.

So far, this question has been addressed in the context of Amazon EC2 pricing. On-demand instances are charged on an hourly basis. The price of spot instances (i.e., spot price) fluctuates over time and is updated every 5 minutes. Every user bids a price for spot instances and only if its bid price is not below the current spot price, it could utilize the spot instances for at least 5 minutes. Spot users are charged according to the spot prices. Under such context, the availability of spot instances depends on the bid price of users and the spot prices.

Algorithm 2: Dynalloc(a j , d j , z j , δ j , β 0 , β, b, N, t) Input : the job's current characteristics {a j , d j , z j , δ j } where z j is still > 0, and a parameterized policy {β 0 , β, b} / * allocate instances at the very beginning of slot t * /

1 if a j = t then // upon arrival of j, allocate self-owned instances to it 2 set the value of r j using Equation (4);

3
for t ← a j to a j + d j -1 do 4 r j (t) ← r j ; // otherwise, j still has the flexibility at the next allocation update where z j = z i+1 j Beyond Amazon EC2, Microsoft Azure began to offer lowpriority VMs (virtual machines) since May 2017, as well as highpriority VMs [START_REF]Low-priority VMs in Batch[END_REF]; it is the second largest IaaS service provider and accounts for 13.3% of the global market share in 2017 [START_REF]Gartner Says Worldwide IaaS Public Cloud Services Market Grew 29.5 Percent in 2017[END_REF]. High-and low-priority VMs respectively correspond to ondemand and spot instances only with some difference in pricing. In Microsoft Azure, high-priority VMs are always available and charged a fixed price; also, low-priority VMs have a lower price but their availability varies over time. However, its pricing model simplifies the Amazon EC2 pricing in that (i) high-priority VMs are charged per second instead of on an hourly basis, and (ii) the price of low-priority VMs is fixed but their availability is a system-level random variable, without depending on the bid price of users. So, we can roughly say that users will be billed for the exact period when VMs are utilized, without rounding up partial instance hour to full hour. Now, we explain how to apply the framework of this paper to the Microsoft Azure scenario. Upon arrival of a job j, we can still use the policy (4) proposed in Section 3.3.2 for the allocation of self-owned instances: in the case that they are not adequate, the number of allocated instances is no larger than r min j ; in the opposite case, the number is no smaller than r min j . After allocating self-owned instances, the job j can be viewed as a new job with a reduced parallelism bound δ j -r j . Unlike the case in Amazon EC2, it is not necessary to update the allocation of on-demand instances and bid a price for spot instances every hour. From its arrival on, job j continuously attempts to utilize δ j -r j lowpriority VMs; once there is no flexibility for j to utilize such VMs at some moment, j turns to utilize δ j -r j high-priority VMs until it is completed. In the allocation process above, only one parameter β 0 is needed to control the allocation of self-owned instances; in contrast, there are three parameters {β 0 , β, b} in the case of Amazon EC2. So, when the approach of online learning is applied here, only β 0 is needed to be learned.

5 i ← t-aj Len + 1// used

EVALUATION

The main aim of our evaluations is to show the effectiveness of the proposed policies of this paper.

Simulation Setups

The on-demand price is p = 0.25 per hour. We set L to 5 (minutes) and all jobs have a parallelism bound of 20. Following [START_REF] Chen | Tradeoffs Between Profit and Customer Satisfaction for Service Provisioning in the Cloud[END_REF], [START_REF] Zheng | On the Viability of a Cloud Virtual Service Provider[END_REF], we generate the jobs as follows. The job's arrival is generated according to a poisson distribution with a mean of 2. The size z j of every job j is set to 12 × 20 × x where x follows a bounded Pareto distribution with a shape parameter = 1 1.01 , a scale parameter σ = 1 6.06 and a location parameter µ = 1 6 ; the maximum and minimum value of x is set to 1 and 10. The job's relative deadline is generated as x • z j /δ j , where x is uniformly distributed over [1, x 0 ]. x represents the slackness of a job; it affects the jobs' capability to utilize spot instances as shown by Proposition 4.5, and is a main factor that determines the performance. In this paper, we consider three types of jobs respectively with a small, medium, and large slackness: the 1st, 2nd, 3rd types of jobs respectively with x 0 = 3, 7, 13. Spot prices are updated every time slot and their values can follow an exponential distribution where its mean is set to 0.11 [START_REF] Zheng | How to Bid the Cloud[END_REF]. Proposed Policies. The policies of this paper are parameterized: β and b are used for determine the allocation of spot and on-demand instances (see lines 5-13 of Algorithm 2), and β 0 is for self-owned instances (see lines 1-4 of Algorithm 2). The parameter

β 0 is chosen in C 1 = { i 10 | 0 ≤ i ≤ 6}.
As illustrated in Fig. 5, for jobs with x 0 > 1.25, the amount of self-owned instances allocated to jobs can be effectively controlled by selecting a value ≤ 0.6; for the others with little flexibility to utilize spot instances, they will be a large number of self-owned instances whenever possible to reduce the consumption of on-demand instances. The parameter

β is chosen from C 2 = { i 10 | 0 ≤ i ≤ 9} ∪ {0.9999}. The bid price b is chosen in B = {b i = 0.13 + 0.03 • (i -1) | 1 ≤ i ≤ 6}.
When only spot and on-demand instances are considered, let

P = {(β, b) | β ∈ C 2 , b ∈ B},
representing all policies of this paper to be evaluated; when self-owned instances are also taken into account, let

P = {(β, b, β 0 ) | β 0 ∈ C 1 , β ∈ C 2 , b ∈ B}.
Compared Policies. The policies of this paper are compared with (i) the naive policy (2) for self-owned instances and (ii) the policy proposed in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF] only for spot and on-demand instances (see Algorithm 1 in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF]). The latter randomly selects a parameter θ ∈ Θ = { i 10 | 0 ≤ i ≤ 10} for every job j: (i) the user will bid a price b for θ • δ j spot instances and acquire (1 -θ) • δ j ondemand instances at every allocation update of j; (ii) it monitors at every slot t whether there is a risk of not completing the job by its deadline if only (1 -θ) • δ j on-demand instances are utilized in the remaining slots; (iii) if such risk exists, there is no flexibility for utilizing spot instances and it turns to utilize min δ j , z ij +1 j /Len on-demand instances alone until j is completed 4 . Let P = {(θ, b) | θ ∈ Θ, b ∈ B}, representing all the policies of [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF]. Performance Metric. Let π denote a policy in P or P . Given a set of jobs J that arrive over time, our aim is to minimize the cost of completing all jobs in J ; and a main performance metric is the average unit cost of processing jobs when the x 2 -th type of jobs are processed with x 1 self-owned instances available, i.e.,

• the ratio of the total cost of utilizing various instances to the processed workload of jobs, denoted by α x1,x2 , where α x1,x2 = j∈J c j (π)/ j∈J z j .

When a policy in P or P is applied to process all jobs, we denote by α x1,x2 (π) the corresponding average unit cost of processing jobs. Against the unknown statistics of spot prices and job's characteristics, there are some policies in P or P that are the most cost-effective. We use α x1,x2 (resp. α x1,x2 ) to denote the minimum of the average unit costs of our policies (resp. the policies in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF] and defined by ( 2)), where x 2 = 1, 2, e.g., α x1,x2 = min π∈P {α x1,x2 (π)}.

The performance of the intuitive policy (2) (for self-owned instances) and the existing policy in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF] (for spot and on-demand instances) are used as the baseline to measure the performance of the proposed policies; so, one performance indicator can be as follows:

ρ x1,x2 = 1 - αx 1 ,x 2 α x 1 ,x 2
; it represents the performance improvement of the proposed policies P over the baseline, that is, the ratio in cost reduction. Moreover, in this paper, the online learning algorithm TOLA is run to actually select a policy for each arriving job. The selection is random according to a distribution that will be updated according to the cost of completing that job; after numerous jobs are processed, the policies that generate the lowest cost will be associated with the highest probability. In this case, we use α x1,x2 (P) or α x1,x2 (P ) to denote the average unit cost of processing jobs when P or P is applied to TOLA. When online learning is applied, the performance indicator can be as follows:

ρ x1,x2 = 1 - αx 1 ,x 2 (P)
αx 1 ,x 2 (P ) ; it represents the ratio in cost reduction when online learning is applied.

Results

In the following, we give the results of simulations that are taken over about 60000 jobs, mainly listed in Tables 2, 4, 7, and 8. In our simulations, all fractional solutions will be rounded up to the nearest integers. Experiment 1. We aim to evaluate the effectiveness of the proposed policies P for spot and on-demand instances alone by means of comparisons with the policies P in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF], where x 1 = 0. The simulation results are listed in Table 2 and show a noticeable cost reduction by up to 64.51%. [START_REF] Orna Agmon Ben-Yehuda | Deconstructing Amazon EC2 Spot Instance Pricing[END_REF]. In [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF], the workload of j is measured in instance hours. There are a total of 66 policies in P. In our simulations, every 11 policies are grouped together and they use the same bid price. We have in the same group of policies that the cost-optimal value of β (denoted by β * ) is the same even under different types of jobs; the particular results are illustrated in Table 3. So, in the rest of our simulations, the effective range of β will be defined in {0.5, 0.6, 0.7, 0.8, 0.9, 0.999999}, to which we reset the value of C 2 . Experiment 2. We aim to evaluate the proposed policy for selfowned instances, compared with the naive policy in (2); here, the allocation of spot and on-demand instances will use the same policy P proposed in this paper. The simulation results are listed in Table 4, showing a noticeable cost reduction by up to 43.74%. The utilizations of self-owned instances under different policies are illustrated in Fig. 9, where the dotted lines from top to down respectively represents the case where x 1 = 200, 400, 600 and 800; the particular results are given by the stars on the same dotted line. The allocation of self-owned instances are determined by the policy (4) or [START_REF] Kumar | A Survey on Spot Pricing in Cloud Computing[END_REF]. Given a set of jobs, the utilization of self-owned instances under the policy (4) only depends on the parameter β 0 since their allocation is before and independent of the allocation of spot and on-demand instances. The intuitive policy (2) is a special form of the policy (4) when β 0 = 0. In the case that x 2 = 2, when x 1 = 200, 400, 600, 800, the minimum average unit cost is generated when β = 0.3, 0.2, 0.2, 0.1 respectively; the corresponding utilizations are given in Table 5; the utilization of the intuitive policy ( 2) is illustrated in Table 6. We can see that, given a case of x 1 and x 2 , the proposed policy achieves a lower utilization than the intuitive policy; even so, it still achieves a lower average unit cost as shown in Table 4 where x 2 = 2. This is because the proposed policy could effectively reduce the unnecessary consumption of on-demand instances as explained in Section 4.1.3. Experiment 3. Assume that there are some amount of self-owned instances, and we show the performance improvement of the proposed policies P, compared with the policies that use P for spot and on-demand instances and (2) for self-owned instances. The simulation is done under the 2nd type of jobs that have a medium slackness, and the results are listed in Table 7, showing the improvement of performance by up to 75.68%.

CONCLUDING REMARK

Utilizing IaaS clouds cost-effectively is an important concern for all users. In this paper, we consider the problem of how to utilize different purchase options including spot and on-demand instances, in addition to possibly existing self-owned instances, to minimize the cost of processing all incoming jobs while respecting their response-time targets. Driven by the goal of maximizing the utilization of self-owned instances while optimizing the possibility of utilizing spot instances, we answer two underlying questions in the instance allocation process: to be cost-effective, what properties should be kept in the policy for allocating self-owned instances and what policy can maximize the utilization of spot instances, escaping unnecessary consumption of costly on-demand instances.

As a result, we propose parametric policies for the allocation of these three types of instances that achieve small costs. The proposed policies are adaptive and, facing the dynamic of cloud market, these policies use online learning to infer the optimal values of their parameters. Through numerical simulations, we show the effectiveness of our proposed policies, in particular that they achieve a cost reduction of up to 64.51% when spot and on-demand instances are considered and of up to 43.74% when self-owned instances are considered. In future, we will extend the framework of this paper to process precedence-constrained jobs.

Proof of Proposition 4.6. We can check that when the strategy of utilizing spot instances is as above, o 1 j , • • • , o κ1 j are of the form in Proposition 4.4; hence, it is optimal.

Proof of Proposition 4.7. Let us consider an arbitrary allocation of on-demand instances to process the remaining z ij +1 j workload, denoted by A, also illustrated in Fig. 10 (left). These workload will be processed on δ j instances, and let x h denote the total workload processed at the h-th instance where δj h=1

x h ≥ z ij +1 j , (9)
x 1 , • • • , x m1 ∈ [0, d j -t 1 + 1], x m1+1 , • • • , x δj ∈ [0, d j -t 2 + 1]. (10)
The allocation A can be transformed into an allocation A with the following form without increasing the total cost of utilizing instances: the x h workload of the h-th instance is processed from the deadline d j towards earlier slots, i.e., in [d j -x h +1, d j ], which is illustrated in Fig. 10 (middle). Hence, in the following, we only need to show the cost-optimal strategy of utilizing instances when the allocation is of the form A .

As illustrated in the Fig. 8, let Î1 = [t 1 , d j ] and Î2 = [t 2 , d j ]. From d j towards earlier slots in Î1 (resp. in Î2 ), let every Len slots constitute a time interval, i.e.,

I i = [d j + 1 -i • Len, d j - (i -1) • Len]; for Î1 the last interval is I κ1+1 = [t 1 , t 1 -1] (resp. for Î2 the last is I κ2+1 = [t 2 , t 2 -1]
). Now, we describe the cost structure when the allocation of j is of the form A . We use x h,i to denote the workload processed by the h-th instance in I i where for all h ∈ [1, m 1 ], and for all h ∈ [m 1 + 1, δ j ],

x h,1 , • • • , x h,κ1 ∈ [0, Len], x h,κ1+1 ∈ [0, φ 1 ], (11)
x h,1 , • • • , x h,κ2 ∈ [0, Len], x h,κ2+1 ∈ [0, φ 2 ]. (12)
Let ψ h = x h Len ; under the allocation form of A , we have for all

h ∈ [1, δ j ] that x h,1 = • • • = x h,ψ h -1 = Len, x h,ψ h = x h -(ψ h -1) • Len, the other x h,i = 0, (13)
and

x h = κ1+1 i=1 x h,i , if h ∈ [1, m 1 ] x h = κ2+1 i=1 x h,i , if h ∈ [m 1 + 1, δ j ] (14)
where 0 ≤ x h,ψ h < Len. We define the sign function sgn(x): it equals 1 if x > 0 and 0 if x = 0. Let

y h,i = sgn(x h,i ) ∈ {0, 1}, (15)
and the price of utilizing the h-th instance is p times the sum of all y h,i ; here, by [START_REF] Ferguson | Jockey: Guaranteed Job Latency in Data Parallel Clusters[END_REF], the sum of all y h,i is ψ h . The cost minimization problem under the allocation form of A is as follows, referred to as Q-I:

min m1 h=1 κ1+1 i=1 p • y h,i + δj h=m1+1 κ2+1 i=1 p • y h,i (16)
subject to the constraints ( 9)- [START_REF] Yao | Cutting Your Cloud Computing Cost for Deadline-Constrained Batch Jobs[END_REF]. Q-I corresponds to another optimization problem: its objective function is also [START_REF] Sunilkumar | Resource Management for Infrastructure as a Service (IaaS) in Cloud Computing: A Survey[END_REF], subject to ( 9), ( 10), ( 14), [START_REF] Yao | Cutting Your Cloud Computing Cost for Deadline-Constrained Batch Jobs[END_REF], and for all h ∈ [1, m 1 ]

x h,1 , • • • , x h,κ1 ∈ {0, Len}, x h,κ1+1 ∈ {0, φ 1 }, (17)
and for all h ∈ [m 1 + 1, δ j ],

x h,1 , • • • , x h,κ2 ∈ {0, Len}, x h,κ2+1 ∈ {0, φ 2 }. (18)
The above mathematical problem is referred to as Q-II. In the following, we prove that (i) any solution to Q-I corresponds to a solution to Q-II and their objective function ( 16) under these two solutions achieves the same value; then, (ii) an optimal solution to Q-II corresponds to a solution to Q-I, and their objective function under these two solutions also achieves the same value. The first point shows that the optimal value of Q-II is a lower bound of the optimal value of Q-I. The second point shows that there is a solution to Q-I under which the value of ( 16) equals the optimal value of Q-II; hence, this solution to Q-I is optimal and we will give such an optimal solution while proving the two points above. The decision variables of both Q-I and Q-II are the same, i.e.,

{y h,i |h ∈ [1, m 1 ], i ∈ [1, κ1 + 1]} ∪ {y h,i |h ∈ [m 1 + 1, δ j ], i ∈ [1, κ2 + 1]}.
Given a solution to Q-I denoted by Y , we set the decision variables of Q-II to the same values. Now, we show Y is a feasible solution to Q-II. Both in Q-II and Q-I, the same x h,i is set to non-zero and the others are set to zero by [START_REF] Yao | Cutting Your Cloud Computing Cost for Deadline-Constrained Batch Jobs[END_REF], and the non-zero's x h,i in Q-II is ≥ the x h,i in Q-I by ( 11), ( 12), [START_REF] Hong | Dynamic Server Provisioning to Minimize Cost in an IaaS Cloud[END_REF], and [START_REF] Chaisiri | Optimization of Resource Provisioning Cost in Cloud Computing[END_REF]. Since ( 9) holds in Q-I where the value of x h is defined in ( 14), we have ( 9) also holds in Q-II. Hence, Y is feasible. Furthermore, Q-I and Q-II have the same objective function ( 16) that achieves the same value under the same Y . This finishes proving the first point above. Now, we give an optimal solution to Q-II. The physical meaning of Q-II can be explained as follows. There are 3 types of items each with a weight p: (i) κ1 •m 1 + κ2 •m 2 items each with a size Len, (ii) m 1 items each with a size φ 1 (< Len), and (iii) m 2 items each with a size φ 2 (< Len); the objective is to select some items such that the total size of chosen items is ≥ z ij +1 j (satisfying (9)) while their total weight (i.e., ( 16)) is minimized. Since items have the same weight, an optimal solution is just to select the minimum number of items, e.g., the items with the largest sizes, to exactly satisfy the size requirement; correspondingly, an optimal solution to Q-II is such that the value of y h,i ∈ {0, 1} satisfies

where y 0 , y 1 , y 2 are described in Proposition 4.7. We denote such a solution by OP T 2 . Here, we set x h,i to non-zero if y h,i = 1 and zero otherwise by [START_REF] Yao | Cutting Your Cloud Computing Cost for Deadline-Constrained Batch Jobs[END_REF]; the particular value of x h,i depends on [START_REF] Hong | Dynamic Server Provisioning to Minimize Cost in an IaaS Cloud[END_REF] and [START_REF] Chaisiri | Optimization of Resource Provisioning Cost in Cloud Computing[END_REF], and it determines the value of x h by ( 14) that can satisfy [START_REF] Wu | Algorithms for scheduling deadlinesensitive malleable tasks[END_REF]; by [START_REF] Wang | Optimal Online Multi-Instance Acquisition in IaaS Clouds[END_REF], x h can satisfy [START_REF] Jain | Near-Optimal Scheduling Mechanisms for Deadline-Sensitive Jobs in Large Computing Clusters[END_REF].

Next, we show OP T 2 corresponds to a solution OP T 1 to Q 1 -I, and their objective function ( 16) under OP T 1 and OP T 2 achieves the same value. In Q-I, we set the value of x h to the same value when the solution to Q-II is OP T 2 where the constraints ( 9) and [START_REF] Wu | Algorithms for scheduling deadlinesensitive malleable tasks[END_REF] in Q-I are naturally satisfied; then, we use [START_REF] Ferguson | Jockey: Guaranteed Job Latency in Data Parallel Clusters[END_REF] to obtain feasible x h,i that will also satisfy [START_REF] Loiseau | Greedy and Dynamic Programming Algorithms for Scheduling Deadline-Sensitive Parallel Tasks[END_REF] and [START_REF] Viswanath Nagarajan | Flowflex: Malleable scheduling for flows of mapreduce jobs[END_REF]; by [START_REF] Yao | Cutting Your Cloud Computing Cost for Deadline-Constrained Batch Jobs[END_REF], the value of y h,i in Q-I can be set, deriving a feasible solution OP T 1 to Q-I. In both Q-I and Q-II, we have the number of non-zero's y h,i is x h /Len ; hence, Q-I under OP T 1 and Q-II under OP T 2 achieve the same value. Finally, OP T is an optimal solution to Q-I by the two points above.

So far, we have completed the proof of Proposition 4.7. In the proof, we have given an optimal solution OP T 1 to the problem Q-I; we can thus know the values of y 0 , y 1 , y 2 in (19) that correspond to a specific cost-optimal allocation of on-demand instances. This is also illustrated in Fig. 10 (right).

Algorithm 3: OptiLearning

Input : a set P of n policies, each π parameterized for indexing so that π ∈ {1, 2, • • • , n}; the set J t of jobs that arrive at t; 1 i ← 1; // i is used to track the number of times updating the weight distribution 2 initialize the weight vector of policies: get a job j from J t-d such that j is the smallest;

w i = {w i,1
13 compute the cost of completing j in the period of [a j , a j + d j -1] under every policy π ∈ P, denoted by c j (π); // When t ranges from a j to a j + d j -1, the allocation to j is completed via Dynalloc a j , d j , z j , δ j , β 0 , β, b, N β 0 , t ; the cost is recorded accordingly

APPENDIX B THE ONLINE LEARNING ALGORITHM

In this section, we formally describe the online learning algorithm (TOLA) used in Section 4.4 to learn the most cost-effective parameters β 0 , β, b. The online learning algorithm that we adopt is the one in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF], presented as Algorithm 3, and is also a form of the classic weighted majority algorithm. There are a set of jobs J that arrive sequentially over time, indexed by j = 1, 2, • • • , and a set of n parametric policies P each specified by {β 0 , β, b} and indexed by π = 1, 2, • • • . Let d = max j∈J {d j }, i.e., the maximum relative deadline of all jobs. Let J t ⊆ J denote all jobs j that arrive at time slot t, i.e., a j = t. There is a weight distribution w over n policies; initially, it is a discrete uniform distribution {1/n, • • • , 1/n} (lines 1-2 of Algorithm 3). The distribution w will be updated as time goes by (lines 3, 9-20) and it is used to choose a policy in P for each job (lines 4-8).

Time t goes from slot 1 to later slots (line 3). When a job j ∈ J t arrives where t = a j , the algorithm randomly picks a policy π j from P according to the current w and bases the allocation of various instances to j on that policy (lines 4-8). Let the policy π j be defined by {β (j) 0 , β (j) , b (j) } and let the array N denote the number of self-owned instances unreserved/available at every slot after allocating self-owned instances to the previous jobs 1, • • • , j -1 via the policy (4) with β

(1) 0 , • • • , β (j-1) 0 as the control parameters respectively; initially, if j = 1, we have N (t) = R for all t ∈ [1, T ] where R is the total number of selfowned instances. As time t goes from slot a j towards a j + d j -1, the allocation of instances to j is taken by executing Algorithm 2, i.e., Dynalloc a j , d j , z j , δ j , β (j) 0 , β (j) , b (j) , N, t , at every slot t ∈ [a j , a j + d j -1] until j is allocated enough instances to complete z j workload. As modeled in the Section 3, the cost of completing a job j is from the use of spot and on-demand instances alone, and denoted by c j (π j ).

On the other hand, when time goes to the beginning of slot d + 1, the update of the weight distribution of policies begins (line 9). In particular, if J t-d = ∅, we sequentially consider every job j in J t-d (lines [START_REF] Wu | Algorithms for scheduling deadlinesensitive malleable tasks[END_REF][START_REF] Loiseau | Greedy and Dynamic Programming Algorithms for Scheduling Deadline-Sensitive Parallel Tasks[END_REF][START_REF] Viswanath Nagarajan | Flowflex: Malleable scheduling for flows of mapreduce jobs[END_REF][START_REF] Vintila | Fast (Re-) Configuration of Mixed On-demand and Spot Instance Pools for High-Throughput Computing[END_REF]. Let a virtual array N β0 denote the number of self-owned instances unreserved/available at every slot if the allocation of self-owned instances to the previous jobs 1, • • • , j -1 follows the policy (4) with the same control parameter β 0 ; initially, if j = 1, we have N β0 (t) = R for all t ∈ [1, T ]. For every policy π ∈ P, it is defined by {β 0 , β, b}; since the spot prices in [t-d, t-1] have been revealed, we are able to compute the cost of completing the job j in [a j , a j + d j -1] under the policy π with N β0 recording the available self-owned instances, denoted by c j (π) (line 13). Subsequently, the weight of each policy (i.e., its probability) is updated so that the lower-cost (higher-cost) polices of this job are re-assigned the enlarged (resp. reduced) weights (lines [START_REF] Zafer | Optimal Bids for Spot VMs in a Cloud for Deadline Constrained Jobs[END_REF][START_REF] Yao | Cutting Your Cloud Computing Cost for Deadline-Constrained Batch Jobs[END_REF][START_REF] Sunilkumar | Resource Management for Infrastructure as a Service (IaaS) in Cloud Computing: A Survey[END_REF][START_REF] Hong | Dynamic Server Provisioning to Minimize Cost in an IaaS Cloud[END_REF][START_REF] Chaisiri | Optimization of Resource Provisioning Cost in Cloud Computing[END_REF]. Let N = | ∪ T t=d+1 J t |, i.e., the number of all jobs that arrive in [d + 1, T ], and, as proved in [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF], we have that Proposition B.1. For all δ ∈ (0, 1), it holds with a probability at least 1 -δ over the random of online learning that max π∈P t∈∪ T t=d+1 Jt cj (πj )-cj (π) N ≤ 9 2d log (n/δ) N .

Proposition B.1 says that, as TOLA runs, the actual total cost of completing all jobs is close to the cost of completing all jobs under a policy π * ∈ P that generates the lowest total cost. Recall that a policy is defined by a tuple of parameters from P.

Fig. 1 .

 1 Fig. 1. On-demand price: users are charged on an hourly basis at a fixed price p.

Fig. 2 .

 2 Fig. 2. Spot price: a user bids a price b for an instance at time 0 and can use it until time t.

4 3

 4 hours to satisfy the deadline constraint.

Fig. 3 .

 3 Fig.3. Illustration of the process of allocating instances to j where a j = 1, d j equals 3 hours, L = 5 minutes, z j = 132, and δ j = 4: the light gray (resp. heavy gray) area in every period of[START_REF] Viswanath Nagarajan | Flowflex: Malleable scheduling for flows of mapreduce jobs[END_REF] • (i -1) + 1, 12 • i]illustrates the workload processed by spot (resp. on-demand) instances in the i-th execution where i = 1, 2.

Fig. 4 .

 4 Fig. 4. The Challenge in Cost-Effectively Utilizing Self-owned Instances.

Proposition 4 . 1 .

 41 The function g j (x) in (3) satisfies Property 4.2. Proposition 4.2. The function g j (x) in (3) satisfies Property 4.1.

Fig. 5 .

 5 Fig. 5. As x ranges in [0, 1), the function g j (x) for jobs respectively with different flexibility to utilize spot instances.

Fig. 7 .

 7 Fig. 7. Illustration of Proposition 4.6 in the case that ν(z j , d j ) < (κ 0 -1) • δ j and κ 2 (z j , d j ) < κ 3 .

Proposition 4 . 6 .

 46 Let κ 2 (z j , d j ) = ν(zj ,dj ) δj and κ 3 = ν(zj ,dj ) δj

Algorithm 1 :

 1 Proportion(j, β, b)

Fig. 10 .

 10 Fig. 10. Illustration for Proposition 4.7: the area of diagonal stripes denotes the allocation of on-demand instances to j.

14 η t ← 2 log n d(t-d) ; 15 for π ← 1 to n do 16 w 17 for π ← 1 to n do 18 w 19 i ← i + 1 ; 20 J

 141516171819120 i+1,π ← w i,π exp -ηtc j (π) ; t-d ← J t-d -{j };

TABLE 1

 1 and a j a job of J and its arrival timed jthe relative deadline: j must be completed by a deadline a j + d j -1 z j the job size of j, measured in CPU × time slots δ j the parallelism bound, i.e., the maximum number of instances that can be simultaneously used by j T the number of time slots, i.e., max j∈J {a j }

		Main Notation
	Symbol	Explanation
	p and p 1	the price of respectively using an on-demand and self-owned instance for an hour
	si i j , b i j , and o i j	the number of spot instances bid for, the bid price, and the number of on-demand instances acquired at the i-th allocation of j
	r j (t), si j (t)	the number of self-owned, spot and on-demand
	and o j (t)	instances utilized by j at a slot t
	z i j	the remaining workload of j to be processed at the i-th allocation of j
	j s i	the slackness at the i-th allocation, i.e.,
	β 0	a parameter that control the allocation of self-owned instances via Equation (4)

L length of a time slot (e.g., 5 minutes) Len the number of time slots in an hour, i.e., 60 L J a set of jobs that arrive over time

j (d j -(i -1) • Len) • δ j /z i j i j

the last allocation of j at which j has flexibility to utilize spot instances r j the number of self-owned instances allocated to a job j at every t ∈ [a j , a j + d j -1] β the availability of spot instances varies over time; at every allocation, the expected time for which a job could utilize spot instances is β • Len where β ∈ [0, 1] R the number of self-owned instances N (t) the number of currently idle self-owned instances at a slot t mt 1 (t 2 ) the maximum number of self-owned instances idle at every slot in [t 1 , t 2 ], i.e., min {N (t 1 ), • • • , N (t 2 )} b the bid price {β, β 0 , b} a parameterized policy for allocating various instances to a job at every allocation, as stated in the Section 4.3 P a set of parameterized policies π the index of a policy in P: π = 1, 2, • • • beginning of any slot t, we have the information on the allocation of self-owned instances to the previous jobs (i.e., the number of self-owned instances allocated to each previous job and the period in which these instances are reserved for this job) and we can get the number of self-owned instances that are not reserved for the previous jobs in the period of each slot t , denoted by N (t ). Let m t1 (t 2 ) = min {N (t 1 ), • • • , N (t 2 )}, where t 1 ≤ t 2 , and it represents the maximum number of self-owned instances idle/nonreserved at every slot in [t 1 , t 2

TABLE 2 Performance

 2 Improvements for Spot and On-Demand Instances

	ρ 0,1	ρ 0,2	ρ 0,3
	58.87%	60.84%	64.51%

TABLE 3 The

 3 Optimal β under a Bid Price b

	b	0.13	0.16	0.19	0.22	0.25	0.28
	β	0.7	0.8	0.9	0.9	0.999999	0.999999

TABLE 4 Performance

 4 Improvement for Self-Owned Instances

		ρ 200,x 2	ρ 400,x 2	ρ 600,x 2	ρ 800,x 2
	x 2 = 1	15.73%	21.41%	27.07%	22.83%
	x 2 = 2	27.25%	39.59%	34.04%	17.85%
	x 2 = 3	33.05%	34.41%	43.74%	31.88%

TABLE 5 The

 5 Instance Utilization of the Proposed Policy under Cost-Optimal β 0

	(β 0 , x 1 )	(0.3, 200)	(0.2, 400)	(0.2, 600)	(0.1, 800)
	Utilization	89.89%	92.41%	72.70%	96.39%

TABLE 6 The

 6 Instance Utilization of the Intuitive Policy Fig. 9. The utilization of self-owned instances under different values of β 0 .

	x 1	200	400	600	800
	Utilization	99.73%	99.57%	99.31%	98.89%

TABLE 7 Performance

 7 Improvement for Three Types of Instances Now, we show the performance of the proposed policies when online learning is applied. The simulation setting is the same as Experiment 3. The related results are illustrated in Table8, showing a cost reduction by up to 66.71%.

	ρ 200,2	ρ 400,2	ρ 600,2	ρ 800,2
	71.30%	75.68%	72.83%	66.65%
	Experiment 4.

TABLE 8

 8

	Performance Improvement under Online Learning
	ρ 0,2	ρ 200,2	ρ 400,2	ρ 600,2	ρ 800,2
	60.89%	63.28%	66.71%	63.60%	51.11%

  , • • • , w i,n } = {1/n, • • • , 1/n}; 3 for t ← 1 to T do// time goes from slot 1 towards later slots j from J t such that j is the smallest;7 pick a policy π j = π with a probability w i,π , applied to j; // When time t goes from a j to a j + d j -1, the allocation of instances to j is completed via the Algorithm 2

4 J t ← J t ; 5 while J t = ∅ do 6 get a job 8 J t ← J t -{j}; 9 if t > d then 10 J t-d ← J t-d ; 11 while J t-d = ∅ do 12

ACKNOWLEDGMENTS

The work of Patrick Loiseau was supported by the French National Research Agency (ANR) through the Investissements davenir program (ANR-15-IDEX-02), and by the Alexander von Humboldt Foundation. Part of Xiaohu Wu's work was done when he was with Eurecom, Sophia-Antipolis, France; in addition, his work was also supported by the European Union's Horizon 2020 research and innovation programme in the ROMA project (grant no. 754514). The work of Esa Hyytiä was supported by the Academy of Finland in the FQ4BD project (grant no. 296206).

APPENDIX A PROOFS OF PROPOSITIONS

This section contains the proofs of the propositions in the Section 4.

Proof of Proposition 4.1. Assume that a job j is allocated r j self-owned instances in [a j , a j + d j -1]. At each of the first κ 0 allocations of j, the expected time of utilizing spot instances is β • Len. If a job can be expected to be completed by the deadline by totally utilizing spot instances after the allocation of self-owned instances, we have that (i) it could be expected that the workload processed by self-owned instances plus the workload processed by spot instances at every allocation of j is no less than z j , and (ii) after the allocation of self-owned instances, the allocation of spot and on-demand instances is always in the first phase as described in the Section 3.3, i.e., the allocation is updated every hour where only spot instances are bid for. Now, we analyze two cases. The first one is d j -κ 0 • Len > β •Len. In this case, in the (κ 0 +1)-th execution of j, the expected time of utilizing spot instances is β • Len; then, it is expected that

This leads to that r j ≥ r j (β). The second case is d j -κ 0 • Len ≤ β •Len. In this case, in the (κ 0 +1)-th execution of j, the expected time of utilizing spot instances is min{β

This leads to that r j ≥ r j (β). As a summary of our analysis of both cases, the proposition holds.

Proof of Proposition 4.2. When x ∈ [0, dj Len -κ 0 ), g j (x) = max{r j (x), 0}; since d j • δ j -z j ≥ 0 and (κ 0 + 1) • Len > 0, r j (x) is a non-increasing function and so is g j (x). Similarly, when x ∈ [ dj Len -κ 0 , 1), g j (x) = max{r j (x), 0} is also nonincreasing. In the rest of this proof, if suffices to show g j (x 1 ) ≥ g j (x 2 ) when 0 ≤ x 1 < dj Len -κ 0 ≤ x 2 < 1. Given a job j, if κ 0 = 0, we have g j (x 1 ) ≥ 0 = g j (x 2 ). If κ 0 ≥ 1 and d j • δ j = z j , we have g j (x 1 ) = δ j = g j (x 2 ). If κ 0 ≥ 1 and d j • δ j > z j , our analysis proceeds as follows. To prove g j (x 1 ) ≥ g j (x 2 ), it suffices to show r j (x 2 ) ≤ r j (x 1 ); the function r j (x) itself is non-increasing when x ∈ [0, 1), and we have r j (x 2 ) ≤ r j (x 1 ).

Hence, to prove r j (x 2 ) ≤ r j (x 1 ), it suffices to prove r j (x 1 ) ≤ r j (x 1 ), which can be proved by showing

Finally, the proposition holds.

Proof of Proposition 4.4. Firstly, we prove by contradiction that the optimal value of o κ1 j is 0. Assume that ô1 j , • • • , ôκ1 j are an optimal solution to (8) where ôκ j ≥ 1. The constraint (6) has no effect on the value of o κ1 j . We can reduce the value of ôκ1 j to 0; such reduction can still guarantee that ( 7) is satisfied, and

, o κ1 j = 0 are a feasible solution to [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF] under which (8) achieves a higher value, which contradicts that ô1 j , • • • , ôκ1 j are an optimal solution to [START_REF] Menache | On-demand, Spot, or Both: Dynamic Resource Allocation for Executing Batch Jobs in the Cloud[END_REF]. Secondly, when o κ1 j = 0, the objective function ( 8) equals

are integers, the maximum possible value of

• δ j which leads to κ 0 -1 ≤ κ 1 -1; to satisfy (5), we have κ 1 = κ 0 . Then, constraint [START_REF] Jain | Allocation of Computational Resources with Policy Selection[END_REF] holds trivially and constraint ( 6) is also satisfied. If (κ 0 -1) • δ j > ν(z j , d j ), κ1-1 i=1 (δ j -o i j ) = ν(z j , d j ); in this case, we have κ 1 -1 ≤ κ 0 -1. Furthermore, we also have ν(z j , d j ) + δ j > dj •δj -zj Len•(1-β) and ( 7) is satisfied. Finally, the proposition holds.