🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🛎️ धडा 10 — Load balancing: अनेक डेस्कसाठी एक reception

📍 तुम्ही इथे आहात: 12 पैकी धडा 10 · मागील: lesson-09-auto-scaling · पुढील: lesson-11-monitoring

📦 या ब्रँचमध्ये काय आहे

धडे 01–09, आणि load balancer: listeners, target groups, thresholds सह health checks, आणि फक्त निरोगी डेस्कनाच पाहुणे मिळतील हा नियम — हे सगळे ec2/fleet.py मधील elb() फेरीफेरीने simulate करते.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

कोणता डेस्क मोकळा आहे हे पाहुण्यांना माहीत असण्याची गरज नसावी. म्हणून अभ्यासिकेच्या प्रवेशद्वारावर एकच सुप्रसिद्ध पत्ता असलेले एक reception 🛎️ आहे. Receptionist प्रत्येक पाहुण्याला आळीपाळीने पुढच्या डेस्ककडे पाठवते.

दर 10 सेकंदांनी receptionist प्रत्येक डेस्कला फोन करते: "सगळे ठीक?" (एक health check). जो डेस्क सलग दोनदा उत्तर देत नाही तो unhealthy ठरवला जातो — तिथे आणखी पाहुणे जात नाहीत. तो पुन्हा सलग तीनदा उत्तर देतो तेव्हा तो निरोगी ठरतो आणि पुन्हा फेरीत येतो. पाहुण्यांना हे कळतही नाही; इतर डेस्क फक्त थोडा वेळ जरा जास्त व्यस्त होतात.

धडा 09 मधला काळजीवाहकही receptionist चे ऐकतो: जो डेस्क unhealthy च राहतो तो बाहेर नेला जातो आणि बदलला जातो.

🗺️ आकृती

flowchart LR
    users["🌍 visitors"]
    alb["🛎️ load balancer<br/>listener :443"]
    tg["🎯 target group<br/>health check every 10 s<br/>2 fails → unhealthy · 3 passes → healthy"]
    a["🖥️ web-a ✅ 6"]
    b["🖥️ web-b 🚫 0<br/>t=30s to t=60s"]
    c["🖥️ web-c ✅ 6"]
    users -->|"1"| alb -->|"2"| tg
    tg -->|"3 round robin over healthy only"| a
    tg -.->|"no traffic while unhealthy"| b
    tg --> c
    back["t=70s: web-b passed 3 checks → back to 4 · 4 · 4"]
    b -.->|"4"| back

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/ec2/lesson-diagrams.html#l10

❓ काय

Elastic Load Balancing — तुम्हाला भेटतील असे तीन प्रकार: Application Load Balancer (ALB, layer 7: HTTP/HTTPS, path आणि host name नुसार routing, ACM certificates सह TLS), Network Load Balancer (NLB, layer 4: TCP/UDP/TLS, खूप जास्त throughput, static IPs), आणि Gateway Load Balancer (मधोमध बसणाऱ्या network appliances साठी).
Listener → rules → target group → targets — listener एक port आणि protocol घेतो, rules एक target group निवडतात, आणि target group मध्ये instances (किंवा IPs, किंवा Lambda functions) असतात. ASG आपले instances आपोआप register आणि deregister करतो.
Health checks — प्रत्येक target group साठी: path (उदा. /), interval, timeout, unhealthy threshold आणि healthy threshold. ALB चे defaults म्हणजे 30 सेकंदांचा interval, 5 सेकंदांचा timeout, 5 passes नंतर healthy आणि 2 fails नंतर unhealthy; गोष्ट एका screen वर बसावी म्हणून हा lab 10 s / 3 / 2 वापरतो. जर प्रत्येक target unhealthy असेल, तर ALB fail open होतो आणि traffic सगळ्यांनाच पाठवतो.
Deregistration delay (connection draining, default 300 s) — निघणारा target काढला जाण्याआधी त्याचे चालू requests पूर्ण करतो.
Cross-zone load balancing — ALBs साठी default ने चालू, म्हणजे कमी डेस्क असलेल्या AZ ला अन्यायकारक वाटा मिळत नाही.
साखळीतले security groups — ALB चा SG internet वरून 443 ला परवानगी देतो; डेस्कचा SG app port ला फक्त ALB च्या SG कडून परवानगी देतो (धडा 05).
ASG + ELB health checks — ASG चा health-check type ELB ठेवा, म्हणजे चालू असून सेवा न देणारा डेस्क फक्त टाळला न जाता बदलला जातो.

