Thesis Document Finished

After a week of fun and networking in northern California earlier this month, where I attended Google IO, I came back with renewed energy to finish the writing process on my thesis document. I'm proud to present it here:

Recent EC2 related events and thesis update

I continue writing my thesis document, chapter 4 is finally taking form and will be finished this week. Then I first need to make a couple of additions and changes to my broker prototype, before I can start writing my final 5th chapter that handles about the evaluation of the performance (in terms of the achieved cost reduction) of my proposed broker. Will try my best to finish a draft before next Friday (May 6th) when I leave for San Fransisco to attend the Google IO conference.

Recently a couple of interesting EC2 related events happened.

With headlines as "Amazon Gets A Black Eye In The Cloud With Server Crash", "Amazon outage casts a cloud over cloud computing?", "Amazon’s EC2 Outage Proves Cloud Failure Recovery is a Myth!" and "Lessons From a Cloud Failure: It’s Not Amazon, It’s You". They all refer to the failures that began Thursday morning (US time) as the Amazon Cloud Crash. These failures were caused because of RDS databases that started to backup theirselves and connectivity problems in multiple availability zones in the US-East region. Popular websites such as Quara, Reddit, GroupMe and FourSquare were affected and weren't reachable for hours. Customers should foresee failure scenarios and do not rely on instances of single cloud provider in a single regions ... as always a single point of failure should be avoided. That's why AWS explicitly advises their developers to design their site’s architecture so that it is resilient to occasional failures and outages. This event brought cloud computing in the picture rather negatively, today the AWS website or AWS blog do not contain any articles telling their users what caused the outages. During the outages there was however a little update every hour or so on the AWS Health Dashboard, we see there that the recovery to bring everything back to normal took about 4 days.
Note: on Rightscale a good blogpost was found about the EC2 US-East outage.

On a different note on April 22th, AWS posted the public IP ranges used by the different geographical EC2 regions, accompanied by this introduction:

We are pleased to announce that as part of our ongoing expansion, we have added a new public IP range (APAC-Tokyo).

These IP ranges can be found here. They can be seen as an indication of the size of the different EC2 regions, it's interesting to have a look at how these number of IP addresses relate to each other:

From this data we see that more than half of all the public IP addresses provided by Amazon EC2 are situated in the US-East region, it is followed by EU-West and US-West who account for about 15 percent of the IP addresses. The Asian regions only represent less than 10 percent of the IP addresses, but these regions are the newest introduced regions and are possibly growing faster than the other regions.

Decision Model for Cloud Computing under SLA Constraints

Today I had a look at the software that comes with the "Decision Model for Cloud Computing under SLA Constraints" paper by Andrzejak A., Kondo D. and Yi S. The implementation of the presented model can be found on the project website.

The paper describes its contribution as follows:

Our main contribution is a probabilistic model that can
be used to answer the question of how to bid given SLA
constraints. A broker can easily apply this model to present
automatically to the user a bid (or set of bids) that will meet
reliability and performance requirements. This model is particularly
suited for Cloud Computing as it is tailored for environments
where resource pricing and reliability vary significantly
and dynamically, and where the number of resources allocated
initially is flexible and is almost unbounded. We demonstrate
the utility of this model with simulation experiments driven
by real price traces of Amazon Spot Instances, and workloads
based on real applications.

So, I had a look at the source file, they implemented the simulation process in one C-file. It took me a while to completely understand the code, especially the implementation of the actual simulation in the methods simulateOptimalCkpt() and simulateHourCkpt() was pretty hard. But now I'm sure this code can be used to develop a broker application (and it can be easily ported to another language). Note that other checkpointing schemes can easily be added since the required methods can be found in the source code that comes with the "Reducing Costs of Spot Instances via Checkpointing in the Amazon Elastic Compute Cloud" paper on this website.

The following quote from the paper describes how the output of the program can be used to make an intelligent (task is done before the given deadline and within the foreseen budget) bid for the spot price:

To find the optimal instance type and bid price, we compute ET(cdead) and M(cB) and check the feasibility (as stated in section 3D) for all relevant combinations of both parameters. As these computations are basically “look-ups” in tables of previously computed distributions, the processing effort is negligible. Among the feasible cases, we select the one with the smallest M(cB); if no feasible cases exist, the job cannot be performed under the desired constraints.

