Vertical বনাম horizontal scaling — stateless সার্ভিস আর autoscaling

১ · Scaling মানে কী — বেশি চাপ, একই latency, সহনীয় খরচ

একটি কাল্পনিক পরীক্ষার-ফল সেবার কথা ভাবুন। সারা বছর দিনে কয়েক হাজার মানুষ পাতাটি খোলেন। ফল প্রকাশের দিন সকাল ১০টায় কয়েক মিনিটের মধ্যে ঢোকেন কয়েক লাখ। প্রশ্ন একটাই: চাপ এতগুণ বাড়লে সেবা কি আগের মতোই দ্রুত উত্তর দেবে, আর তার জন্য খরচ কি অযৌক্তিক হারে বাড়বে? এটাই scalability-র প্রশ্ন, আর এই মডিউলের ছয়টি পর্ব এর উত্তর খোঁজে।

“আমাদের সিস্টেম কি scalable?” — এর উত্তর হ্যাঁ বা না নয়। পর্ব ০২-এ দেখেছেন, চাপকে কয়েকটি load parameter দিয়ে বর্ণনা করতে হয়: প্রতি সেকেন্ডে অনুরোধ, পড়া-লেখার অনুপাত, মোট ডেটা, একসাথে যুক্ত ব্যবহারকারী, fan-out. আসল প্রশ্ন: কোন সংখ্যা দ্বিগুণ হলে কোথায় টান পড়বে? প্রতিটি আলাদা স্তরে চাপ দেয় — পড়া বাড়লে cache আর replica, ডেটা বাড়লে sharding, খোলা সংযোগ বাড়লে সংযোগ সামলানোর স্তর (পর্ব ১০)।

Performance-এর সমস্যা মানে একজন ব্যবহারকারীর জন্যও সেবা ধীর। Scalability-র সমস্যা মানে একজনের জন্য দ্রুত, কিন্তু হাজারজনের ভিড়ে ধীর। প্রথমটির উত্তর ভালো কোড আর index; দ্বিতীয়টির উত্তর এই পর্বের দুই পথ।

২ · Vertical scaling — বড় যন্ত্র, সহজ পথ, কিন্তু ছাদ আছে

Vertical scaling মানে একই সার্ভারকে আরও শক্তিশালী করা: বেশি CPU core, বেশি RAM, দ্রুত disk (NVMe SSD), দ্রুত network card. Cloud-এ এর মানে সাধারণত যন্ত্রের ধরন (instance type) বদলানো।

এর সুবিধাগুলো বড় আর প্রায়ই অবহেলিত। কোড প্রায় বদলাতে হয় না। সব ডেটা এক জায়গায়, তাই transaction, join আর strong consistency সহজ। Network-এর দেরি নেই, “অর্ধেক কাজ হয়ে বাকিটা আটকে যাওয়া” (partial failure, পর্ব ৩৮) নেই। বহু সেবা কখনো একটি ভালো যন্ত্রের সীমা ছোঁয় না। তবে একটি যন্ত্র কত সামলায়, তা কাজের ধরনভেদে বহু গুণ আলাদা — load test ছাড়া কোনো সংখ্যা বিশ্বাস করবেন না।

কিন্তু চারটি সীমা আছে:

যন্ত্রের ভেতরের এই প্রতিযোগিতা বিস্তারিত দেখতে Operating Systems কোর্সের thread পর্ব আর Computer Architecture কোর্সের multicore আর cache coherence পর্ব দেখুন।

৩ · Horizontal scaling — বেশি যন্ত্র, প্রায় সীমাহীন, কিন্তু সমন্বয়ের দাম

Horizontal scaling মানে একই রকম আরও যন্ত্র — প্রতিটি একটি instance — যোগ করা, আর সামনে একটি load balancer বসানো, যে অনুরোধগুলো ভাগ করে দেয় আর অসুস্থ instance-কে বাদ রাখে। কীভাবে ভাগ করে — algorithm, L4 বনাম L7, health check — সব পরের পর্বে (পর্ব ১৪)। যন্ত্রগুলো সাধারণত বাজারে সহজলভ্য, সাধারণ দামের commodity hardware.

অনুরোধগুলো যদি একে অপরের থেকে স্বাধীন হয়, ক্ষমতা প্রায় রৈখিক বাড়ে: ১০টি instance মানে প্রায় ১০ গুণ। সাথে আসে বাস্তবে প্রায় ছাদহীন ক্ষমতা, আপনা-আপনি redundancy (N+1, পর্ব ০৫), সেবা বন্ধ না করে একটি একটি করে নতুন সংস্করণ বসানো (rolling deployment), চাপ অনুযায়ী বাড়ানো-কমানো (অংশ ৭), আর একটি যন্ত্র নষ্ট হলে পুরো বন্ধের বদলে একটু কম ক্ষমতা।

দামও আছে। সামনে load balancer লাগে, সেটিও redundant. State সার্ভার থেকে সরাতে হয় (অংশ ৪)। ভাগ করা সবকিছু — counter, lock, cache — network-এ মেলাতে হয়, আর সেই খরচ যন্ত্রের সংখ্যার সাথে বাড়ে (অংশ ৫)। আর অনেক যন্ত্রের partial failure খুঁজতে লাগে ভালো observability (পর্ব ৫০)।

৪ · Stateless সার্ভিস — horizontal scaling-এর চাবি

Horizontal scaling-এর মূল শর্ত: যেকোনো instance যেকোনো অনুরোধ সামলাতে পারবে। তাহলেই load balancer স্বাধীনভাবে ভাগ করে, autoscaler যেকোনোটি যোগ-বাদ দেয়, আর একটি crash করলে কেউ কিছু হারান না। এমন সার্ভিসকে বলে stateless. কথাটির অর্থ “state নেই” নয় — state সার্ভারের ভেতরে নেই। তা চলে গেছে database, cache বা একটি session store-এ, অথবা client-এর কাছে একটি স্বাক্ষরিত token-এ। কোথায় রাখবেন, sticky session কখন চলে, token-এর সুবিধা-অসুবিধা — সব পর্ব ১৫-এ; এখানে শুধু নীতিটি।

নিচের অ্যাপটি লগইনের session নিজের memory-তে রাখে। দ্বিতীয় সার্ভার যোগ করতেই কী ভাঙে, আর stateless নকশা কীভাবে মেটায় — ধাপে ধাপে:

Session-ই একমাত্র লুকানো state নয়:

৫ · Scaling-এর সীমা — Amdahl-এর সূত্র আর Universal Scalability Law

পর্ব ০১-এর একটি ভাবনার প্রশ্নে এক ঝলক দেখেছেন: সার্ভার দ্বিগুণ মানেই ক্ষমতা দ্বিগুণ নয়। এবার সূত্রে আর প্রমাণে। রান্নাঘরের দুটি ঝামেলা — ফ্রিজের লাইন আর সবাইকে “লবণ শেষ” জানানো — এদের নাম contention (σ) আর coherency (κ)।

Amdahl-এর সূত্র — ভাগ না-হওয়া অংশের দেয়াল

ধরুন একটি যন্ত্রে একগুচ্ছ কাজ শেষ হতে সময় লাগে T. এর একটি ভগ্নাংশ σ এমন, যা ভাগ করা যায় না — একটি ভাগ করা জিনিসের (একটি lock, একটি primary database-এর row) সামনে একে একে চলতেই হয়। একে বলে serial fraction. বাকি (1 − σ) অংশ N টি যন্ত্রে সমান ভাগ করা যায়। তাহলে N যন্ত্রে সময় T(σ + (1 − σ)/N), আর গতি বাড়ে:

দ্বিতীয় রূপটি আসে লব-হরকে N দিয়ে গুণ করে: Nσ + (1 − σ) = 1 + σ(N − 1). এটাই Amdahl-এর সূত্র — IBM-এর প্রকৌশলী Gene Amdahl ১৯৬৭ সালের একটি সম্মেলনে যুক্তিটি দেন, সূত্রের রূপ পরে অন্যরা লেখেন। যত যন্ত্রই যোগ করুন, লাভ কখনো 1/σ ছাড়াবে না: σ = ৫% হলে সর্বোচ্চ ২০ গুণ, σ = ৩% হলে ৩৩.৩ গুণ। Throughput-এর ভাষায় একই কথা: C(N) = N যন্ত্রের throughput ÷ একটি যন্ত্রের throughput.

সমস্যার আকার যন্ত্রের সাথে বাড়লে — বেশি ব্যবহারকারী, তাই বেশি সার্ভার — ছবিটা আশাব্যঞ্জক; ১৯৮৮ সালে John Gustafson এই যুক্তি দেন (Gustafson-এর সূত্র, ভাবনার প্রশ্ন ২)।

Universal Scalability Law — যখন যন্ত্রগুলোকে কথাও বলতে হয়

Amdahl ধরে নেন, যন্ত্রগুলো একে অপরের খোঁজ রাখে না। বাস্তবে রাখতে হয়: মান বদলালে সবার cache থেকে পুরোনো কপি বাতিল, সবার সাথে সবার heartbeat, lock কার হাতে তা নিয়ে সম্মতি। N টি যন্ত্রে এমন জোড়া N(N − 1)টি — খরচ বাড়ে প্রায় N²-এর হারে। Neil Gunther এই খরচ যোগ করে মডেলটি প্রথম প্রকাশ করেন মোটামুটি ১৯৯৩ সালে, পরে Guerrilla Capacity Planning (২০০৭) বইয়ে বিস্তারিত লেখেন; নাম দেন Universal Scalability Law (USL). কোনো লেখায় দুটি ধ্রুবককে α আর β, কোথাও σ আর κ লেখা হয়; অর্থ একই।

নিচের ক্যালকুলেটরে Amdahl আর USL পাশাপাশি। σ = ০.০৩ আর κ = ০.০০১ ধরে নেওয়া মান; বাস্তবে এগুলো load test-এর মাপ থেকে বের করা হয় (অংশ ৮-এর “আরও গভীরে”)।

// Throughput multiplier C(N) with N servers: Amdahl vs USL.
// sigma = contention (share of work that must queue for one shared thing),
// kappa = coherency (cost of every pair of servers keeping each other in sync).
const sigma = 0.03, kappa = 0.001;       // ASSUMED - in practice fitted to a load test
const amdahl = (N) => N / (1 + sigma * (N - 1));
const usl = (N) => N / (1 + sigma * (N - 1) + kappa * N * (N - 1));

const nStar = Math.sqrt((1 - sigma) / kappa);          // where dC/dN = 0
let best = 1;
for (let N = 1; N <= 64; N++) if (usl(N) > usl(best)) best = N;
console.log("Amdahl ceiling 1/sigma      = " + (1 / sigma).toFixed(1) + "x");
console.log("USL peak sqrt((1-s)/k)      = " + nStar.toFixed(2) +
            "  -> best whole N = " + best + ", C = " + usl(best).toFixed(2) + "x");
console.log("   N  Amdahl     USL   USL/N   note");
let prev = 0;
for (const N of [1, 2, 4, 8, 16, 24, best, 40, 48, 64]) {
  const c = usl(N);
  const note = N === best ? "peak" : (c < prev ? "retrograde (less than before)" : "");
  console.log(String(N).padStart(4) + amdahl(N).toFixed(2).padStart(8) +
    c.toFixed(2).padStart(8) + ((100 * c / N).toFixed(0) + "%").padStart(8) + "   " + note);
  prev = c;
}

