VM, container, microVM আর serverless — কোনটি কখন

১ · একটি প্রশ্ন, অনেক উত্তর — isolation-এর বর্ণালি

পর্ব ৫০-এ দেখেছেন hypervisor কীভাবে একটি যন্ত্রে কয়েকটি পূর্ণ OS চালায়, আর পর্ব ৫১-এ দেখেছেন container কীভাবে namespace আর cgroup দিয়ে একটি kernel-এর ভেতরেই আলাদা ঘর বানায়। এই পর্বে নতুন যন্ত্র শেখা নয়, বাছাই শেখা। আপনি একটি ওয়েব অ্যাপ লিখেছেন। এখন সেটি কোথায় চালাবেন — একটি সাধারণ প্রসেস হিসেবে, container-এ, VM-এ, নাকি কোনো serverless প্ল্যাটফর্মে? উত্তর দিতে প্রথমে একটি প্রশ্ন করুন: আমার প্রোগ্রাম পাশের প্রোগ্রামের সাথে কী কী ভাগ করছে?

যে দেয়াল দুই প্রোগ্রামকে আলাদা রাখে, তাকে বলি isolation boundary. দেয়ালটি যত নিচের স্তরে (হার্ডওয়্যারের কাছে) টানা হয়, ভাগ-করা অংশ তত কম, আর ভাগ-করা অংশের বাগ দিয়ে পাশের ঘরে ঢোকার পথও তত কম। নিচের ডায়াগ্রামে বর্ণালির সাতটি ধাপ এক এক করে দেখুন — প্রতিটি ধাপে কী ভাগ হয়, আর সীমানা কে টানে।

২ · মাঝের ধাপগুলো — gVisor, Kata আর Firecracker কীভাবে কাজ করে

Container আর VM-এর মাঝখানের জায়গাটি গত এক দশকে সবচেয়ে বেশি উদ্ভাবন দেখেছে, কারণ ক্লাউড-কোম্পানিগুলো একসাথে দুটি জিনিস চেয়েছে: container-এর গতি আর VM-এর সীমানা। তিনটি পথ তিন রকম কৌশল নিয়েছে। নিচের বিবরণ সরলীকৃত; প্রতিটি প্রকল্প সক্রিয়ভাবে বদলাচ্ছে, তাই বিস্তারিত নকশার জন্য তাদের অফিসিয়াল ডকুমেন্টেশন দেখুন।

তিনটির কোনোটিই নতুন মৌলিক যন্ত্র আনেনি: gVisor হলো syscall interposition আর seccomp, Kata হলো পর্ব ৫০-এর hardware virtualization, Firecracker হলো minimalism — পর্ব ৬-এর microkernel-চিন্তার মতো, বিশ্বস্ত কোড যত ছোট, তত কম বাগ। নিরাপত্তা-প্রকৌশলে এই বিশ্বস্ত অংশকে বলে trusted computing base.

৩ · তুলনার টেবিল — কী কিনছেন, কী দিচ্ছেন

নিচের টেবিল মাত্রার ক্রম (order of magnitude) দেখায়, নির্দিষ্ট সংখ্যা নয়। আসল মান নির্ভর করে image-এর আকার, guest OS, ডিস্ক, hypervisor আর কনফিগারেশনের ওপর — নিজের পরিবেশে মেপে দেখুন।

সংখ্যা মুখস্থ করার চেয়ে হাতে হিসাব করা বেশি শিক্ষণীয়। ধরুন আপনার কাছে ৬৪ GiB RAM-এর একটি সার্ভার। প্রতিটি instance-এর বাড়তি মেমরি (guest kernel, guest OS-এর সার্ভিস, VMM প্রসেস বা runtime shim) কত, তার ওপর নির্ভর করে কতগুলো অ্যাপ বসানো যায়। নিচের ক্যালকুলেটরের সংখ্যাগুলো আনুমানিক — স্পষ্টভাবে অনুমান হিসেবে লেখা, যাতে আপনি নিজের মাপ বসিয়ে আবার চালাতে পারেন:

