Reliability প্রকৌশল — chaos engineering, load test আর capacity planning

১ · অগ্নি-মহড়া — ব্যর্থতাকে আগে থেকে ডেকে আনা

আগের চারটি পর্বে আপনি metric, log, trace আর alert দেখেছেন, আর পর্ব ৬৭-তে incident সামলানো। সবই ব্যর্থতা ঘটার পরের কাজ। এই পর্বের প্রশ্ন উল্টো: ব্যর্থতার আগে কীভাবে জানবেন আপনার সিস্টেম টিকবে কি না?

Reliability নিয়ে আমাদের বেশিরভাগ বিশ্বাসই অনুমান। “তিনটি replica আছে, একটি মরলে কিছুই হবে না।” “Autoscaler আছে, ভিড় সামলে নেবে।” “Backup আছে।” এই বাক্যগুলো হয়তো সত্য। কিন্তু আপনি জানেন না, যতক্ষণ না পরীক্ষা করছেন। এই পর্বে তিনটি হাতিয়ার দিয়ে অনুমানকে মাপে বদলাব:

Principles of Chaos-এর পাঁচটি কথা

• স্থিতি নিয়ে দাবি: ভেতরের খুঁটিনাটি নয়, বাইরে থেকে মাপা যায় এমন আচরণ নিয়ে hypothesis লেখা।
• বাস্তব ঘটনা: নষ্ট server, ধীর network, হঠাৎ ভিড়, এমন ঘটনা বেছে নেওয়া।
• Production-এ: আসল traffic আর আসল config-ই আসল উত্তর দেয়। তবে পৌঁছাতে হয় ধাপে ধাপে।
• স্বয়ংক্রিয়: হাতে একবার করা পরীক্ষা পরের release-এ পুরোনো হয়ে যায়।
• Blast radius ছোট রাখা: ক্ষতি যত কম, শেখা তত নিরাপদ।

২ · একটি পরীক্ষার চারটি খুঁটি

“চলুন একটা server বন্ধ করে দেখি” chaos engineering নয়। বৈজ্ঞানিক পরীক্ষার মতো এখানেও আগে থেকে চারটি জিনিস লিখে নিতে হয়।

একটি সূক্ষ্ম কথা: পরীক্ষা থেকে দুই রকম ফল আসতে পারে, দুটোই লাভ। Hypothesis টিকলে আত্মবিশ্বাস বাড়ে। ভাঙলে আপনি একটি দুর্বলতা পেলেন, যা গ্রাহকের আগে আপনি দেখলেন। তাই পরীক্ষা “ব্যর্থ” হওয়া মানে কাজ বিফল নয়।

৩ · আসল পরীক্ষা — Pod মুছে error মাপা

এবার আসল cluster. web নামের একটি ছোট Python service, Service-এর পেছনে চলছে। এতে তিনটি বাস্তব আচরণ বসানো হয়েছে:

• চালু হওয়ার পরে ৫ সেকেন্ড সে “গরম” হয়, যেন cache ভরছে। এই সময়ে 503 দেয়।
• /ready path জানায় সে কাজ নিতে তৈরি কি না।
• DRAIN_S সেট করলে SIGTERM পাওয়ার পরেও সে এতক্ষণ কাজ চালিয়ে যায়, তারপর থামে।

Client Pod ৩০ সেকেন্ড ধরে ২০ req/s পাঠায়। প্রতিটি অনুরোধ নতুন connection, timeout ১ সেকেন্ড। প্রায় ১০ সেকেন্ডে অন্য একটি terminal থেকে একটি Pod মোছা হয়। মোট ৬০০ অনুরোধ।

প্রথম চেষ্টা: একটি replica, কোনো probe নেই।

$ kubectl exec client -- python /scripts/traffic.py http://web/ 20 30 1.0
sent 600 {'ok': 454, 'refused': 13, 'timeout': 34, '503': 99}
errors per second: 0 0 0 0 0 0 0 0 0 12 20 20 20 20 20 20 14 0 0 0 0 0 0 0 0 0 0 0 0 0
success 75.7%  p50 2 ms  p99 3 ms

এবার ধাপে ধাপে ঠিক করি। প্রতিটি সেটআপ আলাদাভাবে চালানো হয়েছে:

এই টেবিল থেকে তিনটি শিক্ষা:

