अगर आपने AI से बने कोड को सुरक्षित रूप से चलाने के बारे में कुछ भी पढ़ा है, तो आपने microVM शब्द देखा होगा, आम तौर पर Firecracker के साथ। इसे या तो “हल्की VM” कहकर समझाया जाता है (सही, पर बेकार), या कर्नेल के अंदरूनी हिस्सों के आरेख से। यह बीच वाला संस्करण है।
दो पुराने विकल्प, और क्यों कोई भी फ़िट नहीं बैठता
उन दो चीज़ों से शुरू करें जिनके बीच microVM आती है।
कंटेनर आपकी मशीन पर साधारण प्रक्रियाओं का एक समूह है, जिनसे कर्नेल ने “झूठ बोलने” की हामी भरी है। namespaces उन्हें अपना फ़ाइल सिस्टम, प्रक्रियाओं की सूची और नेटवर्क दिखाते हैं; cgroups सीमित करते हैं कि वे कितना CPU और मेमोरी इस्तेमाल कर सकती हैं। यह मिलीसेकंड में शुरू होता है क्योंकि कुछ भी नया बूट नहीं होता। लेकिन एक होस्ट के सारे कंटेनर एक ही कर्नेल से बात करते हैं। किसी एक कंटेनर के अंदर से पहुँच में आने वाला कर्नेल बग सभी कंटेनरों से बाहर निकलने का रास्ता है।
वर्चुअल मशीन अपना कर्नेल लाती है। होस्ट का CPU, हार्डवेयर वर्चुअलाइज़ेशन (Linux पर KVM) के ज़रिए, गेस्ट को ऐसे चलाता है जैसे उसका अपना कंप्यूटर हो। सीमा हाइपरवाइज़र है, जो कर्नेल की सैकड़ों system calls से कहीं कम चीज़ें उजागर करता है। कीमत है भारीपन। एक क्लासिक VM पूरे PC को एम्युलेट करती है: फ़र्मवेयर, PCI बस, USB कंट्रोलर, ग्राफ़िक्स कार्ड, कभी-कभी साउंड कार्ड भी। वह इन सबसे गुज़रकर बूट होती है, सेकंड से मिनट लेती है, और हर इंस्टेंस दसियों या सैकड़ों मेगाबाइट का ओवरहेड ढोता है।
एक उपमा जो काफ़ी हद तक ठीक बैठती है: कंटेनर एक ही इमारत के फ़्लैट हैं, जिनकी नींव, पाइप और वायरिंग साझा है। VM अलग-अलग मकान हैं। मकान ज़्यादा सुरक्षित पड़ोसी हैं, लेकिन 20 सेकंड की मुलाक़ात के लिए कोई मकान नहीं बनाता।
Firecracker क्या हटाता है
Firecracker एक virtual machine monitor है (वह प्रोग्राम जो KVM के ऊपर VM तैयार करता और चलाता है), 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 और पूरी VM को साथ-साथ रखता है। और अगर आपका ध्यान प्रति-सेकंड कीमत ने खींचा है, तो प्रति-सेकंड बिलिंग असल में कैसे काम करती है पूरा हिसाब दिखाता है।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।