// How many instances fit on one 64 GiB host? Overheads are rough, illustrative assumptions (MiB).
const HOST_MIB = 64 * 1024, RESERVED_MIB = 4 * 1024;           // host OS + hypervisor/agent keep 4 GiB
const usable = HOST_MIB - RESERVED_MIB;
const kinds = [                                                // per-instance overhead on top of the app itself
  { name: 'full VM',          guest: 400, vmm: 30, start: 'tens of s' }, // guest kernel + distro services; QEMU-like VMM
  { name: 'microVM',          guest: 40,  vmm: 5,  start: '0.1-1 s' },   // tiny guest kernel; Firecracker-like VMM
  { name: 'gVisor container', guest: 30,  vmm: 0,  start: 'under 1 s' }, // user-space kernel (Sentry) per sandbox
  { name: 'container',        guest: 0,   vmm: 5,  start: 'under 1 s' }, // shared host kernel; runtime shim process
  { name: 'process',          guest: 0,   vmm: 0,  start: 'ms' },
];
for (const app of [128, 1024]) {                               // the app's own working memory
  console.log(`--- app needs ${app} MiB; usable host memory ${usable} MiB ---`);
  console.log('kind              overhead  fits  overhead share  start (typical order)');
  for (const k of kinds) {
    const over = k.guest + k.vmm, fit = Math.floor(usable / (app + over));
    console.log(`${k.name.padEnd(17)} ${String(over).padStart(5)} MiB ${String(fit).padStart(5)}` +
      `  ${(100 * over / (app + over)).toFixed(0).padStart(10)} %     ${k.start}`);
  }
}

--- app needs 128 MiB; usable host memory 61440 MiB ---
kind              overhead  fits  overhead share  start (typical order)
full VM             430 MiB   110          77 %     tens of s
microVM              45 MiB   355          26 %     0.1-1 s
gVisor container     30 MiB   388          19 %     under 1 s
container             5 MiB   461           4 %     under 1 s
process               0 MiB   480           0 %     ms
--- app needs 1024 MiB; usable host memory 61440 MiB ---
kind              overhead  fits  overhead share  start (typical order)
full VM             430 MiB    42          30 %     tens of s
microVM              45 MiB    57           4 %     0.1-1 s
gVisor container     30 MiB    58           3 %     under 1 s
container             5 MiB    59           0 %     under 1 s
process               0 MiB    60           0 %     ms

৪ · Multi-tenancy — কেন cloud container-কে VM-এর ভেতরে রাখে

একটি cloud প্রতিষ্ঠান একই ভৌত সার্ভারে হাজারো গ্রাহকের কোড চালায় — এই ব্যবস্থার নাম multi-tenancy (বহু ভাড়াটে)। এখানে প্রতিবেশী শুধু অচেনা নয়, কেউ কেউ ইচ্ছা করেই আক্রমণকারী হতে পারে: মাসে কয়েক ডলারে একটি অ্যাকাউন্ট খুলে সীমানা ভাঙার চেষ্টা করা সহজ। তাই প্রশ্ন দাঁড়ায়: প্রতিবেশীর থেকে আমাকে আলাদা করছে কোন দেয়াল, আর সেই দেয়াল কতটা পুরু?

সাধারণ container-এ দেয়াল হলো Linux kernel নিজেই। Kernel বিশাল, প্রতি বছর তাতে নিরাপত্তা-বাগ পাওয়া যায়, আর container থেকে kernel-এর প্রায় সব syscall নাগালে (seccomp কিছুটা ছাঁটে)। ২০১৯ সালে প্রকাশিত runc-এর একটি ত্রুটি (CVE-2019-5736) দেখিয়েছিল, নির্দিষ্ট পরিস্থিতিতে container-এর ভেতরের ক্ষতিকর প্রোগ্রাম host-এর runc ফাইলটিই বদলে দিতে পারত। এ ধরনের ঘটনা ঠিক হয়, কিন্তু শিক্ষাটি থাকে: বিশ্বস্ত দলের নিজের সার্ভিস আলাদা করতে container যথেষ্ট; শত্রুভাবাপন্ন হতে পারে এমন প্রতিবেশীর জন্য আরেকটি দেয়াল চাই।

