Blog Posts

In light of today's webtuesday talk by Jürg about load testing of web applications, I'd like to show a way to make your web service a little bit more load resistant (and/or fail safer)

Since quite some time Amazon offers two services - the Elastic Compute Cloud (EC2) and Simple Storage Service (S3) - to make a load balanced setup rather easy and most importantly, you can use it "on demand" and it will cost you almost nothing, if you don't need it. Let's say, you have a blog/website, which usually has normal traffic your webserver can handle without any problems, but now and then you get slashdotted/dugg/reddited or just have a large amount of traffic for other reasons. Amazon EC3/S3 offers now the possibility to create server images on their systems, which you can start on demand with some simple commands (remote via some REST calls or for example via the EC2 Firefox Plugin). With a decent replication setup you could now start as many images as you need until it can handle all the requests. This will cost you 10 cents an hour per instance plus you pay something for the traffic. So if you have a peak now and then, this won't cost you an arm and a leg and you don't have to invest in a big server park just to suit those needs. And if you don't need it, you just pay the space for the images on S3, which is neglectable.

The same principle could also be done for a failover system. You for example sync your relevant data from your main server regularly to S3 and should something hit the fan and your server goes down, you just start the EC2 image, point the DNS do that instance and you're up and running again. Thanks to the simple REST-API of S3 and EC2, this can all be done automatically with some scripts.

Actually, as a proof of concept, this blog is right now running from an EC2 instance (I will shut it down later, 10 cents an hour is cheap for shorttime help, but it nevertheless costs 72$ a month plus traffic. And we don't have that much traffic, that we actually need load balancing :) )

The setup is as following: We point the DNS entry for blog.liip.ch to an EC2 instance, where on port 80 we have pound running for loadbalancing. Pound points to all EC2 apache instances with the blog we may start (but it's currently just 1), so this handles the loadbalancing. The master server in our datacenter is still running and is the master database for a mysql replication setup. The mysql servers on the EC2 instance are therefore just replication slaves. As Flux CMS is capable of reading and writing to different databases, this part was easy to setup. What I didn't setup right now is file replication, but that could be done by some rsync scripts and maybe via S3 for persistant storage (but for just blogging text, it's not needed anyway). That's basically it, if we would now got hit by a lot of traffic, we'd just start up another EC2 instance, point pound to it and we can handle double the traffic (or if the master goes down, we still could deliver pages)

Having said that, the EC2 instances are not the fastest CPUs on earth, our quad core server, where this blog normally is, can handle much more, so maybe this blog is a little bit slower for you today. Furthermore, the servers are located somewhere in the US (or at least it looks like), which doesn't help for a really fast response time here in Europe :)

PS. Long time readers my remember, that we had a similar setup for 72 Stunden, without Amazon but "local" servers, but today, we would certainly consider Amazon's services for that. Read more here.

Update: I turned the EC2 instance off for now. The whole experiment did cost me 1.13$, 1.10$ for the 11 hours uptime and 3 cents for the traffic (yes, we're not really a highly busy site :) ), but aside from one little replication issue (see the comments), it seemed to work fine.