When we were building Discovr Apps we were confident it would do ok, but we had no idea how much traffic it would generate. **Update: we did 250k downloads in 4 days**. We are also a really small development team (1 fulltime, 1 part time), so we needed a system that was:
- Low maintenance
- Easy to scale
- Simple to setup
- Provided good redundancy
We ended up choosing Amazon Web Servers, in particular the following products:
- Elastic Load Balancer
- EC2
- RDS
- S3
Here is a rough idea of the server configuration:
From here we can scale the app servers horizontally within about 10 minutes, we can also automate this in the future if required. We can also scale the database servers horizontally as well by adding more slaves. The Elastic Load Balancer is automatically scaled by Amazon as required.
We do have a lot of advantages:
- It is only a web service returning JSON, hence the rails load is small.
- We can cache heavily
Overall we have been really happy with the way the servers have performed, they handled a feature on Techcrunch and going to #1 in the US and Japan without a glitch. We also think it will serve us well going forward with some bigger plans we have for Discovr Apps.
This is in no way meant to be a guide to a perfect or cheapest server setup, but given a lack of information from others about their setups it may provide useful to some going down the same path.
Stuart is the lead developer on Discovr, you can follow his ramblings on Twitter at @stuartkhall
Follow Us
You should give more information.
What EC2 instances are you using? How much does it cost to run this? What is your typical load/usage? Why were two zones used? Which zones are they?
We are using High CPU Medium, we are evaluating what instances would be best to use based on usage patterns. Two zones were used for redundancy, both in the east.
You write that you can cache heavily. Does this mean that you already use a cache, or are you planning to use a cache? Which caching solution do/would you use?
We are using standard action caching, but we are considering memcache
AWS stands for “Amazon Web Services”.
What’s your DR plan for when the EBS that backs the RDS service goes down, as it has several times recently?
We are still working through it, initially we started with an instance running mysql, which we left running. So initial thoughts was the bring that back up.
Thanks for posting! We’re a small development team as well and as we’re near launch I’ve been blueprinting ideal scaling solutions. Is there any other setups you evaluated? Right now I’m torn between Rackspace & EC2…
Yeah we did the same, pretty hard one to choose, in the end I think both of those would be good options.
Why not use jruby and compile the app to a war for deployment on http://aws.amazon.com/elasticbeanstalk/? This lets amazon take care of the app layer instead.
Any plans for a message queue in front of the single Master DB? Not sure what you’re write requirements are but that looks to be the bottleneck that this scaling is introducing.
caveats -
Could be completely YAGNI.
No idea what your writes are, so could be totally off base.
I imagine you can throw sufficient sums of money at the Master to make it handle a bunch of writes before having to think about message queues.