Amdahl ceiling 1/sigma      = 33.3x
USL peak sqrt((1-s)/k)      = 31.14  -> best whole N = 31, C = 10.95x
   N  Amdahl     USL   USL/N   note
   1    1.00    1.00    100%
   2    1.94    1.94     97%
   4    3.67    3.63     91%
   8    6.61    6.32     79%
  16   11.03    9.47     59%
  24   14.20   10.70     45%
  31   16.32   10.95     35%   peak
  40   18.43   10.72     27%   retrograde (less than before)
  48   19.92   10.29     21%   retrograde (less than before)
  64   22.15    9.25     14%   retrograde (less than before)

এবার বক্ররেখাটি বিন্দু ধরে ধরে পড়ি। প্রতিটি ধাপে হরের দুটি খরচ আলাদা করে দেখুন — কোনটি কখন বড় হয়ে ওঠে:

৬ · Bottleneck কোন স্তরে — ভুল স্তর বাড়ালে কিছুই বদলায় না

একটি অনুরোধ কয়েকটি স্তর পার হয় — load balancer, app, cache, database, বাইরের কোনো সেবা। পুরো পথের সর্বোচ্চ throughput ঠিক করে সবচেয়ে সরু স্তরটি (পর্ব ০৪-এর অংশ ৮)। একটি উদাহরণ, সংখ্যাগুলো ধরা যাক: প্রতিটি অনুরোধে database-এ ২টি query লাগে; database গ্রহণযোগ্য latency-তে সেকেন্ডে প্রায় ৪,০০০টি query সামলায় — তাই পুরো সেবা সর্বোচ্চ ২,০০০ অনুরোধ/সেকেন্ড। App স্তরে ৮টি instance, প্রতিটি ৪০০ অনুরোধ/সেকেন্ড পারে — মোট ৩,২০০। এখন ২,০০০ অনুরোধে database ১০০% ব্যস্ত, app মাত্র প্রায় ৬২%. App instance দ্বিগুণ করে ১৬টি করলে app-এর ক্ষমতা ৬,৪০০, কিন্তু throughput সেই ২,০০০-ই। আরও খারাপ: প্রতিটি instance-এর connection pool-এ ২০টি connection হলে database-এ ১৬০-এর বদলে ৩২০টি connection — বেশি লড়াই, database আরও ধীর। এটাই বাস্তবের retrograde scaling.

কীভাবে খুঁজবেন

প্রতিটি স্তরের জন্য তিনটি প্রশ্ন করুন — Brendan Gregg-এর প্রচলিত USE পদ্ধতি এভাবেই সাজানো: Utilization — কতটা ব্যস্ত (CPU, disk, connection)? Saturation — কাজ কি লাইনে জমছে (queue-র দৈর্ঘ্য, অপেক্ষার সময়)? Errors — timeout বা প্রত্যাখ্যান বাড়ছে কি? যে স্তরে লাইন জমছে, সেটিই bottleneck; সময় কোথায় যাচ্ছে তা স্তর ধরে দেখায় distributed tracing (পর্ব ৫০)।

Data স্তর কেন কঠিন

Stateless app-এর একটি কপি বানাতে লাগে শুধু একটি নতুন instance চালু করা। Database-এর কপি বানাতে লাগে ডেটাও কপি করা — কয়েক TB হলে কয়েক ঘণ্টা — আর তারপর প্রতিটি নতুন লেখা সব কপিতে পৌঁছে দেওয়া। লেখার চাপ ভাগ করতে ডেটা ভাগ করতে হয়, আর তখন দুই ভাগ জুড়ে transaction কঠিন (পর্ব ২৫)। এজন্যই data স্তরে পথটি সাধারণত ধাপে ধাপে, সস্তা থেকে দামি:

৭ · Autoscaling — চাপ অনুযায়ী নিজে থেকে বাড়া-কমা

পর্ব ০৩-এর হিসাবে peak-এর জন্য ৩২টি সার্ভার লেগেছিল, অথচ দিনের বেশিরভাগ সময় তারা প্রায় ১৮% ব্যস্ত। Autoscaling চাপ মেপে instance-এর সংখ্যা নিজে বাড়ায়-কমায় — cloud-এর elasticity-র সবচেয়ে পরিচিত রূপ। শর্ত: app স্তর stateless হতে হবে (অংশ ৪)।

