Over the past few months or so I’ve been working on rewriting my web application engine to go from running on a virtual dedicated server at a hosting company to running an instance on Amazon EC2 instance. Additionally, I decided to take a risk on Amazon SDB and despite its many flaws, eschew MySQL completely and utterly.

One thing I like a lot about Amazon’s service stack is that it forces you to think about scalability problems right up front. If you design with MySQL on a VPS, it’s easy to get into using a lot of the features that don’t scale – so you make a mess for yourself down the road.

There were several challenges to running a site completely on Amazon’s stack:

• Amazon has a large distance between their small nodes and the next size up node. – The small nodes are pretty weak by themselves, you wouldn’t want to base a website on a single node by itself. This forced me to design the architecture to work from day 1 on ‘n’ servers.
• EC2 still has no load balancing API – They should add this, but to get around it we use DNS round robin assignment, which is pretty much good enough for assigning servers that should never be under huge loads anyways.
• SDB is slow. Everything about it is slow. Also it has its own features that don’t scale very well, such as ‘starts-with’ < this runs slowly.
• The data model you want for SDB is different than one you want for an RDBMS. Because you can’t join or index, you want to be thinking about denormalization of your data quite quickly. This also means migration from MySQL to SDB is tricky.
• EC2 payloads are annoying to change – Marc created a script that on instance startup pulls down all the required software for a server from SVN, finds the other servers for dns round robin-ing and for memcaches, and starts up apache.

To move over to Amazon required a migration on our relatively small database of 100k or so rows. This however expanded to around 250k rows on SDB, and required about a million SDB requests to accomplish.

As I wanted to move the site without a lot of downtime, I wrote the migration script to run on ‘N’ servers. When I started the migration up, I ran 20 server instances, and ran the script on all of them. Each segment of the migration took about 2 hours to run, so without EC2’s easy scaling capabilities the site would have been required to be down for 2 days instead of 2 hours.

So far the new Amazon EC2/SDB code base has been up for 3 days. All data is in SimpleDB, from user logins to the friend network graph, despite mysql’s ease of use I’m glad to be rid of the database as a potential bottleneck that could bring the entire site down – something that happened too frequently on my last project.

Overall the site migration went quite smoothly, and we’ve been running for a couple days now without incident. The site has created about 40k html pages, extensive use of memcache means most pages will load in 200ms under a bit of pressure, and best of all costs are reduced and completely trackable.

Now my job is to focus on growing traffic. My new site only has about 7k daily visitors, whereas my previous effort swik.net has about 30k, so I have a ways to go.

• The Universal Amazon EC2 API Adapter (UEC2)