ROGER MARTINEZ: One of the most powerful features
of Google Cloud Compute Engine is managed instance groups.
So managed instance groups let you automatically scale
your application out to handle those peak loads
and automatically heal in case one of your instances go down.
Today, I'm going to do a quick dive into managed instance
groups and show you how easy it is to set one up
for your application.
On Google Cloud, an instance group
is simply a group of virtual machines
that can be managed as a single entity.
A managed instance group is an instance group
of identical VMs created based on an identical instance
template.
A managed instance group introduces a whole bunch
of functionality, like autoscaling
for increasing the size of your group depending on the load,
autohealing for automatically replacing
unhealthy instances, and multizone deployments
for higher availability.
Before I get into any of that, let's
review the four Google Cloud resources
that are associated with creating a managed instance
group.
First is the instance group manager.
This represents the managed instance group itself.
The configuration of a managed instance group manager
will include whether the instance group will
be zonal or regional and, if regional,
which zones to distribute the instances across.
It'll also include the number of instances in the group
and specify the second resource that we
need, the instance template.
The instance template is essentially the cookie cutter
that the managed instance group manager will use
to provision VMs in the group.
The instance template will specify
much of the same configuration that you
might include in a standalone instance, like machine
size, disk, networking settings, and more.
You'll only need one template, but you
do have the option of specifying multiple ones so you
can do things like roll out canary builds
of your applications to only a subset of your instance group.
Next we have a health check.
A health check is only required if you
want to enable autohealing on your instance group.
That's when instances are automatically
replaced when they repeatedly fail the health check.
These health checks are the same ones
a load balancer would use to direct traffic
to healthy instances.
For managed instance groups, it's
used to decide whether the instance needs
to be reprovisioned.
When creating a health check, you
can choose from five different protocols,
and you can specify how rigorous you
want the health check to be by adjusting the check interval
and thresholds.
If you plan on using autoscaling,
the last thing you'll need to have is an autoscaling policy.
The autoscaling policy has all the configuration
that determines under what circumstances new instances
will be added to and removed from the group.
It isn't required for a managed instance group,
and it can be enabled and disabled after being added.
Let's take a quick look at how we can set up
all of these resources and have a managed instance group
up and running in no time.
In this demonstration, I'll be working from a new project
with no existing resources.
And I'll have only the Compute Admin IAM role assigned.
In the Google Cloud console, you'll
find an instance group under Compute Engine
in the Navigation menu.
You can create everything you need for your managed instance
group in one shot by clicking Create Instance Group.
After giving it a snazzy name, the first thing
you'll want to do is choose from these three choices--
stateless managed instance group,
stateful managed instance group, or unmanaged instance group.
Stateful and stateless managed instance groups are similar,
except stateful will let you preserve disks.
Let's choose a stateless managed instance group.
The next big choice you have to make is location.
A zonal managed instance group will provision VMs
in one single zone and is fine for most use cases.
But remember that a regional managed instance
group will improve your availability
by spreading your instances across several zones.
When you choose multiple zones, it'll
let you specify which zones in that region
you want to distribute your instances across.
Choose at least three to maximize availability.
Next, let's specify an instance template.
If the project doesn't have one, we can create it right here.
For this example, I'll just create a simple template
that will create an E2 medium with a Debian boot disk.
Next, let's add an autoscaling policy in this section here.
For this demonstration, I'll leave it
with the default values.
I'll dive deeper into all these settings, like cooldown period
and scaling controls, in a later video.
By default, it's going to use CPU utilization
at 60% as a metric that it uses to scale up.
But you can adjust that percentage
or replace the metric with load balancer
utilization or a Stackdriver monitoring metric.
If you want, you can also add additional metrics
by hitting Add New Metric.
There's no one-size-fits-all configuration here.
It's going to depend on your application's needs,
but the default values will work for most use cases.
One thing I will change is the minimum number
of instances, because remember, this
is a regional instance group.
So I want to make sure that I have
at least one instance in each of the zones that I specified.
Down here at the bottom is where we configure autohealing
by specifying a health check.
I don't have one yet, so I'll just create a new one.
The default here is TCP.
If your application needs something different,
you have the options of these other protocols in this list.
I'll select HTTP and specify the request path for the health
page of my web application.
Down here under Health Criteria is
where we indicate how frequently the health check should run
and at what point to consider the state
of an individual instance as unhealthy.
With these default values, the health check
will run against each instance every 10 seconds.
If it doesn't receive the response
it's looking for in 5 seconds, it'll count that as a failure.
Three consecutive failures means the health check state will
be unhealthy and will only become healthy again
after two consecutive successes.
Once we're done here, we're ready to create our managed
instance group with autoscaling and autohealing.
You can click Create down here or Command Line
to see the corresponding gcloud commands.
You can see here the four resources we're created--
the instance template, the health check,
the instance group itself, and finally,
the autoscaling policy.
That's a really quick rundown, but there's plenty
more you can do to get the most out of your managed instance
groups.
For example, enabling predictive autoscaling
will feed your instance groups historical trends
and current load into machine learning models
so that the autoscaler can anticipate autoscale events.
This way, the autoscaler will behave more proactively
and have machines ready to roll with less time waiting
for machines to initialize.
For more information on managed instance groups and all
they have to offer, check out the link
to the documentation below.
In the next video, I'm going to discuss in more detail how
you can make the most out of your managed instance groups
by making sure you have an effective autoscaling policy.
See you then.
[MUSIC PLAYING]