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

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

📈 धडा 06 — Auto Scaling: रांग वाढली की जास्त खिडक्या

📍 तुम्ही इथे आहात: 13 पैकी धडा 06 · मागे: lesson-05-stateless-load-balancer · पुढे: lesson-07-kubernetes-scaling

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

धडे 01–05, आणि त्याशिवाय आपोआप जोडले आणि काढले जाणारे servers: target tracking (servers सुमारे 60% व्यस्त ठेवा), प्रत्येक नव्या server ला उशीर करणारा warm-up, माहीत असलेल्या गर्दीआधी scheduled scaling, आणि हळूहळू scale in. scale/demo.py मधले autoscale() निकालाच्या दिवसाची 12 मिनिटे चालवून दाखवते.

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

दीपिकाचा एक नियम आहे: "प्रत्येक कारकून दर 10 मिनिटांपैकी सुमारे 6 मिनिटे व्यस्त असावी". त्या जास्त व्यस्त असतील तर ती staff room मधून आणखी कारकून बोलावते.

पण नव्या कारकुनाला चालत येऊन, टेबल लावून आणि पैशांची पेटी उघडायला 2 मिनिटे लागतात. निकाल लागतो. एका मिनिटात गर्दी 150 पालकांवरून 900 होते, मग 1,800. दीपिका लगेच कारकून बोलावते — पण दोन मिनिटे फक्त जुन्या 2 खिडक्याच उघड्या असतात, आणि रांग फाटकाबाहेर जाते.

पुढच्या वर्षी दीपिका जास्त हुशार असते. निकाल कधी लागणार हे तिला माहीत असते. म्हणून ती 20 कारकुनांना त्या वेळेच्या आधीच आपापल्या टेबलांवर यायला सांगते. रांगच नाही.

गर्दी घरी गेल्यावर ती कारकुनांना एकेक करून परत पाठवते, न जाणो दुसरी लाट आली तर.

🗺️ आकृती

flowchart LR
    cw["📊 CloudWatch metric<br/>CPU or requests per target"] --> tt["🎯 target tracking<br/>keep it near 60%"]
    tt -->|"too busy: add"| asg["📈 Auto Scaling group<br/>min 2 · max 20"]
    tt -->|"too idle: remove one"| asg
    sch["🗓️ scheduled action<br/>min 20 before results"] --> asg
    asg --> wu["⏳ warm-up 2 min<br/>then it serves"]
    wu --> alb["⚖️ load balancer targets"]

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

❓ काय

EC2 Auto Scaling group (ASG) — एकाच launch template पासून बनलेल्या एकसारख्या instances चा गट, ज्याला minimum, maximum आणि desired संख्या असते. तो unhealthy instances बदलतो आणि नव्या instances load balancer च्या target group मध्ये register करतो.
Scaling policies:
- Target tracking — "सरासरी CPU 60% वर ठेवा" किंवा "ALBRequestCountPerTarget N वर ठेवा". ASG हिशोब करतो, thermostat सारखा.
- Step scaling — "CPU > 70% असेल तर 2 जोडा; > 85% असेल तर 5", CloudWatch alarms वरून.
- Scheduled scaling — ठरलेल्या वेळी min / max / desired बदला. माहीत असलेल्या events साठी.
- Predictive scaling — मागच्या रोजच्या आणि आठवड्याच्या patterns वरून अंदाज करून load येण्याच्या आधीच scale करते.
Instance warm-up — नव्या instance चे metrics मोजले जाण्याआधी आणि तो आपला वाटा घेऊ शकण्याआधी त्याला लागणारा वेळ (boot, app सुरू करणे, caches भरणे). तो गटाच्या default instance warm-up ने ठरवा.
Cooldown — scaling activity नंतरचा विराम, simple scaling policies वापरतात. Target tracking आणि step scaling त्याऐवजी warm-up वापरतात.
Scale-in protection — scale in करताना ASG ने काढू नयेत अशा instances ना खूण करते (उदाहरणार्थ मोठे काम संपवत असलेला instance).
हळूहळू scale in — target tracking क्षमता जोडण्यापेक्षा काढताना जास्त काळजी घेतो. दुसरी लाट येणे नेहमीचे आहे.

🤔 का

कारण एक सकाळ टिकण्यासाठी वर्षभर 20 servers चे पैसे भरणे म्हणजे उधळपट्टी, आणि त्या सकाळी 2 servers म्हणजे outage. Auto Scaling load च्या मागोमाग जाते. पण ते प्रतिक्रिया देते: ते गर्दी पाहते, मग servers मागते, मग ते warm up होईपर्यंत थांबते. येताना दिसणाऱ्या गर्दीसाठी — 9:00 ला निकाल — scheduled action कोणत्याही प्रतिक्रियेपेक्षा सरस ठरते.

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

scale/sim.py मधले autoscale(load, per_server, target=0.6, start=2, lo=2, hi=20, warmup=2) दर मिनिटाला एक पाऊल टाकते. त्याला हवे असलेले servers ते मोजते (ceil(rps / (per_server × 0.6)), lo आणि hi च्या मध्ये ठेवून), नवे servers मागवते जे warmup मिनिटांनंतर सेवा द्यायला लागतात, आणि कमी हवे असतील तेव्हा मिनिटाला एक server काढते. प्रत्येक ओळ म्हणजे (मिनिट, req/s, सेवा देणारे, व्यस्त %, क्षमतेपेक्षा जास्त requests — प्रत्यक्षात हळू उत्तरे किंवा 5xx errors). Model मध्ये policy ला खरी मागणी दिसते, request-count metric सारखी; CPU metric 100% वर थांबतो आणि गर्दी किती मोठी आहे ते लपवतो.

🧪 करून पाहा

python3 scale/demo.py autoscale
python3 - <<'EOF'
import sys; sys.path.insert(0, "scale"); from sim import autoscale
load = [150, 150, 900, 1800, 2400, 2400, 2400, 1200, 600, 300, 300, 300]
for label, kw in (("as in the demo", {}), ("warm-up 1 minute", dict(warmup=1)), ("warm-up 4 minutes", dict(warmup=4)),
                  ("max size 30", dict(hi=30)), ("scheduled: min 20 all day", dict(start=20, lo=20))):
    rows = autoscale(load, 150, **kw)
    print(f"{label:<26} over capacity (sum) {sum(r[4] for r in rows):>5} · most servers {max(r[2] for r in rows)} · util at minute 6: {rows[6][3]}%")
EOF
python3 scale/test_scale.py

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

autoscale हे print करते (पहिल्या ओळी):

   min  req/s  serving  util  over capacity (slow / 5xx)
     0    150        2   50%        0
     1    150        2   50%        0
     2    900        2  100%      600
     3   1800        2  100%     1500
     4   2400       10  100%      900
     5   2400       20   80%        0

मग 7 1200 20 40% 0, 8 600 19 21% 0 … खाली 11 300 16 12% 0 पर्यंत — दर मिनिटाला एक server कमी.

तुमचा snippet हे print करतो:

as in the demo             over capacity (sum)  3000 · most servers 20 · util at minute 6: 80%
warm-up 1 minute           over capacity (sum)   900 · most servers 20 · util at minute 6: 80%
warm-up 4 minutes          over capacity (sum)  7200 · most servers 20 · util at minute 6: 100%
max size 30                over capacity (sum)  3000 · most servers 27 · util at minute 6: 59%
scheduled: min 20 all day  over capacity (sum)     0 · most servers 20 · util at minute 6: 80%

Tests मध्ये ✅ L06 new servers arrive only after the warm-up आणि ✅ L06 scale in one server at a time असतात.

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

गर्दीला किती त्रास होतो ते warm-up ठरवतो: 1 मिनिट → 900, 2 मिनिटे → 3,000, 4 मिनिटे → 7,200. मोठा maximum (30) गटाला 60% target गाठू देतो (27 servers, 59%) पण पहिल्या मिनिटांना मदत करत नाही — फक्त आधी आलेले servers करतात. Scheduled minimum overflow पूर्णपणे काढून टाकतो. आणि 20 servers वर गट 80% वर राहतो: त्याला 27 हवे असताना त्याच्या maximum ने त्याला 20 वर थांबवले.

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

खऱ्या peak साठी खूप कमी असलेला maximum (demo मधले 20 servers वर 80%)
खऱ्या boot वेळेपेक्षा कमी warm-up — नवे servers प्रत्यक्ष मदत करण्याआधीच मदत करतात असे गटाला वाटते, आणि तो जोडणे थांबवतो
database ची वाट पाहणाऱ्या app साठी CPU वर scale करणे — users थांबलेले असताना CPU कमीच राहतो; request count किंवा latency वर scale करा
scale out इतक्याच वेगाने scale in करणे, आणि मग दुसऱ्या लाटेसाठी पुन्हा warm-up ची किंमत मोजणे
Auto Scaling ला stateless app (धडा 05) आणि कोणत्याही हाताने करायच्या steps शिवाय तयार server पर्यंत boot होणारे launch template लागते हे विसरणे

🏭 प्रत्यक्ष वापरात

On a real account — requests per target वर target tracking (हा metric प्रत्येक target च्या मिनिटाच्या requests मोजतो: 90 req/s × 60 = 5,400), 2 मिनिटांचा default warm-up, आणि निकालाच्या दिवसाआधी scheduled minimum:

aws autoscaling update-auto-scaling-group --auto-scaling-group-name school-api \
    --min-size 2 --max-size 30 --default-instance-warmup 120

aws autoscaling put-scaling-policy --auto-scaling-group-name school-api \
    --policy-name requests-per-target --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{
      "TargetValue": 5400,
      "PredefinedMetricSpecification": {
        "PredefinedMetricType": "ALBRequestCountPerTarget",
        "ResourceLabel": "app/school-alb/50dc6c495c0c9188/targetgroup/school-api/6d0ecf831eec9f09" } }'

aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name school-api \
    --scheduled-action-name results-day --start-time 2026-05-20T03:00:00Z \
    --min-size 20 --desired-capacity 20
aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name school-api \
    --scheduled-action-name results-day-over --start-time 2026-05-20T09:00:00Z --min-size 2

मोठे काम संपवत असलेल्या एका instance चे संरक्षण करा:

aws autoscaling set-instance-protection --auto-scaling-group-name school-api \
    --instance-ids i-0123456789abcdef0 --protected-from-scale-in

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: event नंतर ASG चा activity history load balancer च्या 5xx count आणि p99 शी तुलना करा. नवे instances सेवेत येण्याआधी errors आले असतील, तर schedule आधी सुरू करा किंवा minimum वाढवा.

⏭️ पुढे

पूर्ण servers म्हणजे मोठी पावले, आणि त्यांना मिनिटे लागतात. Kubernetes वर अनेक लहान pods nodes वाटून घेतात — आणि दोन autoscalers असतात, प्रत्येकासाठी एक.

git checkout lesson-07-kubernetes-scaling

📈 Lesson 06 — Auto Scaling: more counters when the queue grows

📍 You are here: Lesson 06 of 13 · Previous: lesson-05-stateless-load-balancer · Next: lesson-07-kubernetes-scaling

📦 What's in this branch

Lessons 01–05, plus servers that are added and removed by themselves: target tracking (keep the servers about 60% busy), the warm-up that delays every new server, scheduled scaling before a known spike, and scaling in slowly. autoscale() in scale/demo.py plays 12 minutes of results day.

🧒 Explain like I'm 5

Dipika has a rule: "each clerk should be busy about 6 minutes in every 10". If they are busier, she calls more clerks from the staff room.

But a new clerk needs 2 minutes to walk over, set up the desk and open the cash box. The results go up. In one minute the crowd grows from 150 parents to 900, then 1,800. Dipika calls clerks at once — but for two minutes, only the old 2 counters are open, and the queue goes out of the gate.

Next year Dipika is smarter. She knows when the results go up. So she asks 20 clerks to be at their desks before that time. No queue at all.

When the crowd goes home, she sends clerks back one at a time, in case a second wave comes.

🗺️ Diagram

flowchart LR
    cw["📊 CloudWatch metric<br/>CPU or requests per target"] --> tt["🎯 target tracking<br/>keep it near 60%"]
    tt -->|"too busy: add"| asg["📈 Auto Scaling group<br/>min 2 · max 20"]
    tt -->|"too idle: remove one"| asg
    sch["🗓️ scheduled action<br/>min 20 before results"] --> asg
    asg --> wu["⏳ warm-up 2 min<br/>then it serves"]
    wu --> alb["⚖️ load balancer targets"]

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

❓ What

EC2 Auto Scaling group (ASG) — a group of identical instances from one launch template, with a minimum, a maximum and a desired count. It replaces unhealthy instances and registers new ones with the load balancer's target group.
Scaling policies:
- Target tracking — "keep average CPU at 60%" or "keep ALBRequestCountPerTarget at N". The ASG does the arithmetic, like a thermostat.
- Step scaling — "if CPU > 70% add 2; if > 85% add 5", from CloudWatch alarms.
- Scheduled scaling — change min / max / desired at a set time. For known events.
- Predictive scaling — forecasts from past daily and weekly patterns and scales before the load arrives.
Instance warm-up — how long a new instance needs before its metrics count and it can take its share (boot, start the app, fill caches). Set it with the group's default instance warm-up.
Cooldown — a pause after a scaling activity, used by simple scaling policies. Target tracking and step scaling use warm-up instead.
Scale-in protection — marks instances the ASG must not remove when it scales in (for example one that is finishing a long job).
Scale in slowly — target tracking removes capacity more carefully than it adds it. A second wave is common.

🤔 Why

Because paying for 20 servers all year to survive one morning is waste, and 2 servers on that morning is an outage. Auto Scaling follows the load. But it reacts: it sees the crowd, then asks for servers, then waits for them to warm up. For a spike you can see coming — results at 9:00 — a scheduled action beats any reaction.

🔧 How (in this repo)

autoscale(load, per_server, target=0.6, start=2, lo=2, hi=20, warmup=2) in scale/sim.py takes one step per minute. It computes the servers it wants (ceil(rps / (per_server × 0.6)), kept between lo and hi), orders new ones that start serving warmup minutes later, and removes one server a minute when it wants fewer. Each row is (minute, req/s, serving, busy %, requests over capacity — slow answers or 5xx errors in real life). In the model the policy sees the real demand, like a request-count metric; a CPU metric stops at 100% and hides how big the crowd is.

🧪 Try it

python3 scale/demo.py autoscale
python3 - <<'EOF'
import sys; sys.path.insert(0, "scale"); from sim import autoscale
load = [150, 150, 900, 1800, 2400, 2400, 2400, 1200, 600, 300, 300, 300]
for label, kw in (("as in the demo", {}), ("warm-up 1 minute", dict(warmup=1)), ("warm-up 4 minutes", dict(warmup=4)),
                  ("max size 30", dict(hi=30)), ("scheduled: min 20 all day", dict(start=20, lo=20))):
    rows = autoscale(load, 150, **kw)
    print(f"{label:<26} over capacity (sum) {sum(r[4] for r in rows):>5} · most servers {max(r[2] for r in rows)} · util at minute 6: {rows[6][3]}%")
EOF
python3 scale/test_scale.py

✅ Verify — what you should see

autoscale prints (first rows):

   min  req/s  serving  util  over capacity (slow / 5xx)
     0    150        2   50%        0
     1    150        2   50%        0
     2    900        2  100%      600
     3   1800        2  100%     1500
     4   2400       10  100%      900
     5   2400       20   80%        0

then 7 1200 20 40% 0, 8 600 19 21% 0 … down to 11 300 16 12% 0 — one server fewer each minute.

Your snippet prints:

as in the demo             over capacity (sum)  3000 · most servers 20 · util at minute 6: 80%
warm-up 1 minute           over capacity (sum)   900 · most servers 20 · util at minute 6: 80%
warm-up 4 minutes          over capacity (sum)  7200 · most servers 20 · util at minute 6: 100%
max size 30                over capacity (sum)  3000 · most servers 27 · util at minute 6: 59%
scheduled: min 20 all day  over capacity (sum)     0 · most servers 20 · util at minute 6: 80%

The tests include ✅ L06 new servers arrive only after the warm-up and ✅ L06 scale in one server at a time.

🏁 What you just proved

The warm-up decides how much the crowd suffers: 1 minute → 900, 2 minutes → 3,000, 4 minutes → 7,200. A bigger maximum (30) lets the group reach the 60% target (27 servers, 59%) but does not help the first minutes — only earlier servers do. The scheduled minimum removes the overflow completely. And at 20 servers the group sits at 80%: its maximum stopped it at 20 when it wanted 27.

⚠️ Common mistakes

a maximum that is too low for the real peak (the demo's 80% at 20 servers)
a warm-up that is shorter than the real boot time — the group thinks new servers help before they do, and stops adding
scaling on CPU for an app that waits on the database — CPU stays low while users wait; scale on request count or latency
scaling in as fast as scaling out, then paying the warm-up again for the second wave
forgetting Auto Scaling needs a stateless app (lesson 05) and a launch template that boots to a ready server with no hands-on steps

🏭 In production

On a real account — target tracking on requests per target (the metric counts requests per target per minute: 90 req/s × 60 = 5,400), a 2-minute default warm-up, and a scheduled minimum before results day:

aws autoscaling update-auto-scaling-group --auto-scaling-group-name school-api \
    --min-size 2 --max-size 30 --default-instance-warmup 120

aws autoscaling put-scaling-policy --auto-scaling-group-name school-api \
    --policy-name requests-per-target --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{
      "TargetValue": 5400,
      "PredefinedMetricSpecification": {
        "PredefinedMetricType": "ALBRequestCountPerTarget",
        "ResourceLabel": "app/school-alb/50dc6c495c0c9188/targetgroup/school-api/6d0ecf831eec9f09" } }'

aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name school-api \
    --scheduled-action-name results-day --start-time 2026-05-20T03:00:00Z \
    --min-size 20 --desired-capacity 20
aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name school-api \
    --scheduled-action-name results-day-over --start-time 2026-05-20T09:00:00Z --min-size 2

Protect one instance that is finishing a long job:

aws autoscaling set-instance-protection --auto-scaling-group-name school-api \
    --instance-ids i-0123456789abcdef0 --protected-from-scale-in

🏭 Why this matters in production: after the event, compare the ASG's activity history with the load balancer's 5xx count and p99. If errors came before the new instances were in service, start the schedule earlier or raise the minimum.

⏭️ Next

Whole servers are big steps and take minutes. On Kubernetes, many small pods share nodes — and there are two autoscalers, one for each.

git checkout lesson-07-kubernetes-scaling

← Previousstateless load balancer Next →kubernetes scaling

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