SPEAKER: It's really easy to set up autoscaling on your Google
Cloud managed instance groups.
The configuration options offer lots of flexibility
to help fit your application's needs.
Let's dive a little deeper into autoscaling and check out
three things that will help you set up effective autoscaling
on your work instance groups.
To implement more effective autoscaling,
it's helpful to understand how it generally works.
The autoscaler monitors your instance group
and offers a size recommendation.
That's a calculated number of VMs
needed to serve the peak load over the last 10 minutes.
These 10 minutes are referred to as the stabilization period.
This stabilization period is 10 minutes,
so the autoscaler can ensure that usage info that it uses
to scale in and out is stable.
And that helps prevent the autoscaler
from adding and removing machines at an excessive rate.
When scaling back down, it's able to determine
that a smaller group size will be
able to support the peak load, so that it can safely
remove instances.
When autoscaling is turned on the number of VMs
it scales your instance group up and down
to will be limited by the minimum and maximum number
of VMs that you specify.
When scaling in, the number of VMs it can remove
is also limited by the scale-in controls, if specified.
If you configure autoscaling and leave it turned off,
it still calculates recommendations.
So you can see what the autoscaler would
do if it's turned on without having
to spin up additional machines in the process.
This way, you can see the effects
it will have before actually committing to them.
So now that you know a little bit about how it works,
here are three things to consider when designing
your autoscaling configuration.
Thing number one, the machine type.
OK, so technically this isn't part
of the autoscale configuration.
You actually indicate the machine type
on the instance template associated with your instance
group.
But that's why it's so important for autoscaling.
A new instance of that type will be
provisioned when the instance group is scaled up.
You might be thinking, well, yeah, of course.
But this is when knowing your application is key.
For example, if you know that your application that you're
running on your instance group needs two virtual CPUs,
then e2-standard-2 has got you covered.
But if you also know that the same application doesn't
need much memory, then e2-highcpu-2
offers the same number of virtual CPUs with less memory.
Choosing that one means that, every time you
scale your instance group out, you're
not scaling out or paying for resources
that you won't be using.
OK, thing two, the cool-down period.
For effective autoscaling, you want
to make sure you specify an accurate cool-down period.
The cool-down period is the initialization time,
the amount of time it takes for your application
to initialize after the host VM has been provisioned.
You want to be sure that you have an accurate one specified.
If you specify a cool-down period that's too long,
then your autoscaler will miss out on that utilization data
and potentially underestimate the required
size of your group.
On the flip side, if you specify a cool-down period that's
shorter than it takes for your application to be ready,
then it's possible for the autoscaler
to get inaccurate utilization data, because in some cases,
CPU utilization while things are getting up and running
is higher and isn't a reflection of normal use.
Finally, there's thing three, scaling controls.
The ability for your managed instance group to scale
is a big win for reducing costs.
But you don't want to take a hit in performance
when you do that.
Scaling controls let you slow things
down by establishing a rate that the autoscaler will scale down
at.
This way, you'll be able to avoid
dramatic drops in group size.
Remember that cool-down period I just mentioned before?
If your cool-down period is on the long side,
by using scaling controls you'll have the added benefit
when there's a sudden spike in demand.
You'll already have machines available
and you can avoid delays caused by long initializations.
Setting up the right scaling controls,
just like choosing the right machine and accurate cool-down
period, all comes down to knowing
your application, its requirements, and expected load
and behavior.
Let's take a look at this managed instance group
that I've set up on a Google Cloud project.
Here's a few things about my configuration.
I've set my minimum instances to two and my maximum to 100.
When I set this up, I wasn't sure about cool-down period,
so I left it at the default value of 60 seconds.
I wasn't sure about scaling controls,
so I left that disabled.
The instance template uses an e2-standard-2.
Let's see how we can make changes to this configuration.
Let's edit my managed instance group called
web-app-instance-group and check out the autoscale settings.
We've got a regional-managed instance group.
So right off the bat, I want to take advantage
of high availability by making sure
that I've got at least one instance in each of my zones.
That's three zones, so I'll increase my minimum to three.
Now that I'm here, I also want to make sure
that my maximum is set to a reasonable number.
Although it may be unlikely for my application
to need to scale that high, it's still possible for it
to go as high as 100.
For my application, this is too much.
So let's lower that to 30.
It takes the application on my virtual machine
two minutes to be ready.
So I'll set the cool down to 120 seconds.
That's pretty long.
So I'm going to enable scaling controls in case
I get any spikes when my group is scaling down.
In this case, my instance group won't scale down
by more than 10 VMs from the peak size, as observed
over the prior 10 minutes.
I'm going to save these settings for now
before I change one more thing.
The VM type specified in the template is an e2-standard-2.
Well, that's got more memory than I need.
So let's see how I can replace that with an e2-highcpu-2
instead.
Rather than clicking Edit on my instance group,
I can instead go up here to Update VMs.
Up top here, it says the current size of my instance group
and the name of the template I used
to create the instances in it.
Here, under New Template, I could add a second template
and roll that out to only a certain percentage
of my instance group.
This is one way to do A/B testing
or deploy a canary of my application.
In this case, I want to replace my only template
with a different one that I created for this demonstration.
With one template specified, my target size
is 100% of my instance group.
Down here, under Update Configuration,
I can specify how I'd like the template to be rolled out.
By selecting Automatic, the managed instance group
will proactively tear down or replace
each of my instance groups instances
created with the old template.
Here, where it says Temporary Additional Instances,
I can specify how many machines beyond the recommended number
can be provisioned to make this transition possible.
This makes it possible to maintain the recommended
number of VMs while still tearing down and recreating
them.
Down here at the bottom is an update summary
that recaps the configuration I set for this update.
Once I'm finished, I can kick this update
off using the equivalent command line or REST API calls.
Otherwise, I can just click Update VMs here.
The autoscaling offered of managed instance groups
is very flexible.
The cool-down period and scaling controls
are a great start to setting up effective autoscaling.
Also, don't forget to choose a properly sized VM
on your instance template.
Beyond that, there's much more you
can learn from the documentation to make sure
that your autoscaling is working for you efficiently,
effectively, and affordably.
To learn more, check out this link for more on autoscaling.
And check out the link in the description for another demo
on autoscaling.
Thanks for watching.