خبر فوریامروز

معماری مایکروسرویس‌ها با وب‌اسمبلی؛ اجرای سریع‌تر و ارزان‌تر در بستر ابری

پایان حکمرانی کانتینرهای سنگین؛ وب‌اسمبلی با مدل کامپوننت و WASI 0.2 امروزه میکروسرویس‌ها را در کسری از میلی‌ثانیه با امنیت نفوذناپذیر اجرا می‌کند.

معماری مایکروسرویس‌ها با وب‌اسمبلی
معماری مایکروسرویس‌ها با وب‌اسمبلی — عکس: آرشیو ماگ بیت
خلاصه در یک نگاه
  • واکاوی تخصصی و راهبردی استقرار جریان‌ساز مدل کامپوننت وب‌اسمبلی (WebAssembly Component Model) و مشخصه سیستمی WASI 0.2 در معماری‌های کلاد نیتیو دوران کنونی. تحلیل گذار بنیادین صنایع از ایمیج‌های حجیم کانتینری داکر و سربارهای سنگین سیستم‌عامل مهمان به باینری‌های چندزبانه کم‌حجم با زمان بوت کمتر از ۳۰ میکروثانیه. کالبدشکافی زبان تعریف رابط WIT (Wasm Interface Type)، مکانیسم‌های هم‌کنش‌پذیری بی‌دردسر میان زبان‌های Rust، Go، Python و C++ بدون سربار مارشالینگ داده‌ها، برقراری امنیت بومی مطلق از طریق معماری کنترل دسترسی مبتنی بر قابلیت (Capability-Based Security) و مهار حملات زنجیره تأمین نرم‌افزاری در میکروسرویس‌های توزیع‌شده لبه و پلتفرم‌های محاسبات بدون سرور (Serverless).
  • بررسی جامع ابعاد فنی و کاربردی توسط تحریریه ماگ بیت.
  • پیش‌بینی اثرات کوتاه‌مدت و بلندمدت بر اکوسیستم فناوری.

فراتر از مرورگرها؛ چرایی مرگ تدریجی کانتینرهای داکر در پردازش لبه

برای بیش از یک دهه، کانتینرهای لینوکس مبتنی بر اکوسیستم OCI و داکر ستون فقرات توسعه و استقرار میکروسرویس‌های مدرن بوده‌اند. با این وجود، انتقال این پارادایم به عصر پردازش لبه (Edge Computing)، توابع بدون سرور (Serverless Functions) و ایجنت‌های هوش مصنوعی توزیع‌شده، محدودیت‌های ذاتی آن را آشکار کرد. یک ایمیج مینیمال داکر به همراه هسته سیستم‌عامل، کتابخانه‌های C و رانتایم‌ها معمولاً به ده‌ها تا صدها مگابایت حافظه احتیاج دارد و زمان آغاز به کار یا همان Cold Start آن بین ۵۰۰ میلی‌ثانیه تا چند ثانیه به درازا می‌کشد.

در سناریوهایی که میلیون‌ها تراکنش اینترنتی نیازمند پردازش فوری در نودهای مرزی شبکه هستند، چنین سربار حجمی و زمانی یک مانع مهندسی غیرقابل توجیه محسوب می‌شود. از سوی دیگر، همان‌گونه که در بررسی الزامات امنیت حافظه با زبان راست در کرنل لینوکس و الزامات CISA دیدیم، سطح آسیب‌پذیری در کانتینرهایی که دسترسی وسیع به تماس‌های سیستمی لینوکس (Syscalls) دارند، به شدت آسیب‌پذیر باقی مانده است.

پاسخ نهایی دنیای نرم‌افزار امروزه بلوغ کامل مدل کامپوننت وب‌اسمبلی (WebAssembly Component Model) و تثبیت استاندارد WASI 0.2 است؛ بستری فوق‌العاده چابک که فایل‌های باینری اجرایی در حد چند کیلوبایت را با سرعت باورنکردنی زیر ۵۰ میکروثانیه به اجرا درمی‌آورد.

کالبدشکافی معماری WASI 0.2 و زبان تعریف رابط WIT

بزرگ‌ترین جهش Wasm امروزه گذار از ماژول‌های ساده تک‌زبانه به کامپوننت‌های ترکیبی چندزبانه به کمک فرمت تعریف رابط WIT (Wasm Interface Type) است. پیش از این، اتصال یک قطعه کد کامپایل‌شده از زبان Rust به یک ماژول نوشته‌شده با زبان Go یا پایتون نیازمند سریال‌سازی دشوار داده‌ها در حافظه خطی مشترک بود؛ فرآیندی که علاوه بر مصرف حافظه، خطاهای مهلک سرریز بافر را در پی داشت.