Their simulations resulted in some interesting findings found in the summary of the results in the paper (section 4F). Note that constraints on other random variables than ET and M can be introduced as well.

How do I see the broker application at the moment? It takes as input a collection of workloads and some properties and constraints should be provided for each workload. For a workload should first be determined on what kind of instance it should be executed (maybe in a first iteration of the software with simple CPU, Memory, ... usage thresholds). Then a division between reserved and other instances should be made (based on the on-demand price, since the spot price fluctuates too much). Then finally the algorithms provided in the paper can be used to determine whether the constraints can be met by using spot instances. The bid price and checkpointing scheme that should be chosen for the spot instances is determined when this is the case. Otherwise on-demand instances can be used. I'm thinking the broker should be a Java webservice that periodically downloads the spot price history and then reruns the simulations to update its data.

Papers

I read these 3 papers during the weekend:

1. "Exploiting Non-Dedicated Resources for Cloud Computing" by Andrzejak A., Kondo D. and Anderson D.P.:

   ABSTRACT Popular web services and applications such as Google Apps, DropBox, and Go.Pc introduce a wasteful imbalance of processing resources. Each host operated by a provider serves hundreds to thousands of users, treating their PCs as thin clients. Tapping the processing, storage and networking capacities of these non-dedicated resources promises to reduce the size of required hardware basis significantly. Consequently, it presents a noteworthy opportunity for service providers and operators of cloud computing infrastructures. We investigate how a mixture of dedicated (and so highly available) hosts and non-dedicated (and so highly volatile) hosts can be used to provision a processing tier of a large-scale web service. We discuss an operational model which guarantees long-term availability despite of host churn, and study multiple aspects necessary to implement it. These include: ranking of non-dedicated hosts according to their long-term availability behavior, short-term availability modeling of these hosts, and simulation of migration and group availability levels using real-world availability data from 10,000 non-dedicated hosts. We also study the tradeoff between a larger share of dedicated hosts vs. higher migration rate in terms of costs and SLA objectives. This yields an optimization approach where a service provider can find a suitable balance between costs and service quality. The experimental results show that it is possible to achieve a wide spectrum of such modes, ranging from 3.6 USD/hour to 5 USD/hour for a group of at least 50 hosts available with probability greater than 0.90.

2. "Reducing Costs of Spot Instances via Checkpointing in the Amazon Elastic Compute Cloud" by Andrzejak A., Kondo D. and Yi S.:

   ABSTRACT Recently introduced spot instances in the Amazon Elastic Compute Cloud (EC2) offer lower resource costs in exchange for reduced reliability; these instances can be revoked abruptly due to price and demand fluctuations. Mechanisms and tools that deal with the cost-reliability trade-offs under this schema are of great value for users seeking to lessen their costs while maintaining high reliability. We study how one such a mechanism, namely check pointing, can be used to minimize the cost and volatility of resource provisioning. Based on the real price history of EC2 spot instances, we compare several adaptive check pointing schemes in terms of monetary costs and improvement of job completion times. Trace-based simulations show that our approach can reduce significantly both price and the task completion times.

3. "Decision Model for Cloud Computing under SLA Constraints" by Andrzejak A., Kondo D. and Yi S.:

   ABSTRACT With the recent introduction of Spot Instances in the Amazon Elastic Compute Cloud (EC2), users can bid for resources and thus control the balance of reliability versus monetary costs. A critical challenge is to determine bid prices that minimize monetary costs for a user while meeting Service Level Agreement (SLA) constraints (for example, sufficient resource availability to complete a computation within a desired deadline). We propose a probabilistic model for the optimization of monetary costs, performance, and reliability, given user and application requirements and dynamic conditions. Using real instance price traces and workload models, we evaluate our model and demonstrate how users should bid optimally on Spot Instances to reach different objectives with desired levels of confidence.

It took a while (I read some parts more than 3 times) to understand everything the papers were talking about, but now I think I get what they are saying. And the presented models sure will be a good extension to the model I'm creating.