• B: এক replica-য় probe কিছুই বাঁচায় না। Probe শুধু বলে “এই Pod-এ পাঠাবেন না”। অন্য Pod না থাকলে পাঠানোর জায়গাই নেই। ৯৯টি দ্রুত 503-এর জায়গায় এলো ১৪০-এর বেশি ১-সেকেন্ডের timeout: ফল বরং একটু খারাপ। (এই cluster-এ ready Pod না থাকার সময়ে connect আটকে timeout হয়েছে; অন্য network সেটআপে সঙ্গে সঙ্গে refused আসতে পারে।)
• C: Replica error কমায়, শেষ করে না। Service গরম না হওয়া নতুন Pod-কেও অনুরোধ দেয়। তিন Pod-এ ভাগ হলে তার ভাগে ২০ ÷ ৩ × ৫ ≈ ৩৩টি 503. মাপে পেয়েছি ৩৭ আর ২৯. বাকি কয়েকটি refused: Pod থেমে গেছে, কিন্তু খবর পুরো ছড়ায়নি।
• D: তিনটি মিলে গ্রাহকের চোখে ব্যর্থতা শূন্য। Probe গরম Pod-কে বাইরে রাখে। Drain থামার ফাঁকটি ঢাকে। Replica জায়গা দেয়।

D সেটআপের মূল অংশ এই। পুরো manifest kubectl apply --dry-run=server পাস করেছে। মনে রাখবেন, periodSeconds: 1 এখানে দ্রুত পরীক্ষার জন্য; production-এ সাধারণত এত ঘন probe দরকার হয় না।

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: abcl-cc
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: web
        image: python:3.12-alpine
        imagePullPolicy: IfNotPresent
        command: ["python", "-u", "/scripts/app.py"]
        env:
        - {name: WARMUP_S, value: "5"}
        - {name: DRAIN_S, value: "3"}
        - {name: WORK_ROUNDS, value: "0"}
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet: {path: /ready, port: 8080}
          periodSeconds: 1
          failureThreshold: 1
        volumeMounts:
        - {name: s, mountPath: /scripts}
        resources:
          requests: {cpu: 50m, memory: 32Mi}
          limits: {cpu: 200m, memory: 64Mi}
      volumes:
      - name: s
        configMap: {name: cc-scripts}

Pod মোছার ঠিক পরের মুহূর্তগুলো D সেটআপে এমন দেখায়:

$ kubectl delete pod web-79bbbc46f5-5cb4g
pod "web-79bbbc46f5-5cb4g" deleted

# 1 second later (AGE column removed)
NAME                   READY   STATUS
web-79bbbc46f5-5cb4g   0/1     Terminating
web-79bbbc46f5-6wkw9   0/1     ContainerCreating
web-79bbbc46f5-7tpxd   1/1     Running
web-79bbbc46f5-bv9p8   1/1     Running

# about 4 seconds later
web-79bbbc46f5-5cb4g   0/1     Completed
web-79bbbc46f5-6wkw9   0/1     Running
web-79bbbc46f5-7tpxd   1/1     Running
web-79bbbc46f5-bv9p8   1/1     Running

# about 8 seconds later
web-79bbbc46f5-6wkw9   1/1     Running
web-79bbbc46f5-7tpxd   1/1     Running
web-79bbbc46f5-bv9p8   1/1     Running

$ kubectl get endpointslices
NAME        ADDRESSTYPE   PORTS   ENDPOINTS                          AGE
web-twrcx   IPv4          8080    10.1.1.215,10.1.1.219,10.1.1.220   15m

# the traffic client, running all this time
sent 600 {'ok': 600}
errors per second: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
success 100.0%  p50 2 ms  p99 3 ms

একটি error-এর দাম মাপা যায়। ২০ req/s-এ ৩০ দিনে মোট অনুরোধ প্রায় ৫.১৮ কোটি। ৯৯.৯% SLO-তে error budget ৫১,৮৪০. A সেটআপে প্রতি মোছায় ১৪৬ ব্যর্থ। মাসে ৩০ বার Pod বদলালে budget-এর ৮.৪% শুধু এতেই শেষ। (অংশ ৭-এর script-এ হিসাবটি আছে।)

৪ · ধীর হওয়াও ব্যর্থতা — latency injection, game day আর টুল

