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

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

👯 धडा 09 — Auto Scaling: दिवसभर डेस्कची योग्य संख्या

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागील: lesson-08-pricing · पुढील: lesson-10-load-balancing

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

धडे 01–08, आणि Auto Scaling group (ASG): min, max आणि desired डेस्क, सरासरी CPU वर target tracking, warm-up, हळू आणि काळजीपूर्वक scale-in, आणि health-check replacement — हे सगळे ec2/fleet.py मधील asg() मिनिटामिनिटाने simulate करते.

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

अभ्यासिकेत एक काळजीवाहक 👯 आहे, आणि त्याच्या clipboard वर तीन आकडे आहेत: कधीही 2 पेक्षा कमी डेस्क नाहीत, कधीही 6 पेक्षा जास्त नाहीत, आणि प्रत्येक डेस्क साधारण निम्मा व्यस्त ठेवा (50%).

गर्दी आली आणि डेस्क 80% व्यस्त झाले की काळजीवाहक recipe card (धडा 03) वरून आणखी डेस्क आणतो. नव्या डेस्कना मोजणीत येण्याआधी तयार होण्यासाठी (warm-up) दोन-तीन मिनिटे लागतात — म्हणून घाबरून डेस्कमागून डेस्क मागवण्याऐवजी काळजीवाहक पुन्हा निर्णय घेण्यापूर्वी त्यांची वाट पाहतो.

गर्दी गेली की काळजीवाहक डेस्क एकेक करून, हळूहळू काढतो, कारण खूप घाईने काढले तर रांग पुन्हा लागते.

आणि एखादा डेस्क मोडला तर काळजीवाहक तो दुरुस्त करत नाही: तो बाहेर नेला जातो आणि recipe card वरून बनवलेला नवा डेस्क त्याची जागा घेतो.

🗺️ आकृती

flowchart LR
    lt["📇 launch template"]
    asg["👯 Auto Scaling group<br/>min 2 · max 6 · target 50% CPU"]
    cw["📈 average CPU of serving desks"]
    out["📈 CPU 80% → launch 2<br/>warm up 2 min before they count"]
    inn["📉 CPU 33% → remove ONE desk<br/>then wait — slowly, on purpose"]
    heal["💥 a desk fails its health check<br/>→ terminated, a fresh one launches"]
    lt --> asg
    cw -->|"1 above target"| out --> asg
    cw -->|"2 below target"| inn --> asg
    heal -->|"3 replace, never repair"| asg
    azs["🏢 desks spread over AZ-a, AZ-b, AZ-c"]
    asg --> azs

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

❓ काय

Auto Scaling group — launch template वरून launch केलेल्या instances चा संच, तुम्ही दिलेल्या subnets (AZs) मध्ये पसरलेला, min आणि max दरम्यान ठेवलेला, आणि desired capacity कडे पाहणारा. तो AZs मध्ये पुन्हा समतोल साधतो.
Scaling policies — target tracking (thermostat: "सरासरी CPU 50% ठेवा" — सहसा पहिली निवड), step scaling (प्रत्येक alarm पातळीसाठी स्पष्ट टप्पे), scheduled ("शाळेच्या दिवशी सकाळी 8 वाजता 8 डेस्क"), आणि predictive (रोजचे नमुने शिकून आधीच scale करतो).
Warm-up — नव्या instance चे metrics त्याचा warm-up वेळ संपेपर्यंत सरासरीतून वगळले जातात (group चा default instance warm-up), म्हणजे boot होणारा डेस्क रिकामा दिसत नाही आणि गर्दी दोनदा मोजली जात नाही.
Scale-in सावध असतो — target tracking पटकन scale out करतो आणि हळूहळू scale in करतो; खूप घाईने काढल्यास flapping होते. Instance scale-in protection आणि lifecycle hooks मुळे डेस्क जाण्याआधी काम पूर्ण करता येते.
Health checks — default म्हणून EC2 (status checks, धडा 11), किंवा ELB (load balancer चा health check, धडा 10) — launch नंतर एका grace period सह. Unhealthy instances terminate करून बदलले जातात.
Model मधले बारीक अक्षर — खरे target tracking अनेक data points वर CloudWatch alarms वापरते, त्यामुळे ते एका tick मध्ये नव्हे तर काही मिनिटांत प्रतिसाद देते; lab मधली ठरलेली 3 मिनिटांची scale-in प्रतीक्षा त्या सावधगिरीचे सोपे रूप आहे.

🤔 का

कारण peak साठी आकारलेला fleet रात्रभर पैसे वाया घालवतो, आणि सरासरीसाठी आकारलेला fleet दुपारच्या जेवणाच्या वेळी कोसळतो. ASG डेस्कची संख्या मागणीमागे चालायला लावतो — आणि तितकेच महत्त्वाचे म्हणजे, कोणालाही page न करता मोडलेले डेस्क नाहीसे करतो.

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

ec2/fleet.py मधील asg(load, target, min_size, max_size, capacity, warmup, fail_at, scale_in_cooldown) दर मिनिटाची मागणी घेते (एक डेस्क 100 units सेवा देतो), फक्त सेवा देणाऱ्या डेस्कवर CPU मोजते, min आणि max च्या आत desired ला ceil(serving × CPU / target) ठेवते, warm up होणारे डेस्क launch करते, थांबत थांबत एकेक डेस्क काढते, आणि निवडलेल्या मिनिटाला एखादा डेस्क नापास करू शकते. ec2/demo.py मधील scaling() 15 मिनिटांची सकाळ चालवते, ज्यात मिनिट 9 ला एक बिघाड होतो. Test L09 तपासते की group कधीही 2–6 च्या बाहेर जात नाही.

🧪 करून पाहा

python3 ec2/demo.py scaling
python3 - <<'EOF'
import sys; sys.path.insert(0, "ec2"); import fleet
# a lunchtime rush, with a higher target (70%) and a slower warm-up (3 min)
rush = [100, 100, 250, 400, 400, 400, 150, 100, 100, 100, 100, 100]
for r in fleet.asg(rush, target=70, warmup=3):
    print(f"min {r['minute']:>2} demand {r['demand']:>3} · desks {r['desks']} ({r['serving']} serving) · CPU {r['cpu']:>3}%  {r['note']}")
EOF

खऱ्या account वर (AWS credentials, धडा 03 मधला school-web launch template आणि तुमचे स्वतःचे subnet IDs लागतात; instances चालू असेपर्यंत बिल लागते — काम झाल्यावर min, max आणि desired 0 करा, किंवा group delete करा):

aws autoscaling create-auto-scaling-group --auto-scaling-group-name school-web \
    --launch-template 'LaunchTemplateName=school-web,Version=$Latest' \
    --min-size 2 --max-size 6 --desired-capacity 2 --default-instance-warmup 120 \
    --vpc-zone-identifier "subnet-0aaa1111,subnet-0bbb2222,subnet-0ccc3333"
aws autoscaling put-scaling-policy --auto-scaling-group-name school-web \
    --policy-name cpu-50 --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":50.0}'
aws autoscaling describe-scaling-activities --auto-scaling-group-name school-web --max-items 5
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name school-web --force-delete

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

scaling मध्ये मिनिट 3 ला desks 4 (2 serving) · CPU 80% 📈 CPU 80% > target 50% → launch 2 (warming up 2 min) दिसते, मिनिट 5 ला आणखी 2 launch होऊन कमाल 6 गाठले जाते, मिनिट 7 ला desks 6 (6 serving) · CPU 50%, मिनिट 8 ला 📉 quiet → scale in ONE desk, मिनिट 9 ला 💥 a desk fails its health check → terminated; a fresh one launches and warms up (5 डेस्क, 4 सेवा देणारे), आणि मिनिट 11 व 14 ला हळू scale-in होऊन desks 3 (3 serving) पर्यंत येते. तुमची गर्दी: मिनिट 3 ला फक्त 1 डेस्क launch होतो (CPU 100% वर थांबतो, त्यामुळे 250 ची मागणी कमी दाखवतो), मिनिट 4–5 तो warm up होण्याची वाट पाहतात, मिनिट 6 ला आणखी 2 launch होतात (desks 5 (3 serving)), आणि scale-in मिनिट 9 व 12 ला एकेक डेस्क करून होतो.

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

तुम्ही fleet मिनिटामिनिटाने समजून घेऊ शकता: तो उड्या मारत का वाढतो, warm-up ची वाट का पाहतो, हळूहळू का लहान होतो, आणि मोडलेला डेस्क कोणीही हात न लावता कसा बदलला जातो.

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

डेस्कवर sessions किंवा files ठेवणाऱ्या app ला scale करणे — आधी ते stateless करा (sessions database किंवा cache मध्ये, files S3 मध्ये)
"पैसे वाचवण्यासाठी" min = max = 1 — दुसरा AZ नाही, जादा जागा नाही, आपोआप बरे होणे नाही
खऱ्या boot वेळेपेक्षा कमी warm-up किंवा grace period — सुरू होत असतानाच डेस्क मारले जातात
अडथळा database किंवा queue असताना CPU वर scaling करणे — ज्या metric ला त्रास होतो त्यावर scale करा
चालू instance हाताने बदलणे — पुढच्या बदली डेस्कमध्ये तुमचा बदल नसेल

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: जवळपास प्रत्येक EC2 web tier म्हणजे load balancer मागे तीन AZs मध्ये पसरलेला ASG, target tracking आणि ELB health checks सह. त्यामुळे "पहाटे 3 वाजता server मेला" हा फोन कॉल न राहता activity history मधली एक ओळ बनतो.

⏭️ पुढे

सहा डेस्क, पाहुण्यांसाठी एकच पत्ता. Load balancing: एक reception, आणि फक्त निरोगी डेस्कनाच पाहुणे मिळतात.

git checkout lesson-10-load-balancing

👯 Lesson 09 — Auto Scaling: the right number of desks, all day

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-pricing · Next: lesson-10-load-balancing

📦 What's in this branch

Lessons 01–08, plus the Auto Scaling group (ASG): min, max and desired desks, target tracking on average CPU, warm-up, slow and careful scale-in, and health-check replacement — simulated minute by minute by asg() in ec2/fleet.py.

🧒 Explain like I'm 5

The study hall has a caretaker 👯 with three numbers on a clipboard: never fewer than 2 desks, never more than 6, and keep each desk about half busy (50%).

When a crowd arrives and the desks are 80% busy, the caretaker wheels in more desks from the recipe card (lesson 03). New desks need a couple of minutes to be set up (warm-up) before they count — so the caretaker waits for them before deciding again, instead of ordering desk after desk in a panic.

When the crowd leaves, the caretaker removes desks one at a time, slowly, because taking them away too fast just brings the queue back.

And if a desk breaks, the caretaker does not repair it: it is carried out and a fresh one from the recipe card takes its place.

🗺️ Diagram

flowchart LR
    lt["📇 launch template"]
    asg["👯 Auto Scaling group<br/>min 2 · max 6 · target 50% CPU"]
    cw["📈 average CPU of serving desks"]
    out["📈 CPU 80% → launch 2<br/>warm up 2 min before they count"]
    inn["📉 CPU 33% → remove ONE desk<br/>then wait — slowly, on purpose"]
    heal["💥 a desk fails its health check<br/>→ terminated, a fresh one launches"]
    lt --> asg
    cw -->|"1 above target"| out --> asg
    cw -->|"2 below target"| inn --> asg
    heal -->|"3 replace, never repair"| asg
    azs["🏢 desks spread over AZ-a, AZ-b, AZ-c"]
    asg --> azs

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

❓ What

Auto Scaling group — a set of instances launched from a launch template, across the subnets (AZs) you list, kept between min and max, aiming at desired capacity. It rebalances across AZs.
Scaling policies — target tracking (a thermostat: "keep average CPU at 50%" — the usual first choice), step scaling (explicit steps per alarm level), scheduled ("8 desks at 8 a.m. on school days"), and predictive (learns daily patterns and scales ahead).
Warm-up — a new instance's metrics are left out of the average until its warm-up time has passed (the group's default instance warm-up), so a booting desk does not look idle and a crowd is not double-counted.
Scale-in is conservative — target tracking scales out quickly and scales in gradually; removing too fast causes flapping. Instance scale-in protection and lifecycle hooks let you finish work before a desk goes.
Health checks — EC2 (the status checks, lesson 11) by default, or ELB (the load balancer's health check, lesson 10) — with a grace period after launch. Unhealthy instances are terminated and replaced.
The fine print of the model — real target tracking uses CloudWatch alarms over several data points, so it reacts in minutes, not in one tick; the lab's fixed 3-minute scale-in wait is a simplification of that caution.

🤔 Why

Because a fleet sized for the peak wastes money all night, and a fleet sized for the average falls over at lunchtime. An ASG makes the number of desks follow the demand — and, just as important, it makes broken desks disappear without anyone being paged.

🔧 How (in this repo)

asg(load, target, min_size, max_size, capacity, warmup, fail_at, scale_in_cooldown) in ec2/fleet.py takes demand per minute (one desk serves 100 units), computes CPU over the serving desks only, sets desired to ceil(serving × CPU / target) within min and max, launches desks that warm up, removes one desk at a time with a wait, and can fail a desk at a chosen minute. scaling() in ec2/demo.py runs a 15-minute morning with a failure at minute 9. Test L09 checks the group never leaves 2–6.

🧪 Try it

python3 ec2/demo.py scaling
python3 - <<'EOF'
import sys; sys.path.insert(0, "ec2"); import fleet
# a lunchtime rush, with a higher target (70%) and a slower warm-up (3 min)
rush = [100, 100, 250, 400, 400, 400, 150, 100, 100, 100, 100, 100]
for r in fleet.asg(rush, target=70, warmup=3):
    print(f"min {r['minute']:>2} demand {r['demand']:>3} · desks {r['desks']} ({r['serving']} serving) · CPU {r['cpu']:>3}%  {r['note']}")
EOF

On a real account (needs AWS credentials, the school-web launch template from lesson 03 and your own subnet IDs; instances bill while they run — set min, max and desired to 0, or delete the group, when you are done):

aws autoscaling create-auto-scaling-group --auto-scaling-group-name school-web \
    --launch-template 'LaunchTemplateName=school-web,Version=$Latest' \
    --min-size 2 --max-size 6 --desired-capacity 2 --default-instance-warmup 120 \
    --vpc-zone-identifier "subnet-0aaa1111,subnet-0bbb2222,subnet-0ccc3333"
aws autoscaling put-scaling-policy --auto-scaling-group-name school-web \
    --policy-name cpu-50 --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":50.0}'
aws autoscaling describe-scaling-activities --auto-scaling-group-name school-web --max-items 5
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name school-web --force-delete

✅ Verify — what you should see

scaling shows minute 3 desks 4 (2 serving) · CPU 80% 📈 CPU 80% > target 50% → launch 2 (warming up 2 min), minute 5 launching 2 more to the max of 6, minute 7 desks 6 (6 serving) · CPU 50%, minute 8 📉 quiet → scale in ONE desk, minute 9 💥 a desk fails its health check → terminated; a fresh one launches and warms up (5 desks, 4 serving), and slow scale-in at minutes 11 and 14 down to desks 3 (3 serving). Your rush: minute 3 launches only 1 desk (CPU is capped at 100%, so it under-reports a demand of 250), minutes 4–5 wait for it to warm up, minute 6 launches 2 more (desks 5 (3 serving)), and scale-in comes one desk at a time at minutes 9 and 12.

🏁 What you just proved

You can follow a fleet minute by minute: why it grows in jumps, why it waits for warm-up, why it shrinks slowly, and how a broken desk is replaced without anyone touching it.

⚠️ Common mistakes

scaling an app that keeps sessions or files on the desk — make it stateless first (sessions in a database or cache, files in S3)
min = max = 1 "to save money" — no second AZ, no headroom, no healing
a warm-up or grace period shorter than the real boot time — desks killed while still starting
scaling on CPU when the bottleneck is the database or a queue — scale on the metric that hurts
editing a running instance manually — the next replacement will not have your change

🏭 Why this matters in production: almost every EC2 web tier is an ASG across three AZs behind a load balancer, with target tracking and ELB health checks. It turns "a server died at 3 a.m." into a line in the activity history instead of a phone call.

⏭️ Next

Six desks, one address for visitors. Load balancing: one reception, and only healthy desks get visitors.

git checkout lesson-10-load-balancing

← Previouspricing Next →load balancing

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