PRIYANKA VERGARDIA: Hey, it's Priyanka.
So far, we've looked at how Critter Junction launched
and globally scaled an app on Compute Engine.
Today, let's learn how they can make their social critter
app more scalable by gracefully replacing failed instances.
[MUSIC PLAYING]
With their growing daily active users,
we help them set up autoscaling and global load
balancing to handle globally distributed
and constantly rising traffic.
But to keep their users from risking their daily game
streaks, they need to make sure their app is available all
the time without interruptions.
So today, let's focus on helping them set up
high availability, or HA.
We know that managed instance groups provide features
such as autoscaling, regional multiple zone deployments,
autohealing, and auto updating.
We covered the autoscaling and regional deployments
in the last episode.
So check it out to learn more about global scaling.
Today, let's focus on autohealing and auto updates.
Autohealing helps proactively identify and replace
the unhealthy instances--
the ones that are not responding--
with the healthy ones.
And the auto update feature helps update the instances
without disrupting the service.
Let's focus on autohealing for a bit.
First, we create a health check, which
not only detects whether the machine is running or not,
but also detects application-specific issues
such as freezing, crashing, or overloading.
If an instance is deemed unhealthy,
new instances are created by the managed instance group.
Let's see how autohealing works in action.
In Google Cloud Console, I have the project
from the previous episode opened here.
First, we will create a health check in Compute engine.
Give it a name.
Protocol is HTTP.
And let's say the path is /health.
It can be any path you decide for your health check.
In our demo app, we added code that ensures that /health
returns a 200 OK response when healthy,
and HTTP 500 internal server error when unhealthy.
Now for setting up health criteria, set check interval
to 10, which means every 10 seconds
the service will be probed for health.
Set timeout to five, which means we
wait for maximum five seconds for a response to a probe.
Set a healthy threshold to two, which
defines the number of sequential probes
that must succeed for the instance
to be considered healthy.
And finally, set an unhealthy threshold
to three, which defines the number of sequential probes
that must fail for the instance to be considered unhealthy.
And then create.
As a best practice, you want a health check to be conservative
so you don't preemptively delete and recreate instances.
Now, let's go to our instance group
we created in the last episode and add a health check to it.
Select the health check with an initial delay of 90 seconds.
Ideally, this initial delay should
be long enough for the instance to be
fully running and ready to respond as healthy.
Let's have some fun with this and simulate failures now.
For that, we go to the VM instance
and click on external IP and make it unhealthy.
Wait for the autohealer to take action,
and we will see that the green check mark next to the instance
turns into a spinner indicating that the autohealer has started
rebooting that instance.
One of the other concerns when it comes to HA
is applying updates to the instances
without impacting the service.
Managed instance groups allow you
to control the speed and scope of the update rollout
to minimize disruptions to your applications.
You can also perform partial rollouts, which
allows for canary testing.
Let's see that in action now.
On our instance group, we see this rolling update button.
Click on that.
Word "rolling" means it is for gradual updates.
We will add a second template for canary testing
and select target size as 20%.
This means we want to send 20% of the traffic
to the new instances for canary testing.
Now, update mode is by default proactive,
which means Compute Engine actively schedules
actions to apply the requested updates to instances
as necessary.
In many cases, this often means deleting and recreating
instances proactively.
You can choose to perform an opportunistic update
if a proactive update is potentially too disruptive.
An opportunistic update is only applied when you manually
initiate the update on selected instances
or when new instances are created by the managed instance
group.
Max surge means how many more instances
are you willing to spin up as a part of this update?
The higher value here speeds up the update,
but costs more for the new instances.
So it is a trade-off between cost and speed.
Max unavailable and min wait time--
I will keep them as zero, but these parameters
are used to control how disruptive the update is
to your service and to control the rate at which the update is
deployed.
Through our help setting up two high availability features
within managed instance groups, Critter Junction
has a much more resilient architecture now.
Autohealing proactively defies unhealthy insurgencies
and heals them.
And auto update updates instances
without disrupting the service.
Stay tuned to find out what more is
in store for Critter Junction.
And remember, always be architecting.
[MUSIC PLAYING]