Pod মরে যাওয়া সহজ ব্যর্থতা: Service সেটি বাদ দেয়। কঠিন ব্যর্থতা হলো ধীর dependency: সে আছে, health check পাস করে, কিন্তু উত্তর দেয় দেরিতে। Latency injection এই অবস্থা বানায়।

client আর web-এর মাঝে ৩০ লাইনের একটি ছোট Python proxy বসানো হলো, যা প্রতিটি উত্তর DELAY_MS পরিমাণ আটকে রাখে। Client-এর timeout ২৫০ ms, হার ২০ req/s, সময় ১০ সেকেন্ড। প্রতিবার proxy-র Pod বদল শেষ হওয়ার পরে মাপা হয়েছে।

$ kubectl set env deploy/delayproxy DELAY_MS=0
$ kubectl exec client -- python /scripts/traffic.py http://delayproxy/ 20 10 0.25
sent 200 {'ok': 200}
errors per second: 0 0 0 0 0 0 0 0 0 0
success 100.0%  p50 5 ms  p99 8 ms

$ kubectl set env deploy/delayproxy DELAY_MS=100
$ kubectl exec client -- python /scripts/traffic.py http://delayproxy/ 20 10 0.25
sent 200 {'ok': 200}
errors per second: 0 0 0 0 0 0 0 0 0 0
success 100.0%  p50 106 ms  p99 109 ms

$ kubectl set env deploy/delayproxy DELAY_MS=300
$ kubectl exec client -- python /scripts/traffic.py http://delayproxy/ 20 10 0.25
sent 200 {'timeout': 200}
errors per second: 20 20 20 20 20 20 20 20 20 20
success 0.0%  p50 None ms  p99 None ms

এখানেই ধীরতা বিপজ্জনক। Caller অপেক্ষা করে, তার thread আর connection আটকে থাকে, আর timeout-এর পরে retry করলে চাপ দ্বিগুণ হয়। এভাবে ছোট দেরি retry storm হয়ে পুরো সিস্টেম ফেলে দিতে পারে। সমাধান: কম timeout, exponential backoff-সহ সীমিত retry, circuit breaker আর load shedding. সেগুলোর বিস্তারিত System Design-এর resilience পর্বে।

Game day — মানুষের পরীক্ষা

Chaos টুল সিস্টেম পরীক্ষা করে। Game day পরীক্ষা করে মানুষ আর প্রক্রিয়া: alert কি বাজল, on-call কি runbook খুঁজে পেলেন, access কাজ করল, দলের মধ্যে কথা ঠিকভাবে গেল? পর্ব ২৪-এ DR-এর মহড়া দেখেছেন। একটি ভালো game day-এর ক্রম:

• আগে: লক্ষ্য, পরিস্থিতি, সময়, দায়িত্ব আর থামার নিয়ম লিখুন। প্রথমবার টেবিলে আলোচনা দিয়ে শুরু করুন।
• সময়ে: একজন পরিচালক ব্যর্থতা ঢোকান, একজন লেখেন, on-call দল আসল incident-এর মতো সাড়া দেন।
• পরে: Blameless পর্যালোচনা, আর প্রতিটি শিক্ষার জন্য দায়িত্ব ও তারিখসহ কাজ।

টুল — ধারণায়

টুলের নাম আর অবস্থা দ্রুত বদলায়, তাই ব্যবহারের আগে নথি দেখে নিন। এগুলো cluster-wide ক্ষমতা নিতে পারে, তাই RBAC আর namespace সীমা (পর্ব ৪৯) আগে ঠিক করুন।

৫ · Load test-এর ধরন আর coordinated omission

নতুন সেতু খোলার আগে প্রকৌশলীরা ভারী ওজন চাপিয়ে তার সহ্যক্ষমতা মেপে নেন। Load test সফটওয়্যারের সেই পরীক্ষা। প্রশ্ন বদলালে পরীক্ষাও বদলায়:

সময়গুলো মোটা দাগের প্রচলিত ধারণা। আসল উত্তর আপনার ঝুঁকি আর traffic ঠিক করে। ফল বিশ্বাসযোগ্য করতে চারটি নিয়ম: production-এর মতো data ও আকার রাখুন, load generator নিজে যেন bottleneck না হয়, গড় নয় percentile দেখুন (tail latency), আর test শুরুর warm-up অংশ আলাদা রাখুন।

Closed বনাম open — দুই রকম ভিড়