با استاندارد WASI 0.2، ماژول‌ها هویت مستقلی به نام «کامپوننت» پیدا کرده‌اند که ورودی‌ها، خروجی‌ها و ساختارهای داده خود (مانند رکوردهای تودرتو، لیست‌ها و انواع داده غنی) را به شکلی شفاف و نوع‌بندی‌شده (Type-Safe) اعلام می‌کنند. موتور رانتایم (مانند Wasmtime 24 یا Wasmer) وظیفه برقراری ارتباط بدون درز میان این کامپوننت‌ها را بدون کپی داده‌ها و بدون نیاز به فرآیندهای سنتی Inter-Process Communication (IPC) به انجام می‌رساند.

این انعطاف‌پذیری خارق‌العاده به تیم‌های نرم‌افزاری اجازه می‌دهد هسته الگوریتمی سنگین خود را در زبان Rust بنویسند، لایه بیزینس را با TypeScript مدیریت کنند و این دو بخش را در قالب یک کامپوننت وب‌اسمبلی واحد و یکپارچه در لبه بدون هیچ‌گونه افت راندمان اجرا نمایند.

شماتیک مدل کامپوننت وب‌اسمبلی و جداسازی سندباکس بر پایه قابلیت‌های WASI 0.2
معماری ارتباطی باینری‌های مستقل در وب‌اسمبلی؛ فراخوانی چندزبانه توابع میان ماژول‌های Rust و Go از طریق رابط‌های تایپ‌شده WIT بدون بارگذاری هسته لینوکس

امنیت مبتنی بر قابلیت (Capability-Based Security)؛ پایان آسیب‌پذیری‌های زنجیره تأمین

تفاوت بنیادین Wasm با مدل‌های امنیتی قدیمی یونیکس در مدل امنیتی مبتنی بر قابلیت (Capability-Based Security) نهفته است. در یک کانتینر یا پردازش مرسوم لینوکس، یک برنامه به طور پیش‌فرض به تمام دایرکتوری‌ها، ساعت سیستم و سوکت‌های شبکه دسترسی دارد، مگر آنکه صراحتاً با سیاست‌های پیچیده AppArmor یا cgroups مسدود شود؛ موضوعی که در صورت نفوذ یک کتابخانه مخرب شخص ثالث، کل سرور را به خطر می‌اندازد.

در WASI 0.2، یک کامپوننت وب‌اسمبلی در یک خلأ مطلق ریاضی آغاز به کار می‌کند؛ این برنامه نه به فایل‌های دیسک دسترسی دارد، نه آدرس IP شبکه را می‌بیند و نه حتی ساعت سیستم را می‌خواند. میزبان (Host) موظف است دقیقاً و با نام، فقط همان توانمندی مشخص (مانند دسترسی فقط-خواندنی به یک شاخه معین یا ارسال درخواست HTTP به یک دامنه خاص) را در زمان بارگذاری به ماژول اعطا کند.

این ساختار نفوذناپذیر، مکمل بی‌نظیری برای استانداردهای مدرن سازمانی نظیر استانداردهای نوین Passkeys 2.0 و FIDO2 امروزه پدید آورده و حملات خطرناک زنجیره تأمین نرم‌افزاری (Software Supply Chain Attacks) را از ریشه عقیم می‌سازد.

تأثیر اقتصادی و زیست‌محیطی؛ جهش ده‌برابری تراکم پردازش در سرورلس دوران کنونی

پیامدهای اقتصادی استقرار کامپوننت مدل Wasm در دیتاسنترها حیرت‌انگیز است. از آنجایی که هر کامپوننت به تنهایی نیازی به هسته مجازی‌سازی‌شده لینوکس ندارد، یک سرور واحد می‌تواند به جای میزبانی از چندصد کانتینر، هم‌زمان بیش از ۵۰ هزار سندباکس وب‌اسمبلی مستقل را در حافظه رم خود فعال نگه دارد.

این تراکم خارق‌العاده، هزینه‌های زیرساخت ابری شرکت‌ها را در پلتفرم‌های محاسبات بدون سرور تا ۸۰ درصد کاهش داده و بازدهی پردازش‌های خط لوله داده را هم‌گام با معماری داده‌های مدرن Zero-ETL و آپاچی آیسبرگ ارتقا بخشیده است. با تلفیق این توانایی‌های نرم‌افزاری با سخت‌افزارهای کم‌مصرف جدید از جمله شتاب‌دهنده‌های هوش مصنوعی نورومورفیک فوتونیک، دوران کنونی رسماً سال افول کانتینرهای سنتی و طلوع پردازش نوین ایزوله بر بستر Wasm نام گرفته است.

این مطلب را با دوستانتان به اشتراک بگذارید
ف
نوشته‌ی
فائزه راهب

روزنامه‌نگار حوزه‌ی فناوری؛ علاقه‌مند به روایت آدم‌ها و تغییراتی که فناوری در زندگی روزمره ایجاد می‌کند.

همه‌ی مطالب
مطالب پیشنهادی ماگ بیت

بیشتر از فناوری

مشاهده همه