🤔 का

कारण मागचे डेस्क येत-जात असताना (धडा 09) clients ना एक स्थिर पत्ता हवा असतो. आणि कारण health check मुळेच "एक डेस्क मोडला, एक-तृतीयांश पाहुण्यांना errors दिसतात" आणि "एक डेस्क मोडला, कोणालाच कळत नाही" यातला फरक पडतो.

🔧 कसे (या repo मध्ये)

ec2/fleet.py मधील elb(target_health, requests, interval, unhealthy_threshold, healthy_threshold) प्रत्येक target साठी pass/fail निकालांची यादी घेते, प्रत्येक फेरीत thresholds लावते, आणि त्या क्षणी निरोगी असलेल्या targets वर 12 requests round robin ने वाटते. ec2/demo.py मधील balancing() web-b ला तीन फेऱ्यांसाठी नापास करते आणि परत आणते. Tests L10 तपासतात की unhealthy target ला traffic मिळत नाही आणि तो परत येतो.

🧪 करून पाहा

python3 ec2/demo.py balancing
python3 - <<'EOF'
import sys; sys.path.insert(0, "ec2"); import fleet
# a flapping desk: pass, fail, pass, fail… it never fails twice in a row, so it is never marked unhealthy
flap = [True, False] * 4
for t, state, spread in fleet.elb({"web-a": [True] * 8, "web-b": flap}):
    print(f"t={t:>2}s", state, spread)
EOF

खऱ्या account वर (AWS credentials, तुमचे स्वतःचे VPC, subnets, SG आणि ASG लागतात; load balancer चे तासाला बिल लागते — काम झाल्यावर तो delete करा):

TG_ARN=$(aws elbv2 create-target-group --name school-web --protocol HTTP --port 80 --vpc-id vpc-0123456789abcdef0 \
    --health-check-path / --health-check-interval-seconds 10 \
    --healthy-threshold-count 3 --unhealthy-threshold-count 2 \
    --query 'TargetGroups[0].TargetGroupArn' --output text)
LB_ARN=$(aws elbv2 create-load-balancer --name school-web --type application \
    --subnets subnet-0aaa1111 subnet-0bbb2222 --security-groups sg-0123456789abcdef0 \
    --query 'LoadBalancers[0].LoadBalancerArn' --output text)
aws elbv2 create-listener --load-balancer-arn "$LB_ARN" --protocol HTTP --port 80 \
    --default-actions Type=forward,TargetGroupArn="$TG_ARN"
aws autoscaling attach-load-balancer-target-groups --auto-scaling-group-name school-web \
    --target-group-arns "$TG_ARN"
aws autoscaling update-auto-scaling-group --auto-scaling-group-name school-web \
    --health-check-type ELB --health-check-grace-period 120
aws elbv2 describe-target-health --target-group-arn "$TG_ARN"

✅ तपासा — तुम्हाला काय दिसायला हवे

balancing छापते t=10s web-a:✅ 4 web-b:✅ 4 web-c:✅ 4 आणि 20 s ला तेच; t=30s ला — web-b चा दुसरा check नापास झाल्यावर — web-a:✅ 6 web-b:🚫 0 web-c:✅ 6, आणि t=60s पर्यंत असेच राहते; t=70s ला, तीन passes नंतर, पुन्हा web-a:✅ 4 web-b:✅ 4 web-c:✅ 4. तुमचा flapping डेस्क प्रत्येक फेरीत {'web-a': 'healthy', 'web-b': 'healthy'} {'web-a': 6, 'web-b': 6} छापतो: तो निम्मे checks नापास होतो, तरी कधीही सलग दोनदा नाही, म्हणून त्याला निम्मा traffic मिळत राहतो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

Reception फक्त checks पास होणाऱ्या डेस्ककडेच पाहुणे पाठवते, बरा झालेला डेस्क त्याने स्वतःला सिद्ध केल्यानंतरच परत घेते — आणि नेमक्या चुकीच्या लयीत नापास होणारा डेस्क निसटू शकतो, म्हणूनच तुम्ही error rates वरही लक्ष ठेवता.