বেশিরভাগ public web service-এর নতুন ব্যবহারকারী প্রায় open: তাঁরা জানেন না আপনার server ধীর কি না। অথচ অনেক জনপ্রিয় load tool-এর সহজ ব্যবহার closed: N-টি worker, প্রতিটি উত্তর পেলে তবে পরেরটি। Closed tool চাপের মধ্যে server ধীর হলে নিজেই পাঠানো কমিয়ে দেয়। Server যেন গোপনে client-কে বলে, “একটু দাঁড়ান”, আর client মেনে নেয়। আসল ব্যবহারকারী মানেন না।

এর ফল coordinated omission, Gil Tene-র দেওয়া নাম। Client ঠিক সেই মুহূর্তের মাপগুলো নেয় না, যখন সিস্টেম সবচেয়ে খারাপ ছিল। নিচের simulator-এ একই server, একই ৫ সেকেন্ডের থেমে যাওয়া, শুধু মাপার ধরন আলাদা।

// Open vs closed load against one server. ASSUMED: 100 req/s for 60 s, service 5 ms,
// one connection, and the server freezes from t = 30 s to t = 35 s.
const RATE = 100, SECS = 60, SERVICE = 5, STALL_FROM = 30000, STALL_TO = 35000;

function finish(start) {                 // when does a request begun at `start` finish?
  const s = start >= STALL_FROM && start < STALL_TO ? STALL_TO : start;
  return s + SERVICE;
}
function closed() {        // next request waits for the previous one to come back
  const out = []; let free = 0;
  for (let i = 0; i < RATE * SECS; i++) {
    const planned = i * 1000 / RATE, start = Math.max(planned, free);
    if (start >= SECS * 1000) break;
    free = finish(start); out.push(free - start);   // clock starts when SENT
  }
  return out;
}
function open() {          // requests leave on schedule, whatever the server is doing
  const out = []; let free = 0;
  for (let i = 0; i < RATE * SECS; i++) {
    const planned = i * 1000 / RATE, start = Math.max(planned, free);
    free = finish(start); out.push(free - planned); // clock starts when PLANNED
  }
  return out;
}
function show(name, a) {
  const s = [...a].sort((x, y) => x - y), p = q => s[Math.floor(s.length * q)];
  const mean = a.reduce((x, y) => x + y, 0) / a.length;
  console.log(name.padEnd(7), String(a.length).padStart(5), mean.toFixed(1).padStart(7),
    String(p(0.5)).padStart(5), String(p(0.99)).padStart(6),
    String(p(0.999)).padStart(6), String(s[s.length - 1]).padStart(6));
}
console.log("model   count  mean ms  p50    p99  p99.9    max");
show("closed", closed());
show("open", open());

model   count  mean ms  p50    p99  p99.9    max
closed   6000     5.8     5      5      5   5005
open     6000   422.1     5   4710   4980   5005

৬ · আসল load run — knee খোঁজা

এবার সত্যিকারের চাপ। Server: একই Python app, একটি replica, প্রতি অনুরোধে কিছু CPU-র কাজ, আর limits.cpu: 300m. Client: একটি ছোট Pod, Python threads, প্রতি ধাপ ৫ সেকেন্ড, মোট এক মিনিটের কম। Open model: অনুরোধ পরিকল্পিত সময়ে ছাড়া হয়, latency গোনা হয় সেই সময় থেকে। Timeout ৩ সেকেন্ড।

আমরা খুঁজছি knee: সেই বাঁক, যার পরে সামান্য বাড়তি চাপেই latency লাফিয়ে বাড়ে। দুইবার চালানো হলো। প্রথমবার সমান দূরত্বে অনুরোধ (even), দ্বিতীয়বার এলোমেলো Poisson আগমনে, যা আসল traffic-এর কাছাকাছি।

$ kubectl exec client -- python /scripts/load.py http://web/ even 5 30 60 75 85 95 110
offered  goodput    p50    p95    p99 failed
     30     30.2      4      8    128      0
     60     60.2      4      5      7      0
     75     75.1      4      5      5      0
     85     85.1      4      5     12      0
     95     89.0    192    370    392      0
    110     88.2    537   1173   1228      0