তাই প্রধান public cloud-গুলো একটি স্তরবিন্যাস ব্যবহার করে: ভাড়াটের container চলে সেই ভাড়াটের নিজের VM বা microVM-এর ভেতরে। Managed Kubernetes-এর worker node-গুলো আসলে আপনার অ্যাকাউন্টের VM; অন্য গ্রাহকের pod আপনার kernel-এ চলে না। ভেতরের container দেয় সুবিধা (image, দ্রুত deploy), বাইরের VM দেয় সীমানা। তবু কিছু ভাগ থেকে যায়: প্রতিবেশীর CPU-ব্যবহার আপনার latency বাড়ালে তা noisy neighbor সমস্যা, আর একই CPU core-এর cache ভাগ করলে Spectre-ধরনের side channel-এর ঝুঁকি — তাই কিছু প্রদানকারী এক core-এর দুই hyperthread দুই ভাড়াটেকে দেন না বলে জানান।

নিজের চোখে দেখুন। এই পাতার কোড-রানার নিজেই এই নকশার একটি উদাহরণ। নিচের স্ক্রিপ্ট শুধু পড়ে, কিছু বদলায় না:

echo "== layer 1: is this kernel running inside a VM? =="
grep -m1 -o -w hypervisor /proc/cpuinfo || echo "no hypervisor flag"
grep -m1 'model name' /proc/cpuinfo
echo "kernel: $(uname -r)   CPUs seen: $(nproc)   $(grep MemTotal /proc/meminfo)"
echo "== layer 2: is this shell inside a container? =="
awk '$2 == "/" {print "root filesystem:", $1, "type", $3}' /proc/mounts
ps -o pid,ppid,comm -p 1,$$
echo "PID 1 says: $(tr '\0' '\n' < /proc/1/environ | grep '^container=')"
echo "marker file: $(ls /run/.containerenv 2>/dev/null || echo none)"
echo "== layer 3: which cgroup, and what limits? =="
echo "cgroup: $(cat /proc/self/cgroup)"
for f in memory.max pids.max cpu.max; do
    echo "$f = $(cat /sys/fs/cgroup/$f 2>/dev/null || echo not-visible)"
done
echo "== namespaces of this shell (inode numbers) =="
for ns in pid mnt net uts user; do printf '%s ' "$(readlink /proc/self/ns/$ns)"; done; echo

== layer 1: is this kernel running inside a VM? ==
hypervisor
model name	: AMD EPYC-Rome Processor
kernel: 6.8.0-137-generic   CPUs seen: 2   MemTotal:        2008912 kB
== layer 2: is this shell inside a container? ==
root filesystem: overlay type overlay
    PID    PPID COMMAND
      1       0 podman-init
      2       1 bash
PID 1 says: container=podman
marker file: /run/.containerenv
== layer 3: which cgroup, and what limits? ==
cgroup: 0::/
memory.max = max
pids.max = 2048
cpu.max = max 100000
== namespaces of this shell (inode numbers) ==
pid:[4026533158] mnt:[4026533154] net:[4026533093] uts:[4026533156] user:[4026532740] 

৫ · Unikernel — OS-কে অ্যাপের মাপে কেটে ফেলা

পর্ব ৬-এ OS-এর গঠনের আলোচনায় unikernel-এর পরিচয় পেয়েছেন। এবার বর্ণালিতে তার জায়গা দেখুন। microVM-এর ভেতরেও একটি সাধারণ Linux kernel চলে, যার বেশিরভাগ অংশ (বহু ব্যবহারকারী, shell, শত ধরনের driver) একটি ওয়েব-ফাংশনের কোনো কাজে লাগে না। Unikernel প্রশ্ন করে: অ্যাপের সাথে শুধু দরকারি OS-অংশ লাইব্রেরির মতো compile করে একটি image বানালে কেমন হয়? Cambridge-এর MirageOS (OCaml ভাষায়, ২০১৩ সালের গবেষণাপত্র) আর পরের Unikraft (Linux Foundation-এর Xen প্রকল্পের অংশ হিসেবে শুরু, ২০২১ সালে গবেষণাপত্র) এর পরিচিত উদাহরণ।

প্রতিশ্রুতি: image কয়েক MiB, গবেষণায় বুট মিলিসেকেন্ডের ঘরে, আর attack surface খুব ছোট — shell-ই নেই। বাধা: প্রচলিত debug-টুল চলে না, অ্যাপ প্রায়ই নতুন করে build করতে হয়, আর Linux-এর সব আচরণ মেলে না। তাই এটি এখনো মূলত বিশেষায়িত কাজে দেখা যায়।

