PRIYANKA VERGARDIA: Hey, it's Priyanka.
So far, we've looked at how Critter Junction was
able to launch a new app on Google Cloud.
Today, let's take a look at how they
can enable their apps to gracefully handle
peaks and dips in traffic.
[THEME MUSIC]
Critter Junction is becoming very popular with more users
than ever.
The game is all about playing daily, collecting items
and furniture to decorate your house,
and interacting with other players.
As we saw in the previous episode,
they have a range of compute options
to deploy their workloads, but they
chose to migrate some game service to Compute Engine.
As their traffic grew, they were struggling
to provision additional instances
globally for anytime of the day.
This led to overutilized Compute and created constant pressure
on their operations teams.
Clearly, they need an automated way
to handle their growing users and maintain performance
to keep their users coming back daily.
So let's see what Critter Junction should do.
They should use a global load balancer
and managed instance groups to scale and distribute
the traffic automatically.
This keeps the operations team happy
and the user satisfied with great performance.
Managed instance groups provide features such as autoscaling,
autohealing, auto updating, and regional multiple zone
deployments.
To understand this better, let's step back
and understand how a Compute Engine Instance is created.
You create a custom image for your application, which is then
used to create an instance, and to make this reusable,
you create an instance template.
In an instance template, you can not only
set up configuration of the VM, but also
run startup scripts to pull down the latest version of your code
when the machine starts up.
You can also attach disk templates with all the software
dependencies your app requires.
Or you leave it as an empty shell
that gets populated by a CICD pipeline.
These templates then automate the creation
of Compute Engine instances at scale
through managed instance groups.
Let's see how this works with a simple web app example.
Let's head over to our project in the Google Cloud Console
and create a firewall rule under VPC networks
to allow HTTP traffic to the app we're about to deploy.
Provide a name, default-allow-http,
default network, targets, select the specific target tags,
and set the target tag as http-server.
Set the source filter to IP ranges and provide 0.0.0.0/0
to allow access for all IP addresses.
For ports and protocol, select TCP and enter 80.
And then Create.
Now, head over to the Compute Engine
and create an instance template.
Give it a name, select machine type, set boot disk image to
[INAUDIBLE],, and check Allow HTTP Traffic.
Under the Management tab, find automation
and add to startup script.
This script causes each instance to run a simple web
application during startup, and finally, Create.
Link to the tutorial is included below for you
to refer to the sample script.
Now that we have an instance template,
we can create an instance group using this template.
Create an instance group.
Give it a name.
Select multiple zones under location.
This protects us from zonal failures.
Select a region, and under Instance Template,
select a template we just created.
Now, set autoscaling mode to Autoscale,
autoscaling policy to CPU utilization.
You can also set policy to HTTP load balancing or monitoring
metrics.
We're going to talk more about HTTP load
balancing in a minute.
We will set the target CPU usage to 60%, minimum number
of instances to 3.
It is recommended that you provision enough instances so
that if an entire zone was to go down,
the remaining instances still meet
the minimum number required.
And set the max number of instances to 6
to make sure you don't incur additional cost.
We will set the cool down period to 120 seconds.
Make this number is higher than the time
it takes for CPU utilization of the VM to initially stabilize.
We will skip setting a health check for now,
but we'll cover that in the next episode.
After that, just Create.
Wait for a few minutes until all of the instances are running,
then go to VM instances, and click
on the external IP of the instance
to see the demo web page.
Now that we have it all set up, let's
generate traffic so we can see the autoscaling in action.
Open Cloud Shell.
Create a local bash project using export project ID
command.
Run this bash script.
Again, that's included in the link below.
This script increases load, which
leads to increase in CPU utilization for our demo app.
When it reaches the target value of 60%,
the autoscaling starts increasing
the size of our instance.
Now, let's navigate to our Monitoring tab
in our instance group, and we can
see the increasing number of instances
as the CPU usage is increasing.
And you can see the scaled down effect
by running a similar bash script that
decreases the load, leading to a decrease in CPU utilization.
And after a few minutes of stabilization period,
the autoscaler prompts to decrease the instance group
size, which is visible in the monitoring tab as well.
Critter Junction has global users.
They want the users from Singapore
to end up on Asia East web server while the ones in the US
end up on US Central Region.
For this, they would use global load balancing,
which routes traffic to the nearest web server
instance, which helps reduce latency and improve
performance.
From there, the internal load balancer
distributes the traffic to manage and maintain load
across the back ends.
These instance groups in different regions
autoscale using an HTTP load balancing
policy to scale seamlessly, regardless of where
the traffic is coming from.
Not only was Critter Junction able to automate
the scaling of their compute instances
using autoscaling and managed instance groups,
they were also able to improve performance by serving traffic
from instances closest to their users using the global load
balancing.
But there's one more step to scale,
identifying the instances that are unhealthy
and replacing them automatically.
So stay tuned for the next episode, where
we will cover how Critter Junction can setup autohealing
and keep their users happy.
And remember, always be architecting.
[MUSIC PLAYING]