اگر آپ نے AI کے بنائے کوڈ کو محفوظ طریقے سے چلانے کے بارے میں کچھ بھی پڑھا ہے تو آپ نے microVM کا لفظ دیکھا ہوگا، عام طور پر Firecracker کے ساتھ۔ اسے یا تو „ہلکی ورچوئل مشین“ کہہ کر سمجھایا جاتا ہے (درست، مگر بے فائدہ)، یا کرنل کے اندرونی حصوں کے خاکے سے۔ یہ درمیانی ورژن ہے۔
دو پرانے متبادل، اور کیوں کوئی بھی موزوں نہیں
ان دو چیزوں سے شروع کریں جن کے درمیان microVM آتی ہے۔
کنٹینر آپ کی مشین پر عام پروسیسز کا ایک گروپ ہے، جن سے کرنل نے „جھوٹ بولنے“ کی حامی بھری ہے۔ namespaces انہیں اپنا فائل سسٹم، پروسیسز کی فہرست اور نیٹ ورک دکھاتے ہیں؛ cgroups یہ محدود کرتے ہیں کہ وہ کتنا CPU اور میموری استعمال کر سکتے ہیں۔ یہ ملی سیکنڈز میں شروع ہوتا ہے کیونکہ کچھ بھی نیا بوٹ نہیں ہوتا۔ لیکن ایک ہوسٹ کے سارے کنٹینر ایک ہی کرنل سے بات کرتے ہیں۔ کسی ایک کنٹینر کے اندر سے پہنچ میں آنے والا کرنل بگ سب سے باہر نکلنے کا راستہ ہے۔
ورچوئل مشین اپنا کرنل لاتی ہے۔ ہوسٹ کا CPU، ہارڈویئر ورچوئلائزیشن (Linux پر KVM) کے ذریعے، مہمان کو ایسے چلاتا ہے جیسے اس کا اپنا کمپیوٹر ہو۔ سرحد ہائپروائزر ہے، جو کرنل کی سیکڑوں system calls سے کہیں کم چیزیں ظاہر کرتا ہے۔ قیمت ہے بھاری پن۔ ایک کلاسک ورچوئل مشین پورا PC ایمولیٹ کرتی ہے: فرم ویئر، PCI بس، USB کنٹرولر، گرافکس کارڈ، کبھی کبھی ساؤنڈ کارڈ بھی۔ وہ ان سب سے گزر کر بوٹ ہوتی ہے، سیکنڈوں سے منٹوں تک لیتی ہے، اور ہر انسٹینس دسیوں یا سیکڑوں میگابائٹ کا اوور ہیڈ اٹھاتا ہے۔
ایک تشبیہ جو کافی حد تک ٹھیک بیٹھتی ہے: کنٹینر ایک ہی عمارت کے فلیٹ ہیں، جن کی بنیاد، پائپ اور وائرنگ مشترک ہے۔ ورچوئل مشینیں الگ الگ مکان ہیں۔ مکان زیادہ محفوظ پڑوسی ہیں، لیکن 20 سیکنڈ کی ملاقات کے لیے کوئی مکان نہیں بناتا۔
کیا کچھ Firecracker ہٹا دیتا ہے
یہ Firecracker ایک virtual machine monitor ہے (وہ پروگرام جو KVM کے اوپر ورچوئل مشین تیار کرتا اور چلاتا ہے)، Rust میں لکھا گیا اور 2018 میں اوپن سورس کیا گیا۔ اسے ایک کام کے لیے بنایا گیا تھا: مشترکہ ہارڈویئر پر بہت بڑی تعداد میں کم عمر، ایک دوسرے پر بھروسا نہ کرنے والے ورک لوڈ چلانا۔ یہ وہاں زیادہ تر چیزیں ہٹا کر پہنچتا ہے:
- نہ فرم ویئر، نہ ہارڈویئر کی تلاش۔ کرنل سیدھا میموری میں لوڈ ہو کر شروع ہوتا ہے۔ کوئی ان ڈیوائسز کو نہیں ٹٹولتا جو موجود ہی نہیں۔
- چھوٹا سا ڈیوائس ماڈل۔ ایک نیٹ ورک کارڈ، ایک بلاک ڈیوائس، ایک سیریل کنسول اور چند اور، سب virtio (ورچوئل مشینوں کے لیے بنائے گئے ڈیوائس، جسمانی ڈیوائسز کی نقل نہیں)۔ نہ USB، نہ گرافکس، نہ PCI۔
- چھوٹا، میموری کے لحاظ سے محفوظ کوڈ بیس۔ ڈیوائس ایمولیٹ کرنے والا کوڈ کم ہو تو ایسے بگ کے لیے جگہیں بھی کم ہوتی ہیں جو مہمان کو ہوسٹ تک پہنچنے دیں۔
- خود VMM کے گرد ایک پنجرہ۔ ہر Firecracker پروسیس chroot کے اندر چلتا ہے، اس کی اپنی system calls پر seccomp فلٹر اور اس کے وسائل پر cgroups کی حد ہوتی ہے۔ اگر کچھ مہمان سے نکل بھی جائے تو وہ ہوسٹ پر نہیں، پنجرے میں گرے گا۔
منصوبے کے اپنے شائع کردہ اعداد ہیں: محض 125 ms میں user space، اور ہر microVM پر 5 MiB سے کم میموری اوور ہیڈ۔ یہ لیبارٹری کے بہترین اعداد ہیں؛ ایک اصل سینڈباکس کو ڈسک اور نیٹ ورک کی تیاری اور اندر کمانڈ لینے کو تیار ایک ایجنٹ بھی چاہیے، اس لیے ہمارا سینڈباکس تقریباً ایک سیکنڈ میں تیار ہوتا ہے۔ یہ اب بھی کنٹینر کی رفتار کے اتنا قریب ہے کہ آپ ہر کام کے لیے ایک بنا کر بعد میں پھینک سکیں۔
عملی طور پر کنٹینر بمقابلہ microVM
| کنٹینر | Firecracker microVM | |
|---|---|---|
| کرنل | ہوسٹ کے ساتھ مشترک | اپنا |
| ہوسٹ سے سرحد | مشترک کرنل میں system calls | ہائپروائزر + چھوٹا VMM |
| شروع ہونے کا وقت | ملی سیکنڈ | ~0.1–1 سیکنڈ |
| فی انسٹینس اوور ہیڈ | بہت کم | چند MiB |
| ڈیوائس | جو ہوسٹ ظاہر کرے | نیٹ ورک، ڈسک، کنسول |
| GPU | ممکن | نہیں |
| کس کے لیے اچھا | بھروسے مند کوڈ، ایپ پیکجنگ | ناقابل اعتماد کوڈ، ملٹی ٹیننٹ ورک لوڈ |
جو قطار اہم ہے وہ دوسری ہے۔ کنٹینر کے ساتھ „کیا یہ کوڈ باہر نکل سکتا ہے؟“ کا سوال بن جاتا ہے „کیا ہوسٹ کے کرنل میں کہیں پہنچ میں آنے والا کوئی بگ ہے؟“۔ microVM کے ساتھ یہ بن جاتا ہے „کیا ہائپروائزر یا گنے چنے ورچوئل ڈیوائسز میں کوئی بگ ہے؟“۔ دوسری سطح کہیں چھوٹی ہے، اور یہی وہ سطح ہے جس کا دفاع کلاؤڈ پلیٹ فارمز اپنی ملٹی ٹیننٹ ہوسٹنگ کے لیے پہلے سے کرتے ہیں۔
آپ کیا چھوڑتے ہیں
ایک microVM مفت کا اپ گریڈ نہیں ہے۔
- نہ GPU، نہ ڈسپلے۔ یہ کوڈ چلانے کے لیے ہے، ڈیسک ٹاپ یا گرافکس ورک لوڈ کے لیے نہیں۔
- کم ڈیوائس، کم لچک۔ جو کچھ بھی اصل ہارڈویئر یا کرنل ماڈیولز کی لمبی فہرست کی توقع رکھتا ہے، وہ یہاں آرام سے نہیں رہے گا۔
- سرحدوں کو اب بھی پالیسی چاہیے۔ کھلے egress والی microVM اب بھی ایسا ٹریفک بھیج سکتی ہے جو آپ نہیں چاہتے؛ جس کے اندر آپ کی API keys ہوں، وہ اب بھی انہیں لیک کر سکتی ہے۔ آئسولیشن ہوسٹ کو مہمان سے بچاتی ہے، آپ کے رازوں کو اس کوڈ سے نہیں جسے آپ نے وہ سونپ دیے۔
ہمارے سینڈباکس اسے کیسے استعمال کرتے ہیں
ہر EQVPS سینڈباکس اپنے کرنل والی ایک Firecracker microVM ہے، 0.25 vCPU اور 512 MB سے لے کر 8 vCPU اور 16 GB تک۔ اس میں Python 3.12، Node.js 22، bash، git اور curl آتے ہیں، آؤٹ باؤنڈ انٹرنیٹ ہے اور کوئی ان باؤنڈ پورٹ نہیں۔ عارضی سینڈباکس کام ختم ہونے پر حذف کر دیے جاتے ہیں؛ مستقل (persistent) سینڈباکس اپنی ڈسک رکھتے ہیں، اور pause کرنے پر microVM کا اسنیپ شاٹ ڈسک پر لکھ دیا جاتا ہے، تاکہ دوبارہ شروع ہونے تک کوئی خرچ نہ ہو۔ رکے ہوئے اسنیپ شاٹ 14 دن رکھے جاتے ہیں۔ اس کے بعد سینڈباکس حذف ہو جاتا ہے اور اس کی id 410 sandbox_deleted لوٹاتی ہے۔
ہم نے کنٹینر کے بجائے microVM ایک ہی وجہ سے چنی: سینڈباکس میں چلنے والا کوڈ، اپنی بناوٹ سے ہی، ایسا کوڈ ہے جسے کسی نے ریویو نہیں کیا۔ کسی AI ایجنٹ کا آؤٹ پٹ، کسی اجنبی کی pull request، ماڈل کے لکھے ہزار پروگراموں کا بینچ مارک۔ ان کے لیے اپنا کرنل ہی وہ سرحد ہے جس کی ادائیگی بامعنی ہے۔ اس کے گرد ہم نے جو رکھا ہے اس کی تفصیل — ٹیرف، کوٹے، سنکرونس کمانڈ کی 55 سیکنڈ کی حد — سینڈباکس دستاویزات میں ہے۔
اگر آپ اس سرحد کا دوسرے متبادلات سے زیادہ گہرائی میں موازنہ کرنا چاہتے ہیں تو ناقابل اعتماد کوڈ کے لیے آئسولیشن کی سطحیں پروسیسز، کنٹینرز، microVM اور مکمل ورچوئل مشینوں کو ساتھ ساتھ رکھتا ہے۔ اور اگر آپ کی توجہ فی سیکنڈ قیمت نے کھینچی ہے تو فی سیکنڈ بلنگ اصل میں کیسے کام کرتی ہے پورا حساب دکھاتا ہے۔
تبصرے
ابھی کوئی تبصرہ نہیں۔ پہلے بنیں۔