৬ · Serverless আর FaaS — ঘটনা এলে চলে, না এলে শূন্য

Serverless নামটি বিভ্রান্তিকর: সার্ভার অবশ্যই আছে, শুধু আপনি তা দেখেন না, বেছে নেন না, patch করেন না। সবচেয়ে পরিচিত রূপ FaaS (Function as a Service): আপনি একটি ফাংশন লেখেন, আর প্ল্যাটফর্ম ঠিক করে কখন, কোথায়, কয়টি কপিতে সেটি চলবে। AWS Lambda ২০১৪ সালে এই ধারণা জনপ্রিয় করে; পরে Google Cloud Functions, Azure Functions আর অন্যরা আসে। মূল বৈশিষ্ট্যগুলো:

• Event-driven: ফাংশন চলে কোনো ঘটনায় — HTTP অনুরোধ, একটি ফাইল আপলোড, queue-তে নতুন বার্তা, নির্দিষ্ট সময় (cron-এর মতো)।
• Scale to zero: অনুরোধ না থাকলে কোনো instance চলে না, আর spike এলে প্ল্যাটফর্ম নিজে শত শত instance বাড়ায়।
• Pay-per-use: দাম সাধারণত অনুরোধের সংখ্যা আর “মেমরি × চলার সময়” (GB-second) দিয়ে, অলস সময়ের জন্য নয়।
• সময়-সীমা: প্রতিটি কল একটি নির্দিষ্ট সময়ের বেশি চলতে পারে না — প্রদানকারী আর প্ল্যানভেদে আলাদা; যেমন লেখার সময় AWS Lambda-র সর্বোচ্চ ১৫ মিনিট। লম্বা কাজ ভেঙে queue বা workflow সার্ভিসে দিতে হয়।
• Stateless: একটি কল থেকে পরের কলে instance-এর মেমরি বা লোকাল ডিস্কে কিছু থাকবে, এমন ভরসা করা যায় না। Session, ফাইল, ফলাফল — সব থাকে বাইরের সার্ভিসে: ডেটাবেস (দেখুন DBMS কোর্সের cloud database পর্ব), object storage, cache.

Cold start আর warm start

Scale to zero-র উল্টো পিঠ: শূন্য থেকে প্রথম অনুরোধ এলে কাউকে instance বানাতে হয়। এই বাড়তি দেরিই cold start. আগের অনুরোধ শেষ করে অপেক্ষায় থাকা instance পেলে সেটি warm start, শুধু ফাংশনের নিজের কাজের সময়। নিচের ডায়াগ্রামে একটি ফলাফল-দেখার ফাংশনে দুই পথের সময় ধাপে ধাপে দেখুন। সময়গুলো উদাহরণ — runtime, প্যাকেজের আকার আর প্রদানকারীভেদে অনেক বদলায়।

শেষ কৌশলটির একটি পরিচিত উদাহরণ AWS Lambda-র SnapStart: ফাংশন প্রকাশের সময় init শেষ হওয়া microVM-এর মেমরি আর ডিস্কের ছবি রাখা হয়, আর cold start-এ নতুন করে বুট না করে সেই ছবি থেকে ফিরিয়ে আনা হয়। ২০২২ সালে Java-র জন্য চালু হয়, পরে আরও কিছু runtime-এ — কোন runtime-এ, কোন শর্তে, তা AWS-এর বর্তমান ডকুমেন্টেশনে দেখুন। ফিরিয়ে আনার পথটি পর্ব ৩৫-এর demand paging আর copy-on-write-এর আত্মীয়: পুরো মেমরি একবারে না এনে যে পাতা ছোঁয়া হয়, সেটি আনা।

সিমুলেটর ১ — ফলাফল-দিবসে serverless

