PRIYANKA VERGADIA: Welcome to Get Cooking in Cloud,
where we share the best recipes to apply in your Cloud kitchen.
I am Priyanka Vergadia.
STEPHANIE WONG: And I'm Stephanie Wong.
PRIYANKA VERGADIA: And in this season,
we will share some recipes involving a major networking
ingredient.
STEPHANIE WONG: Cloud load balancers.
PRIYANKA VERGADIA: So, Stephanie,
what are we cooking today?
STEPHANIE WONG: Today we are making desserts.
PRIYANKA VERGADIA: Yum.
Do I get to sample some at the end?
I am a great dessert taster--
tester-- taster.
STEPHANIE WONG: Either way, sure, if you like dog food.
PRIYANKA VERGADIA: What?
STEPHANIE WONG: Yep, because today we're making dog treats.
[MUSIC PLAYING]
Imagine you're in charge of a complex website, Beyond Treat--
your one-stop shop for vegan dog treats--
and it's an online hit.
It continues to face high amounts of traffic,
and you're not sure your website backend can
handle the amount of traffic from all over the world.
You know you need to use load balancers,
but the options are confusing.
PRIYANKA VERGADIA: I totally agree.
Without a recipe, it can be hard to know exactly how to settle
on a load balancing architecture that meets your needs
and figure out the prerequisites you need for the best
performance without making much of a dent in the wallet.
STEPHANIE WONG: Well, to start, you
need to know what load balancing is
and why it's so important to the long-lasting success
of your application.
Modern high-traffic websites serve hundreds of thousands,
if not millions, of concurrent requests from users or clients
and return the correct text, images, video,
or application data all in a fast, reliable manner.
PRIYANKA VERGADIA: You've probably all
experienced visiting your favorite website only
for long wait times, connection timeout errors, or images
and videos buffering.
STEPHANIE WONG: And, a lot of the times,
this is because the website backend
is unable to cost-effectively scale
to meet these high volumes.
PRIYANKA VERGADIA: Of course, the logical answer here
is to add more backend servers to help server traffic.
But the next question becomes, how do you distribute traffic
to those backend servers based on things
like capacity and health?
STEPHANIE WONG: This is where load balancing makes a splash.
Load balancing is the process of distributing traffic
across your network of servers to ensure that the system does
not get overwhelmed and all requests
are handled easily and efficiently.
There are a number of delicious reasons
why load balancing is important.
It lets you distribute load-balanced resources
in a single or multiple regions, meet your high availability
requirements, scale your resources up or down
with intelligent autoscaling and use Cloud content delivery
network for optimal content delivery.
PRIYANKA VERGADIA: With Cloud Load Balancing,
you can serve content as close as
possible to your users on a system that can respond to over
one million queries per second.
To decide which load balancer best suits your implementation,
you need to think about whether you need global
versus regional load balancing.
Global load balancing means backend endpoints
live in multiple regions, whereas regional load
balancing means backend endpoints live
in a single region.
External versus internal load balancing-- and what traffic
types are you going to serve?
STEPHANIE WONG: They would use external load balancers
to distribute traffic coming from the internet to their GCP
network and internal load balancers
to distribute traffic within their GCP network.
PRIYANKA VERGADIA: The external load balancing
includes four options--
the HTTP(S) load balancing, for a HTTP or HTTP(S)
traffic; the TCP proxy for TCP traffic,
for ports other than 80 and 8080 without SSL offload;
the SSL proxy, for SSL offload on ports other than 80 or 8080;
or the network load balancing, for TCP or UDP traffic.
STEPHANIE WONG: While the global HTTP(S) load balancer
is for layer 7 traffic and is built using the Google frontend
engines at the edge of Google's network,
the regional network load balancer
is for the layer 4 traffic and is built using Maglevs.
Google built Maglevs in 2008 to load-balance all traffic that
comes into our data centers and distribute traffic
to the frontend engines at our network edges.
The traffic is distributed to a set
of regional backend instances.
PRIYANKA VERGADIA: I'm not going to lie, Stephanie,
Maglevs sound like delicious baked goods.
What makes them so special?
STEPHANIE WONG: Maglev was a break from traditional load
balancers in that it is software-based and operates
in an active-active scale-out architecture.
Maglev evenly distributes traffic
over hundreds of backends and minimizes the negative impact
of unexpected faults on connection-oriented protocols.
It's great for lightweight L4-based load balancing, where
you want to preserve the client IP address,
all the way to the backend instance,
and perform TLS termination on these instances.
PRIYANKA VERGADIA: As for HTTP(S) load balancers,
I mentioned that Google pushed load balancing out
to the edge network on frontend service,
as opposed to using traditional DNS-based approach.
So global load balancing capacity
can be behind a single anycast virtual IPv4 or IPv6 addresses.
This means you can deploy capacity in multiple regions,
without having to modify the DNS entries
or add new load balancer IP addresses for new regions.
So it's clear that with global HTTP(S) load balancing,
you get cross-regional failover and overflow.
STEPHANIE WONG: And the distribution algorithm
automatically directs traffic to the next closest instance
with available capacity in the event of a failure of or lack
of capacity, for instances in the region closest to the end
user.
We'll cover this more in the next couple of episodes.
PRIYANKA VERGADIA: GCP also offers proxy-based load
balancers for TCP and SSL traffic.
And they use the same globally distributed infrastructure.
Generally speaking, your decision to use them
would depend on whether you require SSL offload or not.
You can find out more in the links below.
Now let's get back to Beyond Treat.
In Beyond Treat's case, we are only
going to receive HTTP and HTTP(S) traffic,
so they will choose HTTP(S) load balancer.
But, like most companies, the website
also has private workloads, such as application servers
that need to be protected from the public internet.
Those services need to scale and grow
behind a private watchful IP that is accessible only
by internal instances.
STEPHANIE WONG: For this, their best option
is the regional layer 7 internal load
balancing based on Google's Andromeda network
virtualization stack.
Similar to the HTTP(S) load balancer and the network load
balancer, internal layer 7 load balancing
is neither a hardware appliance nor an instance-based solution
and can support as many connections per second
as you need, since there is no load
balancer in the path between your client
and the backend instances.
PRIYANKA VERGADIA: Over the next few videos,
we'll follow Beyond Treats as they grow,
and even experience unpredictable spikes
in traffic, like when it's International Dog Day and Big
Bone treat orders are up the wazoo.
This makes their website an ideal candidate
for explaining all the load balancing options
you have at your disposal.
STEPHANIE WONG: But, of course, you
can apply these principles described in these videos
to a wide range of workloads.
PRIYANKA VERGADIA: Well, there you have it.
STEPHANIE WONG: Load balancing deconstructed--
my dog is going to be so excited,
and he might even make an appearance next time.
PRIYANKA VERGADIA: Wow.
That's all for today on Get Cooking in Cloud.
We are hoping that you are making the correct load
balancing choice for your architecture.
If you would like to see more such content,
don't forget to like and subscribe to our channel.
[MUSIC PLAYING]