Chapter 18: Load Balancing
Let's go. In Chapter 17 we added a second server. Today we see how the visitor still uses one name, and the request goes to whichever server is healthy. Don't worry, you will get it.
चला मित्रांनो, Chapter 17 मध्ये आपण दुसरा server लावला. आज बघूया visitor ला एकाच नाव दिसत, आणि मागचा server healthy असेल त्याच्याकडे request जातोय. घबरू नका, कळेल तुम्हाला.
चलो दोस्तों, Chapter 17 में हमने दूसरा server लगाया. आज देखें visitor को एक ही नाम दिखता है, और पीछे का server healthy हो तो request उसी के पास जाता है. घबराओ मत, समझ आएगा.
What you will learn in this chapter
- Why one DNS name can hide more than one server
- What a load balancer does with one request, step by step
- How many EC2 instances sit behind it, and why the balancer itself is not one of them
- Manual balancing with two IP addresses, and what breaks when one server dies
- Which balancer to choose: manual DNS, Application, Network, Gateway, or Classic
- A target group: health checks, registering EC2, one listener, and a path rule
- Round robin, least outstanding requests, and host or path rules
- Application Load Balancer: example.com and api.example.com
- Network Load Balancer: TCP port 443 passed through
- Gateway Load Balancer, in brief, for a firewall appliance
- Why you do not create a new Classic Load Balancer
- One app in two regions: each region has its own balancer
- How this attaches to the Auto Scaling group from Chapter 17
- Several target groups on one balancer, and more than one HTTP listener
- A health check with numbers you set, and a
/healthpath that returns 200 - Internet-facing and internal balancers, and where each one sits in three tiers
- Cross-zone load balancing on and off, and one domain name in front of two regions
This chapter uses the two EC2 instances and the target group idea from Chapter 17, Nginx or Apache from Chapters 6 and 8, and DNS from Chapter 9. The site name in every example is example.com. Keep the console in Asia Pacific (Mumbai) ap-south-1 until the region section says otherwise. Do every step yourself. When the lab is finished, delete the load balancer. Do not leave it running.
People already know the feeling of one front door and many workers, even if they have never opened this console.
| What you have seen | The honest lesson | What this chapter will not invent |
|---|---|---|
| Flipkart on a sale day | Shoppers type one name. Something in front has to send each click to a server that is still answering | Flipkart's private design |
| Amazon on a sale day | Same shape: one website name, many servers behind it | Amazon's real catalog or server count |
| Netflix when a new title opens | Many people press play. The front door spreads those requests | Netflix's real video path |
| Paytm in the week salaries arrive | Many people open the app on the same morning. A dead server should not keep receiving them | Paytm's real payment design |
example.com in this lab is a small teaching site, not those apps. The shape is the same. Users remember one name. You decide which healthy computer answers.
User types example.com
|
v
DNS returns the load balancer's name
|
v
Load balancer (not an EC2 you installed Nginx on)
|
+--> EC2 A healthy "This is server A"
|
+--> EC2 B healthy "This is server B"
A stopped instance is not in this list.
The balancer does not send the request there.
Concepts in this chapter
- 18.1How a load balancer actually works
- 18.2How many EC2 instances
- 18.3Manual load balancing
- 18.4Which load balancer to use
- 18.5Target groups
- 18.6Routing policy
- 18.7Application Load Balancer
- 18.8Network Load Balancer
- 18.9Gateway Load Balancer
- 18.10Classic Load Balancer
- 18.11One app, multiple regions
- 18.12How this connects to scaling
- 18.13Multiple target groups
- 18.14Different HTTP listeners
- 18.15Health checks
- 18.16Internet-facing and internal load balancers
- 18.17Load balancer in a three-tier architecture
- 18.18Cross-zone load balancing, enabled and disabled
- 18.19One domain name, many regions, many load balancers