ধরুন একটি বিশ্ববিদ্যালয়ের ফলাফল-পোর্টাল। মাসের বেশিরভাগ সময় অল্প অনুরোধ — দিনে প্রতি ৪ মিনিটে গড়ে একটি, রাতে প্রতি ৩০ মিনিটে একটি। ৩০তম দিনে সকাল ১০টায় ফলাফল প্রকাশ, আর এক ঘণ্টা ধরে সেকেন্ডে গড়ে ২০০ অনুরোধ। অনুরোধ আসে এলোমেলোভাবে (Poisson প্রক্রিয়া, নির্দিষ্ট seed-এ, তাই প্রতিবার একই ফল)। নিচের সব সংখ্যা — cold start ৮০০ ms, warm কাজ ৫০ ms, ১০ মিনিট অলস থাকলে instance সরানো, আর দাম — উদাহরণের অনুমান, কোনো প্রদানকারীর বর্তমান দাম নয়:

// Serverless result portal for one month: cold vs warm starts. ALL numbers are illustrative assumptions.
const WORK = 0.050, COLD = 0.800, KEEP_WARM = 600;            // seconds: handler work, cold-start penalty, idle timeout
const MEM_GB = 0.5, PER_REQ = 0.20 / 1e6, PER_GBS = 0.0000166667; // example prices (USD), not a real quote
let seed = 52; const rnd = () => (seed = (seed * 16807) % 2147483647) / 2147483647;
const rate = (d, h) => d === 29 && h >= 10 && h < 11 ? 200 :     // day 30, 10-11 am: results published
  (h >= 9 && h < 21 ? 1 / 240 : 1 / 1800);                       // otherwise: 1 per 4 min by day, 1 per 30 min at night
const idle = [], busyWarm = [], busyCold = [], lat = { quiet: [], spike: [] };
let n = 0, colds = 0, gbs = 0;
for (let d = 0; d < 30; d++) for (let t = 0; t < 86400; ) {
  const r = rate(d, t / 3600), hourEnd = (Math.floor(t / 3600) + 1) * 3600, gap = -Math.log(1 - rnd()) / r;
  if (t + gap >= hourEnd) { t = hourEnd; continue; }             // Poisson arrivals, rate fixed within each hour
  t += gap;
  const now = d * 86400 + t, kind = r > 1 ? 'spike' : 'quiet';
  for (;;) {                                                     // finished instances become idle (oldest first)
    const q = (busyWarm[0] ?? Infinity) <= (busyCold[0] ?? Infinity) ? busyWarm : busyCold;
    if (!q.length || q[0] > now) break;
    idle.push(q.shift());
  }
  while (idle.length && now - idle[0] > KEEP_WARM) idle.shift(); // idle too long: reclaimed (scale to zero)
  const cold = idle.length === 0;
  if (cold) colds++; else idle.pop();                            // reuse the most recently used warm instance
  const busy = WORK + (cold ? COLD : 0);
  (cold ? busyCold : busyWarm).push(now + busy);
  lat[kind].push(Math.round(busy * 1000)); gbs += MEM_GB * busy; n++;
}
const pct = (a, p) => a[Math.min(a.length - 1, Math.floor(p / 100 * a.length))];
for (const k of ['quiet', 'spike']) {
  const a = lat[k].sort((x, y) => x - y), c = a.filter(v => v > 100).length;
  console.log(`${k.padEnd(5)}: ${String(a.length).padStart(7)} requests, ${String(c).padStart(5)} cold (${(100 * c / a.length).toFixed(2)}%)` +
    `  p50 = ${pct(a, 50)} ms  p95 = ${pct(a, 95)} ms  p99 = ${pct(a, 99)} ms`);
}
const cost = n * PER_REQ + gbs * PER_GBS;
console.log(`month: ${n} requests, ${colds} cold starts, ${gbs.toFixed(0)} GB-s billed -> about $${cost.toFixed(2)}`);

quiet:    6088 requests,   961 cold (15.79%)  p50 = 50 ms  p95 = 850 ms  p99 = 850 ms
spike:  721190 requests,   134 cold (0.02%)  p50 = 50 ms  p95 = 50 ms  p99 = 50 ms
month: 727278 requests, 1095 cold starts, 18620 GB-s billed -> about $0.46

সিমুলেটর ২ — একই ট্রাফিক, সবসময় চালু VM-এ

