Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is my first time releasing a web app. I'm going to using Django with Nginx and a couple of other scripts that have been piped. I wanted to know which auto scaling strategy I can use.

Right now, I'm playing around with the free EC2 micro instance. Works well.

I'm not sure if I can afford a dedicated RDS. I'm looking for the most cost efficient configuration. I was thinking of auto scaling with micro instances that have been setup with Load balancer but I haven't figured out how to sync the database in all the instances.

I'm also thinking of other alternatives like App Engine and Heroku but I don't think it'll give me VM like freedom. Is there a PaaS where a normal VM can be auto scaled without much worry?

Also, it there some kind of chart that can approximately tell me how much traffic Micro, Small, etc instances can each withstand.

Can someone shed some light?

share|improve this question

closed as not constructive by mailq, Jim B, Ward, Shane Madden, cyberx86 Jan 8 '12 at 8:57

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 6 down vote accepted

Scaling an application is something that you must design your application to be able to do - regardless of the platform.

Some considerations include:

  • Making files (e.g. uploads, source code changes, etc) available to all nodes
  • Sharing session information between all nodes
  • Replicating your database across multiple nodes
  • Determining the health of nodes and when to bring up new nodes

I would suggest that the best approach is to first offload your database to another instance. If your databases and application run on different instances, you can scale each independently, and will have a much easier time of managing the problem. (See this article - a bit old, but no less valid).

Secondly, you want to scale up and out. With EC2, you get much better performance from the larger instance types - in terms of performance, a small instance is better than 3 micro instances. My suggestion would be to scale out to two nodes (for failover), and then start switching your nodes for larger instance types before you continue to scale out (on a more permanent basis). By all means, though, keep auto-scaling functional so that your application can handle additional load at any time.

Scale your databases separately - typically your application will require more nodes than your databases (you databases may benefit from higher memory instances). Also keep in mind that RDS does not do the scaling for you.

Amazon doesn't provide a chart of 'traffic' - because that is completely dependent on your application (a highly dynamic application that is processor intensive can serve far fewer requests than one delivering a static page on the same hardware). It does, however, provide a somewhat 'subjective' comparison here. One point worth highlighting is 'I/O Performance'. This descriptor includes network bandwidth and disk i/o. The smaller instances are more susceptible to variation in performance (especially available bandwidth). Since EBS volumes require network bandwidth, this will also affect their performance.

As for micro instances - as soon as is merited by your application, move up to a small instance. You will find that whenever you 'burst' cpu on the micro, there is a subsequent penalty in performance (indicated by the 'steal' value from top). Other instances (that you do not own) can use significant amounts of your CPU on a micro instance).

It is also worth mentioning that you can set the size of an autoscaling group to '1', which allows you to have an instance relaunched if it becomes unavailable. (The problem that arises though, is getting your current data back on that new instance, since it launches from a snapshot).

If you can use MySQL cluster (it uses a different storage engine - ndbcluster) or a NoSQL solution with sharding, you will have a much easier time auto-scaling your databases than using traditional Master-Slave replication in MySQL. (There is another solution that has reportedly seen some success, but I probably wouldn't advise at this point - using a distributed filesystem, specifically GlusterFS, to store your databases - the file system manages the file locking and distribution, and each instance accesses the databases as needed - this will run into problems as you add more instances, but may see some success with a 2 node database cluster).

A practical course of action therefore may be:

  1. Start with 1 micro instance which has both your database and application on it
    • Separate your database to a one instance and your application to a second instance
  2. Setup autoscaling on your application instance.
  3. Add a second application node
  4. Add a second database node and configure replication between your nodes (if you opt to use MySQL cluster, or NoSQL solutions, you should be able to setup autoscaling as well).
  5. Upgrade one instance at a time to larger instance sizes as demand merits it

(You should find that for most sites 2 of the bigger instances are more than enough to run your database, especially if you implement caching correctly, but adding an additional slave as needed shouldn't be too troublesome).

The above course of action addresses scaling fairly well, but it does have a single point of failure until step 4 (i.e. if you database node fails, your application goes down). A much more difficult setup, but a more resilient one, would see you have both your application and database on the same node, then setup two copies of that node with MySQL replication (and MySQL proxy to handle requests from the load balancer) - you would need to manage failover on your own (with something like Heartbeat/Pacemaker) and then go directly to 4 nodes (2 database, 2 application).

share|improve this answer
Thanks a ton! That cleared a lot of my doubts. I'll probably go with the separated DB and application strategy. How about I use a DBaS like and only scale the application instances? That should take half of the headache off my head. I suppose latency shouldn't be a problem as both reside on the EC2 architecture. – Suhas Jan 8 '12 at 4:25
I must say those look rather pricey ($149/mo for 2GB replicated?). At those costs, I am sure you can do better rolling your own solution with MongoDB - sure it will be harder to implement initially, but you'll have a much better understanding of your setup, and should be able to deal with any future issues much more efficiently. Besides - the 'fun' of servers is in the challenge. Look at setting up a 'Replica Set' of MongoDB instances. (Also, please close out your question(s) by accepting an answer when feel your initial question is resolved) – cyberx86 Jan 8 '12 at 4:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.