۶ میلی‌ثانیه؛ این است زمان جدیدی که یک کاربر برای دریافت پاسخ از توابع لبه (Edge Functions) نتلیفای منتظر می‌ماند. این زمان از ۴۰ میلی‌ثانیه به ۶ میلی‌ثانیه کاهش یافته است. این افزایش سرعت ۵ برابری، نتیجه بازسازی کامل زیرساخت است که در آن V8 isolates با MicroVMهای Firecracker جایگزین شده‌اند؛ جزئیاتی که در گزارش مهندسی ۳۰ سپتامبر ۲۰۲۶ منتشر شد.
برای توسعه‌دهندگانی که می‌خواهند صفحات شخصی‌سازی‌شده یا سیستم‌های مسیریابی سریع بسازند، این یعنی زمان انتظار کاربر اکنون تقریباً ناچیز است. این تحول در حالی رخ می‌دهد که صنعت به سمت محاسبات پیچیده‌تر در لبه حرکت می‌کند و دیگر به ریدایرکت‌های ساده بسنده نمی‌کند و به دنبال اجرای منطقهای کامل اپلیکیشن در لبه است. همان‌طور که در تحلیل قبلی ما درباره‌ی استفاده از توابع لبه برای مقیاس‌دهی به عامل‌های صوتی هوش مصنوعی از طریق Supabase اشاره کردیم، حرکت نتلیفای نشان‌دهنده ترندی گسترده‌تر است که لبه را نه به عنوان یک اجراکننده اسکریپت‌های سبک، بلکه به عنوان یک لایه محاسباتی قدرتمند و مستحکم می‌بیند. این رویکرد یادآور تلاش‌های مشابه در سایر پلتفرم‌ها برای کاهش تأخیر است، مشابه آنچه در بهینه‌سازی عملکرد مدل‌های آنتروپیک با متدولوژی Hill Climbing مشاهده کردیم.
تصور کنید رایانش لبه (Edge Computing) — به جای یک استخر حافظه مشترک — شبیه داشتن ناوگانی از کامپیوترهای کوچک و مستقل باشد که در کسری از ثانیه بوت می‌شوند. این هسته اصلی معماری جدید است.
ابعاد چالش
نتلیفای در حال حاضر روزانه حدود یک میلیارد تابع لبه را پردازش می‌کند. تنوع کاربردها در این مقیاس بسیار زیاد است: برای مثال، شرکت Sunweb از این توابع برای شخصی‌سازی صفحات وب استفاده می‌کند، در حالی که Loto-Québec از آن‌ها برای مسیریابی ترافیک بر اساس بررسی کوکی‌ها بهره می‌برد. صدها هزار سایت دیگر نیز از این پلتفرم برای هر چیزی، از احراز هویت گرفته تا مسیریابی‌های پیچیده، استفاده می‌کنند.
برای مدیریت این حجم عظیم، نتلیفای باید هر درخواست را پردازش کرده، آن را مسیریابی کند، ظرفیت محاسباتی اختصاص دهد و هم کد پلتفرم و هم کد مشتری را در عرض چند میلی‌ثانیه بوت کند. پیش از این، درخواست‌ها برای اجرا از شبکه نتلیفای خارج شده و به یک سرویس اجرای میزبانی‌شده (Hosted Execution Service) می‌رفتند. اما اکنون، این درخواست‌ها روی MicroVMها در داخل شبکه لبه خود نتلیفای اجرا می‌شوند که سربار عملکرد را به‌شدت کاهش می‌دهد.
جهش در کاهش تأخیر
طبق گزارش فنی نتلیفای، بهبودهای عملکردی در انواع مختلف فراخوانی‌ها بسیار چشمگیر و ملموس است:
- فراخوانی‌های گرم (Warm Invocations): تأخیر میانه (p50) اکنون حدود ۵ تا ۶ میلی‌ثانیه است، در حالی که در زیرساخت قبلی این رقم بین ۲۵ تا ۴۰ میلی‌ثانیه بود. این زمان شامل تمام مراحل مسیریابی به گره محاسباتی، ورود به MicroVM، اجرای تابع و تولید هدرهای پاسخ است.
- فراخوانی‌های p99: سرعت این درخواست‌ها ۴۷.۴٪ نسبت به قبل افزایش یافته است.
- راه‌اندازی سرد (Cold Start): این حالت در حدود ۱.۲٪ از موارد رخ می‌دهد. فراخوانی‌های سرد اکنون به طور میانگین ۹ میلی‌ثانیه زمان می‌برند. این اتفاق زمانی می‌افتد که درخواستی به منطقهای می‌رسد که هیچ گره محاسباتی در آنجا پیش از این با آن تابع مواجه نشده است و سیستم باید ابتدا تصاویر (Images) مربوطه را واکشی کند.
- پایداری: سیستم توانسته است نرخ در دسترس بودن ۹۹.۹۹۸٪ را حفظ کند.
- گزارش‌دهی: سرعت تحویل لاگ‌های توابع لبه اکنون ۵ برابر سریع‌تر شده است.
مسیر حرکت درخواست
وقتی درخواستی به شبکه می‌رسد، ابتدا روی نزدیک‌ترین گره لبه نتلیفای می‌نشیند. این گره اتصال TLS را خاتمه می‌دهد (Terminate می‌کند) و بررسی می‌کند آیا درخواست با مسیر یک تابع لبه برای آن استقرار (Deploy) خاص مطابقت دارد یا خیر. اگر هیچ تطابقی پیدا نشود، درخواست طبق روال معمول به حافظه پنهان (Cache) و منبع اصلی (Origin) می‌رود. اما در صورت تطابق، درخواست به یک گره محاسباتی در داخل شبکه داخلی نتلیفای ارجاع داده می‌شود.
مشخصات ماشین
قبل از اینکه درخواست مسیریابی شود، گره لبه یک «مشخصات» (Specification) برای ماشینی که قرار است تابع را اجرا کند می‌نویسد. این مشخصات همراه با هر درخواست جابه‌جا می‌شود و موارد زیر را تعریف می‌کند:
- سه تصویر ضروری: تصویر زمان اجرا (Runtime)، تصویر پلتفرم و تصویر تابع لبه.
- محدودیت منابع: تنظیمات دقیق برای CPU، حافظه و محدودیت‌های اتصال.
سیستم یک هش (Hash) از این مشخصات و اطلاعات خاص هر سایت محاسبه می‌کند تا یک شناسه سرویس (Service ID) منحصربه‌فرد ایجاد کند. این سازوکار تضمین می‌کند که دو استقرار با کدهای متفاوت یا متغیرهای محیطی متفاوت، به عنوان دو سرویس مجزا شناخته شوند و هرگز یک MicroVM را به اشتراک نگذارند.
مسیریابی و انتخاب گره محاسباتی
برای تضمین سرعت، گره لبه از روش Rendezvous Hashing برای انتخاب گره محاسباتی استفاده می‌کند. این روش تضمین می‌کند که یک سرویس خاص به‌طور مداوم روی یک گره یکسان قرار بگیرد؛ این کار باعث می‌شود MicroVM «گرم» بماند و کدها روی دیسک کش شوند.
با این حال، این «چسبندگی» (Stickiness) می‌تواند باعث ایجاد «نقاط داغ» (Hot Spots) شود؛ وضعیتی که در آن یک تابع بسیار پرکار، تمام منابع یک گره را اشغال می‌کند. برای جلوگیری از این مشکل، نتلیفای در ترافیک‌های بسیار بالا، سخت‌گیری در اتصال به یک گره را کاهش می‌دهد و سرویس را در میان مجموعه‌ای از گره‌ها پخش می‌کند تا جهش‌های ناگهانی ترافیک را بدون تأثیر بر سایر مشتریان جذب کند. این مدیریت بهینه ترافیک و توزیع بار، شباهت زیادی به استراتژی Tailscale در بازنگری ساختار صف‌ها برای بهبود توان عملیاتی دارد.
سازوکار MicroVM
هر تابع اکنون در یک Firecracker MicroVM اجرا می‌شود که با همکاری Unikraft توسعه یافته است. این ماشین‌های مجازی به دلیل استفاده از یک محیط لینوکس بسیار سبک و حذف‌شده (Stripped-down) به جای یک سیستم‌عامل کامل، در کمتر از یک میلی‌ثانیه بوت شده و در حدود ۲ میلی‌ثانیه (p99) شروع به کار می‌کنند.
برای بهینه‌سازی بیشتر، نتلیفای از یک استراتژی تخصصی بارگذاری و عکس‌برداری (Snapshotting) استفاده می‌کند:
- بارگذاری بهینه: فایل‌های تابع به صورت تصاویر EROFS فشرده‌نشده مونت شده و Memory-mapped می‌شوند. این قابلیت به VM اجازه می‌دهد به جای بارگذاری کل بسته، فقط بخش‌های خاصی از باندل را که به آن‌ها نیاز دارد بخواند.
- عکس‌برداری (Snapshotting): پس از بوت شدن VM و شروع به گوش دادن سرور جاوااسکریپت روی یک پورت، نتلیفای یک Snapshot از وضعیت MicroVM می‌گیرد.
- مقیاس‌دهی به صفر: وقتی تابعی در حال استفاده نیست، MicroVMها برای ذخیره منابع به صفر می‌رسند.
- بازیابی سریع: در درخواست بعدی، یک MicroVM جدید مستقیماً از روی Snapshot حافظه-نگاشته (Memory-mapped) شروع به کار می‌کند و بلافاصله اجرا می‌شود، بدون اینکه منتظر خواندن کامل Snapshot در حافظه بماند.
مدیریت سرویس و مقیاس‌پذیری
یک «سرویس» اجازه می‌دهد چندین MicroVM به توابع یک سایت متصل شوند. نتلیفای این سرویس‌ها را بر اساس پارامترهای خاص مقیاس می‌دهد:
- محدودیت درخواست: هر MicroVM پس از پردازش تعداد مشخصی درخواست خاموش می‌شود تا از اجرای نامحدود و احتمالی نشت منابع جلوگیری شود.
- بوت پیش‌دستانه (Eager Booting): سیستم از همان پارامترها استفاده می‌کند تا پیش از خاموش شدن MicroVM فعلی، یک MicroVM جدید را به طور فعال بوت کند.
- واکشی تصاویر: اگر سرویسی روی یک گره محاسباتی وجود نداشته باشد، گره ابتدا دیسک را برای تصاویر مورد نیاز بررسی می‌کند. تصاویر مفقود از گره لبه دریافت می‌شوند؛ این یعنی فقط تصاویری که در آن منطقه ترافیک فعال دارند، به صورت محلی ذخیره می‌شوند.
امنیت و ایزولاسیون
یکی از حیاتی‌ترین تغییرات، فاصله گرفتن از V8 isolates است. اگرچه ایزوله‌ها سریع هستند، اما ایزولاسیون در سطح سخت‌افزار را که یک ماشین مجازی فراهم می‌کند، ندارند. در مدل جدید، اگر یک استقرار هک شود، مهاجم در MicroVM خود زندانی می‌ماند. حتی اگر بتواند از محیط Runtime خارج شود، نمی‌تواند به سایر مشتریان یا لایه محاسباتی زیرین آسیب بزند یا آن‌ها را مسموم کند. نتلیفای صراحتاً اشاره می‌کند که V8 isolates این سطح از ایزولاسیون را فراهم نمی‌کردند.
برای حفظ پایداری در مقیاس بالا، حفاظ‌های عملیاتی متعددی اضافه شده است:
- DNS محلی: گره‌های محاسباتی اکنون Resolverهای DNS محلی اجرا می‌کنند تا از شکست‌های رایج شبکه جلوگیری شود.
- متریک‌های پیشرفته: تیم مهندسی اکنون زمان بوت، زمان باز شدن اولین پورت و زمان شروع اجرای کد کاربر را ثبت می‌کند.
- قطع‌کننده‌ها (Circuit Breakers): چندین قطع‌کننده در جایگاه‌های مختلف تعبیه شده است تا مسیریابی سریع و خارج کردن گره‌های محاسباتی ناسالم از چرخه تضمین شود.
طراحی برای تاب‌آوری
نتلیفای گره‌های محاسباتی را از گره‌های لبه جدا کرده است تا گره‌های لبه سبک بمانند و امکان استفاده از انواع مختلف نمونه‌ها (Instance Types) و مقیاس‌دهی مستقل فراهم شود. یک Control Plane سلامت گره‌های محاسباتی را رصد می‌کند و گره‌های لبه به‌طور منظم وضعیت آن‌ها را چک (Poll) می‌کنند.
برای به‌روزرسانی‌ها، یک ناوگان (Fleet) جدید از ماشین‌ها در کنار ناوگان فعال مستقر می‌شود. ناوگان جدید ابتدا مقیاس می‌گیرد تا با بار فعلی مطابقت یابد و تنها پس از تأیید سلامت، ترافیک را تحویل می‌گیرد. این روش امکان بازگشت سریع (Rollback) را در صورت بروز هرگونه مشکل فراهم می‌کند.
جابه‌جایی سقف قابلیت‌ها
این تغییر معماری محدودیت‌های قدیمی را از بین می‌برد. چون توابع اکنون در یک VM واقعی با یک سیستم‌فایل (Filesystem) واقعی اجرا می‌شوند، پشتیبانی از بسته‌های npm از حالت بتا خارج می‌شود. پیش از این، باینری‌های Native و وارد کردن فایل‌ها در زمان اجرا مشکل‌ساز بودند، اما وجود یک سیستم‌فایل واقعی این موانع را حذف می‌کند.
علاوه بر این، شرکت در حال بازنگری در محدودیت‌های عملیاتی است. سقف‌های قبلی — ۵۰ میلی‌ثانیه CPU برای هر درخواست، ۵۱۲ مگابایت حافظه و ۲۰ مگابایت کد فشرده — محصولات مدل ایزوله بودند و اکنون احتمالاً افزایش می‌یابند.
این انتقال برای کاربر کاملاً شفاف است؛ هیچ مرحله مهاجرتی وجود ندارد، قیمت‌ها تغییر نکرده‌اند و نیازی به بازنویسی اعلان‌های netlify.toml یا تغییر در وارد کردن URLها و گردش‌کارهای توسعه محلی نیست.
برای کل حوزه رایانش لبه، این اتفاق ثابت می‌کند که موازنه بین «امنیت» و «عملکرد» در حال از بین رفتن است. با استفاده از Snapshotهای MicroVM و کرنل‌های لینوکس تخصصی، پلتفرم‌ها می‌توانند امنیت یک ماشین مجازی را با تأخیر یک تابع ارائه دهند.
گام بعدی شما
- اگر توابع لبه شما به دلیل سنگین بودن وابستگی‌های Node.js در V8 isolates ناپایدار بودند، اکنون زمان تست مجدد آن‌هاست.
- منتظر اعلام محدودیت‌های جدید CPU و حافظه باشید؛ این تغییر احتمالاً تعریف «آنچه می‌توان در لبه میزبانی کرد» را عوض می‌کند.
- بررسی کنید آیا می‌توانید منطقهای پیچیده‌تر اپلیکیشن خود را از سرور مرکزی به لبه منتقل کنید تا تجربه کاربر را بهبود ببخشید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو