কোন compute কখন — VM, container, PaaS আর FaaS-এর তুলনা

১ · “সবচেয়ে ভালো compute” বলে কিছু নেই

এই মডিউলে আপনি VM, image, autoscaling আর load balancer দেখেছেন। পর্ব ০২-এ দেখেছেন কে কী সামলায়, অর্থাৎ দায়িত্বের তুলনা। এবার প্রশ্ন আলাদা: আমার এই কাজটি কোথায় চালাব? এখানে আমরা দায়িত্ব নয়, workload-এর সাথে মানানসই হওয়া মাপব। Workload মানে আপনার সিস্টেম আসলে যে কাজটি করে: একটি API, রাতের রিপোর্ট, বা ছবি ছোট করার কাজ।

বিকল্পগুলোকে একবার গুছিয়ে নিই। সব কিছুর ভেতরে শেষ পর্যন্ত server-ই আছে। পার্থক্য হলো আপনি কতটা দেখেন আর সামলান।

এই বিকল্পগুলোকে একটি রেখায় সাজানো যায়। ডানে গেলে নিয়ন্ত্রণ বাড়ে, আর ওপরে গেলে আপনার দলের operational burden, অর্থাৎ চালিয়ে রাখার ঝক্কি বাড়ে। প্রায় সব কিছুই একটি কোনাকুনি রেখায় বসে। একটি ব্যতিক্রম খেয়াল করুন।

VM-এ OS-এর ভেতরের সব কিছু আপনার হাতে। Kubernetes-এ node-এর kernel সাধারণত আপনি বদলান না, তবু cluster, upgrade আর network নিয়ে অনেক কাজ থাকে। বড় দলে এই বিনিয়োগ শোধ হয়, কারণ এক platform-এ শত শত service চলে। তাই ঝক্কির মাপ দলের আকার আর service সংখ্যার ওপরও নির্ভর করে। VM, container আর serverless-এর ভেতরের isolation বিষয়টি Operating Systems কোর্সের এই পর্বে আছে। এখানে সেটি আর নয়, এখানে শুধু সিদ্ধান্ত।

২ · নয়টি মাত্রা — তুলনা করবেন কী দিয়ে

“কোনটি ভালো” বলার আগে ঠিক করুন, কী মাপছেন। নিচের টেবিলের নয়টি মাত্রা প্রায় যেকোনো সিদ্ধান্তের জন্য যথেষ্ট। সংখ্যাগুলো মাত্রার ধারণা দেয়, provider আর সেটিংভেদে আলাদা হয়।

খরচ দুটি সারিতে ভাঙা, তবু মাত্রা একটিই। কারণ এই দুই সারি উল্টো দিকে চলে, আর সেখান থেকেই অংশ ৪-এর crossover আসে। Startup time-ও শুধু গতির প্রশ্ন নয়। পর্ব ১৭-এ দেখেছেন, VM উঠতে দেরি হলে autoscaling ভিড়ের পেছনে পড়ে যায়। Container মিনিটের বদলে সেকেন্ডে ওঠে বলে হঠাৎ ভিড় সামলানো সহজ হয়।

State নিয়ে এক লাইন মনে রাখুন। Stateful process নিজের ভেতরে এমন ডেটা রাখে, যা হারালে ক্ষতি। পর্ব ০২-এর stateless নিয়ম মানলে ডানের তিনটি কলাম সহজে খোলে। যে app লোকাল disk-এ session বা upload রাখে, সেটি আগে বদলাতে হয়।

৩ · কাজ ধরে ধরে — সাতটি workload

এবার নিয়মগুলো সাতটি পরিচিত কাজে খাটাই। শেষ কলামটিই সবচেয়ে কাজের: কেন অন্য বিকল্প বাদ গেল। সিদ্ধান্তের কারণ জানলে শর্ত বদলালে সিদ্ধান্তও বদলাতে পারবেন।