কোন metric দেখে

• CPU utilisation: সবচেয়ে প্রচলিত; কিন্তু I/O-র অপেক্ষায় থাকা সার্ভিসে কম দেখায়, আর ১০০%-এ আটকে যায় বলে অতিরিক্ত চাপ কতটা তা বোঝায় না।
• Instance-প্রতি অনুরোধের হার: load balancer থেকে মাপা আসল চাহিদা, সীমায় আটকে যায় না; একটি instance কত পারে তা load test-এ জানা থাকলে (পর্ব ০৩) সবচেয়ে সরাসরি।
• Queue-র দৈর্ঘ্য: পেছনের worker-দের জন্য সেরা — জমে থাকা কাজ ÷ প্রতি worker-এর হার = কতজন লাগবে (পর্ব ৩১)।
• p99 latency: ব্যবহারকারীর অভিজ্ঞতার সবচেয়ে কাছের, কিন্তু এর মান অনেক ওঠানামা করে (noisy) আর দেরিতে আসে; আর latency database-এর জন্য বাড়লে app বাড়ানো ক্ষতি করে (অংশ ৬)। তাই এটি সতর্কসংকেত, একমাত্র নিয়ম নয়।

চার ধরনের নিয়ম

বাড়ান দ্রুত, কমান ধীরে — আর warm-up-এর দেরি

দুই দিকের ভুলের দাম সমান নয়: কম instance মানে ব্যবহারকারী ফেরত যান, বেশি মানে কয়েক মিনিটের বাড়তি ভাড়া। তাই scale out দ্রুত, scale in ধীরে। বারবার ওঠানামা (flapping) ঠেকাতে থাকে cooldown বা stabilization window: গত কয়েক মিনিটের সবচেয়ে বড় সুপারিশটি ধরে রাখা। লেখার সময়ে Kubernetes-এর HPA-তে কমানোর এই জানালার ডিফল্ট প্রায় ৫ মিনিট (সংস্করণভেদে বদলাতে পারে)। কমানোর সময় instance-কে হঠাৎ বন্ধ না করে আগে নতুন অনুরোধ বন্ধ, চলমানগুলো শেষ করতে দেওয়া — connection draining.

সবচেয়ে বড় সমস্যা warm-up. নতুন instance-কে চালু হতে হয় (virtual machine হলে প্রায়ই এক বা একাধিক মিনিট, container হলে সাধারণত কয়েক সেকেন্ড), তারপর প্রোগ্রাম load, connection pool খোলা, cache ভরা, JIT compile (চলার সময় কোডকে যন্ত্রের ভাষায় রূপান্তর) — আর load balancer-এর health check পরপর কয়েকবার পাস করা। ততক্ষণ পুরোনোরাই সব চাপ টানে। নিচের সময়রেখার সংখ্যা ধরা যাক — প্রতিটি instance ১০০ অনুরোধ/সেকেন্ড পর্যন্ত ভালো p99 দেয়, লক্ষ্য ৬০%, metric instance-প্রতি অনুরোধের হার:

এবার একই ধরনের ঘটনা মিনিট ধরে, দুই নিয়মে। Reactive: শুধু target tracking. Scheduled: একই target tracking, সাথে একটি নির্ধারিত নিয়ম — ফল প্রকাশ (মিনিট ১০) জানা, তাই মিনিট ৬ থেকে ১৯ পর্যন্ত সর্বনিম্ন ৫২টি instance (পূর্বাভাসের peak প্রায় ৩,১০০ ÷ ৬০ ≈ ৫১.৭, ওপরে গোল)। চাপে ±৩% এলোমেলো ওঠানামা — seed বাঁধা, তাই প্রতিবার একই ফল। ৮৫%-এর বেশি ব্যস্ততায় সেই মিনিটের সব উত্তর “slow” (M/M/1-এ সেখানে অপেক্ষা সেবার সময়ের কয়েক গুণ, পর্ব ০৪), আর ক্ষমতার বেশি অংশ “drop”:

// Autoscaler, minute by minute. Exam results go live at minute 10 (known in advance).
// ASSUMED: 1 instance = 100 req/s at good p99; target utilisation 60%;
// a new instance needs WARM minutes (boot + warm-up) before it takes traffic.
const CAP = 100, TARGET = 0.6, WARM = 2;
let seed = 13;                                   // mulberry32: seeded, repeatable
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 shape = [9,9,9,9,9,9,9,9,9,9, 24,30,30,30,30,30,30,30,24,18, 14,12,11,10,10,10,10,10,10,10];
const load = shape.map(h => Math.round(h * 100 * (0.97 + 0.06 * rand())));   // req/s

function run(plan) {              // plan = [from, to, at least N instances] or null
  let ready = 15, boot = [], recs = [], out = [], slow = 0, drop = 0, cost = 0;
  for (let t = 0; t < load.length; t++) {
    ready += boot.filter(b => b === t).length; boot = boot.filter(b => b > t);
    const cap = ready * CAP, u = load[t] / cap;
    const d = Math.max(0, load[t] - cap) * 60, s = u > 0.85 ? Math.min(load[t], cap) * 60 : 0;
    drop += d; slow += s; cost += ready + boot.length;   // booting instances are paid too
    out.push([ready, boot.length, u, s, d]);
    let want = Math.ceil(load[t] / (CAP * TARGET));      // target tracking on minute t
    if (plan && t + 1 >= plan[0] && t + 1 < plan[1]) want = Math.max(want, plan[2]);
    recs.push(want);
    const keep = Math.max(...recs.slice(-5));           // scale in: highest of last 5 min
    if (want > ready + boot.length) while (ready + boot.length < want) boot.push(t + 1 + WARM);
    else if (keep < ready && boot.length === 0) ready = keep;
  }
  return { out, slow, drop, cost };
}
const R = run(null), S = run([6, 20, 52]), k = (x) => Math.round(x / 1000) + "k";
const cell = (r) => (r[0] + (r[1] ? "+" + r[1] : "")).padStart(6) +
  (Math.round(r[2] * 100) + "%").padStart(5) + k(r[3]).padStart(5) + k(r[4]).padStart(5);
console.log("min req/s │ R: inst util slow drop │ S: inst util slow drop");
for (let t = 4; t < 27; t++)
  console.log(String(t).padStart(3) + String(load[t]).padStart(6) + " │" + cell(R.out[t]) + " │" + cell(S.out[t]));
for (const [name, x] of [["reactive ", R], ["scheduled", S]])
  console.log(name + " slow " + k(x.slow) + ", dropped " + k(x.drop) + ", instance-minutes " + x.cost);

min req/s │ R: inst util slow drop │ S: inst util slow drop
  4   875 │    16  55%   0k   0k │    16  55%   0k   0k
  5   873 │    16  55%   0k   0k │    16  55%   0k   0k
  6   878 │    15  59%   0k   0k │ 16+36  55%   0k   0k
  7   892 │    15  59%   0k   0k │ 16+36  56%   0k   0k
  8   903 │    15  60%   0k   0k │    52  17%   0k   0k
  9   920 │  15+1  61%   0k   0k │    52  18%   0k   0k
 10  2422 │  15+1 161%  90k  55k │    52  47%   0k   0k
 11  3047 │ 16+25 190%  96k  87k │    52  59%   0k   0k
 12  2962 │ 16+35 185%  96k  82k │    52  57%   0k   0k
 13  2940 │ 41+10  72%   0k   0k │    52  57%   0k   0k
 14  3011 │    51  59%   0k   0k │    52  58%   0k   0k
 15  2976 │    51  58%   0k   0k │    52  57%   0k   0k
 16  3014 │    51  59%   0k   0k │    52  58%   0k   0k
 17  3021 │    51  59%   0k   0k │    52  58%   0k   0k
 18  2346 │    51  46%   0k   0k │    52  45%   0k   0k
 19  1816 │    51  36%   0k   0k │    52  35%   0k   0k
 20  1394 │    51  27%   0k   0k │    52  27%   0k   0k
 21  1211 │    51  24%   0k   0k │    52  23%   0k   0k
 22  1089 │    51  21%   0k   0k │    52  21%   0k   0k
 23   976 │    40  24%   0k   0k │    52  19%   0k   0k
 24  1015 │    31  33%   0k   0k │    31  33%   0k   0k
 25   994 │    24  41%   0k   0k │    24  41%   0k   0k
 26   975 │    21  46%   0k   0k │    21  46%   0k   0k
reactive  slow 282k, dropped 224k, instance-minutes 943
scheduled slow 0k, dropped 0k, instance-minutes 1160

৮ · Headroom, N+1, খরচ আর scale-এর একক

Autoscaling থাকলেও বাড়তি ক্ষমতা হাতে রাখতে হয়। Headroom-এর তিনটি স্তর আলাদা করে ভাবুন:

• Queue-র জন্য: utilisation ১০০%-এর কাছে গেলে অপেক্ষা বিস্ফোরিত হয় (M/M/1-এ মোট সময় S ÷ (1 − ρ): ρ = ০.৬-এ ২.৫S, ০.৯-এ ১০S; পর্ব ০৪), তাই peak-এ মোটামুটি ৫০–৭০% লক্ষ্য।
• ব্যর্থতার জন্য: একটি instance বা একটি পুরো zone হারালেও বাকিরা peak টানতে পারবে কি? এটাই N+1, N+2 বা zone-ভিত্তিক হিসাব (পর্ব ০৫, আর পর্ব ০৩-এর অংশ ৮)।
• প্রতিক্রিয়ার সময়ের জন্য: autoscaler সাড়া দিতে যতক্ষণ নেয়, ততক্ষণ চাপ যতটা বাড়তে পারে — বাড়তি ক্ষমতা ≥ চাপ বাড়ার হার × (সিদ্ধান্ত + warm-up). প্রতি মিনিটে ২০০ অনুরোধ/সেকেন্ড বাড়লে আর সাড়া দিতে ৪ মিনিট লাগলে অন্তত ৮০০ অনুরোধ/সেকেন্ড বাড়তি রাখতে হবে।

খরচের হিসাব — এক বড় বাক্স বনাম অনেক ছোট

অংশ ২-এর খরচের বাঁক আর পর্ব ০৫-এর k-of-n অঙ্ক একসাথে: peak-এ ৩২ একক ক্ষমতা লাগে। দাম আপেক্ষিক একক-এ আর ধরে নেওয়া: ৮ একক পর্যন্ত দাম আকারের সমানুপাতিক, তার ওপরে প্রতিবার আকার দ্বিগুণে প্রতি এককের দাম ১.৫ গুণ। যেকোনো একটি যন্ত্রের availability ধরা হলো ৯৯.৫% (crash আর patch-এর restart মিলিয়ে)। একাধিক যন্ত্রের সামনে একটি LB জোড়া (খরচ ২ একক, প্রতিটি ৯৯.৯%):

// One big machine or many small ones for the same peak? Cost and availability.
// ASSUMED price curve in RELATIVE units (not real prices): up to size 8 the price
// grows in step with size; above 8 every doubling costs 1.5x more per unit.
const price = (size) => size <= 8 ? size : size * Math.pow(1.5, Math.log2(size / 8));
const A1 = 0.995;        // ASSUMED availability of ANY one machine (crash, patch reboot)
const LB = { cost: 2, a: 1 - 0.001 ** 2 };   // LB pair (or failover pair), 99.9% each
function atLeast(k, n, a) {                  // P(at least k of n machines are up)
  let sum = 0, c = 1;                        // c = C(n, i)
  for (let i = 0; i <= n; i++) {
    if (i >= k) sum += c * a ** i * (1 - a) ** (n - i);
    c = c * (n - i) / (i + 1);
  }
  return sum;
}
console.log("size  price  per unit");
for (const s of [1, 2, 4, 8, 16, 32, 64])
  console.log(String(s).padStart(4) + price(s).toFixed(0).padStart(7) + (price(s) / s).toFixed(2).padStart(10));

const NEED = 32;                             // capacity units needed at peak
const designs = [["1 x 32  vertical", 32, 1], ["2 x 32  active-passive", 32, 2],
  ["4 x 8   no spare", 8, 4], ["5 x 8   N+1", 8, 5], ["34 x 1  N+2", 1, 34]];
console.log("\ndesign                  cost  full peak (down/yr)    half peak");
for (const [name, size, n] of designs) {
  const k = NEED / size, extra = n > 1 ? LB.a : 1;     // >1 machine: LB pair in front
  const full = atLeast(k, n, A1) * extra, half = atLeast(Math.ceil(k / 2), n, A1) * extra;
  const cost = n * price(size) + (n > 1 ? LB.cost : 0);
  console.log(name.padEnd(23) + cost.toFixed(0).padStart(5) +
    ((100 * full).toFixed(3) + "% (" + ((1 - full) * 8760).toFixed(1) + " h)").padStart(21) +
    ((100 * half).toFixed(4) + "%").padStart(13));
}

size  price  per unit
   1      1      1.00
   2      2      1.00
   4      4      1.00
   8      8      1.00
  16     24      1.50
  32     72      2.25
  64    216      3.38

design                  cost  full peak (down/yr)    half peak
1 x 32  vertical          72     99.500% (43.8 h)     99.5000%
2 x 32  active-passive   146      99.997% (0.2 h)     99.9974%
4 x 8   no spare          34    98.015% (173.9 h)     99.9999%
5 x 8   N+1               42      99.975% (2.2 h)     99.9999%
34 x 1  N+2               36      99.933% (5.8 h)     99.9999%

Scale-এর একক — VM, container, serverless

একক যত হালকা, তত দ্রুত বাড়ানো যায়, warm-up-এর সমস্যা তত ছোট। সময়গুলো মোটামুটি মাত্রা; প্রদানকারী, image আর runtime-ভেদে বহু গুণ আলাদা:

Container, image আর orchestration কীভাবে deploy-এর অংশ হয়, তা পর্ব ৫৩-এ (Deployment আর release). ভেতরের প্রযুক্তি দেখতে Operating Systems কোর্সের container আর virtual machine পর্ব পড়ুন।

৯ · AI-এর যুগে scaling-এর নকশা যাচাই

“আমার অ্যাপকে ১ কোটি ব্যবহারকারীর জন্য scalable করার নকশা চাই” লিখলে AI নিমেষে Kubernetes, autoscaling, Kafka, Redis আর microservices-এর ছবি দেবে। কিন্তু কিছু ভুল প্রায় নিয়ম করে আসে:

AI-এর দেওয়া scaling-নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• instance-এর সংখ্যা নিজে হিসাব করেছি — লক্ষ্য-utilisation, N+1 আর ওপরে গোল সহ
• bottleneck স্তরটি চিহ্নিত করেছি; app বাড়ালে database, connection বা বাইরের সেবা আগে ভাঙবে কি না মিলিয়েছি
• সব লুকানো state (session, local ফাইল, counter, cron, সংযোগ) খুঁজে তার জায়গা ঠিক করেছি
• autoscaling-এর প্রতিক্রিয়ার সময় × চাপ বাড়ার হার হিসাব করেছি; জানা ভিড়ে scheduled নিয়ম আর সর্বোচ্চ সীমা রেখেছি
• ছোট load test বা simulation চালিয়েছি; পণ্যের সীমা বা দাম অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি; অপ্রয়োজনীয় অংশ বাদ দিয়েছি