$ kubectl exec client -- python /scripts/load.py http://web/ poisson 5 30 60 75 85 95 110
offered  goodput    p50    p95    p99 failed
     30     30.9      4    109    334      0
     60     56.6      4      8     42      0
     75     69.9      4     15     56      0
     85     79.3      4     41     64      0
     95     88.1     64    189    217      0
    110     88.5    480   1043   1099      0

ধাপে ধাপে Poisson run পড়ি। ρ এখানে utilisation, অর্থাৎ পাঠানো চাপ ÷ ৮৯.

দুটি লুকানো শিক্ষা। এক, ৮৫ req/s-এ even run-এর p95 5 ms, Poisson-এর 41 ms. গড় হার একই, শুধু আগমনের এলোমেলোতা আলাদা। সমান দূরত্বে পাঠানো test তাই সিস্টেমকে বেশি ভালো দেখায়। দুই, ছাদটি CPU limit-এর: এক অনুরোধে প্রায় ৩.৪ ms CPU (০.৩ ÷ ৮৯), আর 300m মানে প্রতি ১০০ ms-এ ৩০ ms. সেটি ফুরালে CPU throttling (পর্ব ৪৮)। তাই limit বদলালে capacity-র সংখ্যাও বদলাবে।

৭ · Little's law আর 1/(1−ρ) — knee-র গণিত

Knee কোনো রহস্য নয়। দুটি ছোট সূত্রেই এর ব্যাখ্যা আছে।

John Little ১৯৬১ সালে এর প্রমাণ প্রকাশ করেন। সূত্রটি আশ্চর্য সাধারণ: আগমন বা সেবার ধরন নিয়ে কোনো শর্ত নেই, শুধু সিস্টেম স্থির থাকতে হবে। লঞ্চঘাটে প্রতি মিনিটে ২ জন আসেন, প্রত্যেকে ১৫ মিনিট থাকেন, তবে ঘাটে গড়ে ৩০ জন।

আমাদের cluster-এ সূত্রটি যাচাই করা যায়। Closed client-এ N-টি worker, তাই ভেতরে থাকা অনুরোধ ঠিক N. আসল run:

$ kubectl exec client -- python /scripts/closed.py http://web/ 6 1 2 4 8 16
    N  X(r/s) W(avg ms)    X*W
    1    90.0      11.2   1.00
    2    90.3      22.1   2.00
    4    89.3      44.8   4.00
    8    89.3      89.9   8.03
   16    87.7     184.0  16.13

Utilisation আর queueing delay

ρ (রো) হলো ব্যস্ততা: ρ = λ × S, যেখানে λ আগমনের হার, S গড় সেবার সময়। সবচেয়ে সরল সারির মডেল M/M/1-এ একটি অনুরোধের গড় মোট সময়:

১/(১ − ρ) অংশটিই knee. ρ ০.৫ হলে ২ গুণ, ০.৮ হলে ৫ গুণ, ০.৯ হলে ১০ গুণ, ০.৯৯ হলে ১০০ গুণ। সেবার সময় একই, বাড়ছে শুধু queueing delay. কেন? অনুরোধ এলোমেলোভাবে আসে। গুচ্ছ এলে সারি হয়, আর ফাঁকা সময়ে সেই সারি শোধ হয়। ব্যস্ততা যত বেশি, শোধ করার ফাঁকা সময় তত কম।

এখন simulator. Seed-দেওয়া random দিয়ে ৩ লাখ অনুরোধ চালিয়ে সূত্রের সাথে মিলিয়ে দেখি। S বা তালিকা বদলে দেখুন।

// M/M/1 queue: latency vs utilisation, by formula and by a seeded simulation.
// ASSUMED: one server, mean service time S = 20 ms (so capacity 50 req/s).
const S = 20, N = 300000;
function mulberry32(a) {
  return () => { a |= 0; a = a + 0x6D2B79F5 | 0;
    let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const exp = (rnd, mean) => -mean * Math.log(1 - rnd());

function simulate(rho) {                 // Lindley: wait(i+1) = max(0, wait(i) + s(i) - gap)
  const rnd = mulberry32(42), meanGap = S / rho, all = [];
  let wait = 0, sum = 0;
  for (let i = 0; i < N; i++) {
    const s = exp(rnd, S), total = wait + s;
    all.push(total); sum += total;
    wait = Math.max(0, total - exp(rnd, meanGap));
  }
  all.sort((a, b) => a - b);
  return { mean: sum / N, p99: all[Math.floor(N * 0.99)] };
}

const pad = (x, w) => String(x).padStart(w);
console.log("  rho  req/s  W=S/(1-rho)  sim mean  p99 formula  sim p99  in system");
for (const rho of [0.3, 0.5, 0.7, 0.8, 0.9, 0.95, 0.98]) {
  const W = S / (1 - rho), L = rho / (1 - rho), r = simulate(rho);
  console.log(pad(rho.toFixed(2), 5), pad(rho * 50, 6), pad(W.toFixed(0), 12),
    pad(r.mean.toFixed(0), 9), pad((W * Math.log(100)).toFixed(0), 12),
    pad(r.p99.toFixed(0), 8), pad(L.toFixed(1), 10));
}

  rho  req/s  W=S/(1-rho)  sim mean  p99 formula  sim p99  in system
 0.30     15           29        29          132      131        0.4
 0.50     25           40        40          184      186        1.0
 0.70     35           67        67          307      309        2.3
 0.80     40          100        99          461      458        4.0
 0.90     45          200       192          921      852        9.0
 0.95   47.5          400       368         1842     1678       19.0
 0.98     49         1000       880         4605     3750       49.0

আসল server M/M/1 নয়। আমাদের run-এ সেবার সময় প্রায় সমান ছিল, তাই knee আরও চোখা, ρ ০.৮৪-এও অনেক ভালো। আকৃতি একই, সংখ্যা আপনার সিস্টেম মাপেই পাবেন। সূত্র দিক দেখায়; load test সংখ্যা দেয়।

গণনা করে দেখি

পরীক্ষা আর ইন্টারভিউর ধরনের ছয়টি হিসাব, script দিয়ে করা। প্রতিটি লাইন আপনি বদলাতে পারেন।

// Worked numericals: Little's law, utilisation, and what a Pod delete costs.
const f = (x, d = 1) => x.toFixed(d);

// 1. Little's law: L = lambda * W
const lambda = 4140, W = 0.120;
console.log(`1. L = ${lambda} x ${W} = ${f(lambda * W)} requests inside`);

// 2. Check Little's law on a measured closed-loop row
const X = 89.3, Wm = 0.0899;
console.log(`2. X*W = ${X} x ${Wm} = ${f(X * Wm, 2)} (the run used N = 8)`);

// 3. Size a database pool: 2 queries per request, 5 ms each, keep the pool at 70%
const busy = lambda * 2 * 0.005;
console.log(`3. busy connections ${f(busy)}, pool ${Math.ceil(busy / 0.7)}`);

// 4. M/M/1: S = 20 ms. Traffic +10% from 40 to 44 req/s
const S = 0.020, wait = l => S / (1 - l * S) * 1000;
console.log(`4. rho ${f(40 * S, 2)}: ${f(wait(40), 0)} ms; rho ${f(44 * S, 2)}: ${f(wait(44), 0)} ms; ` +
  `+${f((wait(44) / wait(40) - 1) * 100, 0)}% latency`);

// 5. Largest utilisation that keeps mean latency at most 60 ms, and servers for 1000 req/s
const target = 0.060, rhoMax = 1 - S / target, perServer = rhoMax / S;
console.log(`5. rho max ${f(rhoMax, 3)}, ${f(perServer)} req/s per server, ` +
  `${Math.ceil(+(1000 / perServer).toFixed(6))} servers for 1000 req/s`);

// 6. A failed Pod delete against a 99.9% SLO at 20 req/s for a 30-day month
const budget = 20 * 86400 * 30 * 0.001, lost = 146;
console.log(`6. budget ${f(budget, 0)} failures; ${lost} per delete; ` +
  `30 deletes = ${f(100 * 30 * lost / budget)}% of the budget`);

1. L = 4140 x 0.12 = 496.8 requests inside
2. X*W = 89.3 x 0.0899 = 8.03 (the run used N = 8)
3. busy connections 41.4, pool 60
4. rho 0.80: 100 ms; rho 0.88: 167 ms; +67% latency
5. rho max 0.667, 33.3 req/s per server, 30 servers for 1000 req/s
6. budget 51840 failures; 146 per delete; 30 deletes = 8.4% of the budget

৮ · Capacity planning — forecast, headroom আর N+1

বিয়েবাড়ির ক্যাটারিং ভাবুন। গত বছর ২০০ জন খেয়েছিলেন, এবার আত্মীয় বেড়েছে, দাওয়াত ৩০০. বাবুর্চি ৩৩০ জনের রান্না ধরেন, আর একটি চুলা নষ্ট হলেও যেন চলে, সে ব্যবস্থা রাখেন। Capacity plan হুবহু এই চিন্তা, চারটি ধাপে:

• Demand forecast: আজকের চূড়া × স্বাভাবিক বৃদ্ধি × জানা ঘটনার গুণক। গড় নয়, চূড়া।
• প্রতি ইউনিটের নিরাপদ ক্ষমতা: বিজ্ঞাপনের সংখ্যা নয়, আপনার load test-এর knee-র নিচের মান।
• Headroom: forecast-এর ভুল আর হঠাৎ ধাক্কার জন্য margin.
• N+1: একটি ইউনিট হারালেও চলবে। Cloud-এ বড় ইউনিটটি হলো একটি পুরো zone (পর্ব ০৫)।

Zone-এর হিসাবের মূল সূত্র: z-টি zone থাকলে একটি হারানোর পরে (z − 1)-টিকে পুরো চাপ নিতে হবে। তাই প্রতি zone-এ চাপ ÷ (z − 1) ÷ নিরাপদ ক্ষমতা।

এখন একটি কাল্পনিক অনলাইন বাজার অ্যাপের ঈদ সেলের পরিকল্পনা। ধরে নিই load test বলেছে: এক instance-এর knee ১০০ req/s, নিরাপদ ৭৫ req/s. দাম ধরে নিই ঘণ্টায় $০.১০ (কাল্পনিক; আসল দাম provider-এর পাতায় দেখুন)।

এবার নিজে সংখ্যা বদলান: zone-এর সংখ্যা, margin, নিরাপদ ক্ষমতা।

// Capacity plan with zone-failure headroom. Change the numbers and run again.
// ASSUMED: every value is an example; PRICE is a round number, not a real price.
const today = 1200;      // peak req/s today
const growth = 0.15;     // organic growth until the sale
const event = 2.5;       // the sale multiplies the peak by this
const margin = 0.20;     // safety margin on the forecast
const safe = 75;         // req/s one instance serves below the knee (from a load test)
const knee = 100;        // req/s where latency explodes on one instance
const PRICE = 0.10;      // assumed $ per instance-hour
const HOURS = 72;        // length of the sale

const peak = today * (1 + growth) * event, plan = peak * (1 + margin);
const noZone = Math.ceil(plan / safe);
console.log(`forecast ${peak.toFixed(0)} req/s, plan ${plan.toFixed(0)} req/s`);
console.log(`ignoring zone failure: ${noZone} instances, $${(noZone * PRICE * HOURS).toFixed(1)}`);
console.log("zones per-zone total normal/safe lost-zone rho(knee) cost$ extra");
for (const z of [2, 3, 4, 6]) {
  const perZone = Math.ceil(plan / (z - 1) / safe);   // z-1 zones must carry the plan
  const total = perZone * z, left = total - perZone;
  console.log(String(z).padStart(5), String(perZone).padStart(8), String(total).padStart(5),
    `${(100 * plan / (total * safe)).toFixed(1)}%`.padStart(11),
    `${(100 * plan / (left * knee)).toFixed(1)}%`.padStart(19),
    (total * PRICE * HOURS).toFixed(1).padStart(6), `+${total - noZone}`.padStart(5));
}
// over-provisioning: keep the sale fleet all month, or only for the sale?
const quiet = 3 * Math.ceil(today * (1 + margin) / 2 / safe);
const month = 720, big = 3 * Math.ceil(plan / 2 / safe);
const always = big * PRICE * month;
const sched = big * PRICE * HOURS + quiet * PRICE * (month - HOURS);
console.log(`quiet fleet ${quiet}, sale fleet ${big}`);
console.log(`sale fleet all month $${always.toFixed(0)}, scheduled $${sched.toFixed(0)}, ` +
  `saved $${(always - sched).toFixed(0)}`);

forecast 3450 req/s, plan 4140 req/s
ignoring zone failure: 56 instances, $403.2
zones per-zone total normal/safe lost-zone rho(knee) cost$ extra
    2       56   112       49.3%               73.9%  806.4   +56
    3       28    84       65.7%               73.9%  604.8   +28
    4       19    76       72.6%               72.6%  547.2   +20
    6       12    72       76.7%               69.0%  518.4   +16
quiet fleet 30, sale fleet 84
sale fleet all month $6048, scheduled $2549, saved $3499

৯ · Autoscaling কোথায় থামে, আর বাড়তি ক্ষমতার দাম

“Cloud তো elastic, plan কেন লাগবে?” পর্ব ১৭-তেই উত্তরের বড় অংশ দেখেছেন। সেটি মনে করিয়ে দিই, এবার এই পর্বের দৃষ্টিতে:

• প্রতিক্রিয়ার দেরি: Metric পড়া, সিদ্ধান্ত, boot, warm-up মিলিয়ে কয়েক মিনিট। ধাক্কা তার আগেই আসে। পর্ব ১৭-র ঈদ simulator-এ autoscaler ভুল না করেও ২,৩৪,০০০ অনুরোধ হারিয়েছিল।
• Knee-র কাছে সময় নেই: Target ৯০% রাখলে ১/(১ − ρ) আগেই ১০ গুণে। নতুন instance আসার আগে সারি জমে যায়। তাই target-ও capacity-র প্রশ্ন।
• সীমা: Provider-এর হাতে ক্ষমতা, quota, subnet-এর IP, max মান। Zone বিকল হলে অনেকেই একসাথে অন্য zone-এ instance চান, তখন সেটি না-ও মিলতে পারে।
• পেছনের স্তর: Web স্তর বাড়লে database-এর চাপ বাড়ে, আর সে সাধারণত নিজে নিজে horizontally বাড়ে না। Bottleneck শুধু সরে যায়।
• Scale up নিজেই dependency: Scale-এর পথ যদি সেই নষ্ট অংশের ওপর নির্ভর করে (image registry, config service), তবে দরকারের সময়েই আটকে যায়।

এজন্যই দৃঢ় সিস্টেম ব্যর্থতার সময়ে নতুন কিছু চালু করার ওপর নির্ভর করে না: আগে থেকে যথেষ্ট ক্ষমতা হাতে রাখে। Autoscaling রোজকার ওঠানামা সামলায়; zone-ব্যর্থতা আর জানা ধাক্কা সামলায় পূর্ব পরিকল্পনা।

Over-provisioning-এর দাম

কিন্তু “সব সময় অনেক রাখি” কোনো উত্তর নয়। ওপরের script-এর শেষ লাইন: সেলের ৮৪টি সারা মাস রাখলে $৬,০৪৮. মাসের বাকি সময়ে ৩০টি আর সেলের ৭২ ঘণ্টায় ৮৪টি রাখলে $২,৫৪৯. একই নিরাপত্তা, $৩,৪৯৯ কম। অঙ্কগুলো কাল্পনিক দামে, কিন্তু অনুপাতটি আসল শিক্ষা।

তাই লক্ষ্য হলো সবচেয়ে কম খরচে SLO. হিসাবের পথ: খরচ ÷ সফল অনুরোধ। Rightsizing, spot আর commitment-এর কৌশল আসবে পর্ব ৭২ আর ৭৩-এ। Scheduled scaling, পরিষ্কার পরিকল্পনা আর নিয়মিত load test মিলিয়েই “ঠিক মাপ” পাওয়া যায়।

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

AI খুব দ্রুত k6 script, chaos manifest আর capacity-র হিসাব লিখে দেয়। সমস্যা হলো, এই কাজের ভুল production-এ সরাসরি আঘাত করে, আর ভুল সংখ্যা দেখতে বিশ্বাসযোগ্য লাগে।

• Hypothesis মাপা যায়, আর abort condition লেখা আছে
• Namespace, selector আর লক্ষ্য নিজে পড়ে দেখেছি; --dry-run আগে চালিয়েছি
• Load tool open না closed জানি, আর latency পরিকল্পিত সময় থেকে গোনা
• Generator নিজে bottleneck নয়, আর L = λW দিয়ে মাপ মিলিয়েছি
• Capacity-র হিসাব চূড়া আর একটি zone হারিয়ে হাতে মিলিয়েছি
• Test-এর সিস্টেম আমার নিজের, অনুমতি আছে, দল জানে, budget alert আছে
• Secret, আসল hostname বা account id prompt-এ দিইনি