Launching your iPhone & iPad App With Amazon Web Services

When I wrote about our Amazon rails setup we had a lot of people asking for more info.

You asked for it, so here it is, all the answers that I wish I’d known about before we launched.

Server Configuration

Load Balancer : Elastic Load Balancing

Rails App Servers : 4 x EC2 High-CPU Medium Instances

Database Servers : 1 x Master Large RDS Instance, 1 x Slave Large RDS Instance

How Did We Decide On The Configuration?

It was pretty technical actually, we took a guess and multiplied it by two. We did load testing, but in the end we really had no idea how much traffic it would generate.

Playing heavily on my mind was Flipboard’s server issues on launch, so we put in place what we thought would be more than enough and were in a place to quickly scale if required. We did this by having private Amazon Machine Images ready to roll, this meant where could scale the rails servers horizontally in approximately 12 minutes, and we could do multiples of these at the same time.

How did it all go?

Right. So the really interesting part, be prepared to be overwhelmed by charts. All these stats are based on the 250k downloads we did in 4 days.

Overall performance

We are using the awesome New Relic to monitor the server performance, here is how it stacked up:

As labelled on the chart above:

1. We had averages of around 1600 request per minute over 30 minutes with peaks up to 2000 requests per minute.
2. We managed to maintain a sub 30ms response time during this period.
3. The load balancer did a really great job of spreading the load over the servers.
4. There was significant performance difference between the instances, more details below.
5. One server gave really weird CPU readings, details below.

EC2 instances can vary significantly in performance

As you can see the performance of each instance varies up to 50% in CPU and response time, this is consistant over time.

WTF is with the CPU on the last server?

Good question, one I am still not 100% sure of, I’m putting it down to a bug on Ubuntu with the specific CPU that instance must be running.

As you can see below, top reports CPU usage overall as you’d expect, but each process is reported as 100x actual CPU usage.

Requests over time

Request counts did vary over time, here are the 1hr and 1min charts:

Instance CPU Usage

The instances travelled pretty consistently with the CPU, slight spikes but well within acceptable levels.

Database CPU Usage

The database CPU also travelled along pretty happily:

Database RAM Usage

RAM usage was acceptable, over 2.5GB available (A large instance has 7.5GB of RAM).

Database Write Latency

Write latency was generally pretty good, the spikes I can’t explain as they don’t appear to line up with the peak periods.

That’s It!

Overall it went really well, if anything we over-scaled, but I am quite happy to over-scale than under-scale. We also couldn’t be happier with Amazon Web Services, any lean startups looking for a quick and easy way to deploy their applications I would highly recommend AWS.

Hopefully this is useful for others out there looking to launch applications with web services. I know I would have really liked to know some sort of ballpark figures like this!

Stuart is the CTO of Filter Squad / Discovr, you can follow his ramblings on Twitter at @stuartkhall