এবার একই অনুরোধগুলো (একই seed) চালানো যাক কয়েকটি সবসময়-চালু VM-এ, প্রতিটিতে ৪টি worker (container বা প্রসেস)। এখানে cold start নেই, কিন্তু worker সংখ্যা স্থির: সবাই ব্যস্ত থাকলে অনুরোধ লাইনে দাঁড়ায় (পর্ব ১৬-এর FCFS queue-র মতো)। VM-এর দাম ঘণ্টায় ০.০৫ ডলার ধরা — এটিও উদাহরণ:

// Same month of traffic, served by an always-on fleet of VMs/containers. Illustrative assumptions only.
const WORK = 0.050, WORKERS_PER_VM = 4, VM_PER_HOUR = 0.05;    // 50 ms per request; example price in USD
let seed = 52; const rnd = () => (seed = (seed * 16807) % 2147483647) / 2147483647;
const rate = (d, h) => d === 29 && h >= 10 && h < 11 ? 200 : (h >= 9 && h < 21 ? 1 / 240 : 1 / 1800);
const arrivals = [];                                            // identical traffic generator (same seed)
for (let d = 0; d < 30; d++) for (let t = 0; t < 86400; ) {
  const r = rate(d, t / 3600), hourEnd = (Math.floor(t / 3600) + 1) * 3600, gap = -Math.log(1 - rnd()) / r;
  if (t + gap >= hourEnd) { t = hourEnd; continue; }
  t += gap; arrivals.push(d * 86400 + t);
}
const pct = (a, p) => a[Math.min(a.length - 1, Math.floor(p / 100 * a.length))];
for (const vms of [2, 3, 4]) {
  const free = new Array(vms * WORKERS_PER_VM).fill(0), lat = [];
  for (const now of arrivals) {                                 // FIFO: next request goes to the earliest free worker
    let w = 0;
    for (let i = 1; i < free.length; i++) if (free[i] < free[w]) w = i;
    const start = Math.max(now, free[w]);
    free[w] = start + WORK;
    lat.push(Math.round((free[w] - now) * 1000));
  }
  lat.sort((x, y) => x - y);
  const cost = vms * VM_PER_HOUR * 24 * 30;
  console.log(`${vms} VMs x ${WORKERS_PER_VM} workers: p50 = ${pct(lat, 50)} ms  p95 = ${pct(lat, 95)} ms` +
    `  p99.9 = ${pct(lat, 99.9)} ms  worst = ${lat[lat.length - 1]} ms  cost = $${cost.toFixed(2)}/month`);
}
const perReq = 0.20 / 1e6 + 0.5 * WORK * 0.0000166667;         // serverless price of one warm 50 ms request
const vm3 = 3 * VM_PER_HOUR * 24 * 30;
console.log(`break-even: ${(vm3 / perReq / 1e6).toFixed(0)} million requests/month = ` +
  `${(vm3 / perReq / (30 * 86400)).toFixed(0)} requests/second around the clock`);

2 VMs x 4 workers: p50 = 447871 ms  p95 = 861582 ms  p99.9 = 906414 ms  worst = 907516 ms  cost = $72.00/month
3 VMs x 4 workers: p50 = 50 ms  p95 = 79 ms  p99.9 = 123 ms  worst = 154 ms  cost = $108.00/month
4 VMs x 4 workers: p50 = 50 ms  p95 = 50 ms  p99.9 = 69 ms  worst = 86 ms  cost = $144.00/month
break-even: 175 million requests/month = 68 requests/second around the clock

৭ · WebAssembly আর V8 isolate — আরও হালকা sandbox, edge-এ

বর্ণালিতে আরেকটি পথ আছে, যা kernel-এর সীমানা নয়, ভাষা-runtime-এর সীমানা ব্যবহার করে। একটি JavaScript ইঞ্জিন (যেমন Chrome-এর V8) একই প্রসেসের ভেতরে অনেকগুলো isolate চালাতে পারে — প্রতিটির নিজের heap আর global অবস্থা, একে অপরের অবজেক্ট ছুঁতে পারে না। Cloudflare Workers এই নকশায় তৈরি: প্রতিটি গ্রাহকের কোড একটি isolate-এ, আর নতুন isolate চালু হতে নতুন প্রসেস বা VM-এর মতো সময় লাগে না — কোম্পানিটি মিলিসেকেন্ডের ঘরের startup-এর কথা বলে। এতে কোড চালানো যায় ব্যবহারকারীর কাছের অনেক ছোট ডেটা সেন্টারে — একে বলে edge computing.

