26 Oct 2013

Scaling for one - Single instance resilience with AWS EC2

For startups or small businesses migrating to AWS there may be no immediate requirement for extensive multi-instance scaling or any of the other bells and whistles, indeed perhaps all they are looking for is the flexibility and future potential a cloud starting point provides.
That said, even if it's just a single server instance being deployed it still makes total sense to implement high availability cover for zone outages and/or EBS failures.
Let's take a look at easy resilience for single instance launch configurations.

Stateless

Stateless boxes are the holy grail of scale. What this means, basically, is that the core app box is bootstrapped to update and pull down/install the application from Git or w.h.y, with static/dynamic assets (media files, images etc) held in centralised storage (i.e AWS S3) and a remote database endpoint connection should a database component be used (which will invariably be the case).

AWS facilitates scripted launch configs via the user data field and it's a simple process to connect to a managed database service (or create your own cluster).

Overview

AWS scaling groups don't have to 'scale' as such and for single instance resilience the trick is simply to create a load balanced multi zone scaling group with a maximum and minimum instance of one.

Scaling groups pull from a launch config (an 'ami'), which can either be a base instance with linked bootstrap scripts, or a pre-built role, prepped with the latest tested updates and primed to pull down the latest version release from your Git repo along with configured endpoints into a remotely managed DB source.

The group will be configured to an AWS Elastic Load Balancer (ELB) which acts as the DNS entry point whilst taking care of contained instance health. Before creating the scaling group the ELB must be in place and configured to manage required zones (invariably all within a Region) along with a relevant health check for app services, i.e HTTP:80 for web (although base TCP:22 can be used as a starting point). The ELB is easiest created from the AWS management UI and there's an easy How-To available in the core AWS documentation pages.

Launch Config

Creation of both the launch config and scaling group are via the AWS CLI tools. Installation of the tools used to be a somewhat lengthy process with a confusing selection of mixed methods. Thankfully this convolution has been distilled for easy installation in a single hit on Ubuntu and the How-To can be found on Eric Hammonds ever useful and comprehensive Alestic blog site - http://alestic.com/2013/08/awscli

With the CLI tools installed it's a simple two stage process to create the launch config and scaling group. Firstly create the launch config.

Prerequisites - A private key and suitably configured security group.

Substitute your own details into the following:

as-create-launch-config my-launch-config --region eu-west-1 --image-id ami-480be3f --instance-type t1.micro --key my-private-key --group my-security-group

Scaling Group

With the launch config in place create the scaling group (*NOTE* - Once created the group will be live and instances will launch):

Prerequisites - An ELB configured for relevant zones and instance health checks.

Substitute your own details into the following: 

as-create-auto-scaling-group my-scaling-group --region eu-west-1 --launch-configuration my-launch-config --availability-zones eu-west-1a,eu-west-1b,eu-west-1c --load-balancers my-load-balancer --max-size-1 --min-size-1

To modify either the launch config or scaling group just use as-update with amendments as desired. For example to take the group offline just drop max and min scaling parameters to 0, or, if demand increases (and you have implemented stateless config) you can easily upscale your fixed instance pool by increasing the maximum and minimum values.

Implementing dynamic scaling in response to load metrics provides a more cost effective solution as your site popularity increases and the easiest way to facilitate and manage this is via Ylastic. It's not possible to use Ylastic for creating single instance scaling configs (hence the reason for this post) but for everything else it delivers an excellent feature set to enhance and assist with all aspects of AWS admin. I love Ylastic and rate it very highly, if I'm feeling generous I may put together a supplemental post for you covering some Ylastic highlights.

No comments:

Post a Comment