নিয়মগুলোকে কোড করে নিলে কৌশলটি স্পষ্ট হয়। নিচের elimination rule-গুলো “কোনটি ভালো” বলে না, শুধু বলে “কোনটি চলবে না”। প্রতিটি বাদের কারণ পাশে ছাপা হয়। যা বাকি থাকে, তার মধ্যে হালকাটি বাছা হয়। পাতার ভেতরেই চলে, কোনো account লাগে না। TEAM_K8S বা MAX_MIN বদলে চালিয়ে দেখুন।

// Workload-to-compute recommender: rules ELIMINATE options, then the
// lightest survivor wins. The limits below are ASSUMED; check your provider.
const MAX_MIN = 15, TEAM_K8S = false;
const ORDER = ["FaaS", "Batch", "PaaS", "CaaS", "K8s", "VM"]; // light to heavy
const rules = [
  [(w) => w.legacyOS, ["FaaS", "Batch", "PaaS", "CaaS", "K8s"], "full OS"],
  [(w) => w.minutes > MAX_MIN, ["FaaS"], "run time"],
  [(w) => w.gpu, ["FaaS", "PaaS", "CaaS"], "GPU"],
  [(w) => w.alwaysOn, ["Batch"], "always on"],
  [(w) => !w.alwaysOn, ["PaaS"], "not a service"],
  [(w) => w.coldOK === false, ["FaaS"], "cold start"],
  [(w) => w.nativeLibs, ["PaaS"], "custom runtime"],
  [() => !TEAM_K8S, ["K8s"], "team skill"],
];
const jobs = [
  { name: "web API",         minutes: 0.1, alwaysOn: true, coldOK: false },
  { name: "nightly batch",   minutes: 40 },
  { name: "ML training",     minutes: 600, gpu: true },
  { name: "stream consumer", minutes: Infinity, alwaysOn: true, nativeLibs: true },
  { name: "cron job",        minutes: 2 },
  { name: "legacy Windows",  minutes: Infinity, alwaysOn: true, legacyOS: true },
  { name: "event thumbnail", minutes: 0.1 },
];
for (const w of jobs) {
  const out = new Map();
  for (const [when, opts, why] of rules) {
    if (!when(w)) continue;
    for (const o of opts) if (!out.has(o)) out.set(o, why);
  }
  const keep = ORDER.filter((o) => !out.has(o));
  console.log(w.name);
  console.log("  out : " + [...out].map(([o, y]) => `${o} (${y})`).join(", "));
  console.log("  keep: " + keep.join(", ") + "  -> pick " + keep[0]);
}

web API
  out : Batch (always on), FaaS (cold start), K8s (team skill)
  keep: PaaS, CaaS, VM  -> pick PaaS
nightly batch
  out : FaaS (run time), PaaS (not a service), K8s (team skill)
  keep: Batch, CaaS, VM  -> pick Batch
ML training
  out : FaaS (run time), PaaS (GPU), CaaS (GPU), K8s (team skill)
  keep: Batch, VM  -> pick Batch
stream consumer
  out : FaaS (run time), Batch (always on), PaaS (custom runtime), K8s (team skill)
  keep: CaaS, VM  -> pick CaaS
cron job
  out : PaaS (not a service), K8s (team skill)
  keep: FaaS, Batch, CaaS, VM  -> pick FaaS
legacy Windows
  out : FaaS (full OS), Batch (full OS), PaaS (full OS), CaaS (full OS), K8s (full OS)
  keep: VM  -> pick VM
event thumbnail
  out : PaaS (not a service), K8s (team skill)
  keep: FaaS, Batch, CaaS, VM  -> pick FaaS

৪ · খরচের crossover — কোন load-এ কে সস্তা

VM-এর বিল একটি স্থির ভাড়া, আর FaaS-এর বিল প্রতি request-এ বাড়ে। মোবাইল প্যাকেজের মতো: মাসিক বান্ডেল কিনলে কম কথা বললে লোকসান, মিনিট-প্রতি রেটে বেশি কথা বললে লোকসান। দুই বিল যে load-এ সমান হয়, সেটিই cost crossover. পর্ব ০৪-এর break-even ছিল সময়ের ওপর, আর এটি load-এর ওপর।

