6

So first off I'm completely new to AWS so bear with me.

I have had one instance running for a few months now and I now need to autoscale it as I am getting bigger traffic spikes and it gets overloaded at times.

So let me go through what I have done so far and you guys can tell me where I went wrong and what I have to do differently.

  • First I created a Load Balancer that has my one main instance on it, call it "instance A"
  • Next I created two CloudWatch alarms on "instance A" monitoring the CPU Load. Next I created an image of "instance A"
  • Next I created a Launch Configuration linking to my newly created AMI.
  • Next I created a Auto Scaling Group and linked it to my Load Balancer and also setup the two Scaling Alarms I setup previously.
  • I set the AutoScaling group Min to 0 and Max to 3 because I only want it to start launching instances when my original instance (instance A) goes over capacity.

So basically I want my original instance to be running at all times. Then when it starts going over capacity I want the Auto Scaling Group to start launching instances and the Load Balancer to distribute the load across them. Is my thinking here sound?

Other Important Questions.

When I make code and data changes to my original instance, do I have to remake the image my Launch Configuration uses?

What needs to be down with DNS names and IPs? I'm currently using Route 53, do I make that point to my Load Balancer and that's it?

Thanks Guys!

Dan
  • 237
  • 4
  • 9

1 Answers1

8

Let's go over your questions.

So basically I want my original instance to be running at all times. Then when it starts going over capacity I want the Auto Scaling Group to start launching instances and the Load Balancer to distribute the load across them. Is my thinking here sound?

I'd say yes, but I do have a couple reservations. If I understand correctly, you've placed your "main" instance outside of the auto scaling group. Theoretically, that would ensure that auto scaling doesn't kill off your original instance. There are a couple of things I'd like to mention:

  • You're not making full use of the possibilities of Auto Scaling. Auto Scaling not only enables your setup to scale, but it can also ensure limits. If, for whatever reason, your "main" instance dies, your auto scaling policy won't come into action. If you keep your instance in an auto scaling group with a min-size of 1, Auto Scaling automatically replaces the failed instance.
  • When auto scaling, it's often best practise to treat your instances as being "disposable", because that's how you build resilient systems. Don't depend on one instance to always be available.
  • You can set the termination policy for your auto scaling group so that it always terminates the newest instances first. That would ensure your "main" instance will be kept (as long as it's healthy). My previous comment still applies though.

When I make code and data changes to my original instance, do I have to remake the image my Launch Configuration uses?

I'd say no, but that's more of a design issue. Your image should describe the state of your server, but it shouldn't be responsible for code distribution. Consider a situation where you'd have to update your application because of an urgent bug, but your servers are under high load. Does updating your main server, creating an AMI, updating your launch config and killing off your auto scaled servers so they can be respawned with the latest AMI sound like an attractive solution? My answer to that would be no (again). Look into source code version control and deployment strategies (I'm a Rails developer 60% of the time and use git and capistrano, for instance).

There are situations where your approach would work as well and there is a lot of middle ground here (I would recommend also looking into Chef and userdata scripts). I myself actually rarely use custom AMIs, thanks to Chef.

What needs to be down with DNS names and IPs? I'm currently using Route 53, do I make that point to my Load Balancer and that's it?

Basically, yes. You can select the loadbalancer(s) that should be attached to new instances when creating your auto scaling group. I haven't used the GUI for Auto Scaling yet, but I'm quite sure it's in there somewhere. If not, the CLI still supports it. Point your Route53 record to your ELB alias and that's basically it.

Response to additional questions (2014/02/23):

If you're developing using Rails, I can highly recommend Capistrano for deployments, which can take a specific version of your app in your preferred version control system (like git) and deploy it to a number of servers in a specific environment. There are a bunch of tutorials out there, but Ryan Bates' revised (and pro) Railscasts on the subject are very concise, although you need a subscription to his website to watch both of them. Most of the other tutorials will get you going as well though. Fire up a new server with your AMI and a launch script that pulls a temporary clone of your git repo and runs a local Capistrano command to get your app going. This ensures that, later on, you can also deploy new versions of your application using Capistrano with just one command to all running servers.

Capistrano also provides a couple of other benefits, including enabling you to execute specific tasks on all or just one of your servers and roll back a deployment, which is very hard to accomplish using just git.

Jaap Haagmans
  • 414
  • 3
  • 11
  • Thanks for the clear answer Jaap! Could you point me towards some good resources on using version control with my autoscaling group and instances. I have used git with Rails before but that was on heroku and I am a little confused as to the method of deploying code and file changes to a autoscale group inside EC2. Thanks Again! – Dan Feb 21 '14 at 16:14
  • Sure Dan, I've updated my answer. If you have any more questions, let me know! – Jaap Haagmans Feb 23 '14 at 11:31
  • Thanks a ton for the updated answer. Setting up a script and cloning a git repo makes a lot of sense. For a HTML/PHP sites would i just use git and a script or do I also need a Capistrano alternative. Thanks! – Dan Feb 23 '14 at 18:44
  • It depends on your preferred strategy. Git can be used as a tool in your deployment strategy, but it doesn't deploy code. However, you don't need Capistrano to deploy code. It can, of course, be scripted in any other way. I'd just like to add that Capistrano can also be used with HTML/PHP sites and it can make your deployments a -lot- easier if used properly. Especially if you're leaning towards a distributed / auto scaled setup. If you don't mind logging in to every server manually and updating the code using git (e.g. fetching the latest code changes), that could also be an option. – Jaap Haagmans Feb 24 '14 at 13:11
  • Cool i'll definitely give Capistrano a look. Thanks for all your help Jaap. – Dan Feb 24 '14 at 13:49
  • What strategies do you use with Capistrano to deploy to an autoscaling group ? I've seen a couple on the web but they often imply integrating other services, etc. I was wondering if there was *smart* way using just capistrano (like retrieving the list of currently running instances under the autoscaling group and updating them one by one) – Cyril Duchon-Doris May 08 '16 at 14:58
  • If you have an adequate retirement protocol for your setup (where instances are removed from the chef server when they're scaled down), you should be able to retrieve all relevant instances from the chef server (using a chef query). We deploy using our CI and we have a master branch that's always safe to deploy to production, so we can trigger a full CI deployment run when the servers have scaled up. That's not fast though, you could script something that actually copies data from a running instance or work with shared file storage (if code is loaded into memory, like with Rails). – Jaap Haagmans May 17 '16 at 14:26