⚠️ नेहमीच्या चुका

database लागणाऱ्या path वर health check — एक संथ database एकदम प्रत्येक डेस्कला unhealthy ठरवतो
app मोडलेले असतानाही 200 परत करणारा / वरचा health check — काहीतरी अर्थपूर्ण, आणि स्वस्त, तपासा
डेस्कचा SG फक्त ALB च्या SG ऐवजी internet साठी उघडा
ASG चा health-check type EC2 वरच ठेवलेला, त्यामुळे चालू-पण-मोडलेला डेस्क कधीच बदलला जात नाही
deregistration delay विसरणे आणि मग scale-in किंवा deploys ला पाच मिनिटे का लागतात याचे आश्चर्य वाटणे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: ALB म्हणजे जिथे TLS संपतो, जिथून access logs आणि HTTPCode_Target_5XX_Count येतात, आणि जिथे AWS WAF जोडला जातो. Incident मध्ये कोणीही उघडणारा पहिला graph म्हणजे त्याचा target health.

⏭️ पुढे

Fleet स्वतःच चालतो — काहीतरी विचित्र घडेपर्यंत. दोन status checks, दोन वेगळे उपाय, आणि hypervisor ला न दिसणारे आकडे: monitoring आणि troubleshooting.

git checkout lesson-11-monitoring

🛎️ Lesson 10 — Load balancing: one reception for many desks

📍 You are here: Lesson 10 of 12 · Previous: lesson-09-auto-scaling · Next: lesson-11-monitoring

📦 What's in this branch

Lessons 01–09, plus the load balancer: listeners, target groups, health checks with thresholds, and the rule that only healthy desks get visitors — simulated round by round by elb() in ec2/fleet.py.

🧒 Explain like I'm 5

Visitors should not have to know which desk is free. So the study hall has one reception 🛎️ at the entrance with one well-known address. The receptionist sends each visitor to the next desk in turn.

Every 10 seconds the receptionist rings each desk: "are you OK?" (a health check). A desk that fails to answer twice in a row is marked unhealthy — no more visitors go there. When it answers three times in a row again, it is healthy and back in the rotation. The visitors never notice; the other desks just get a little busier for a while.

The caretaker from lesson 09 listens to the receptionist too: a desk that stays unhealthy is carried out and replaced.

🗺️ Diagram

flowchart LR
    users["🌍 visitors"]
    alb["🛎️ load balancer<br/>listener :443"]
    tg["🎯 target group<br/>health check every 10 s<br/>2 fails → unhealthy · 3 passes → healthy"]
    a["🖥️ web-a ✅ 6"]
    b["🖥️ web-b 🚫 0<br/>t=30s to t=60s"]
    c["🖥️ web-c ✅ 6"]
    users -->|"1"| alb -->|"2"| tg
    tg -->|"3 round robin over healthy only"| a
    tg -.->|"no traffic while unhealthy"| b
    tg --> c
    back["t=70s: web-b passed 3 checks → back to 4 · 4 · 4"]
    b -.->|"4"| back

🗺️ Drawn version + a lab: https://school-edh.pages.dev/ec2/lesson-diagrams.html#l10

❓ What

Elastic Load Balancing — three kinds you will meet: Application Load Balancer (ALB, layer 7: HTTP/HTTPS, routing by path and host name, TLS with ACM certificates), Network Load Balancer (NLB, layer 4: TCP/UDP/TLS, very high throughput, static IPs), and Gateway Load Balancer (for inline network appliances).
Listener → rules → target group → targets — the listener takes a port and protocol, rules pick a target group, and the target group holds instances (or IPs, or Lambda functions). An ASG registers and deregisters its instances automatically.
Health checks — per target group: path (for example /), interval, timeout, unhealthy threshold and healthy threshold. ALB defaults are a 30-second interval, 5-second timeout, healthy after 5 passes and unhealthy after 2 fails; this lab uses 10 s / 3 / 2 so the story fits on a screen. If every target is unhealthy, an ALB fails open and sends traffic to all of them.
Deregistration delay (connection draining, default 300 s) — a leaving target finishes its in-flight requests before it is removed.
Cross-zone load balancing — on by default for ALBs, so an AZ with fewer desks does not get an unfair share.
Security groups, chained — the ALB's SG allows 443 from the internet; the desks' SG allows the app port only from the ALB's SG (lesson 05).
ASG + ELB health checks — set the ASG's health-check type to ELB so a desk that is running but not serving is replaced, not just skipped.