Crossover একটি সংখ্যা নয়, অনুমানের ফল। আগের ধাপগুলোতে দেখলেন, কোন সারি ধরছেন তার ওপর উত্তর আড়াই গুণ বদলে গেল। এবার মাঝে container service-কেও যোগ করি। ধরি একটি task ০.৫ vCPU আর ১ GB-র, ঘণ্টায় $০.০৪, অর্থাৎ মাসে $২৮.৮০। একটি task সেকেন্ডে ১৫টি request নিতে পারে, আর একটি VM ৬০টি। VM-গুলো peak-এর মাপে স্থির (peak গড়ের ১.৫ গুণ), আর task load-এর সাথে বাড়ে-কমে, ২০% বাড়তি জায়গা রেখে। সবই অনুমান।

// Monthly bill: VM vs container service vs FaaS. All prices are ASSUMED.
const P = {
  vmMonth: 72,      vmRps: 60,   peak: 1.5,  // VMs are fixed, sized for the peak
  taskMonth: 28.8,  taskRps: 15, head: 1.2,  // tasks follow the load, 20% headroom
  faasPerM: 3.2,                             // $ per million requests
};
const rps = (m) => m * 1e6 / (30 * 86400);   // m = million requests per month
const count = (need, cap) => Math.max(1, Math.ceil(need / cap));
const bill = {
  VM:   (m) => count(rps(m) * P.peak, P.vmRps) * P.vmMonth,
  CaaS: (m) => count(rps(m) * P.head, P.taskRps) * P.taskMonth,
  FaaS: (m) => m * P.faasPerM,
};
const names = Object.keys(bill);
const best = (m) => names.reduce((a, b) => (bill[b](m) < bill[a](m) ? b : a));

console.log(" M req/mo  avg rps      VM    CaaS     FaaS  cheapest");
for (const m of [1, 5, 9, 20, 50, 70, 100, 200, 400]) {
  const row = names.map((n) => bill[n](m).toFixed(0).padStart(n === "FaaS" ? 9 : 8));
  console.log(String(m).padStart(8), rps(m).toFixed(1).padStart(8), row.join(""), "", best(m));
}
console.log("\ncheapest choice, scanning 0.5M to 400M:");
let cur = best(0.5), from = 0.5;
for (let m = 1; m <= 400; m += 0.5) {
  if (best(m) !== cur) {
    console.log(`  ${from}M - ${m - 0.5}M: ${cur}`);
    cur = best(m); from = m;
  }
}
console.log(`  ${from}M - 400M: ${cur}`);

 M req/mo  avg rps      VM    CaaS     FaaS  cheapest
       1      0.4       72      29        3  FaaS
       5      1.9       72      29       16  FaaS
       9      3.5       72      29       29  CaaS
      20      7.7       72      29       64  CaaS
      50     19.3       72      58      160  CaaS
      70     27.0       72      86      224  VM
     100     38.6       72     115      320  VM
     200     77.2      144     202      640  VM
     400    154.3      288     374     1280  VM

cheapest choice, scanning 0.5M to 400M:
  0.5M - 8.5M: FaaS
  9M - 64.5M: CaaS
  65M - 103.5M: VM
  104M - 129.5M: CaaS
  130M - 207M: VM
  207.5M - 226.5M: CaaS
  227M - 400M: VM

৫ · Container service — VM আর Kubernetes-এর মাঝখানে

অনেক দল এভাবে ভাবে: হয় VM, নয়তো Kubernetes. মাঝখানে একটি বড় জায়গা আছে। Serverless container service-এ আপনি একটি image দেন, CPU আর memory বলেন, কয়টি কপি চলবে বা কোন rule-এ বাড়বে তা বলেন। Node কেনা, patch করা, cluster upgrade করা আপনার কাজ নয়।

এই তথ্যগুলো লেখার সময়ের। সুবিধা বদলায়, তাই provider-এর নথি দেখে নিন। নিচের উদাহরণটি একটি সাধারণ deployment-এর চেহারা দেখায়, যা service-এর ধারণা বোঝাতে লেখা। এতে node, cluster বা OS-এর কথা নেই। অন্য provider-এ command আলাদা, ধারণা একই। কোনো account ছাড়াই শুধু পড়ে দেখুন। আসলে চালালে খরচ হতে পারে, আর পরে service মুছে ফেলতে হবে।

