AI-র তৈরি কোড নিরাপদে চালানো নিয়ে যদি কিছু পড়ে থাকেন, তাহলে microVM শব্দটি দেখেছেন, সাধারণত Firecracker-এর পাশে। এটিকে হয় “হালকা VM” বলে ব্যাখ্যা করা হয় (সত্যি, কিন্তু কাজে আসে না), নয়তো কার্নেলের ভেতরের নকশার একটি ডায়াগ্রাম দিয়ে। এখানে মাঝামাঝি সংস্করণটি দেওয়া হলো।
দুটি পুরোনো বিকল্প, আর কেন কোনোটিই খাপ খায় না
যে দুটি জিনিসের মাঝখানে microVM আছে, সেখান থেকে শুরু করা যাক।
কনটেইনার হলো আপনার মেশিনে সাধারণ প্রসেসের একটি দল, যাদের কাছে কার্নেল “মিথ্যা বলতে” রাজি হয়েছে। namespaces তাদের নিজস্ব ফাইল সিস্টেম, প্রসেসের তালিকা আর নেটওয়ার্ক দেখায়; cgroups সীমা টানে তারা কতটা CPU আর মেমরি ব্যবহার করতে পারবে। এটি মিলিসেকেন্ডে চালু হয় কারণ নতুন কিছু বুট হয় না। কিন্তু একটি হোস্টের সব কনটেইনার একই কার্নেলের সঙ্গে কথা বলে। একটি কনটেইনারের ভেতর থেকে নাগাল পাওয়া যায় এমন কার্নেল বাগ সবগুলো থেকে বেরোনোর পথ।
ভার্চুয়াল মেশিন নিজের কার্নেল নিয়ে আসে। হোস্টের CPU হার্ডওয়্যার ভার্চুয়ালাইজেশনের (Linux-এ KVM) মাধ্যমে গেস্টকে এমনভাবে চালায় যেন তার নিজের কম্পিউটার আছে। সীমানা হলো হাইপারভাইজার, যা কার্নেলের শত শত system call-এর চেয়ে অনেক কম জিনিস উন্মুক্ত করে। এর মূল্য হলো ভারীপনা। একটি প্রচলিত VM পুরো একটি PC এমুলেট করে: ফার্মওয়্যার, PCI বাস, USB কন্ট্রোলার, গ্রাফিক্স কার্ড, কখনো সাউন্ড কার্ডও। এই সবকিছুর মধ্য দিয়ে বুট হতে সেকেন্ড থেকে মিনিট লাগে, আর প্রতিটি ইনস্ট্যান্স দশ বা শত মেগাবাইট ওভারহেড বয়ে বেড়ায়।
একটি তুলনা যা মোটামুটি ভালোই খাটে: কনটেইনার হলো একই ভবনের ফ্ল্যাট, যাদের ভিত, পাইপ আর তার ভাগ করা। VM হলো আলাদা আলাদা বাড়ি। বাড়িগুলো বেশি নিরাপদ প্রতিবেশী, কিন্তু ২০ সেকেন্ডের সাক্ষাতের জন্য কেউ বাড়ি বানায় না।
Firecracker কী বাদ দেয়
Firecracker একটি virtual machine monitor (যে প্রোগ্রাম KVM-এর ওপর VM সাজায় ও চালায়), Rust-এ লেখা এবং ২০১৮ সালে ওপেন সোর্স করা। এটি একটি কাজের জন্যই তৈরি: ভাগ করা হার্ডওয়্যারে বিপুল সংখ্যক স্বল্পায়ু, পরস্পরের প্রতি অবিশ্বাসী ওয়ার্কলোড চালানো। সেখানে পৌঁছাতে এটি মূলত জিনিসপত্র মুছে ফেলে:
- ফার্মওয়্যার নেই, হার্ডওয়্যার খোঁজা নেই। কার্নেল সরাসরি মেমরিতে লোড হয়ে চালু হয়। যে ডিভাইস নেই, তা কেউ খুঁজে বেড়ায় না।
- ছোট্ট ডিভাইস মডেল। একটি নেটওয়ার্ক কার্ড, একটি ব্লক ডিভাইস, একটি সিরিয়াল কনসোল এবং আরও কয়েকটি, সবই virtio (ভৌত ডিভাইসের অনুকরণ নয়, ভার্চুয়াল মেশিনের জন্য নকশা করা ডিভাইস)। USB নেই, গ্রাফিক্স নেই, PCI নেই।
- ছোট, মেমরি-নিরাপদ কোডবেস। ডিভাইস এমুলেট করা কোড কম মানে এমন বাগের জায়গাও কম, যা গেস্টকে হোস্টে পৌঁছাতে দেয়।
- VMM-এর নিজের চারপাশে একটি খাঁচা। প্রতিটি Firecracker প্রসেস chroot-এর ভেতরে চলে, এর নিজের system call-এ seccomp ফিল্টার আর রিসোর্সে cgroups-এর সীমা থাকে। কিছু যদি গেস্ট থেকে বেরিয়েও আসে, তা হোস্টে নয়, খাঁচায় গিয়ে পড়বে।
প্রকল্পের নিজের প্রকাশিত সংখ্যা: মাত্র ১২৫ ms-এ user space, আর প্রতি microVM-এ ৫ MiB-এর কম মেমরি ওভারহেড। এগুলো ল্যাবের সেরা সংখ্যা; একটি আসল স্যান্ডবক্সে ডিস্ক আর নেটওয়ার্ক প্রস্তুত করতে হয় এবং ভেতরে কমান্ড নেওয়ার জন্য একটি এজেন্ট তৈরি থাকতে হয়, তাই আমাদেরটা প্রায় এক সেকেন্ডে প্রস্তুত হয়। এটা এখনো কনটেইনারের গতির এতটা কাছাকাছি যে প্রতিটি কাজের জন্য একটি বানিয়ে পরে ফেলে দেওয়া যায়।
বাস্তবে কনটেইনার বনাম microVM
| কনটেইনার | Firecracker microVM | |
|---|---|---|
| কার্নেল | হোস্টের সঙ্গে ভাগ করা | নিজস্ব |
| হোস্টের সঙ্গে সীমানা | ভাগ করা কার্নেলে system call | হাইপারভাইজার + ছোট VMM |
| চালু হওয়ার সময় | মিলিসেকেন্ড | ~০.১–১ সে. |
| প্রতি ইনস্ট্যান্সে ওভারহেড | খুব কম | কয়েক MiB |
| ডিভাইস | হোস্ট যা উন্মুক্ত করে | নেটওয়ার্ক, ডিস্ক, কনসোল |
| GPU | সম্ভব | না |
| যার জন্য ভালো | বিশ্বস্ত কোড, অ্যাপ প্যাকেজিং | অবিশ্বস্ত কোড, মাল্টি-টেন্যান্ট ওয়ার্কলোড |
গুরুত্বপূর্ণ সারিটি হলো দ্বিতীয়টি। কনটেইনারে “এই কোড কি বেরিয়ে যেতে পারে?” প্রশ্নটি হয়ে যায় “হোস্টের কার্নেলের কোথাও কি নাগালের মধ্যে কোনো বাগ আছে?”। microVM-এ এটি হয়ে যায় “হাইপারভাইজার বা হাতে গোনা কয়েকটি ভার্চুয়াল ডিভাইসে কি কোনো বাগ আছে?”। দ্বিতীয় পৃষ্ঠতলটি অনেক ছোট, আর ক্লাউড প্ল্যাটফর্মগুলো তাদের নিজেদের মাল্টি-টেন্যান্ট হোস্টিংয়ের জন্য ঠিক এটিই ইতিমধ্যে রক্ষা করে।
আপনি কী ছেড়ে দেন
microVM কোনো বিনামূল্যের আপগ্রেড নয়।
- GPU নেই, ডিসপ্লে নেই। এটি কোড চালানোর জন্য, ডেস্কটপ বা গ্রাফিক্স ওয়ার্কলোডের জন্য নয়।
- কম ডিভাইস, কম নমনীয়তা। যা কিছু আসল হার্ডওয়্যার বা কার্নেল মডিউলের লম্বা তালিকা আশা করে, তা এখানে স্বস্তি পাবে না।
- সীমানার জন্য এখনো নীতি দরকার। খোলা egress-সহ microVM এখনো এমন ট্র্যাফিক পাঠাতে পারে যা আপনি চান না; ভেতরে আপনার API key থাকলে সেটি এখনো ফাঁস করতে পারে। আইসোলেশন গেস্ট থেকে হোস্টকে রক্ষা করে, যে কোডের হাতে আপনি গোপন তথ্য তুলে দিয়েছেন তার থেকে সেগুলোকে নয়।
আমাদের স্যান্ডবক্স এটি কীভাবে ব্যবহার করে
প্রতিটি EQVPS স্যান্ডবক্স নিজস্ব কার্নেলসহ একটি Firecracker microVM, 0.25 vCPU ও 512 MB থেকে 8 vCPU ও 16 GB পর্যন্ত। এতে Python 3.12, Node.js 22, bash, git আর curl থাকে, আউটবাউন্ড ইন্টারনেট আছে এবং কোনো ইনবাউন্ড পোর্ট নেই। অস্থায়ী স্যান্ডবক্স কাজ শেষে মুছে ফেলা হয়; persistent স্যান্ডবক্স তাদের ডিস্ক রাখে, আর pause করলে microVM-এর একটি স্ন্যাপশট ডিস্কে লেখা হয়, তাই আবার চালু হওয়া পর্যন্ত কোনো খরচ হয় না। থেমে থাকা স্ন্যাপশট ১৪ দিন রাখা হয়। তারপর স্যান্ডবক্স মুছে যায় আর তার id 410 sandbox_deleted ফেরত দেয়।
আমরা কনটেইনারের বদলে microVM বেছে নিয়েছি একটিই কারণে: স্যান্ডবক্সে যে কোড চলে, নকশা অনুযায়ীই তা এমন কোড যা কেউ রিভিউ করেনি। একটি AI এজেন্টের আউটপুট, অপরিচিত কারও pull request, মডেলের লেখা হাজারটি প্রোগ্রামের একটি বেঞ্চমার্ক। এগুলোর জন্য নিজস্ব কার্নেলই সেই সীমানা যার জন্য টাকা দেওয়া সার্থক। এর চারপাশে আমরা যা রেখেছি তার বিস্তারিত — ট্যারিফ, কোটা, সিঙ্ক্রোনাস কমান্ডের ৫৫ সেকেন্ডের সীমা — আছে স্যান্ডবক্স ডকুমেন্টেশন-এ।
এই সীমানাকে অন্য বিকল্পগুলোর সঙ্গে আরও গভীরভাবে তুলনা করতে চাইলে অবিশ্বস্ত কোডের জন্য আইসোলেশনের স্তর প্রসেস, কনটেইনার, microVM আর পূর্ণ VM পাশাপাশি রাখে। আর প্রতি-সেকেন্ডের দামই যদি আপনার নজর কেড়ে থাকে, প্রতি-সেকেন্ড বিলিং আসলে কীভাবে কাজ করে পুরো হিসাব দেখায়।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।