اگر دربارهٔ اجرای امن کدی که هوش مصنوعی تولید کرده چیزی خوانده باشید، واژهٔ microVM را دیده‌اید، معمولاً کنار Firecracker. معمولاً یا به‌عنوان «ماشین مجازی سبک» توضیح داده میشود (درست، ولی بی‌فایده) یا با نموداری از درونیات هسته. این نسخهٔ میانه است.
دو گزینهٔ قدیمی‌تر، و چرا هیچ‌کدام مناسب نیست
از دو چیزی شروع کنید که microVM بینشان قرار می‌گیرد.
کانتینر گروهی از فرایندهای معمولی روی ماشین شماست که هسته پذیرفته به آن‌ها «دروغ بگوید». namespaces به آن‌ها فایل‌سیستم، فهرست فرایندها و شبکهٔ مخصوص خودشان را نشان می‌دهند؛ cgroups مقدار CPU و حافظه‌ای را که می‌توانند مصرف کنند محدود میکند. در چند میلی‌ثانیه راه میافتد چون هیچ چیز تازه‌ای بوت نمی‌شود. اما همهٔ کانتینرهای یک میزبان با یک هستهٔ واحد حرف می‌زنند. باگی در هسته که از داخل یک کانتینر در دسترس باشد، راه خروج از همهٔ آن‌هاست.
ماشین مجازی هستهٔ خودش را می‌آورد. CPU میزبان از طریق مجازی‌سازی سخت‌افزاری (KVM در Linux) مهمان را طوری اجرا میکند که انگار رایانهٔ خودش را دارد. مرز، هایپروایزر است که بسیار کمتر از صدها فراخوانی سیستمی هسته را در معرض قرار میدهد. بهای آن، سنگینی است. یک ماشین مجازی کلاسیک کل یک PC را شبیهسازی میکند: فرم‌ور، گذرگاه PCI، کنترلرهای USB، کارت گرافیک و گاهی کارت صدا. از میان همهٔ این‌ها بوت میشود، از چند ثانیه تا چند دقیقه طول می‌کشد، و هر نمونه ده‌ها یا صدها مگابایت سربار با خود دارد.
تشبیهی که نسبتاً خوب جواب میدهد: کانتینرها آپارتمان‌های یک ساختمان‌اند که پی، لوله‌کشی و سیم‌کشی مشترک دارند. ماشین‌های مجازی خانه‌های جدا هستند. خانه‌ها همسایه‌های امن‌تری‌اند، اما هیچ‌کس برای دیداری ۲۰ ثانیه‌ای خانه نمی‌سازد.
چه چیزهایی را Firecracker حذف میکند
Firecracker یک virtual machine monitor است (برنامه‌ای که ماشین مجازی را روی KVM آماده و اجرا میکند)، به زبان Rust نوشته شده و از سال ۲۰۱۸ متن‌باز است. برای یک کار ساخته شد: اجرای شمار عظیمی از بارهای کاری کوتاه‌عمر و بی‌اعتماد به یکدیگر روی سختافزار مشترک. بیشتر با حذف کردن چیزها به این هدف می‌رسد:
- نه فرم‌ور، نه شناسایی سختافزار. هسته مستقیم در حافظه بارگذاری و اجرا میشود. هیچ‌چیز دنبال دستگاه‌هایی که وجود ندارند نمی‌گردد.
- مدل دستگاه بسیار کوچک. یک کارت شبکه، یک دستگاه بلوکی، یک کنسول سریال و چند مورد دیگر، همه از نوع virtio (دستگاه‌هایی که برای ماشین‌های مجازی طراحی شدهاند، نه تقلید دستگاه‌های فیزیکی). نه USB، نه گرافیک، نه PCI.
- کدپایهٔ کوچک و ایمن از نظر حافظه. کد کمتر برای شبیهسازی دستگاهها یعنی جای کمتر برای باگی که به مهمان اجازه دهد به میزبان برسد.
- قفسی دور خودِ VMM. هر فرایند Firecracker داخل یک chroot اجرا میشود، با فیلترهای seccomp روی فراخوانیهای سیستمی خودش و cgroups روی منابعش. اگر چیزی هم از مهمان فرار کند، در قفس میافتد، نه روی میزبان.
اعدادی که خود پروژه منتشر کرده: رسیدن به فضای کاربر در تنها ۱۲۵ میلی‌ثانیه و سربار حافظهٔ کمتر از ۵ MiB برای هر microVM. این‌ها بهترین اعداد آزمایشگاهی‌اند؛ یک سندباکس واقعی به آماده‌سازی دیسک و شبکه و عاملی در داخل که آمادهٔ دریافت دستور باشد هم نیاز دارد، به همین دلیل سندباکس ما در حدود یک ثانیه آماده میشود. این هنوز آن‌قدر به سرعت کانتینر نزدیک است که بتوانید برای هر کار یکی بسازید و بعد دورش بیندازید.
کانتینر در برابر microVM، در عمل
| کانتینر | Firecracker microVM | |
|---|---|---|
| هسته | مشترک با میزبان | مستقل |
| مرز با میزبان | فراخوانی سیستمی به هستهٔ مشترک | هایپروایزر + VMM کوچک |
| زمان راهاندازی | میلی‌ثانیه | ~0.1–1 ث |
| سربار هر نمونه | بسیار کم | چند MiB |
| دستگاهها | هرچه میزبان در معرض بگذارد | شبکه، دیسک، کنسول |
| GPU | ممکن | خیر |
| مناسب برای | کد مورد اعتماد، بسته‌بندی برنامه‌ها | کد نامطمئن، بارهای کاری چندمستأجری |
ردیفی که اهمیت دارد، ردیف دوم است. با کانتینر، پرسش «آیا این کد میتواند فرار کند؟» تبدیل میشود به «آیا جایی در هستهٔ میزبان باگی در دسترس هست؟». با microVM تبدیل میشود به «آیا در هایپروایزر یا چند دستگاه مجازی انگشتشمار باگی هست؟». سطح دوم بسیار کوچکتر است، و همان سطحی است که پلتفرم‌های ابری همین حالا برای میزبانی چندمستأجری خودشان از آن دفاع می‌کنند.
از چه چیزی می‌گذرید
یک microVM ارتقای رایگان نیست.
- نه GPU، نه نمایشگر. برای اجرای کد است، نه برای دسکتاپ یا بارهای کاری گرافیکی.
- دستگاه کمتر، انعطاف کمتر. هر چیزی که سختافزار واقعی یا فهرست بلندی از ماژول‌های هسته انتظار دارد، این‌جا راحت نخواهد بود.
- مرزها همچنان به سیاست نیاز دارند. microVM با خروجی باز همچنان میتواند ترافیکی بفرستد که نمی‌خواهید؛ اگر کلیدهای API شما داخلش باشد، همچنان میتواند آن‌ها را نشت دهد. جداسازی میزبان را از مهمان محافظت میکند، نه رازهای شما را از کدی که آن‌ها را به دستش داده‌اید.
سندباکسهای ما چطور از آن استفاده می‌کنند
هر سندباکس EQVPS یک Firecracker microVM با هستهٔ مستقل است، از 0.25 vCPU و 512 MB تا 8 vCPU و 16 GB. با Python 3.12، Node.js 22، bash، git و curl می‌آید، اینترنت خروجی دارد و هیچ پورت ورودی ندارد. سندباکسهای موقت پس از پایان کار حذف می‌شوند؛ سندباکسهای persistent دیسک خود را نگه می‌دارند، و توقف موقت (pause) یک اسنپ‌شات از microVM روی دیسک می‌نویسد تا تا زمان ادامه هیچ هزینه‌ای نداشته باشد. اسنپ‌شات‌های متوقف ۱۴ روز نگه داشته می‌شوند. پس از آن سندباکس حذف میشود و شناسه‌اش 410 sandbox_deleted برمی‌گرداند.
ما به یک دلیل microVM را به کانتینر ترجیح دادیم: کدی که در سندباکس اجرا میشود، ذاتاً کدی است که هیچ‌کس بازبینی‌اش نکرده. خروجی یک عامل هوش مصنوعی، pull request یک غریبه، بنچمارکی از هزار برنامهٔ نوشته‌شده توسط مدل. برای این‌ها، هستهٔ مستقل همان مرزی است که ارزش پرداخت دارد. جزئیات آنچه دور آن گذاشته‌ایم — تعرفه‌ها، سهمیه‌ها، محدودیت ۵۵ ثانیه‌ای دستورهای همگام — در مستندات سندباکس‌ها آمده است.
اگر می‌خواهید این مرز را با گزینه‌های دیگر عمیق‌تر مقایسه کنید، سطوح جداسازی برای کد نامطمئن فرایندها، کانتینرها، microVM و ماشین‌های مجازی کامل را کنار هم می‌گذارد. و اگر قیمت ثانیه‌ای توجهتان را جلب کرده، صورت‌حساب ثانیه‌ای واقعاً چطور کار میکند محاسبات را نشان میدهد.
نظرات
هنوز نظری نیست. اولین نفر باشید.