# উদাহরণ — চালাতে Google Cloud account লাগে, খরচ হতে পারে
gcloud run deploy shop-api \
  --image=example.registry.dev/shop/api:1.4.2 \
  --cpu=1 --memory=512Mi \
  --min-instances=0 --max-instances=20 \
  --concurrency=80 --region=asia-south1

# কাজ শেষে মুছে ফেলুন
gcloud run services delete shop-api --region=asia-south1

latest tag নয়, নির্দিষ্ট 1.4.2 ব্যবহার করা হয়েছে, যাতে কী চলছে তা জানা থাকে। --max-instances বিলের ওপর একটি ছাদ, আর পরের অংশে দেখবেন এটি database-কেও বাঁচায়।

Kubernetes কখন ছোট দলের জন্য বেশি

Microservice-এর মতো Kubernetes-ও বড় সমস্যার সমাধান, আর ছোট দলে সেটি নিজেই সমস্যা হতে পারে। Managed Kubernetes-এ control plane provider চালান, তবু version upgrade, node group, ingress, network policy, RBAC, observability দলের কাজই থাকে। Kubernetes বছরে কয়েকটি minor version ছাড়ে, আর প্রতিটির সমর্থন সীমিত সময়ের। তাই upgrade একবারের কাজ নয়, নিয়মিত কাজ।

নিচের প্রশ্নগুলোর বেশিরভাগ উত্তর “না” হলে Kubernetes-এর আগে container service বা PaaS ভাবুন:

• আপনার কি অন্তত ৮–১০টি স্বাধীন service আছে, বা শিগগিরই হবে?
• দলে কি Kubernetes জানা অন্তত দুজন আছেন, যাতে on-call একজনের ওপর না পড়ে?
• Custom scheduling, sidecar বা operator-এর মতো সত্যিকারের কোনো দরকার আছে?
• একই platform-এ অনেক দল কাজ করবে, তাই সাধারণ নিয়ম লাভজনক?
• Cluster-এর খরচ আর সময় উঠে আসার মতো স্থির load আছে?

ওপরের ৮–১০ কোনো মানদণ্ড নয়, শুধু আলোচনার একটি শুরু। ছবি ১৯.১-এর কথা মনে রাখুন: ৩ জনের দলে যে ঘণ্টাগুলো cluster-এ যায়, সেগুলো পণ্য থেকে কমে। Kubernetes-এর পথ পরে খোলাই থাকে। Image আগে থেকেই তৈরি থাকলে সরে যাওয়া তুলনামূলক সহজ। এজন্যই container service একটি ভালো মাঝের ধাপ। পর্ব ৪২-এ Kubernetes-কে নিজের জায়গায় পূর্ণ মর্যাদায় দেখবেন।

৬ · FaaS-এর সীমা কখন কামড়ায় — concurrency check

FaaS-এ স্কেল করা বিনামূল্যের জাদু মনে হয়। কিন্তু একটি নিয়ম আছে: অনেক FaaS platform-এ এক instance একসাথে একটি request-ই সামলায়। তাই একসাথে যত request চলছে, ততগুলো instance লাগে। এই সংখ্যাই concurrency. এটি বের হয় Little's law থেকে:

রেলস্টেশনের টিকিট কাউন্টার ভাবুন। মিনিটে ৬ জন আসেন আর একজনের ২ মিনিট লাগলে গড়ে ১২ জন কাউন্টারে থাকেন। কাজ যদি ধীর হয়, ভিড় বাড়ে, যদিও মানুষ বেশি আসেনি। FaaS-এও তা-ই। সূত্রের দ্বিতীয় অংশটি লক্ষ করুন: database ধীর হলে duration বাড়ে, আর concurrency বাড়ে কোনো নতুন ক্রেতা ছাড়াই।

