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]
