خب احتمالا با واژه Serverless Computing اشنایی داشته باشید یا بدون اینکه بدونید، دارید برای ساده‌تر کردن کار‌هاتون ازش استفاده میکنید! رایانش سرورلس یا بدون-سرور موضوعی هست که شدیدا در حال معروف شدنه (لااقل خارج از ایران) و من تو این پست میخوام در مورد ویژگی‌هایی از مدل سرورلس توضیح بدم که اون رو نسبت به بقیه مدل‌های ابری متمایز میکنه و بعد توضیح میدم که ایا این مدل رایانشی که با زرق و برقش همه رو مجذوب کرده، برای چه نوع برنامه‌های مناسب و برای چه سیستم‌هایی نا‌مناسب هست.
خب مدل رایانشی سرورلس یک مدل پردازشی ابری هست که خیلی از ورودش به بازار نمیگذره. این مدل هم مانند بقیه مدل‌های ابری مثل SaaS، هدف افزایش دردسترس‌پذیری، افزایش کیفیت سرویس و خیلی موارد خوب دیگه رو هدف قرار داده. برخلاف برداشتی که اولین بار بعد از شنیدن اسمش دارید، این مدل سرور‌ها و سیستم‌های پردازشی رو حذف نمیکنه، بلکه فقط از دید شما (صاحب کسب و کار) پنهانش میکنه و شما دیگه لزومی نداره هزینه‌های زیاد برای نگهداری و توسعه زیرساختتون بپردازید. حتی نیازی به استفاده از ابزا‌ر‌هایی مثل OpenStack، Kubernetes برای مدیریت سیستمتون ندارید چرا که وظیفه مدیریت، نگهداری، توسعه، مقیاس‌پذیری و ... توسط ارائهدهنده سرویس انجام میشه. البته مدل‌هایی دیگه رایانشی مثل PaaS یا CaaS هم همچین ادعایی دارند ولی این ادعا در مدل سرورلس بهتر خودشو نشون داده. ولی چرا؟
تابع به عنوان سرویس (Function as a Service)
مدلی که تونسته رایانش سرورلس رو تا این مرحله معروف کنه، مدل Function as a Service یا به اختصار FaaS است. این مدل پیاده‌سازی دقیق‌تری از رایانش سرورلس رو به کاربر ارائه میده. در این مدل شما لازمه برنامه‌هاتون رو به صورت توابع برنامه‌نویسی و در قالب Image هایی که Containerize شدن بر روی سرویسدهنده قرار بدید. این ویژگی باعث میشه برنامه‌نویسی تابع محور مکمل خوبی برای مدل سرورلس باشه. توابع پیاده‌سازی شده امکان شخصه‌سازی شدن رو دارند که بعدز از چه رویداد و فراخوانی‌هایی اجرا بشن. مثلا تابعی رو تنظیم کنید که وقتی کاربری محصولی رو به سبد خرید اضافه میکنه فراخوانی بشه یا مثلا بعد از بازگشت کاربر از درگاه پرداخت. مساله مهم اینه که شما در واقع فقط هزینه زمان اجرای تابع رو به ارائهدهنده سرویس پرداخت میکنید نه زمان اجاره کردن سرور. که البته نحوه محاسبه مدل درامدی بین سرویسدهنده ها متفاوت هست. برای مثال Amazon Lambda بر اساس تعداد فراخوانی تابع و مصرف حافظه اصلی هزینه رو اعمال میکنه.
البته باید توجه داشت که FaaS تنها مدل معروف رایانش سرورلس نیست بلکه مدل‌های دیگه‌ای مثل Back-end as a Service هم وجود دارند. در این مدل سرویسدهنده سرویس‌هایی رو از طریق API در اختیار توسعه‌دهنده قرار مید‌هند که عملا حتی نیاز به راه‌اندازی برخی برنامه‌ها رو هم حذف می‌کنند. برای مثال سرویس‌هایی مثل پایگاه‌داده، سرویس ارسال ایمیل، سرویس نوتیفیکش و ... که همگی کاملا توسط سرویسدهنده نگهداری میشوند و شما فقط با فراخوانی API ها از سرویسها استفاده میکنید. نمونه‌ای از این سرویس که احتمالا ازش هم استفاده کردید سرویس Firebase گوگل هستش که سرویس‌های مختلف رو پشتیبانی میکنه. البته هدف ما تو این مقاله BaaS نیست پس بهتره برگردیم سر موضوع خودمون. در ضمن توضیحاتی که از این به بعد داده میشه حول مدل FaaS هستند.
بدون-حالت بودن توابع (Stateless)
در مدل FaaS توابع استفاده شده به صورت stateless هستند. و هیچ دیتایی در session اجرایی خودشون برای استفاده اینده ذخیره نمی‌کنن چرا که این توابع بعد از مدتی بی‌کار بودن، خاموش میشن!! بله درست شنیدید، توابع خاموش میشن. توابعی که در قالب ایمیج توسط ابزاری مثل Docker کانتینر‌سازی شدن، در حالت معمولی در وضعیت down و خاموش قرار دارند. ولی به محض فراخوانی یک رویداد مشخص، ایمیج اجرا شده و به درخواست پاسخ مید‌هد. این توابع بعد از زمان مشخصی خاموش شده و از مصرف انرژی و هزینه اضافی جلوگیری میکند. این عملیات رو اصطلاحا Scale to zero می‌نامند که مخصوصا در مدل سرورلس قابل انجام هست که به شدت باعث کاهش هزینه اجرایی می‌شود.
ویژگی stateless بودن توابع امکان مقیاس‌پذیری اون‌ها رو نسبت به برنامه‌های statefull بسیار بالاتر میبره. چرا که شما بعد از ایجاد چند نمونه یا instance از توابعتون نیاز دارید که state های اون‌ها رو هم با هم دیگه اصطلاحا sync داشته باشید تا مشکلی در تفاوت داده‌ها بین سرویس‌های مختلف ایجاد نشه که این خودش میتونه روی فرایند مقیاس‌پذیری تاثیر داشته باشه. البته اگه برنامه شما نیازمند پایدار کردن داده هست، میتونید از پایگاه‌داده‌های خارجی هم استفاده کنید که تا حدودی مشکل مذکور رو براتون رفع میکنه.
چالش شروع سرد (Cold-Start)
نکته‌ای که باید بهش توجه داشت اینه زمان Scale up کردن و اجرا شدن تابع، میتونه زمانبر باشه (۱ تا ۱۰ ثانیه) که این زمان به شرایط مختلفی بستگی داره. مثلا اگر ایمیج تابع از قبل روی ماشین حضور نداشته باشه، لازمه اون رو از مخزن مربوطه مثل DockerHub بارگذازی کنه که خود زمان این فرایند بسته به ویژگیهای شبکه زمانبر هست. این زمان اجرا شدن تابع رو اصطلاحا Cold-Start نامگذاری کردند که شبیه استارت زدن ماشین در هوای سرده و گرم کردن موتور اون مقداری زمانبر هست. در حال حاضز مسئله کاهش زمان cold-start از چالش‌های جدی این مدل ابری است که سرویس‌دهنده‌ها و مراکز تحقیقاتی، بر روی این چالش تمرکز زیادی کرده‌اند.
خب تا اینجا به محدودیت‌ها و ویژگیهای خاص این مدل ابری اشاره کردم ولی مساله‌ی مهمی که وجود داره اینه که چه نوع برنامه‌هایی مناسب این مدل ابری هست؟ ایا میشه برای برنامه‌ای که در معماری Monolithic پیاده‌سازی شده از این مدل استفاده کنیم؟ ایا تابعی که زمان اجراییش ممکنه ساعت‌ها زمان ببره میتونه در این محیط سرورلس به خوبی عمل کنه؟
در ادامه توضح میدم که مدل سرورلس مناسب چه نوع برنامه‌هایی هست و در چه حالت‌هایی هم نمیتونه براتون مفید باشه.
- برنامه‌های با پیچیدگی ساختاری یا تجاری بالا
در مدل سرورلس شما در نهایت مجبور به تقسیم برنامه‌تون به توابع با ابعاد کوچک هستید که تقسیم بندی یک برنامه با پیچیدگی بالا میتونه براتون دردسرساز باشه. این دردسر میتونه از جنبه‌های مختلف بررسی بشه. مثلا ریفکتور، توسعه و نگهداری با تعداد بالا میتونه نیازمند تیم حرفه‌ای توسعه باشه. یا فراخوانی یک رویداد که در نتیجه اون ماژول‌های مختلف فعال میشوند، در صورتی که از معماری و تکنولوژی‌ها مناسب استفاده نکنید، کارایی سیستم میتونه کاهش چشم گیری داشته باشه.
- برنامه‌های رویداد محور (Event Driven)
برنامه‌هایی که اصطلاحا رویداد رویداد محور هستند، بعد از راه‌اندازی روی مدل سرورلس، نتیجه بهتری می‌گیرند. در این این نوع برنامه‌ها، دریافت، پردازش و ماندگار کردن رویداد‌های سیستم تمرکز اصلی در طراحی سیستم هست. جدا از مدل سرورلس، معماری رویداد محور مکمل خوبی برای سیستم‌های توزیع شده مدرن مثل معماری میکروسرویس(Microservice) یا سرویس-بیس(Servicebased) هستند.
- برنامه‌های پیاده‌سازی شده روی معماری سرویس گرا (Service Oriented Architecture)
برنامه‌هایی که ساختار انها در جهت تقسیتم‌‌بندی سیستم به دامنه‌های مجزا از هم هست، اهداف نسبتا مشترکی با مدل سرورلس دارند. این نوع برنامه‌ها سیستم رو از نظر ساختار تجاری به بخش‌های مجزایی تقسیم میکند که هر قسمت/سرویس مفهوم و دامنه مشخصی از هدف کلی برنامه را پیاده‌سازی میکند. در این معماری، بعد از ماژولار کردن سیستم، ممکن است سرویس‌هایی وجود داشته باشند که تنها مسئول یک عملیات مشخص باشند. این نوع سرویسها که مسئولیت بسیار دقیقی دارند می‌توانند نتیجه خوبی از مدل سرورلس بگیرند.
- سیستم‌های با حجم‌کاری انفجاری (Bursty Workloads)
برخی از سیستم‌ها در مدت زمانی طولانی مسئول پاسخگویی به تعداد درخواست‌های ثابتی از طرف کاربر نهایی هستند و این تعداد معمولا شیب تغییر شدیدی را شاهد نیستند. مدل سرورلس نمی‌تواند گزینه خوبی برای این نوع سیستم‌ها باشد چرا که مدل سرورلس با توجه به مقیاش‌پذیری بالایی که دارد، از پس درخواست‌های با حجم‌کاری انفجاری و هیجانی بهتر بر‌‌می‌اید. برای مثال سیستمی را در نر بگیرید که شاهد هجوم ناگهانی کاربران برای ثبت نام در برنامه بعد از تبلیغات تلویزیونی است که سیستم ثبت‌نام در زمان کوتاهی با افزایش لحظه‌ای درخواست‌ها روبرو می‌شود و لازم است تعداد توابع بسته به نیاز سیستم هرچه سریعتر افزایش پیدا کرده تا کیفیت سرویس ارائه شده به کاربران کاهش پیدا نکند.
- فرایند‌های با زمان پردازش زیاد
در برخی برنامه‌ها فرایند‌هایی وجود دارند که زمان اجرای طولانی دارند. برای مثال یک تابع پردازش تصویر که ممکن است زمان اتمام کار ان چند دقیقه باشد. مدل سرورلس نمی‌تواند پاسخ خوبی برای این نوع برنامه‌ها باشد از انجایی که برخی از سرویس‌دهنده‌ها، یک زمان حداکثری برای اجرای توابع در نظر گرفته اند. برای مثال Amazon Lambda پردازش توابعی که بیشتر از ۵ دقیقه اجرا باشند را متوقف میکند. البته محدودیت برای سرویس‌دهنده‌های دیگر متفاوت است.
- محدودیت قفل‌شدگی میزبان (Vendor Lock-In)
با توجه به جدید بودن مدل سرورلس، استاندارد یکسانی بین سرویس‌دهنده‌ها در نحوه ارائه سرویس و محدودیت‌های ان وجود ندارد، که این باعث می‌شود شما نتونید به راحتی مهاجرت به یک سرویسدهنده دیگر رو انجام بدید. برای مثال شما ممکنه از زبان برنامه‌نویسی Go برای پیاده‌سازی توابعتون بر روی امازون لامبدا استفاده کرده باشید و سرویسدهنده دومی که قصد مهاجرت به اون رو دارید، از این زبان برنامه‌نویسی پشتیبانی نکند و مجبور به استفاده از ابزار دیگه‌ای باشید. البته این محودیت با پا به سن گذاشتن مدل سرورلس میتواند بهبود پیدا کند.
- برنامه‌های حساس به تاخیر
ممکن است برنامه شما از نوع حساس به تاخیر باشد و نیاز باشد در کوتاه‌ترین زمان ممکن به درخواست‌های کاربر پاسخ بدید. احتمالا مدل سرورلس برای برنامه شما گزینه مناسبی نباشد چرا که این مدل رایانشی از مشکل cold-start رنج می‌برد و راه‌اندازی توابع میتواند تا ۱۰ ثانیه متغیر باشد.
- محدودیت در شخصی‌سازی زیرساخت
همونطور که توضیح داده شد در این مدل دسترسی شما در تغییر و توسعه زیرساخت محدودتر از مدل‌های دیگه ابری مانند IaaS است که این محدودیت ممکنه برای برنامه شما مناسب نباشد. برای مثال شما دیگه هیچ دسترسیی برای راه‌اندازی Kubernetes جهت مدیریت کانتینرهاتون ندارید که ممکنه در شخصی‌سازی معماری و زیرساخت شما رو محدود کنه.
- برنامه‌های Stateless
همونطور که توضیح داده شد، توابع سرورلس به صورت stateless هستند و توابع بعد از خاموش شدن، داده‌ای رو که در session خودشون ذخیره کردن، از دست میدن. البته در صورت نیاز شما برای استفاده از داده‌های درخواست محورتون، میتونید از سیستم‌های پایدار کننده خارجی داده مثل پایگاه‌داده‌ها استفاده کنید ولی لازمه توجه داشته باشید که اتصال به یک پایگاه‌داده و جمع‌اوری و ذخیره داده میتونه مساله‌زمان‌بری باشه. البته لازم به ذکره که راه‌کار هایی توسط برخی از ارائهدهندگان سرویس جهت statefull کردن توابع مدل سرورلس ارائه شده است.
نتیجه گیری
مدل رایانشی سرورلس هم مانند بقیه مدل‌ها و معماری‌ها، یک tradeoff و معامله محسوب میشه و باید در نهایت بین معیار‌های موجود، شاخصی که شما رو بهتر به هدف اصلی برنامه‌تون می‌رسونه، نسبت به بقیه اولویت قرار بدید. برای مثال برنامه شما بعد از اجرا بر روی این مدل ممکنه هزینه راه‌اندازی کمتری نسبت به مدل IaaS داشته باشه ولی همزمان نیاز به یک پایگاه‌داده برای پایداری داده‌هاتون نسبتا زمان اجرای درخواست‌ها رو افزایش بده. موردی که باید بهش توجه داشته باشیم اینه که متاسفانه در داخل کشور هیچ ارائه دهنده‌دهنده سرویسی برای مدل ابری سرورلس وجود نداره (نه FaaS و نه BaaS). با توجه به محبوبیت این مدل در خارج از کشور، جای خالی همچین سرویسی در بین ارائهدهندگان سرویس ابری داخلی مثل ابرآروان محسوس هست.
منابع
- Aslanpour, M. S., Toosi, A. N., Cheema, M. A., & Gaire, R. (2022). Energy-Aware Resource Scheduling for Serverless Edge Computing. The 22nd IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGrid). IEEE
- Mampage, Anupama & Karunasekera, Shanika & Buyya, Rajkumar. (2022). A Holistic View on Resource Management in Serverless Computing Environments: Taxonomy and Future Directions. ACM Computing Surveys. 10.1145/3510412
- Das, A., Imai, S., Patterson, S., & Wittie, M. P. (2020, May). Performance optimization for edge-cloud serverless platforms via dynamic task placement. In 2020 20th IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGRID) (pp. 41-50). IEEE
- S. Agarwal, M. A. Rodriguez and R. Buyya, "A Reinforcement Learning Approach to Reduce Serverless Function Cold Start Frequency," 2021 IEEE/ACM 21st International Symposium on Cluster, Cloud and Internet Computing (CCGrid), 2021, pp. 797-803, doi: 10.1109/CCGrid51090.2021.00097