এবার তিনটি ছাদ ধরি। Account-এর concurrency সীমা ১,০০০, database-এর connection সীমা ৩০০, আর নতুন instance ওঠার গতি মিনিটে ৫০০। শেষ সংখ্যাটি বিশেষভাবে অনুমিত, কারণ provider-ভেদে এটি অনেক আলাদা আর অনেক দ্রুতও হতে পারে। প্রতিটি instance একটি করে database connection খোলে ধরা হলো।

// Concurrency check. Little's law: concurrent = rate x duration.
// Limits are ASSUMED round numbers; real ones differ by provider and account.
const LIMIT = 1000, DB_CONN = 300, NEW_PER_MIN = 500, PER_TASK = 80;
const cases = [
  ["normal day",  100, 0.2],
  ["sale begins", 800, 0.2],
  ["DB is slow",  800, 1.0],
  ["Eid peak",   3000, 0.4],
];
console.log("case          req/s  sec  concurrent  platform  database");
for (const [name, rate, sec] of cases) {
  const c = Math.round(rate * sec);
  const lost = Math.max(0, rate - LIMIT / sec);
  const plat = c > LIMIT ? `-${lost}/s` : "ok";
  const db = c > DB_CONN ? "over" : "ok";
  console.log(name.padEnd(12), String(rate).padStart(6), String(sec).padStart(4),
    String(c).padStart(11), plat.padStart(9), db.padStart(9));
}
console.log("\nramp to Eid peak: starts from 20 running, +" + NEW_PER_MIN + " per minute");
const want = 1200, sec = 0.4, rate = want / sec;
let running = 20;
for (let min = 0; min <= 3; min++) {
  const served = Math.min(running, want, LIMIT) / sec;
  console.log(`minute ${min}: running ${String(running).padStart(4)}, ` +
    `served ${String(served).padStart(4)}/s, rejected ${String(rate - served).padStart(4)}/s`);
  running = Math.min(running + NEW_PER_MIN, LIMIT);
}
const tasks = Math.ceil(want / PER_TASK);
console.log(`\ncontainer service: ${want} / ${PER_TASK} per task = ${tasks} tasks; ` +
  `pool of 10 per task = ${tasks * 10} DB connections`);

case          req/s  sec  concurrent  platform  database
normal day      100  0.2          20        ok        ok
sale begins     800  0.2         160        ok        ok
DB is slow      800    1         800        ok      over
Eid peak       3000  0.4        1200    -500/s      over

ramp to Eid peak: starts from 20 running, +500 per minute
minute 0: running   20, served   50/s, rejected 2950/s
minute 1: running  520, served 1300/s, rejected 1700/s
minute 2: running 1000, served 2500/s, rejected  500/s
minute 3: running 1000, served 2500/s, rejected  500/s

container service: 1200 / 80 per task = 15 tasks; pool of 10 per task = 150 DB connections

সমাধানগুলো চিনে রাখুন, বিস্তারিত পর্ব ৬৯ আর ৭০-এ। Function-এর সর্বোচ্চ concurrency একটি নির্দিষ্ট সংখ্যায় বেঁধে দিলে database বাঁচে। সামনে queue রাখলে কাজ জমা থাকে, হারায় না, যদিও উত্তর দেরিতে আসে। Provisioned concurrency কিছু instance আগেই তৈরি রাখে, যদিও তার জন্য অলস সময়েও বিল আসে। ঈদের আগে quota বাড়ানোর আবেদনও আগেভাগে করুন।

৭ · Batch আর spot — শেষ হয় এমন কাজ

Web service-এর কাজ কখনো শেষ হয় না। Batch job-এর কাজ শেষ হয়। রাতের রিপোর্ট, ভিডিও রূপান্তর, ML training সবই শুরু আর শেষ আছে এমন কাজ। এদের বিশেষ সুবিধা: সাধারণত কেউ তাকিয়ে অপেক্ষা করেন না। এক ঘণ্টা দেরি হলেও ক্ষতি নেই, যদি সকালের আগে শেষ হয়। তাই এরাই spot-এর স্বাভাবিক গ্রাহক।