WebAssembly (Wasm) একই চিন্তার একটি বহনযোগ্য রূপ (পর্ব ৪৯-এ এর sandbox-এর পরিচয় পেয়েছেন)। C, Rust, Go-র মতো ভাষা থেকে Wasm-এ compile করা কোড শুধু নিজের linear memory দেখে, আর বাইরের জগতে যেতে পারে শুধু host যে ফাংশন দেয় সেগুলো দিয়ে। ব্রাউজারের বাইরে এই “বাইরের জগৎ”-এর মানদণ্ড WASI — ফাইল, ঘড়ি, এলোমেলো সংখ্যা, socket-এর মতো সেবা, capability-ধাঁচে: runtime যে ফোল্ডার খুলে দেয়, কেবল সেটিই দেখা যায়। WASI-র কয়েকটি সংস্করণ এসেছে (২০১৯ সালের preview 1, ২০২৪ সালে component model-ভিত্তিক 0.2), আর Wasmtime, WasmEdge-এর মতো runtime এগুলো বাস্তবায়ন করে।

একই প্রসেসে অনেক গ্রাহক মানে runtime-এর একটি বাগ বা CPU-র side channel সরাসরি প্রতিবেশীর দিকে খোলে। তাই এই প্ল্যাটফর্মগুলো প্রসেস-স্তরের sandbox আর ঘড়ির নির্ভুলতা কমানোর মতো বাড়তি স্তর ব্যবহার করে বলে জানায় — আবার defense in depth.

৮ · Cloud-এর OS-চিন্তা — নতুন kernel, পাল, অপরিবর্তনীয় সার্ভার আর Kubernetes

Hypervisor নতুন kernel. একটি সাধারণ কম্পিউটারে kernel প্রসেসদের মধ্যে CPU, মেমরি আর ডিভাইস ভাগ করে আর তাদের আলাদা রাখে। Cloud-এর ডেটা সেন্টারে এই কাজটিই করে hypervisor — শুধু “প্রসেস” এখানে পুরো VM. Cloud প্রদানকারীরা তাই hypervisor-কে যতটা সম্ভব ছোট আর বিশেষায়িত করছে: যেমন AWS-এর Nitro ব্যবস্থায় নেটওয়ার্ক, স্টোরেজ আর ব্যবস্থাপনার কাজ আলাদা হার্ডওয়্যার কার্ডে সরানো, আর মূল যন্ত্রে KVM-ভিত্তিক একটি পাতলা hypervisor — AWS-এর ভাষ্য অনুযায়ী। পর্ব ৬-এর microkernel-চিন্তা এখানে ডেটা সেন্টারের মাপে ফিরে এসেছে।

Cattle, not pets. পুরোনো দিনে প্রতিটি সার্ভার ছিল পোষা প্রাণী: নাম ছিল, প্রশাসক হাতে যত্ন নিতেন, অসুস্থ হলে সারাতেন। ক্লাউডে সার্ভার হলো পালের গরু: নম্বর আছে, নাম নেই; একটি অসুস্থ হলে সরিয়ে নতুন একটি আনা হয়। তুলনাটির উৎস হিসেবে সাধারণত ২০০০-এর দশকে Bill Baker-এর একটি বক্তৃতার কথা বলা হয়; ২০১০-এর দশকের শুরুতে Randy Bias-এর মতো cloud-প্রকৌশলীদের হাত ঘুরে এটি জনপ্রিয় হয়। এর সাথে আসে immutable infrastructure: চলমান সার্ভারে ssh করে প্যাকেজ আপডেট করা হয় না; নতুন image বানিয়ে পুরোনো সার্ভার বদলে দেওয়া হয়। লাভ: প্রতিটি সার্ভার ঠিক জানা অবস্থায়, “আমার মেশিনে চলে” সমস্যা কম, আর ফেরত যাওয়া মানে পুরোনো image আবার চালানো।

