What is Cloud Load Balancing?
Priyanka Vergadia
Staff Developer Advocate, Google Cloud
Let’s say your new application has been a hit. Usage is growing across the world and you now need to figure out how to scale, optimize, and secure the app while keeping your costs down and your users happy. That’s where Cloud Load Balancing comes in.
What is Cloud Load Balancing?
Cloud Load Balancing is a fully distributed load balancing solution that balances user traffic (HTTP(s), HTTPS/2 with gRPC, TCP/SSL, UDP, and QUIC) to multiple backends to avoid congestion, reduce latency, increase security, and reduce costs. It is built on the same frontend-serving infrastructure that powers Google, supporting 1 million+ queries per second with consistent high performance and low latency.
- Software-defined network (SDN) Cloud Load Balancing is not an instance- or device-based solution, which means you won't be locked into physical infrastructure or face HA, scale, and management challenges.
- Single global anycast IP and autoscaling: Cloud Load Balancing front-ends all your backend instances in regions around the world. It provides cross-region load balancing, including automatic multi-region failover, which gradually moves traffic in fractions if backends become unhealthy or scales automatically if more resources are needed.
How does Cloud Load Balancing work?
External load balancing
Consider the following scenario. You have a user, Shen, in California. You deploy your frontend instances in that region and configure a load-balancing Virtual IP (VIP). When your user base expands to another region, all you need to do is to create instances in additional regions. There is no change in the VIP or the DNS server settings. As your app goes global, the same patterns follow: Maya from India is routed to the instance closer to her in India. If the instances in India are overloaded and are autoscaling to handle the load, Maya will seamlessly be redirected to the other instances in the meantime and route back to India when instances have scaled sufficiently to handle the load. This is an example of external load balancing at Layer 7.
Internal load balancing
In any three-tier app, after the frontend you have the middleware and the data sources to interact with, in order to fulfill a user request. That's where you need Layer 4 internal load balancing between the frontend and the other internal tiers. Layer 4 internal load balancing is for TCP/UDP traffic behind RFC 1918 VIP, where the client IP is preserved.
You get automatic heath checks and there is no middle proxy; it uses the SDN control and data plane for load balancing.
How to use global HTTP(S) load balancing
For global HTTP(s) load balancing the Global Anycast VIP (IPv4 or IPv6) is associated with a forwarding rule, which directs traffic to a target proxy.
The target proxy terminates the client session, and for HTTPs you deploy your certificates at this stage, define the backend host, and define the path rules. The URL map provides Layer 7 routing and directs the client request to the appropriate backend service.
The backend services can be managed instance groups (MIGs) for compute instances, or network endpoint groups (NEGs) for your containerized workloads. This is also where service instance capacity and health is determined.
Cloud CDN is enabled to cache content for improved performance. You can set up firewall rules to control traffic to and from your backend.
The internal load balancing setup works the same way; you still have a forwarding rule but it points directly to a backend service. The forwarding rule has the Virtual IP address, Protocol, and up to five ports.
How to secure your application with Cloud Load Balancing
As a best practice,run SSL everywhere. With HTTPS and SSL proxy load balancing you can use managed certs, for which Google takes care of the provisioning and managing the SSL certificate lifecycle.
Cloud Load Balancing supports multiple SSL certificates, enabling you to serve multiple domains using the same load balancer IP address and port.
It absorbs and dissipates layer 3 and layer 4 volumetric attacks across Google’s global load balancing infrastructure
Additionally, with Cloud Armor, you can protect against Layer 3 to Layer 7 application level attacks
By using Identity Aware Proxy and firewalls you can authenticate and authorize access to backend services.
How to choose the right load balancing option
When deciding which load balancing option is right for your use case, consider factors such as: Internal vs external, global vs regional and type of traffic (HTTPs, TLS, or UDP)
If you are looking to reduce latency, improve performance, enhance security, and lower costs for your backend systems then check out Cloud Load Balancing. It is easy to deploy in just a few clicks; simply set up the frontend and backends associated with global VIP and you are good to go! For a more in-depth look into the service check out the documentation.
For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev