Autoscaling — scaling policy, health check আর instance group

১ · Instance group — min, desired আর max

ঈদের আগের সন্ধ্যায় বাসের টিকিট কাউন্টারের কথা ভাবুন। সকালে দুটি কাউন্টার খোলা, সন্ধ্যায় ভিড় বাড়লে মালিক আরও চারটি খোলেন, রাতে আবার বন্ধ করেন। Autoscaling এই সিদ্ধান্তটিই যন্ত্রের হাতে দেয়: চাপ মেপে server-এর সংখ্যা নিজে থেকে বাড়ানো আর কমানো। এটি elasticity-র (পর্ব ০৪) ব্যবহারিক রূপ।

Horizontal scaling কেন কাজ করে, stateless হওয়া কেন শর্ত, এই তত্ত্ব আছে System Design-এর scaling পর্বে। এখানে আমাদের প্রশ্ন আলাদা: বাস্তবে এটি কীভাবে সাজাবেন, চালাবেন আর ঠিক করবেন?

Autoscaling একা একটি VM-এর ওপর চলে না। চলে একটি instance group-এর ওপর, অর্থাৎ একই ছাঁচের VM-এর দলের ওপর। ছাঁচটি হলো launch template: কোন image (পর্ব ১৬), কোন instance type (পর্ব ১৫), কোন network আর কোন cloud-init script. দলের সংখ্যা ঠিক হয় তিনটি মান দিয়ে:

• Min: এর নিচে কখনো নামবে না। চাপ শূন্য হলেও এতগুলো চালু থাকবে।
• Desired: এই মুহূর্তে কতটি থাকা উচিত। Autoscaler শুধু এই সংখ্যাটিই বদলায়।
• Max: এর ওপরে কখনো উঠবে না। এটি আপনার খরচ আর পেছনের database-এর রক্ষাকবচ।

সব বড় provider-এ ধারণাটি একই, শুধু নাম আলাদা:

নিচের উদাহরণগুলো দেখায় কী কী সিদ্ধান্ত নিতে হয়। সবগুলো নমুনা; পড়ার জন্য account লাগবে না। চালালে VM চালু হবে আর টাকা লাগতে পারে, তাই শেষে group মুছে ফেলতে হবে।

# Launch template version is pinned: never let a new version roll out by surprise
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template LaunchTemplateName=web-lt,Version=7 \
  --min-size 4 --desired-capacity 6 --max-size 30 \
  --vpc-zone-identifier "subnet-0aaa,subnet-0bbb,subnet-0ccc" \
  --health-check-type ELB --health-check-grace-period 180

# cpu60.json: {"PredefinedMetricSpecification":
#   {"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":60.0}
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg --policy-name cpu-60 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration file://cpu60.json

# Clean up afterwards (this terminates every instance in the group)
aws autoscaling delete-auto-scaling-group \
  --auto-scaling-group-name web-asg --force-delete

# Azure autoscale uses rules; here: above 70% for 5 minutes, add 2
az monitor autoscale create --resource-group demo-rg \
  --resource web-vmss \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name web-autoscale --min-count 4 --max-count 30 --count 6

az monitor autoscale rule create --resource-group demo-rg \
  --autoscale-name web-autoscale \
  --condition "Percentage CPU > 70 avg 5m" --scale out 2

# Regional MIG: keep average CPU near 60%
gcloud compute instance-groups managed set-autoscaling web-mig \
  --region=asia-south1 \
  --min-num-replicas=4 --max-num-replicas=30 \
  --target-cpu-utilization=0.60 --cool-down-period=180

২ · চার ধরনের policy আর মূল সূত্র

Policy হলো সেই নিয়ম, যা ঠিক করে desired কখন কত হবে। চারটি ধরন চার রকম প্রশ্নের উত্তর দেয়:

একাধিক policy একসাথে থাকতে পারে। সাধারণত যে policy সবচেয়ে বেশি ক্ষমতা চায়, তার কথাই থাকে (provider-এর নথিতে মিলিয়ে নিন)। তাই scheduled policy min তুলে দেয়, আর target tracking তার ওপরে কাজ করে।

Target tracking-এর হিসাব

যুক্তিটি সহজ। ৬টি instance-এ প্রতিটিতে ১৫০ অনুরোধ মানে মোট ৯০০. প্রতিটিতে ৬০ রাখতে চাইলে লাগবে ৯০০ ÷ ৬০ = ১৫টি। ⌈ ⌉ মানে ওপরের দিকে গোল করা (ceil), কারণ ৬.৫টি VM হয় না, আর কম ধরলে লক্ষ্য ছাড়িয়ে যায়।

এই রূপটি Kubernetes-এর Horizontal Pod Autoscaler-এর নথিতে সরাসরি আছে (পর্ব ৪৮)। Cloud provider-এর target tracking-এর ভেতরের হিসাব হুবহু প্রকাশিত নাও হতে পারে, তবে হাতে অনুমানের জন্য এটি ভালো মডেল।

৩ · কোন signal দেখে সিদ্ধান্ত

ভুল signal মানে ভুল জ্বরের থার্মোমিটার। প্রশ্ন একটাই: কোন সংখ্যাটি সবচেয়ে আগে আর সবচেয়ে সৎভাবে বলে যে আরও instance লাগবে?

নিচের ক্যালকুলেটরে ছয়টি কাজের হিসাব একসাথে আছে। প্রতিটি সংখ্যা অনুমিত, বদলে “চালান” চাপুন। কোনো account লাগবে না।

// Worked autoscaling numbers. Every input is ASSUMED: change them and Run.
const ceil = Math.ceil, MIN = 4, MAX = 30;
const desired = (n, m, t) => Math.min(MAX, Math.max(MIN, ceil(n * m / t)));

console.log("A. desired = ceil(current x metric / target), then clamp to 4..30");
for (const [n, m, t] of [[6, 150, 60], [6, 65, 60], [20, 35, 60], [18, 320, 60], [5, 20, 60]])
  console.log(`  ${n} x ${m} / ${t} = ${(n * m / t).toFixed(2)} -> ${desired(n, m, t)}`);

console.log("B. CPU is stuck at 100%, true demand needs 30 instances");
let n = 6, demand = 1800, round = 0;              // 1800 req/s, 1 instance = 100 req/s
while (n * 100 / demand < 1) {                    // saturated: CPU reads 100
  const next = desired(n, 100, 60);
  console.log(`  round ${++round}: ${n} -> ${next}`); n = next;
}
const cpu = demand / n, last = desired(n, cpu, 60);
console.log(`  round ${++round}: ${n} at ${cpu.toFixed(1)}% -> ${last}`);

console.log("C. Queue depth: backlog per worker");
const backlog = 90000, rate = 20, maxWait = 300;  // jobs, jobs/s per worker, seconds
const perWorker = rate * maxWait;
console.log(`  target ${perWorker} jobs per worker -> ${ceil(backlog / perWorker)} workers`);

console.log("D. Target needed if load grows g per minute for T minutes");
for (const [g, T] of [[0.05, 4], [0.20, 4], [0.20, 2]])
  console.log(`  g=${g * 100}% T=${T}: target <= ${(100 / (1 + g) ** T).toFixed(1)}%`);

console.log("E. The real max is the smallest limit");
const lim = { configured: 30, quota: Math.floor(96 / 4), db: Math.floor(500 / 20) };
console.log(`  max ${lim.configured}, quota ${lim.quota}, db ${lim.db} -> usable ${Math.min(...Object.values(lim))}`);

console.log("F. One zone of Z lost: utilisation of the survivors");
for (const [u, z] of [[60, 3], [70, 3], [60, 2]])
  console.log(`  target ${u}%, ${z} zones -> ${(u * z / (z - 1)).toFixed(1)}%`);

A. desired = ceil(current x metric / target), then clamp to 4..30
  6 x 150 / 60 = 15.00 -> 15
  6 x 65 / 60 = 6.50 -> 7
  20 x 35 / 60 = 11.67 -> 12
  18 x 320 / 60 = 96.00 -> 30
  5 x 20 / 60 = 1.67 -> 4
B. CPU is stuck at 100%, true demand needs 30 instances
  round 1: 6 -> 10
  round 2: 10 -> 17
  round 3: 17 -> 29
  round 4: 29 at 62.1% -> 30
C. Queue depth: backlog per worker
  target 6000 jobs per worker -> 15 workers
D. Target needed if load grows g per minute for T minutes
  g=5% T=4: target <= 82.3%
  g=20% T=4: target <= 48.2%
  g=20% T=2: target <= 69.4%
E. The real max is the smallest limit
  max 30, quota 24, db 25 -> usable 24
F. One zone of Z lost: utilisation of the survivors
  target 60%, 3 zones -> 90.0%
  target 70%, 3 zones -> 105.0%
  target 60%, 2 zones -> 120.0%

৪ · ঈদের সেল — boot-এর দেরির আসল দাম

একটি কাল্পনিক অনলাইন বাজার অ্যাপ ধরি। প্রতিটি instance সেকেন্ডে ১০০ অনুরোধ পারে, target ৬০, শুরুতে ৬টি, max ৩০. মিনিট ৫-এ ঈদের সেল শুরু, দুই মিনিটে চাপ ৩৬০ থেকে ১,৮০০ হলো। Metric পড়া হয় প্রতি মিনিটের শেষে, আর নতুন instance traffic নিতে পারে ৩ মিনিট পরে। ক্ষমতার বাইরের অনুরোধ এই মডেলে বাদ পড়ে।

নিচের ধাপগুলোতে যারা boot-এ আছে তাদের দিকে নজর রাখুন। “পরে” চাপুন।

এবার নিজে সংখ্যা বদলান। নিচের simulator-এ ms হলো latency-র একটি মোটা অনুমান: ৫০ ÷ (১ − ব্যস্ততা), ১,০০০ ms-এ আটকানো। এটি মাপা latency নয়, শুধু দিক বোঝায়।

// Eid sale: autoscaler against a sudden spike, minute by minute. Scale-in is left out.
// ASSUMED: 1 instance = 100 req/s; target 60 req/s per instance; max 30.
// The metric is read at the end of a minute; new instances serve BOOT minutes later.
const CAP = 100, TARGET = 60, MIN = 4, MAX = 30;
const load = [360, 360, 360, 360, 360, 900, 1500, 1800, 1800, 1800, 1800, 1800,
              1800, 1500, 1200, 900, 600, 480];

function run(BOOT, schedAt) {          // schedAt: minute when min is raised to MAX
  let ready = 6, boot = [], drop = 0, paid = 0, rows = [];
  for (let t = 0; t < load.length; t++) {
    ready += boot.filter(b => b === t).length;
    boot = boot.filter(b => b > t);
    const L = load[t], rho = L / (ready * CAP);
    const lost = Math.max(0, L - ready * CAP) * 60;
    const ms = Math.round(50 / (1 - Math.min(rho, 0.95)));   // latency proxy
    drop += lost; paid += ready + boot.length;
    rows.push({ t, L, ready, wait: boot.length, rho, ms, lost });
    const floor = t >= schedAt ? MAX : MIN;
    const want = Math.min(MAX, Math.max(floor, Math.ceil(ready * (L / ready) / TARGET)));
    for (let i = ready + boot.length; i < want; i++) boot.push(t + 1 + BOOT);
  }
  return { rows, drop, paid };
}
console.log("min  load ready+boot  rho    ms   dropped");
for (const r of run(3, 99).rows.slice(4, 13))
  console.log(String(r.t).padStart(3), String(r.L).padStart(5),
    `${r.ready}+${r.wait}`.padStart(10), `${Math.round(r.rho * 100)}%`.padStart(5),
    String(r.ms).padStart(5), String(r.lost).padStart(9));
console.log("--- BOOT minutes -> dropped requests, instance-minutes");
for (const b of [1, 3, 6, 10]) {
  const x = run(b, 99);
  console.log(`boot ${String(b).padStart(2)}: dropped ${String(x.drop).padStart(7)}, paid ${x.paid}`);
}
const s = run(3, 1);
console.log(`scheduled at minute 1 (boot 3): dropped ${s.drop}, paid ${s.paid}`);

min  load ready+boot  rho    ms   dropped
  4   360        6+0   60%   125         0
  5   900        6+0  150%  1000     18000
  6  1500        6+9  250%  1000     54000
  7  1800       6+19  300%  1000     72000
  8  1800       6+24  300%  1000     72000
  9  1800      15+15  120%  1000     18000
 10  1800       25+5   72%   179         0
 11  1800       30+0   60%   125         0
 12  1800       30+0   60%   125         0
--- BOOT minutes -> dropped requests, instance-minutes
boot  1: dropped   90000, paid 376
boot  3: dropped  234000, paid 376
boot  6: dropped  450000, paid 376
boot 10: dropped  612000, paid 376
scheduled at minute 1 (boot 3): dropped 0, paid 492

একটি ব্যর্থতার গল্প (কাল্পনিক)

দলটি পরীক্ষায় দেখেছিল boot ৩ মিনিট। তাই সেলের রাতে শুধু target tracking-এ ভরসা করল। কিন্তু সেই রাতে নতুন instance startup script-এ package নামাচ্ছিল, আর config আনছিল সেই database থেকে, যা নিজেই চাপে কাঁপছিল। Boot হয়ে গেল ১০ মিনিট।

Simulator-এর boot 10 সারিটি সেই রাতের গল্প: 612000 অনুরোধ বাদ। প্রথম ৯টি instance মিনিট ১৬-তে এলো, যখন চাপ নেমে ৬০০. ভিড় শেষ, ক্রেতা চলে গেছেন, ভাড়ার বিল শুরু। পরের দিনের postmortem-এ তিনটি শিক্ষা উঠে এলো:

• জানা ভিড়ে আগেই বাড়ান। Scheduled min সেল শুরুর অন্তত boot-এর সময়ের চেয়ে বেশি আগে বসান, আর বাড়তি সময় রাখুন।
• Boot ছোট রাখুন। সব package image-এ পুরে দিন (পর্ব ১৬), startup-এ শুধু config আনুন। প্রয়োজনে warm pool ব্যবহার করুন।
• চাপের মধ্যেই boot মাপুন। শান্ত পরিবেশের ৩ মিনিট ভিড়ের রাতের ৩ মিনিট নয় (load test, পর্ব ৬৮)।

Target tracking বনাম step

একই instance আর একই boot, শুধু নিয়ম আলাদা। Step-এর ধাপ: metric ৭০-এ +২, ৮৫-এ +৪, ১০০-এ +৮, আর boot-এ থাকা সংখ্যা বাদ দিয়ে যোগ। দুই রকম চাপে চালিয়ে দেখি: হঠাৎ ধাক্কা আর ধীরে বাড়া।

// Target tracking vs step policy on two traffic shapes (scale-in is left out).
// ASSUMED: 1 instance = 100 req/s, target 60, boot 3 minutes, start 6, max 30.
const CAP = 100, TARGET = 60, BOOT = 3, MAX = 30;
const sudden = [360, 360, 360, 360, 360, 900, 1500, 1800, 1800, 1800, 1800, 1800, 1800, 1800, 1800];
const ramp = Array.from({ length: 30 }, (_, i) => Math.min(1800, 360 + 60 * i));

function stepAdd(m) { return m >= 100 ? 8 : m >= 85 ? 4 : m >= 70 ? 2 : 0; }

function run(load, policy) {
  let ready = 6, boot = [], drop = 0, paid = 0, peak = 6;
  for (let t = 0; t < load.length; t++) {
    ready += boot.filter(b => b === t).length;
    boot = boot.filter(b => b > t);
    const L = load[t], metric = L / ready;
    drop += Math.max(0, L - ready * CAP) * 60;
    paid += ready + boot.length;
    let add;
    if (policy === "tracking") add = Math.ceil(ready * metric / TARGET) - ready - boot.length;
    else add = stepAdd(metric) - boot.length;       // in-flight capacity counts
    add = Math.min(add, MAX - ready - boot.length);
    for (let i = 0; i < add; i++) boot.push(t + 1 + BOOT);
    peak = Math.max(peak, ready + boot.length);
  }
  return { drop, paid, peak, ready };
}
const show = (name, x) => console.log(name.padEnd(16), "dropped", String(x.drop).padStart(7),
  " paid", String(x.paid).padStart(4), " peak", String(x.peak).padStart(2), " end", x.ready);
console.log("sudden spike");
show("target tracking", run(sudden, "tracking")); show("step", run(sudden, "step"));
console.log("slow ramp (+60 req/s each minute)");
show("target tracking", run(ramp, "tracking")); show("step", run(ramp, "step"));

sudden spike
target tracking  dropped  234000  paid  286  peak 30  end 30
step             dropped  312000  paid  204  peak 24  end 22
slow ramp (+60 req/s each minute)
target tracking  dropped       0  paid  577  peak 30  end 30
step             dropped       0  paid  512  peak 26  end 24

৫ · Warm-up, cooldown আর flapping

নতুন instance “running” হলেই কাজের হয় না। তার cache ফাঁকা, connection pool খোলেনি, runtime গরম হয়নি। এই সময়টি warm-up. এই অবস্থায় তার metric গড়ে ঢুকলে autoscaler ভুল বোঝে। তাই AWS-এ instance warmup সেটিং আছে, আর Google Cloud-এ initialization period: এই সময়ে নতুন instance-এর মান গড়ে ধরা হয় না বা আলাদাভাবে দেখা হয় (provider-ভেদে আলাদা)।

Cooldown হলো দুটি সিদ্ধান্তের মাঝের বিরতি, যাতে আগের সিদ্ধান্তের ফল মাপে আসার সুযোগ পায়। Stabilization window একটু বুদ্ধিমান: গত কয়েক মিনিটের সুপারিশ মনে রেখে কমানোর সময় সবচেয়ে বড়টি মানে।

এই ফাঁক না থাকলে দেখা দেয় flapping: চাপ প্রায় এক, অথচ instance বারবার বাড়ে-কমে। প্রতিটি ঘূর্ণিতে boot-এর ভাড়া, ফাঁকা cache আর কাটা connection-এর দাম। নিচের চাপ ২৮৫ থেকে ৩০৫-এর মধ্যে থাকে, নিয়ম: ৭০-এর ওপরে +২, ৫০-এর নিচে −২. প্রতিটি অঙ্ক এক মিনিটের instance সংখ্যা।

// Flapping: load barely moves, yet a careless rule never settles. 60 simulated minutes.
// Rule: metric > 70 add 2; metric < 50 remove 2. New instances serve after 2 minutes.
let seed = 7;                                      // mulberry32: repeatable noise
const rand = () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
const load = Array.from({ length: 60 }, () => Math.round(285 + 20 * rand()));  // 285..305 req/s
const BOOT = 2, MIN = 4;

function run(cooldown, safeIn) {
  let ready = 6, boot = [], last = -99, starts = 0, stops = 0, paid = 0, strip = "";
  for (let t = 0; t < load.length; t++) {
    ready += boot.filter(b => b === t).length; boot = boot.filter(b => b > t);
    const m = load[t] / ready; strip += ready.toString(16); paid += ready + boot.length;
    if (t - last < cooldown || boot.length) continue;
    if (m > 70) { boot.push(t + 1 + BOOT, t + 1 + BOOT); starts += 2; last = t; }
    else if (m < 50 && ready - 2 >= MIN) {
      if (safeIn && load[t] / (ready - 2) > 60) continue;  // would overshoot: hold
      ready -= 2; stops += 2; last = t;
    }
  }
  return { strip, starts, stops, paid };
}
for (const [name, c, s] of [["no cooldown", 0, false], ["cooldown 10", 10, false],
                            ["cooldown 10 + safe scale-in", 10, true]]) {
  const r = run(c, s);
  console.log(name); console.log(" ", r.strip);
  console.log(`  launches ${r.starts}, terminations ${r.stops}, paid ${r.paid} instance-minutes`);
}

no cooldown
  644464446444664446444664446444644464446444644464446444664446
  launches 28, terminations 30, paid 332 instance-minutes
cooldown 10
  644444444444466666666444444444444666666664444444444446666666
  launches 6, terminations 6, paid 300 instance-minutes
cooldown 10 + safe scale-in
  666666666666666666666666666666666666666666666666666666666666
  launches 0, terminations 0, paid 360 instance-minutes

তাই সাধারণ নীতি: বাড়ান দ্রুত, কমান ধীরে। কম instance-এ ব্যবহারকারী ফিরে যান, বেশি instance-এ কয়েক মিনিটের ভাড়া যায়। দুই ভুলের দাম সমান নয়।

৬ · Health check আর instance বদল

Group দুই রকম health check-এর খবর শুনতে পারে, আর পার্থক্যটি বড়:

App deadlock-এ আটকালে VM দিব্যি “running”. Group যদি শুধু instance check শোনে, তাহলে load balancer সেটিকে বাদ দেবে, কিন্তু group ভাববে সব ঠিক। Desired ৬, কাজ করছে ৫, আর কেউ বদলাচ্ছে না। AWS-এ এই কারণেই --health-check-type ELB; অন্য provider-এ autohealing বা application health নামে একই ধারণা।

নতুন instance-কে শুরুতে কিছুটা সময় দিতে হয়, নইলে boot শেষের আগেই “অসুস্থ” বলে মেরে ফেলা হবে, আর ঘূর্ণি চলতেই থাকবে। সেই সময়টি grace period. Boot আর warm-up-এর চেয়ে সামান্য বড় রাখুন। ডিফল্ট মান provider আর তৈরির পথভেদে আলাদা, তাই ধরে না নিয়ে দেখে নিন।

৭ · Multi-AZ বণ্টন

Group-কে একাধিক availability zone-এ ছড়ালে সে নিজে সমান রাখার চেষ্টা করে। একটি zone গেলে কী হয়, ৯টি instance আর ৩টি zone দিয়ে দেখি:

তিনটি বাস্তব কথা। প্রথমত, বদলি আসতে মিনিট লাগে, আর সেই সময়ে বাকিদের ব্যস্ততা ৬০% থেকে ৯০%-এ যায় (ওপরের হিসাব F). তাই target-এ zone হারানোর হিসাব ধরে রাখুন। দ্বিতীয়ত, যে সময় একটি zone বিকল, তখন অনেক গ্রাহক একসাথে বাকি zone-গুলোতে instance চাইছেন। ক্ষমতা নাও মিলতে পারে (অংশ ৯)। তৃতীয়ত, rebalance-এর সময় group সাধারণত আগে নতুন বসায়, পরে পুরোনো সরায়। তাই লেখার সময়ে AWS-এর নথি অনুযায়ী সংখ্যা সাময়িকভাবে max ছাড়াতে পারে (প্রায় ১০% বা ১টি, যেটি বড়)।

Scale in-এও বণ্টন বজায় থাকে: সাধারণত সবচেয়ে বেশি instance যে zone-এ, সেখান থেকে আগে বাদ যায়। Zone-এর ধারণা বিস্তারে আছে পর্ব ০৫-এ।

৮ · ভদ্রভাবে কমানো — draining, hook আর protection

Scale out-এ ভুল হলে ধীর হয়; scale in-এ ভুল হলে চলমান পেমেন্ট মাঝপথে কাটা পড়ে। তিনটি হাতিয়ার এই ঝুঁকি কমায়।

• Draining: Load balancer নতুন অনুরোধ বন্ধ করে, চলমানগুলোকে একটি সময়সীমা পর্যন্ত শেষ করতে দেয়। AWS-এর target group-এ এর নাম deregistration delay (লেখার সময়ে ডিফল্ট ৩০০ সেকেন্ড)। সময়টি আপনার দীর্ঘতম স্বাভাবিক অনুরোধের চেয়ে একটু বড় রাখুন।
• Lifecycle hook: Instance-কে “বন্ধ হচ্ছে” অবস্থায় আটকে রাখে, যতক্ষণ আপনার script log আপলোড বা কাজ হস্তান্তর শেষ না করে। Launch-এর পথেও hook আছে, যেমন traffic নেওয়ার আগে cache ভরা। সময়সীমা পেরোলে নির্ধারিত ফল ধরে এগিয়ে যায়।
• Scale-in protection: চিহ্নিত instance scale in-এ বাছাই হয় না। লম্বা job চালানো worker-এর জন্য কাজের। সীমা মনে রাখুন: এটি health check-এর কারণে বদল, হাতে বন্ধ করা বা spot ফেরত নেওয়া ঠেকায় না।

নিচের উদাহরণে ১০টি instance, চাপ ৪০০ অনুরোধ/সেকেন্ড, zone বণ্টন ৪-৩-৩. Metric ৪০, তাই ⌈১০ × ৪০ ÷ ৬০⌉ = ৭. In-flight সংখ্যাগুলো অনুমিত।

App-কেও সহযোগিতা করতে হয়। SIGTERM পেলে নতুন কাজ বন্ধ করে হাতের কাজ শেষ করা, অর্থাৎ graceful shutdown, আপনার কোডের দায়িত্ব। Draining আর hook শুধু সময় দেয়।

৯ · যে সীমা autoscaler পার হতে পারে না

Desired ৩০ লেখা মানে ৩০টি পাওয়া নয়। Group চেষ্টা করে, ব্যর্থ হলে activity log-এ কারণ লেখে, কিন্তু আপনার app-এর চাপ তাতে কমে না। চারটি সীমা জেনে রাখুন:

• Provider-এর হাতে ক্ষমতা: On-demand মানে “আজ পাবেনই” নয়। কোনো zone-এ নির্দিষ্ট instance type ফুরিয়ে যেতে পারে, বিশেষ করে একটি zone বিকল হলে বা বড় আঞ্চলিক ভিড়ে। AWS-এ দেখবেন InsufficientInstanceCapacity, Google Cloud-এ ZONE_RESOURCE_POOL_EXHAUSTED, Azure-এ AllocationFailed ধরনের error.
• Quota: Account-এর vCPU বা instance-এর সীমা। লেখার সময়ে নতুন account-এ এটি প্রায়ই খুব কম থাকে, আর বাড়াতে অনুরোধ করতে হয় (পর্ব ০৬, ৩৫)। সেলের আগের রাতে নয়, কয়েক দিন আগে বাড়ান।
• পেছনের সীমা: ৩০টি instance × ২০ connection = ৬০০, অথচ database পারে ৫০০. ওপরের স্তর বাড়ানো নিচের স্তর ডুবিয়ে দিতে পারে।
• Network-এর সীমা: Subnet-এ ফাঁকা IP ঠিকানা ফুরালে নতুন instance বসবে না (পর্ব ২৫)।

প্রতিরক্ষার উপায়

Instance না পেলে শেষ ভরসা সিস্টেমকে ভদ্রভাবে কম কাজ করানো। সেই কৌশলগুলো আছে System Design-এর overload পর্বে। আর alarm রাখুন: group max-এ পৌঁছালে, desired আর ready অনেকক্ষণ না মিললে, আর launch ব্যর্থ হলে।

১০ · AI-এর যুগে autoscaling যাচাই

AI কয়েক সেকেন্ডে পুরো group লিখে দেয়। কিন্তু সে আপনার boot-এর সময়, quota বা database-এর সীমা জানে না। সাধারণ ভুলগুলো:

চালুর আগের চেকলিস্ট

• Boot আর warm-up চাপের মধ্যে মেপেছি, শান্ত পরিবেশে নয়
• Max হিসাব করেছি quota, database আর subnet দেখে, আর max-এ পৌঁছালে alarm আছে
• Target এমন যে একটি zone গেলেও বাকিরা টেকে
• App থামিয়ে দেখেছি group সেটি বদলায়, আর grace period-এ ঘূর্ণি হয় না
• Scale in-এ draining পরীক্ষা করেছি, চলমান অনুরোধ কাটা পড়েনি
• Plan বা --dry-run দেখেছি, diff পড়েছি, throwaway পরিবেশে চালিয়েছি
• * permission, 0.0.0.0/0, public storage, hardcoded secret আর latest নেই
• Budget alert চালু আছে, আর prompt-এ কোনো secret দিইনি