🤔 Why

Because clients need one stable address while the desks behind it come and go (lesson 09). And because a health check is the difference between "one desk is broken, a third of the visitors see errors" and "one desk is broken, nobody notices".

🔧 How (in this repo)

elb(target_health, requests, interval, unhealthy_threshold, healthy_threshold) in ec2/fleet.py takes a list of pass/fail results per target, applies the thresholds each round, and spreads 12 requests round robin over the targets that are currently healthy. balancing() in ec2/demo.py fails web-b for three rounds and brings it back. Tests L10 check that the unhealthy target gets no traffic and that it returns.

🧪 Try it

python3 ec2/demo.py balancing
python3 - <<'EOF'
import sys; sys.path.insert(0, "ec2"); import fleet
# a flapping desk: pass, fail, pass, fail… it never fails twice in a row, so it is never marked unhealthy
flap = [True, False] * 4
for t, state, spread in fleet.elb({"web-a": [True] * 8, "web-b": flap}):
    print(f"t={t:>2}s", state, spread)
EOF

On a real account (needs AWS credentials, your own VPC, subnets, SG and ASG; a load balancer bills by the hour — delete it when you are done):

TG_ARN=$(aws elbv2 create-target-group --name school-web --protocol HTTP --port 80 --vpc-id vpc-0123456789abcdef0 \
    --health-check-path / --health-check-interval-seconds 10 \
    --healthy-threshold-count 3 --unhealthy-threshold-count 2 \
    --query 'TargetGroups[0].TargetGroupArn' --output text)
LB_ARN=$(aws elbv2 create-load-balancer --name school-web --type application \
    --subnets subnet-0aaa1111 subnet-0bbb2222 --security-groups sg-0123456789abcdef0 \
    --query 'LoadBalancers[0].LoadBalancerArn' --output text)
aws elbv2 create-listener --load-balancer-arn "$LB_ARN" --protocol HTTP --port 80 \
    --default-actions Type=forward,TargetGroupArn="$TG_ARN"
aws autoscaling attach-load-balancer-target-groups --auto-scaling-group-name school-web \
    --target-group-arns "$TG_ARN"
aws autoscaling update-auto-scaling-group --auto-scaling-group-name school-web \
    --health-check-type ELB --health-check-grace-period 120
aws elbv2 describe-target-health --target-group-arn "$TG_ARN"

✅ Verify — what you should see

balancing prints t=10s web-a:✅ 4 web-b:✅ 4 web-c:✅ 4 and the same at 20 s; at t=30s — after web-b's second failed check — web-a:✅ 6 web-b:🚫 0 web-c:✅ 6, staying that way to t=60s; at t=70s, after three passes, back to web-a:✅ 4 web-b:✅ 4 web-c:✅ 4. Your flapping desk prints {'web-a': 'healthy', 'web-b': 'healthy'} {'web-a': 6, 'web-b': 6} in every round: it fails half its checks, yet never twice in a row, so it keeps getting half the traffic.

🏁 What you just proved

The reception only sends visitors to desks that pass their checks, takes a recovered desk back only after it proves itself — and a desk that fails in just the wrong rhythm can slip through, which is why you also watch error rates.

⚠️ Common mistakes

a health check on a path that needs the database — one slow database marks every desk unhealthy at once
a health check on / that returns 200 even when the app is broken — check something meaningful, and cheap
desks' SG open to the internet instead of only to the ALB's SG
ASG health-check type left at EC2, so a running-but-broken desk is never replaced
forgetting the deregistration delay and wondering why scale-in or deploys take five minutes

🏭 Why this matters in production: the ALB is where TLS ends, where access logs and HTTPCode_Target_5XX_Count come from, and where AWS WAF attaches. Its target health is the first graph anyone opens in an incident.

⏭️ Next

The fleet runs itself — until something odd happens. Two status checks, two different fixes, and the numbers the hypervisor cannot see: monitoring and troubleshooting.

git checkout lesson-11-monitoring

← Previousauto scaling Next →monitoring

This page is the lesson's README from the lesson-10-load-balancing branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.