HOW SMALL AND MEDIUM ENTERPRISES (SMEs) SHOULD BID FOR SPOT INSTANCES OF AMAZON’S EC2 CLOUD Debashis Saha IIM Calcutta, Joka, Kolkata, India
[email protected]
ABSTRACT In cloud service provisioning, spot instances are spare slots having no pre-booking, unlike reserved or on-demand instances with a priori booking. Cloud service providers prefer spot instance approach to sell “idle” resources. Though they price the spot instances dynamically, usually the spots instances are relatively cheap. For instance, Amazon’s spot instances are an attractive option for IT managers in small and medium enterprises (SMEs) that usually have sporadic requirements for resources. However, the manager has to win spot instances through the auction mechanism conducted by Amazon. Finding how to bid for spot instances for a limited budget is a challenging task. She continues to consume spot instances as long as her bid exceeds the current spot price. But, if she loses at any point, the unfinished task be put on hold by checkpointing mechanism. We find that, at lower bid price, OPTIMAL checkpointing leads to higher total cost than total HOURLY checkpointing cost on higher bid value. So she should bid higher with OPTIMAL checkpointing and lower with HOURLY checkpointing. Keyword: SME, cloud computing, spot instances, spot price, bidding, EC2, simulation.
1
INTRODUCTION Cloud computing is the utility-way of sharing computing resources – similar to the way we consume our utility services (say, electricity, water, etc.) from the corresponding service providers (Gartner report, 2015). However, a major characteristic of cloud computing is that it is Internet-based utility computing, whereby shared resources (like infrastructure, platform, and services) are provided to end-users’ devices on demand via the shared Internet, whereas the other utilities are delivered to our home via separate dedicated distribution channels. Among the multitude of benefits that cloud computing offers, arguably the most promising one is to relieve the organizations of planning, purchasing, and maintaining in-house computing facilities, and converts their large fixed costs (CapEx) into much smaller variable costs (OpEx). Nearly 24% of the companies now have adopted “cloud-first” policy1. There are mainly two types of clouds: private and public. In case of public cloud, users (such as individuals, institutions, companies and business houses) purchase just-as-much-required resources, on pay-as-you-go basis, from remote servers hosted by cloud service providers (CSPs), such as Amazon Web Services (AWS), through some form of contract or service level agreement (SLA) (Andrzejak, A. Kondo, D. & Songho, Y. 2010). The CSPs build, own, operate and manage these servers at their premises; thus, companies can store data in Google’s cloud (https://cloud.google.com/) or in AWS (http://aws.amazon.com) using its simple storage services (S3). Next, they can use Amazon’s Elastic Compute Cloud (EC2) (http://aws.amazon.com/ec2/) to perform necessary computations on those data and then again store the results in any of the cloud storages. On the other hand, in case of private cloud, organizations create cloud-like environment inside their premises so that various business units (BUs) use that private cloud infrastructure as common shared services over the organization’s intranet/extranet. Usually, the IT department, with the help from 3rd parties, maintains the internal private cloud for the organization. As reported in the literature (Foster, I. Zhao, Y. Raicu, I. & Lu S., 2008), there are several advantages of transferring resources from thin client devices to cloud, which may be as thick as possible. Thus, the key attractions of cloud computing (either commercial grade public clouds or enterprise-owned private clouds) are twofold: (i) it is shared, dynamically-configured and market-driven, and (ii) everything in it is provided as a service (XaaS) (Foster, I. Zhao, Y. Raicu, I. & Lu S., 2008). Naturally, Small and Medium Enterprises (SMEs) are turning to cloud computing in order to eliminate their non-core IT-related activities, thereby allowing them to focus more on their core competence and high impact making strategic activities. Software as a Service (SaaS) is the most common usage for cloud, and CSPs usually charge SaaS on a fixed price basis per month or per year. Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) follow, however, variable pricing models. Cloud users in this case have to deal with several different structures. At the core they have to rent a virtual machine (VM) first. Then they need storage. To calculate storage, the CSPs charge a per-GB price. Since PaaS and IaaS Solutions consume network and Internet traffic too, the users also get charged on incoming and outgoing bandwidth. Here also, the chargeability is based on a per-GB fee. The CSPs offer on rent their VMs called instances. Each Instance runs for a certain number of hours, called Compute Hours. Often CSPs lease out the instances at a fixed price, such as Amazon EC2 Small Instance (Shao, J. T. Yuan, J. & Li, X-Y. 2012), 1
http://news.verizonenterprise.com/2015/08/2015-hbr-info-cloud-report/ 2
and Windows Azure Small Compute Instance (Andrzejak, A. Kondo, D. & Anderson, D. P. 2010). They also have a dynamically configured price-conscious model with a market-driven mechanism in-built. For example, Amazon EC2 provides three primary models to purchase their instances: (i) On-Demand, (ii) Reserved, and (iii) Spot (Shao, J. T. Yuan, J. & Li, X-Y. 2012). The models follow different pricing mechanisms and accordingly guarantee three levels of assurance regarding when instances can be launched and terminated. Spot instances, unlike reserved or on-demand instances, are spare slots (or, unused capacity) of VMs for which the CSP has no pre-booking or reservation. Spot instances are typically ideal for flexible tasks, which do not have any stringent constraint on deadline, and also for those unscheduled jobs which pop up suddenly in enterprises. The price for a spot instance changes dynamically based on supply-demand logic and/or some other complex logic followed by CSPs (Macias, M. & Gitart, J. 2011; Tsai, C-W. & Tsai, Z. 2012; Ben-Yehuda, O. A. Ben-Yehuda, M. Schuster A. & Tsafrir, D. 2011). Being relatively cheap, spot instances are an attractive option for small and medium enterprises (SMEs) with non-uniform requirements for cloud based resources. Interestingly, AWS supports a minimum probability of task completion, under the given budget constraints, known as confidence level, which tells about SME’s desired surety of meeting its monetary constraints. SMEs with no hard requirements and/or long running jobs can bid for the spot instances by placing their own prices. Customers, whose bids exceed the spot price, gain access to the available spot instances. If we assume that proxy bidding (Ebay website, 2015) is used by SMEs, a mechanism to evaluate the correct bid amount for any spot instance becomes absolutely necessary. Thus, guessing the correct bid and finding an appropriate bidding strategy, subject to both time and money constraints imposed SMEs, is worth investigating. Since the bidding is done for previously used resources, past experience with the resources becomes very crucial and can be used as a base to find an effective bidding strategy. Using simulations, we have tried to identify which checkpoint strategy (Gong, Y. Zhou, A. C. & He, B. 2014) is suitable for SMEs when they are vying for spot instances. We showcase our approach with simulated Amazon EC2 clients bidding for a spot instance. Furthermore, some interesting observations on the relationship among checkpointing strategy, task reliability and completion time as to bid price dynamics are also elaborated. LITERATURE REVIEW Since cloud computing model follows closely the power utility model, many of the bidding strategies prescribed for the electricity market (Steeger, G. Barroso, L.A. & Rebennack, S. 2014) are applicable to the cloud market too which, however, is yet to mature like other age-old utility markets. Nonetheless, the published literature in the area of cloud computing abounds in the research to come up with a model which would provide a cloud user with a bidding strategy and would satisfy her requirement of cost reduction and time minimization (Tang, S., Yuan, J., Wang, C., Li, X-Y., 2014). Though many of these works talk about bidding strategy in general, very few have tried to classify the strategies with respect to the types of client enterprises, namely small, medium and large. To the best of our knowledge, no paper has addressed the issue for SMEs in specific, keeping in mind the unique requirements of such enterprises. This motivated us to take up this assignment in our present research. Related works (Andrzejak, A. Kondo, D. & Songho, Y. 2010; Tang, S., Yuan, J., Wang, C., Li, X-Y., 2014) discuss two checkpointing strategies, namely hourly and optimal. In hourly case, a checkpoint is set at the boundary of each paid hour of spot 3
instance. This lessens ambiguity on the number of hours required to complete a task. It is not affected by the distribution of in-bid or out-bid hours. For example, given a task that requires 6 hours for completion, checkpointing time of 15 minutes would require total 8 hours of in-bid options. On the other hand, in optimal checkpointing, a checkpoint is taken before every failure. This adds a lot of ambiguity to the total execution time. For instance, in the 6 hour-long job example cited above, it might just take 6 hours in the best scenario but it can go up to 12 hours if none of the in-bid hours happen in continuity (considering 15 minutes of checkpoint and 15 minutes of restart time). The optimal checkpointing seems to be better considering that it doesn’t store unnecessary checkpoints. But, from a practical standpoint, hourly checkpointing is more common because, for a particular task, there is more clarity in terms of time required which remains constant irrespective of other factors. Also, it adds consistency to task being operated on various instances simultaneously. So the authors recommend hourly checkpointing in general. But our question here is: is it suitable for SMEs too? The paper by Shao, Yuan & Li (Shao, J. T. Yuan, J. & Li, X-Y. 2012) discusses that, along with monetary constraints, a user is also concerned about reliability of the resources that she is using. This essentially means constraint on the amount of time that an SME would require completing its task and the trade-off between monetary costs and reliability features. The paper also discusses how a user effectively implements optimal checkpointing strategy by adding a checkpoint every time the next bid goes out-bid for her. This reduces effective work time of last hour by the checkpointing time. If the next time the instance is in-bid, a restart time is allocated and hence subtracted from effective working time. From this paper, we can conclude that, for an SME, OPTIMAL checkpointing strategy is better than the more practical HOURLY strategy in terms of both monetary cost and execution reliability. Next comes the question: what should be the ideal bid price in this case? The work in (Andrzejak, A. Kondo, D. & Anderson, D. P. 2010) has provided information on user’s bidding criteria but missed on the information about the kind of spot prices that may be expected on the various types of Amazon EC2 spot instances. We argue that an SME can use either statistical models available for EC2 spot prices (Javadi, B. Thulasiram, R. K. & Buyya, R. 2011) or deconstructed pricing mechanism of EC2 (Ben-Yehuda, O. A. Ben-Yehuda, M. Schuster A. & Tsafrir, D. 2011), along with its own past records, to identify its future bidding strategy even without having a clear indication of what might be the future spot prices. Interestingly, none of the above papers has considered confidence level which is again an important criterion for SMEs. So we have identified, along with checkpointing strategy, confidence level as another main parameter for modelling our case with SMEs. The SME needs to decide its checkpointing strategy and also mention the confidence level before starting to bid for the spot instances. BACKGROUND ON AMAZON EC2 INSTANCES Amazon Elastic Compute Cloud (Amazon EC2) provides resizable compute capacity in the cloud so as to help enterprises obtain and configure capacity with minimal friction. EC2 reduces the time required by its clients to obtain and boot new server instances (i.e., virtual machines (VMs) on rent) to minutes, allowing them to quickly scale capacity, both up and down, as computing requirements change. In Amazon EC2, if one pays an annual fee, she can launch one reserved instance whenever she wishes in that year. Thus, reserved instances provide the option to lease instances if the requirement is almost constant throughout the year. This entails in a significant 4
discount on the hourly charge for that instance. There are three types of reserved instances (Light, Medium, and Heavy Utilization Reserved Instances) that enable balancing upfront price with effective hourly price. This instance is typically designed for the fixed requirements of the very large organizations for their regular day-to-day tasks. Medium-sized clients may instead choose to forgo the annual fee and attempt to purchase an on-demand instance as and when they need it, at a higher hourly fee and with no guarantee that launching will be possible at any given time. On-demand instances let them pay for compute capacity per usage hour with no upfront cost commitments. These instances are also used by large organizations which experience varying demand for resources. Such organizations generally use reserved instances and request for top up in the form of on-demand instances when there is additional demand. Both reserved and on-demand instances remain active until terminated by the client. But none of these instances are suitable to SMEs for obvious reasons. Spot instances, on the contrary, is the cheapest because it ensures no guarantee on either launch or termination time. Users place a request for a particular spot instance by bidding the maximum hourly price they are willing to pay for running it. If the bid is higher than the spot price, the request is granted; otherwise it waits. Periodically, Amazon publishes a new spot price and launches all waiting instance requests having the maximum bid exceeding this value; the instances runs until clients terminate them or the spot price increases above their maximum bid. EC2 spot instances perform exactly like other Amazon EC2 instances while running. They only differ in their pricing model and the possibility of being interrupted when the spot price exceeds your max bid. SMEs will never pay more than their maximum bid price per hour. If spot instance is interrupted by Amazon EC2, the SME is not charged for any partial hour of usage. But, if the instance is terminated by the SME, it will pay for any partial hour of usage. However, the SME should always be prepared for the possibility that the spot instance might be interrupted. A high max bid price may reduce the probability that the spot instance will be interrupted, but cannot prevent interruption. If the spot price exceeds the max bid or there is no longer spare EC2 capacity in a given Spot pool, instances will be terminated. Spot instances are very much beneficial for small enterprises. These enterprises have to constrain themselves within a specified budget. For them, cost is more important than the number of hours required for procuring the spot instances. Medium enterprises have to perform a cost-benefit analysis so as to what is more important for them- the cost which increases as the number of hours increases or the time in which they want to get the desired number of instances. Based on this, they take their decisions. The large enterprises mainly use reserved instances instead of spot instances as they are more concerned about getting the instances in time as compared to higher cost that it would require. Amazon EC2 spot instances are currently organized into 8 regions: US East (North Virginia), US West (Oregon), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), and South America (Sao Paulo). An instance is rented within a geographical region. To assist the user in bidding for the spot instances, history of spot prices on each instance in these regions is available on Amazon website. For example, at a given moment, the prices for US East (North Virginia) are shown in Table 1. EC2 instances are of named as “x.y” where x indicates level such as standard (m1), high memory (m2), and high CPU (c1), and y indicates size, like small, medium, large, etc. For example, m1.small and m1.large denote small, and large “standard” instances, respectively; m2.xlarge, m2.2xlarge, and m2.4xlarge denote extra large, double extra large, and quadruple 5
extra large “high memory” instances, respectively; c1.medium and c1.xlarge denote medium and extra-large “high CPU” instances, respectively. Table 1: Spot Prices at a given instance (accessed from website)
The use of spot instance in purchasing and consuming cloud service is the first step towards “market pricing” for computing resources based on supply and demand. The spot price changes periodically based on supply and demand and customers whose bids exceed the spot price gain access to the available spot instances. Spot Instances are generally cheaper than on demand instances but higher than reserved option. The registration fee required in case of reserved instances makes it costlier in terms of overall cost. Spot instances are used for tasks which do not have a steep completion deadline and are required for certain sudden tasks which do not need reserved instances. That is why SMEs love it. All running spot instances incur a uniform hourly charge, which is the current spot price. The charge is in full hours, unless the 6
instance was terminated due to a spot price change, in which case the last fraction of an hour is free of charge. In this work, we assume that instances with bids equal to the spot price are treated similarly to instances with bids higher than the spot price. Thus, we observe that while reserved instances follow a hybrid pricing model (i.e., you pay a certain amount upfront and your hourly fee gets reduced), spot instances follow a flexible pricing. MODELING AND STRATEGY FORMULATION As discussed earlier, we assume that the prices of Amazon EC2 spot instances are dependent on the supply and demand at that particular instance. We further assume that it follows the conventional conventional supply-demand logic of microeconomics, where supply and demand constitutes an economic model of price determination in a market. However, it is to be noted that, unlike in a normal production model of resources where the supply varies with the price, in case of spot instances demand does not influence the supply but only the price. Therefore, for a given quantity of spot instances Q, when the demand is low (say D1), the spot prices (P1) are lower because less numbers of users are bidding for the same instance. Therefore, a bidder’s probability of incurring less monetary cost is higher. On the other hand, when the demand is high (say D2), users are willing to pay higher to get access to the spot instance and hence the spot prices (P2) go up and the bidder’s net monetary involvement goes up (Figure 1). It is worth mentioning here that the actual graphs in real life may not be so regular as shown in Figure 1; nevertheless we may consider it in our model because the curves may tend to smoothen over a long period of observation when competition turns the market towards equilibrium.
Figure 1. Price variation of Spot Instances (D2>D1; P2>P1) There are a number of bidding strategies (Ebay website, 2015), used by bidders in online auctions, such as bid sniping, proxy bidding, buy it now, low ball bidding and bid nibbling. Bid sniping involves placing a bid as late as possible within the auction closing time, typically within the last few minutes or seconds of an auction. The underlying ideology is that your bid will go unnoticed, and competing bidders will not have a chance to reciprocate and bid higher as there is not much time left. Proxy bidding means placing highest bid upfront (the highest amount you are willing to pay), and bid will automatically increase up to the highest amount specified. If one is outbid at any time, another higher bid can be inserted later on. Buy-it-now strategy involves 7
eliminating bidding and looking only for items offered with ‘Buy it Now’ prices in price range. It is based upon a price predetermined by a seller. The sale in such cases is immediate whenever a buyer is ready to pay the price listed by seller. Low-ball bidding is suitable for those bidders who have high hopes of winning high-ticket items at ridiculously low prices. Many sellers often start the opening bid at values under $9.99 in order to pay lower listing fees. Some buyers are misled and think they can purchase the item at this price. Thus, these buyers scour the site for all the expensive items with low opening bids and right away place the first opening bid at the lowest price possible. These buyers will do this repeatedly to have as many as 100 or more low-ball bids on items simultaneously. Bid nibbling involves occasionally or gradually placing bids on a single item, attempting to be the winning bidder the majority of the time. The bid is just enough to outbid the current winning bidder and not the highest price. In case of spot instances in cloud computing, the most common bidding strategy used is “Proxy Bidding” where different users tell their bid value in advance (Shao, J. T. Yuan, J. & Li, X-Y. 2012; Tsai,C-W. & Tsai, Z. 2012). We shall also follow proxy bidding in this work for the SME users who can broadly be of two types: Experienced user For an experienced SME, the bidding strategy decision depends not only on Amazon spot price data (Ben-Yehuda, O. A. Ben-Yehuda, M. Schuster A. & Tsafrir, D. 2011) but also on its past experience with the website. This means that it has a history of how many times in the past it had bid different bid values for the same type of spot instances. It also has information on how much time and monetary cost was incurred to complete a given length of task. Both things together can be used by an experienced SME to decide its future bidding strategy. Table 2: Spot Price Statistics
New or Novice user On the other hand, typically, a new SME user accessing Amazon EC2 spot instances for the first time does not have access to any past record to support it in deciding its bidding strategy. For such a user, the past spot price data available on its Amazon Web Services account or the model proposed in (Javadi, B. Thulasiram, R. K. & Buyya, R. 2011) is the only source of information to be used. The mean and variance of various spot instances vary on the basis of processing speed provided and the current demand scenario (Gong, Y. Zhou, A. C. & He, B. 2014). Table 2 (taken from Javadi, B. Thulasiram, R. K. & Buyya, R. 2011) shows one sample finding. In fact, we can go to Amazon site2 and find out the pricing history for Spot instances during 2
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances-history.html 8
any time interval of our choice. Figure 2 shows some traces obtained for EU-west zone. The Y-axis indicates US Dollar prices and X-axis time elapsed. The price remains fixed for a certain interval and then changes. We have noticed that the ratios between the median and mean for spot prices are close to 1 for different traces (Figure 2) indicating that Gaussian distribution is a good option to model Amazon EC2 spot prices. The skewness and kurtosis values of these distributions show that the underlying distributions are right-skewed and short-tailed. We know that normal distribution is a much simpler special case of Gaussian distribution with zero mean and unit variance. In this work, we consider normal distribution for the sake of simplicity. However, the reader may try with pure Gaussian distribution too.
Figure 2. Price distribution for different spot instances in EU-west (X-axis denotes time of day; Y-axis denotes price in USD)
Since cloud is a relatively new concept, we assume that SMEs will also be new to spot instances. So we categorize them as novice users in this model. Next, we implement all possible strategies with novice users to compare and evaluate the strategies in terms of various parameters discussed in the previous sections, such as cost, time, money, reliability, and confidence level. We have developed a MATLAB model (Figure 3) to perform the task of giving an optimal bidding strategy to the user and then evaluating that strategy. The model has three modules for a full execution cycle. The module I simulates past data in order to create a knowledge base for the novice user. Based on the analytics of those data, module II selects an appropriate strategy and implements it. Finally, module III gathers simulation results and evaluates the strengths and weaknesses of the strategy used in module II. We run the 9
complete model several times to collect all possible data and then conclude for the SME which would be the best strategy.
Figure 3. MATLAB model
Assumptions in the model (1) Spot instance price follows a normal distribution pattern (note: normal distribution is a special case of Gaussian distribution). Though it depends on the demand and supply of a particular spot instance, past data has shown that this usually results in a Gaussian/normal distribution (Javadi, B. Thulasiram, R. K. & Buyya, R. 2011). (2) The model has been designed on single instance requirement basis. While it can be argued that for a real task scenario more than one instance would be required, it can also be safely assumed that all instances of the same type would be affected by the same supply-demand constraints at any given time. (3) The task length is assumed to be fixed at 6 hours in all the simulations. It may vary from 1 hour to 6 hours. So, in real time, the bidder can either change it or use multiple of this result for the overall task. In order to make our problem simpler, we could have chosen the small tasks of length 1 hour only. In that case, checkpointing would be less in number. But, in real life, workloads will be much longer, say 15 hrs. Then, we need to break it into chunks of 6 hours. Module I: Algorithm to generate simulation of past data (Figure 4)
First of all, this module generates a pseudorandom set of data points which follow a normal distribution pattern and are similar in pattern to the distribution of spot prices of Amazon EC2 instances. Along with this, an algorithm runs parallel to this, which generates data on amount of time and money that would be required to complete the given task. This process is repeated for various user-entered bid prices. Similar algorithm is run for both checkpointing strategies – hourly (HOURLY) and optimal (OPTIMAL) (Shao, J. T. Yuan, J. & Li, X-Y. 2012). This also provides a comparison basis for performance of both checkpoint strategies on both time and money parameters.
10
Figure 4. Flow diagram for Module I
11
Figure 5. Flow Diagram for Module II Module II: Algorithm to give future bidding strategy (Figure 5)
This module uses results of the module I to provide an SME user with an optimal bid for the next hour. Here, the result of the first round are simulation result; in reality, the bid data available on Amazon web services portal can be a pointer as to what is the expected bid range for any particular instance. The SME will use this data to get its optimum bid. In a typical scenario, when an SME wants to know its future bidding strategy, it is prompted to tell its desired parameters like confidence level, checkpointing strategy, maximum time or money it is willing to spend. In most real world scenarios, the bidder is constrained either by money or by time. So, based on his desired confidence level and the maximum bidding time or maximum monetary cost of performing the task, it will be provided with the desired bid value.
12
Figure 6. Flow Diagram for Module III Module III: Evaluation of bidding strategy in achieving user goals (Figure 6)
This module is run to see the performance of the model in real time scenario. After getting the optimal bid value from the second module, if the user bids the same amount, this model tests whether its task is completed within the given constraints.
13
SIMULATION RESULTS The simulation results were generated for different input combinations. The system settings for the simulation are: MATLAB Version 7.6.0.324 (R2008a) running on Windows 7 desktop with Intel Core i3 processor with 2.10 GHz speed and 4 GB RAM. Task length is assumed to be of 6 hours. The results are for c1.medium instance from EU-West data center with spot price mean of 8 cents and standard deviation of 0.27 cents. User inputs (Figure 7) include (1) Checkpointing Strategy – HOURLY or OPTIMAL, (2) Confidence level, (3) Maximum monetary Cost, (4) Maximum bidding time, and (5) User Bid Amount.
Figure 7. Snapshot of command window For an SME user with HOURLY checkpointing strategy and a bid of 8.04 cents, a typical bid scenario is shown in Figure 8. The user is in bid for 6 hours of 13 that it bids for. Total monetary cost is 47 cents. With a bid of 8.04 cents, the SME’s maximum willingness to pay was 48.24 cents. It is able to achieve its task in less monetary cost than the maximum. As a user bids higher amount his total time for bidding decreases as the probability of getting spot instance in each bid increases (Figure 8). Overall this algorithm gives better performance in terms of in-bid time when compared to previously published results. For a user bid of 7.6 cents, his minimum expectation is reduced from 100+ hours to 25 hours. The maximum expectation also reduces from 400 hours to 270 hours which is a significant improvement in reliability terms. If we compare the performance of this algorithm on cost parameter (Figure 9), there is a certain dip in the performance level implying that cost is slightly higher than the earlier algorithms but is compensated by the fact that total time of execution is much less.
14
Figure 8. Illustration of results for a user When we compare both the checkpointing strategies, it is observed that the time taken in both strategies effectively remains similar but the costs follow a slightly different pattern. In case of hourly checkpointing strategy, the cost is more for high bid values. On the other hand, in optimal checkpointing strategy, if the user puts a low bid, his probability of winning continuous instance hours decreases and hence checkpointing overhead increases. This leads to an overall increase in the monetary cost of task. The simulation results (Figure 10) reveals that, at a lower bid price OPTIMAL checkpointing leads to a total cost higher than the total HOURLY checkpointing cost on a much higher bid value. Therefore, it is better to go for higher bid prices when using OPTIMAL checkpointing and lower bid with HOURLY checkpointing.
15
Figure 9. Total execution time in our model is less than previous results (while cost is higher)
Figure 10. Cost distribution for two checkpointing strategies
16
CONCLUSION Historically speaking, Amazon began with their On-Demand pricing model in 2006, and then, in 2009, added Spot instances and Reserved Instances (RI) which was later on differentiated into three different options in 2014 (Figure 11). This year they have spawned two new options, namely Spot Fleet and Spot Block, from classical Spot instance model. Though Amazon has been continuously refining its instance categories, spot instances remain one of their popular options. Spot instances are spare Amazon EC2 instances for which the potential user can name her own price. Spot instances allow customers to bid on unused Amazon EC2 capacity and run those instances for as long as their bid exceeds the current Spot Price. Spot instances are particularly suitable for the SMEs for their deadline-agnostic applications that can checkpoint (i.e., create a restore point) when interrupted and can resume afterwards at a favourable point in time. Our objective is to come up with a framework that can be useful for SME users in bidding for a spot instance in Amazon EC2. Based on our model, developed for bidding by SME users, we conclude that (a) SMEs should follow optimal checkpointing strategy, and (b) should increase their bid value to increase probability of winning (and hence increase reliability) thereby lowering their overall monetary outflow. Bidding low prices reduces the monetary cost by a small value but the execution time goes up by high value. Therefore, total effective investment goes up. We hope that our study will help the managers in SMEs take informed decisions while going for spot instances in public clouds. On-demand instances (2006) Reserved
Spot instances
instances
(2009)
(2009) No upfront RI
Partial upfront
Full upfront RI
Spot fleet
Spot block
(2014)
RI (2014)
(2014)
(2015)
(2015)
Figure 11. Temporal evolution of pricing models of Amazon (RI: reserved instances)3
The possible future directions of this work include extending and fine-tuning the proposed framework for ‘Spot fleet’ and ‘Spot block’. For instance, Spot block is suitable for ‘defined-duration’ jobs which might require that Spot instances that will run continuously for a finite duration (say, 1 to 6 hours). Since price of Spot blocks are different from that of Spot instances, it would be an interesting task to formulate a bidding strategy that fits Spot block of size k (1≤ k ≤6).
3
https://aws.amazon.com/blogs/aws/category/amazon-ec2/ 17
ACKNOWLEDGEMENT The author is grateful to graduate students Shruti Srivastava and Garvita Gupta for their immense effort and support in conducting this research and running the simulation on MATLAB.
REFERENCES Andrzejak, A. Kondo, D. & Songho, Y. 2010. Decision Model for Cloud Computing under SLA Constraints, 18th Annual IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication System, 2010. Andrzejak, A. Kondo, D. & Anderson, D. P. 2010. Exploiting Non-Dedicated Resources for Cloud Computing, IEEE Network Operations and Management Symposium, NOMS 2010. Ben-Yehuda, O. A. Ben-Yehuda, M. Schuster A. & Tsafrir, D. 2011. Deconstructing Amazon EC2 Spot Instance Pricing, 2011 IEEE Third International Conference on Cloud Computing Technology and Science (CloudCom), 2011, pp. 304 – 311, Athens. Cloudvane website, 2015. Pricing Models for Cloud Computing http://cloudvane.com/2012/08/23/pricing-models-for-cloud-computing/ Ebay website, 2015. Bidding Strategies: Tips for Successfully Winning Items, http://reviews.ebay.com/Bidding-Strategies-Tips-for-Successfully-Winning-Ite ms?ugid=10000000004396516 Foster, I. Zhao, Y. Raicu, I. & Lu S., 2008. Cloud Computing and Grid Computing 360-Degree Compared, Proc. IEEE Grid Computing Environments Workshop, pp. 1-10, 2008. Gartner report, 2015. http://www.gartner.com/technology/topics/cloud-computing.jsp Gong, Y. Zhou, A. C. & He, B. 2014. Monetary cost optimizations for hpc applications on amazon clouds: Checkpoints and replicated execution. Technical Report 2014-TR-120, NTU, http://pdcc.ntu.edu.sg/xtra/tr/2014TR-120-SOMPI.pdf, 2014. Javadi, B. Thulasiram, R. K. & Buyya, R. 2011. Statistical Modeling of Spot Instance Prices in Public Cloud Environments, Fourth IEEE International Conference on Utility and Cloud Computing, 2011. Macias, M. & Gitart, J. 2011. A Genetic Model for Pricing in Cloud Computing Markets, Proc. ACM 26th Symposium on Applied Computing (SAC’2011), special track on Cloud Computing, TaiChung, Taiwan, 2011. Shao, J. T. Yuan, J. & Li, X-Y. 2012. Towards Optimal Bidding Strategy for Amazon EC2 Cloud Spot Instance, IEEE 5th International Conference on Cloud Computing, 2012. Steeger, G. Barroso, L.A. & Rebennack, S. 2014. Optimal Bidding Strategies for Hydro-Electric Producers: A Literature Survey, IEEE Transactions on Power Systems, 29( 4), 1758 – 1766. Tang, S., Yuan, J., Wang, C., Li, X-Y., 2014. A Framework for Amazon EC2 Bidding Strategy under SLA Constraints. IEEE Transactions on Parallel and Distributed Systems, 25(1), 2-11. Tsai, C-W. & Tsai, Z. 2012. Bid-Proportional Auction for Resource Allocation in Capacity-constrained Clouds, Proc. IEEE 26th International Conference on Advanced Information Networking and Applications Workshops, pp. 1178-1183, 2012. 18