নিচের কাজটি দেখুন। ধরা যাক, FaaS-এর একটি call সর্বোচ্চ ১৫ মিনিট চলে। লেখার সময়ে AWS Lambda-র সীমা এমনই, তবে অন্য provider আর plan-এ এই সীমা ভিন্ন: কোথাও কম, কোথাও এক ঘণ্টা বা তারও বেশি। আপনার ক্ষেত্রে সীমা বদলালে ফলও বদলাবে।

Spot মানে provider-এর ফাঁকা ক্ষমতা, যা দরকার হলে ফেরত নেওয়া হয়। আগে একটি ছোট নোটিশ আসে: লেখার সময়ে AWS-এ প্রায় দুই মিনিট, Azure আর Google Cloud-এ প্রায় ৩০ সেকেন্ড। নিচের প্রশ্নগুলো মিলিয়ে দেখুন, কোন কাজ spot-এ চলবে।

সময়সীমা শক্ত হলে একটি ব্যবহারিক পথ আছে: শুরুতে spot, শেষ সময়ের আগে কাজ না ফুরালে on-demand-এ চলে যাওয়া। Checkpoint-এর মূল্য অনুশীলন ৪-এ হিসাব করবেন। দামের নিয়ম আর spot-এর বিস্তারিত পর্ব ৭২-এ আছে।

৮ · একটি সিস্টেমে কয়েকটি compute, আর সময়ের সাথে বদল

আসল সিস্টেম একটি compute-এ থাকে না। প্রতিটি অংশের চরিত্র আলাদা, তাই উত্তরও আলাদা। বিয়েবাড়ির ক্যাটারিংয়ের মতো: মূল রান্না নিজের হাঁড়িতে, মিষ্টি বাইরে থেকে অর্ডার, আর বাড়তি অতিথি এলে অতিরিক্ত লোক ডাকা। নিচে একটি কাল্পনিক অনলাইন শাড়ির দোকানের তিন বছর দেখুন। লক্ষ করুন, কোনো ধাপেই “সব নতুন করে” লেখা হয়নি। প্রতিটি বদল এসেছে একটি নির্দিষ্ট ব্যথা থেকে।

মিশ্রণের একটি দাম আছে। প্রতিটি নতুন compute মানে আরেকটি deployment পথ, আরেক ধরনের log, আরেক সেট permission, আর on-call-এ শেখার আরেকটি জিনিস। তাই নিয়মটি হলো: কারণ ছাড়া নতুন ধরন যোগ করবেন না। দোকানটি প্রতিটি ধরন যোগ করেছে একটি মাপা ব্যথার জন্য। সবাইকে মিলিয়ে দেখার কৌশল পর্ব ৬৫-এর tracing-এ আছে।

সিদ্ধান্ত একবার নিলেই শেষ নয়। নিচের ঘটনাগুলোর কোনোটি ঘটলে হিসাবটি আবার খুলুন। না ঘটলেও বছরে অন্তত দুবার দেখুন।

৯ · AI-এর যুগে compute বাছাই

AI ভালো তালিকা বানায়, কিন্তু আপনার workload চেনে না। আর একটি প্রবণতা আছে: “scalable” শব্দটি শুনলেই সে Kubernetes লিখে দেয়, দলের আকার না জেনেই। নিচের টেবিলে এই বিষয়ে তার সাধারণ ভুলগুলো আছে।

AI-এর পরামর্শ হাতে পেলে — চেকলিস্ট

• প্রতিটি বাদ পড়া বিকল্পের কারণ আমার নিজের সংখ্যা দিয়ে মিলিয়েছি
• Crossover একবার হাতে হিসাব করেছি
• Run time, concurrency আর GPU-র সীমা provider-এর নথিতে দেখেছি, তারিখসহ
• Rate × duration হিসাব করে database-এর connection সীমার সাথে মিলিয়েছি
• দলের কে রাত ২টায় এটি সামলাবেন, সেই নাম লিখেছি
• * permission, 0.0.0.0/0, public storage আর hardcoded secret নেই
• --dry-run বা terraform plan পড়েছি, throwaway পরিবেশে চালিয়েছি, আর budget alert রেখেছি