تاوان استارت سرد: چگونه «تابع به عنوان سرویس» تأخیر را فدای هزینه و سادگی عملیاتی می‌کند

پلتفرم‌های «تابع به عنوان سرویس» (FaaS) با از بین بردن محیط‌های اجرایی بیکار برای صرفه‌جویی در منابع، تأخیر را فدای هزینه و سادگی عملیاتی می‌کنند و درخواست‌های بعدی را مجبور می‌کنند تا زمان مقداردهی اولیه یک کانتینر جدید از صفر، منتظر بمانند.

این تأخیر که به عنوان «استارت سرد» (cold start) شناخته می‌شود، مصالحه بنیادین در قلب پردازش بدون سرور (serverless) است. توسعه‌دهندگان کنترل زیرساخت‌های پایه را واگذار می‌کنند و در ازای آن مقیاس‌پذیری خودکار و صورت‌حساب‌های دقیق به دست می‌آورند، اما می‌پذیرند که برنامه آن‌ها گاهی اوقات پیش از پاسخگویی به کاربر، برای بازسازی خود متوقف شود.[1][4]

پارادایم بدون سرور که با راه‌اندازی AWS Lambda در سال ۲۰۱۴ به محبوبیت رسید، به عنوان پایان مدیریت زیرساخت بازاریابی شد. وعده آن‌ها سرراست بود: کد را بنویسید، آن را آپلود کنید و ارائه‌دهنده ابری بقیه کارها را انجام می‌دهد. اما این انتزاع، یک واقعیت مکانیکی پیچیده را پنهان می‌کند.

هنگامی که یک تابع فراخوانی می‌شود، ارائه‌دهنده باید منابع پردازشی را تخصیص دهد، بسته استقرار را دانلود کند، محیط زمان اجرا (runtime) را مقداردهی اولیه کرده و هرگونه منطق راه‌اندازی را اجرا کند. اگر تابع اخیراً فراخوانی شده باشد، محیط «گرم» نگه داشته می‌شود و در چند میلی‌ثانیه پاسخ می‌دهد. اما اگر بیکار بوده باشد، ارائه‌دهنده منابع را پس می‌گیرد و فراخوانی بعدی باعث یک استارت سرد می‌شود.[3][5]

بزرگی این تاوان به شدت به محیط زمان اجرا و پیچیدگی برنامه بستگی دارد. محیط‌های سبک مانند Node.js یا Python اغلب می‌توانند در ۱۰۰ تا ۲۰۰ میلی‌ثانیه مقداردهی اولیه شوند.

با این حال، همان‌طور که محققان خاطرنشان می‌کنند، «تاوان استارت سرد از ده‌ها میلی‌ثانیه برای زمان‌اجراهای سبک تا چند ثانیه برای برنامه‌هایی که روی ماشین مجازی جاوا (JVM) اجرا می‌شوند، متغیر است.» برای استقرارهای عملیاتی حساس به تأخیر، یک تأخیر چند ثانیه‌ای نقض مستقیم اهداف سطح سرویس (SLO) است که منجر به رها شدن سبدهای خرید و تایم‌اوت شدن درخواست‌های API می‌شود.[1][5]

برای درک چرایی این اتفاق، بهتر است استارت سرد را به مراحل تشکیل‌دهنده آن تجزیه کنیم. مرحله اول، مقداردهی اولیه نمونه (instance) است، جایی که ارائه‌دهنده ابری یک ماشین مجازی یا کانتینر را تأمین می‌کند. مرحله دوم، انتقال برنامه است که کد را از فضای ذخیره‌سازی به محیط اجرا منتقل می‌کند. مرحله نهایی، بارگذاری کد برنامه است، جایی که محیط زمان اجرا کد را تجزیه کرده و وابستگی‌ها را مقداردهی اولیه می‌کند. هر مرحله تأخیری به همراه دارد و هرچه فریم‌ورک سنگین‌تر باشد، این انتظار طولانی‌تر خواهد بود.[3]

ارائه‌دهندگان ابری انگیزه مالی قدرتمندی برای بازپس‌گیری تهاجمی منابع بیکار دارند. نگهداری کانتینرهای گرم نیازمند حافظه و چرخه‌های پردازنده (CPU) است که هزینه در بر دارد. با خاتمه دادن به توابع غیرفعال — اغلب پس از ۵ تا ۱۵ دقیقه بیکاری — ارائه‌دهندگان تراکم منابع را در سرورهای فیزیکی خود به حداکثر می‌رسانند.

این بهره‌وری چندمستأجری (multi-tenant) همان چیزی است که به آن‌ها اجازه می‌دهد از کاربران فقط برای میلی‌ثانیه‌های دقیقی که کدشان در حال اجراست، هزینه دریافت کنند. استارت سرد یک باگ نیست؛ بلکه مکانیزمی است که مدل کسب‌وکار بدون سرور را سودآور می‌کند.[4][5]

