چطور Vercel زمان انتظار بیلد رو از ۹۰ ثانیه به ۵ رساند
خلاصهٔ کاملتر
Vercel یه پلتفرم دیپلوی وباپلیکیشنه. هروقت یه توسعهدهنده کد پوش میکنه، Vercel اون رو میگیره، روی سرورهای خودش بیلد میکنه و نتیجه رو روی یه شبکه توزیعشده جهانی (CDN لبه) دیپلوی میکنه. مشکل اینه که هزاران مشتری اسکریپتهای بیلد خودشون رو روی ماشینهای مشترک Vercel اجرا میکنن — و Vercel نمیتونه از نیت هیچکدومشون مطمئن باشه.
مشکل اصلی: multi-tenancy خصمانه. کانتینرهای معمولی (مثل Docker) برای ایزولهسازی در برابر کدهای مخرب کافی نیستن، چون همه کانتینرها روی یه کرنل لینوکس مشترک اجرا میشن. اگه یه اکسپلویت کرنل وجود داشته باشه، یه مهاجم میتونه از کانتینر خودش خارج بشه و به بیلدهای بقیه دسترسی پیدا کنه. ابزارهایی مثل Kubernetes هم برای تنانتهای همکار طراحی شدن، نه تنانتهای خصمانه.
راهحل سنتی ماشین مجازی (VM) بود، ولی VMهای کلاسیک ۳۰ تا ۶۰ ثانیه برای بوت نیاز دارن و حافظه زیادی میخورن. اینجا بود که Firecracker وارد ماجرا شد — یه ابزار متنباز از AWS که اولین بار برای Lambda ساخته شد. Firecracker یه microVM سبکوزن میسازه که در حدود ۱۲۵ میلیثانیه بوت میشه، فقط چند مگابایت RAM مصرف میکنه، و ایزولهسازی واقعی در سطح کرنل داره. این یه نقطه جدید در فضای تریدآف بین امنیت و سرعته.
Vercel این microVMها رو پایه معماری داخلیش به اسم Hive قرار داد. ساختار Hive از چند لایه تشکیل شده:
- Hive: یه کلاستر منطقهای (چند تا Hive در یه region ممکنه)
- Box: یه ماشین فیزیکی داخل Hive
- Cell: یه microVM روی Box که دقیقاً یه بیلد رو اجرا میکنه
- Control Plane: مغز متفکر کلاستر
هر Cell یه کانتینر داخلش داره که بیلد واقعی رو اجرا میکنه. کانتینر وظیفه بستهبندی ابزارهاست، microVM وظیفه ایزولهسازی. بعد از اتمام هر بیلد هم Cell بلافاصله نابود میشه — حتی اگه قابل استفاده مجدد بود. این یه تصمیم امنیتی عمدیه تا هیچ دادهای از بیلد یه مشتری به بیلد بعدی نشت نکنه.
بهبود ۱۸ برابری از سه لایه بهینهسازی روی این پایه به دست اومد:
اول، بوت سریعتر: ایمیج کانتینر بیلد به صورت لوکال کش میشه (نه دانلود از registry) و از block device snapshotting استفاده میشه — یعنی یه snapshot از حالت آماده Cell ذخیره میشه و Cellهای جدید از روی همون شروع میکنن. این دو تغییر حدود ۴۵ ثانیه از زمان استارت کم کردن.
دوم و مهمترین، warm pool: Vercel یه مخزن از Cellهایی نگه میداره که از قبل بوت شدن و آمادهان. وقتی بیلدی میاد، یه Cell آماده بهش تحویل داده میشه و بیلد بلافاصله شروع میشه. ۵ ثانیه پروویژن فقط برای موقعیه که warm pool خالی باشه.
سوم، سرعت پایه Firecracker: بدون بوت ۱۲۵ میلیثانیهای Firecracker، نگهداشتن warm pool در مقیاس عملاً ممکن نبود. این پایهست که بقیه بهینهسازیها روش میتونن بایستن.
نتیجه کلی: ۳۰٪ بهبود در عملکرد کلی بیلدها و ۴۰٪ کاهش زمان در مسیر سرد (cold path). البته warm pool هزینه داره — Vercel برای Cellهایی که کار مفیدی انجام نمیدن پول میده، و تنظیم اندازه pool یه چالش عملیاتی مداومه. ولی کنترل کامل روی زیرساخت، امکان ارائه ویژگیهایی مثل ماشینهای بیلد تقویتشده و Secure Compute برای مشتریان Enterprise رو هم فراهم کرد.
نکات کلیدی:
- مدل تهدید باید معماری رو تعیین کنه، نه برعکس
- Firecracker یه نقطه طلایی بین امنیت VM و سرعت کانتینره: بوت ۱۲۵ms با ایزولهسازی کرنل واقعی
- بیشتر بهبود سرعت از warm pool میاد، نه از سریعتر شدن cold path
- Cell بعد از هر بیلد نابود میشه — یه تصمیم امنیتی عمدی برای جلوگیری از نشت داده
- ساختن زیرساخت از صفر هزینه مهندسی بالایی داره ولی انعطاف محصولی بیشتری میده
