- Here we'll talk about auto scaling.
Auto scaling service is an incredibly powerful service
that allows us to handle changes in traffic
or changes in the demands of our application.
Now one of the really key features of not only
Amazon Web Services but cloud computing as a whole,
is the ability to be elastic.
We're operating from a paradigm
of use what you need, and pay for what you use.
So if we don't need it, why should we be paying for it?
If we don't need massive servers,
we should be paying for smaller ones.
If we don't need 1,000 machines,
we should be paying for fewer ones.
We want to be looking at our traffic,
looking at the demands of our application
and really saying, what's the minimum
that we need to fulfill these requests and meet this demand?
And then as that demand rises,
again, we ask that question.
Okay, from this point on what's the minimum that we need?
And we keep doing that as demand rises,
and then of course ad demand falls,
we wanna be reevaluating that
and going, you know what, demand is coming down,
we don't need this amount of compute power
so let's pull these machines out and save money.
So the auto scaling service can help us with that.
We have our VPC leveraging multiple availability zones.
We have an elastic load balancer
leveraging multiple availability zones.
As is our application in multiple EC2 instances
across multiple availability zones.
What we have here is an auto scaling group
that is designed to launch machines
into multiple availability zones.
As our traffic increases,
and we start to see perhaps that we're going over
some threshold,
maybe it's CPU, or network, or the number of processes,
then we can allow the auto scaling service
to start to add machines for us,
and perhaps we wanna start at three and go up from there.
So after a certain period of time
we see that our metrics have not lowered.
We're still above a certain amount of CPU usage.
We're still above a certain amount of network usage.
Whatever it is, whatever we determine the bottle neck to be,
then the auto scaling service will continue
to add machines for us, and will continue to scale.
Now we do have some limits.
We can set a minimum, we can set a maximum.
Typically the minimum would be set based on
how many machines do we need to maintain
the minimum load or the lowest amount of traffic
that we ever see.
The maximum would be determined simply by
how much we're willing to spend.
Within Amazon, while we do have some initial limits
on the number of instances we launch,
we can very easily get those limits lifted,
and perhaps we aren't willing to pay for
100 machines running.
Perhaps we're only willing to spend money on 12 or 20,
and so we can set that as our maximum.
And now we could see that our system has scaled out
and it's maintained a balance of machines
across multiple availability zones.
If we were to lose one of these machines,
then auto scaling would automatically replace it.
If we were to lose one of these availability zones,
the auto scaling group is smart enough to know
if that availability zone is unreachable,
then it will automatically rebalance
and put these two machines over here
in the other two availability zones
that are still in operation.
Now as our traffic starts to come down,
and starts to fall off,
we can allow the auto scaling service
to start terminating machines.
So our traffic comes down even further
and we've removed three machines.
We're back to our original minimum.
So auto scaling service can help us scale out
to meet demand and then during times where
we don't have that demand,
it helps us scale in to save money,
and the scaling in is just as important,
because one of the primary reasons so many people,
so many fortune 500s and government agencies
are moving to Amazon Web Services
is the opportunity to save money,
and so it doesn't really do us any good
to scale out to dozens of machines
and just leave them there.
We want to be sure that we configure our auto scaling group
to scale in as a way to lower our costs.
Now in order to create an auto scaling group,
two things are required.
We're going to have what we call
the auto scaling group itself
and then a launch configuration.
Some things that are optional would be
scheduled actions, and scaling policies,
and we'll talk about the details of these things
here coming up.
The auto scaling service can replace failed instances.
It can change the capacity or the number of instances
in that group.
We could, in some cases, maybe we don't need
to scale out and in,
maybe we just wanna maintain two instances,
or three, or four instances.
Some fixed number of instances,
and so if one of them fails, auto scaling will replace it
and just maintain that certain number of machines.
We're gonna see here in a little bit
how auto scaling can work with Amazon CloudWatch
so that we can leverage alarms to trigger scaling events.
As our machines come and go,
as machines are launched, as machines are terminated,
we can capture those events with the Amazon
simple notification service,
as well as Lambda and do some kind of processing
or coordination on that event.
So let's take a look at the two things that are required.
The launch configuration and the auto scaling group.
The launch configuration defines what gets launched.
Such as the instance type.
Maybe we wanna launch a T2 small, or an M4 large,
or a C4 extra large.
So we defined the type of instance
that we're going to launch.
We can specify the EBS volumes
or the instance store volumes.
We can specify the Amazon machine image,
any user data that we wanna us to bootstrap that machine,
and once we create the launch configuration,
it cannot be edited.
We have to delete and recreate a launch configuration
if we need to make a change to it.
The other component that's required is
the auto scaling group itself.
Where the launch configuration determines
what gets launched, the auto scaling group determines
where it gets launched,
and that is, here we specify what subnets
and by way of subnets we thus specify
what availability zones are being used.
We also specify which elastic load balancers
are going to be used,
and yes we can specify multiple elastic load balancers
for an auto scaling group to use
so that when instances are launched,
the auto scaling group will automatically
register those instances to the ELBs that we've defined.
Within the auto scaling group we also specify
the health check type.
Now an auto scaling group needs some way
of knowing whether or not a machine is healthy
or unhealthy.
If a machine is considered to be unhealthy,
then the auto scaling group will terminate it
and replace it with a new machine.
We can get those health checks from either
EC2 system health checks
or we can get the health checks from the ELB itself,
and we can configure a health check on the ELB.
If we specify tags, as we should be doing
in order to keep our environments organized,
we have the option of adding these tags
to the auto scaling group
and then the auto scaling group can propagate those tags
to the instances that are launched.
A couple of things that are optional
within auto scaling would be things like scheduled actions.
So let's say that you're planing some large marketing event.
Perhaps your business is gonna be featured on the news,
or perhaps you're launching some kind of campaign
and you note that you expect a certain amount of traffic
or a spike in traffic as a result.
If you know about it ahead of time,
we can schedule perhaps a one time event,
or I've worked with plenty of customers
who have, if you look at their traffic patterns
it's like a regular sign wave.
Everyday at a certain period of time they see the same spike
and everyday at another time they see the same troff,
and so when you know you have those types of rises and falls
in traffic, then we can leverage intervals
to schedule, all right, everyday at four o'clock
we're gonna scale out,
and everyday at eight o'clock we're gonna scale back in,
and that's really helpful when you know
the events ahead of time,
then you can get out ahead of that curve
and go ahead and have those machines available
before that traffic starts coming in.
The other thing that we could do is what's called
a scaling policy,
and this allows us to scale based on a dynamic load.
It's really useful for those times when you can't predict
when that load is gonna come in.
Maybe just out of the blue your website is featured on CNN
or out of the blue it's featured,
it's on the front page of Reddit,
and all of the sudden you have a million more users today
than you did yesterday and you didn't expect them,
and so we can leverage these scaling policies
to scale our system in a number of different ways.
Now a scaling policy has to be triggered by something.
We could trigger it via a CloudWatch alarm.
We could trigger it manually.
Which is what we might call the push button approach.
You just go into the console and say trigger,
and allow the scaling policy to do what it does.
We could do it programmatically.
Perhaps even from within our own application.
Maybe the application is smart enough to know
that it's time to scale
and it can trigger the scaling policy.
So leveraging the elastic load balancer,
leveraging auto scaling,
leveraging our launch configurations,
we can achieve what we call self-healing services.
I don't know about you but I personally don't really like
being woken up at two o'clock in the morning
to go in and reinstall and reconfigure Apache
because our server failed.
I don't wanna have to do that.
Our customers don't wanna wait for us to do that.
Our business owners don't want to be losing money
because we were down for an hour or more.
We want a system that can heal itself
in the case of a fault.
So if one of these instances were to fail
for whatever reason, then we want the auto scaling
service to be able to replace it.
We can leverage user data, as we've talked about,
either adding environment variables,
or adding a script that installs what needs to be installed,
configures what needs to be configured,
and gets that machine bootstrapped and running
as quickly as possible.
So here's an example where perhaps we have
a front end web server tier that needs
a little more CPU than it does memory.
So perhaps in this tier we have a launch configuration
that uses a C4 launch,
and the user data just has environment variables
and then starts the process,
and the process looks to those environment variables
to determine what environment it's in,
what backend service to connect to, and so on.
In our private backend service
behind the internal load balancer,
we also have an auto scaling group
that is with a launch configuration,
that leverages a different AMI.
Perhaps this is an application AMI
that already has our application installed and configured,
but this one will use the M4 large
rather than a smaller server,
because perhaps our application needs more memory.
Here we would leverage the user data to one,
perhaps pull the latest version of our code
down from GitHub, start our application,
and then leveraging the simple notification service,
notify perhaps some monitoring system,
or the person on call that hey,
an instance has been launched,
and is now up and running and ready to go.
So combining our launch configurations,
multiple availability zones,
and auto scaling service,
we can achieve a system that is not only highly available,
but fault tolerant and self-healing as well.