با رشد پذیرش معماری بدون سرور، صنعت استراتژی‌های مختلفی را برای کاهش این تأخیر معرفی کرده است. رایج‌ترین راه‌حل تجاری، «هم‌زمانی تأمین‌شده» (provisioned concurrency) است که توسط ارائه‌دهندگان بزرگ در حدود سال ۲۰۱۹ معرفی شد.

این ویژگی به توسعه‌دهندگان اجازه می‌دهد تا با پرداخت هزینه‌ای ثابت، تعداد مشخصی از محیط‌های اجرایی را به طور دائم گرم نگه دارند. اگرچه این کار مشکل عملکرد را حل می‌کند، اما اساساً مدل هزینه بدون سرور را در هم می‌شکند و قیمت‌گذاری متغیر و مبتنی بر استفاده را دوباره به هزینه‌های ثابت زیرساختی تبدیل می‌کند.[1][4]

فراتر از خرج کردن پول برای حل مشکل، مهندسان بهینه‌سازی‌هایی در سطح برنامه را نیز بررسی کرده‌اند. یکی از رویکردها «ادغام توابع» (function fusion) است که چندین تابع کوچک را در یک استقرار بزرگ‌تر ترکیب می‌کند تا فرکانس استارت‌های سرد را در یک معماری میکروسرویس توزیع‌شده کاهش دهد. با تجمیع مسیر اجرا، توسعه‌دهندگان می‌توانند به جای مدیریت چرخه حیات ده‌ها تابع پراکنده، یک کانتینر واحد و سنگین‌تر را گرم نگه دارند.[2][5]

مسیر امیدوارکننده دیگر، بارگذاری هوشمند کد است. محققان فریم‌ورک‌هایی مانند FaaSLight توسعه داده‌اند که گراف‌های فراخوانی در سطح تابع می‌سازند تا در مرحله مقداردهی اولیه، تنها کدهای ضروری را شناسایی و بارگذاری کنند.

با جداسازی کدهای اختیاری و بارگذاری آن‌ها در صورت تقاضا، «FaaSLight می‌تواند تأخیر بارگذاری کد برنامه را تا ۷۸٫۹۵٪ کاهش دهد» که به نوبه خود تأخیر کل پاسخ را به طور متوسط ۱۹٫۲۱٪ پایین می‌آورد. این رویکرد مستقل از پلتفرم نیازی به تغییر در هایپروایزر پایه ندارد، که آن را برای توسعه‌دهندگانی که در اکوسیستم‌های ابری خاصی قفل شده‌اند، بسیار جذاب می‌کند.[3]

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

این کار می‌تواند زمان راه‌اندازی JVM را از چند ثانیه به صدها میلی‌ثانیه کاهش دهد. با این حال، استفاده از اسنپ‌شات چالش‌های جدیدی ایجاد می‌کند، مانند مدیریت کهنگی وضعیت (state staleness) و اطمینان از اینکه تصادفی بودن رمزنگاری هنگام کلون شدن یک اسنپ‌شات برای چندین بار، به خطر نمی‌افتد.[1][5]

مجازی‌سازی سبک مسیر دیگری را پیش رو می‌گذارد. فناوری‌هایی مانند WebAssembly (Wasm) با اجرای باینری‌های از پیش کامپایل‌شده در یک سندباکس بسیار محدود و دور زدن سربار کانتینرهای سنتی، زمان راه‌اندازی تقریباً آنی را فراهم می‌کنند. در حالی که Wasm هنوز در حال بلوغ است، توانایی آن در مقداردهی اولیه در حد میکروثانیه به جای میلی‌ثانیه، آن را به عنوان جانشین بالقوه‌ای برای نسل فعلی پلتفرم‌های FaaS مبتنی بر کانتینر مطرح می‌کند.[1][5]

با وجود این پیشرفت‌ها، مصالحه بنیادین همچنان پابرجاست. تیم‌های مهندسی باید به طور مداوم سادگی عملیاتی معماری بدون سرور را در برابر الزامات سخت‌گیرانه تأخیر برنامه‌های خود متعادل کنند. برای پردازش‌های پس‌زمینه، مدیریت رویدادهای ناهمگام و کارهای دسته‌ای (batch jobs)، تاوان استارت سرد کاملاً قابل قبول است. اما برای APIهای همگام و کاربرمحور، این امر نیازمند برنامه‌ریزی دقیق معماری و اغلب، هزینه‌های اضافی است.[4][5]

اکوسیستم بدون سرور در حال تکامل از یک انتزاع «یک اندازه برای همه» به طیفی از مدل‌های اجرایی است. توسعه‌دهندگان در حال یادگیری این موضوع هستند که از هیاهوی بازاریابی مقیاس‌پذیری بی‌نهایت و نگهداری صفر عبور کنند تا واقعیت‌های مکانیکی پلتفرم را درک کنند. تاوان استارت سرد احتمالاً هرگز به طور کامل از بین نخواهد رفت، زیرا این تجلی فیزیکی مدل اقتصادی بدون سرور است. اکنون هدف دیگر حذف آن نیست، بلکه مدیریت پیش‌بینی‌پذیر آن است.[1][4][5]