Container-optimised OS. সার্ভার যদি শুধু container চালায়, তবে তার OS-এ কী লাগে? খুব কম। Bottlerocket (AWS, ২০২০), Flatcar Container Linux (CoreOS Container Linux-এর উত্তরসূরি) আর Talos Linux (shell বা SSH ছাড়া, শুধু API দিয়ে পরিচালিত) এর উদাহরণ। সাধারণত: শুধু-পড়ার root file system, প্যাকেজ ম্যানেজার নেই, আর পুরো OS একসাথে A/B partition-এ হালনাগাদ — ব্যর্থ হলে আগের partition থেকে বুট। খুঁটিনাটি প্রকল্পভেদে আলাদা।

Kubernetes — একটি “cluster-এর OS”-এর উপমা

Google ২০১৪ সালে Kubernetes প্রকাশ করে, ভেতরের Borg ব্যবস্থার অভিজ্ঞতা থেকে। একে অনেকে “cluster-এর OS” বলেন। উপমাটি শিক্ষণীয়, তবে এটি একক kernel নয় — অনেক যন্ত্রে ছড়ানো প্রোগ্রামের একটি দল, যারা একটি ডেটাবেসে (etcd) লেখা “কাঙ্ক্ষিত অবস্থা”-র দিকে বাস্তবকে বারবার টেনে আনে।

requests আর limits বোঝা জরুরি, কারণ ভুল সেটিং বহু রহস্যময় সমস্যার উৎস। requests হলো প্রতিশ্রুতি: scheduler শুধু সেই node-এ pod বসায়, যেখানে অন্তত এতটা CPU আর মেমরি এখনো কাউকে প্রতিশ্রুত নয়। limits হলো ছাদ, যা kubelet cgroup দিয়ে প্রয়োগ করে: CPU limit পেরোলে প্রসেস মারা যায় না, শুধু থামিয়ে রাখা হয় (throttling, পর্ব ২১-এর CFS bandwidth), তাই latency হঠাৎ লাফায়; মেমরি limit পেরোলে OOM kill. দুটো সমান দিলে pod পায় “Guaranteed” শ্রেণি, শুধু requests দিলে “Burstable”, কিছুই না দিলে “BestEffort” — চাপের সময় আগে সরানো হয়।

৯ · খরচ আর সিদ্ধান্ত — বাংলাদেশের তিনটি দৃশ্যপট

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

এবার তিনটি কাল্পনিক কিন্তু পরিচিত দৃশ্যপটে প্রশ্নগুলো প্রয়োগ করা যাক। এগুলো কোনো নির্দিষ্ট প্রতিষ্ঠানের বর্ণনা নয়, আর বাস্তব সিদ্ধান্তে আপনার নিজের সংখ্যা, বাজেট আর আইনি শর্ত লাগবে।

১০ · AI-এর যুগে প্ল্যাটফর্ম-পরামর্শ — দামি ভুল কম করুন

“আমার অ্যাপের জন্য Kubernetes নাকি serverless?” — এই প্রশ্নে AI সাধারণত আত্মবিশ্বাসী, গোছানো উত্তর দেয়। সমস্যা হলো, উত্তরটি প্রায়ই আপনার ট্রাফিক, বাজেট আর দলের আকার না জেনেই দেওয়া, আর দাম বা সীমার সংখ্যাগুলো পুরোনো প্রশিক্ষণ-ডেটা থেকে আসে। প্ল্যাটফর্মের ভুল সিদ্ধান্ত মাসের পর মাস বিল আর রক্ষণাবেক্ষণে দাম চায়।

AI-এর প্ল্যাটফর্ম-পরামর্শ মানার আগে — চেকলিস্ট

• নিজের ট্রাফিকের আকৃতি (গড়, সর্বোচ্চ, spike কতক্ষণ) আর latency-লক্ষ্য (p95) লিখে AI-কে দিয়েছি
• প্রতিটি দাম, timeout আর quota প্রদানকারীর বর্তমান অফিসিয়াল পাতায় মিলিয়েছি
• খরচে gateway, egress, লগ, ডেটাবেস আর ব্যাকআপ যোগ করেছি
• অচেনা কোড বা বহু গ্রাহক থাকলে isolation-এর স্তর (VM, microVM, gVisor) আলাদা করে ভেবেছি
• একটি ছোট load test চালিয়ে cold start, p95 আর throttling নিজে মেপেছি
• দলের দক্ষতা আর রাতের দায়িত্ব — কে এটি চালাবেন — হিসাবে ধরেছি