اگر هزینه‌های ماهانه نگهداشت سرور مجازی یا اختصاصی برای کسب‌وکارتان به عددی سنگین و بیهوده تبدیل شده، احتمالاً بخش بزرگی از توان پردازشی این زیرساخت‌ها هرگز به‌طور واقعی استفاده نمی‌شود. معماری Serverless یا «معماری بدون سرور»، دقیقاً برای همین نقطه‌ی ضعف طراحی شده است: به‌جای پرداخت هزینه سلان برای اجاره سرور، فقط بابت تعداد واقعی اجرای کد و زمان پردازش هزینه می‌پردازید؛ بنابراین مقیاس‌پذیری تا بالا بدون دردسر و هزینه را می‌توانید پیش‌رو داشته باشید مصطلح معماری بدون سرور مطرح در آن، You آنچه در ادامه می‌خوانید، بررسی تخصصی است برای اینکه با دید باز و میزان دقیق مالی، بتوانید خودتان تعیین کنید این معماری برای کاهش هزینه زیرساخت وب شما انتخاب درستی هست یا نه. این راهنما بر مبنای تجربه اجرا در پروژه‌های واقعی نگارش شده و قرار است از مرز توضیح‌های کلیشه‌ای فراتر برویم: هزینه‌ها را با جدول مقایسه می‌کنجیم، نقطه تعادل را پیدا می‌کنیم و گام‌هایی عملی برای مهاجرت به این اجرا را بررسی خواهیم کرد.
بهعنوان یک مشاور زیرساخت، این را همین ابتدا بگویم: هیچ‌کس توصیه‌ای نمی‌کند که وب‌سایت کامل و بدون برنامه را به یک توابع بدون حالت تبدیل کنید؛ بلکه تمام هنر در این است که بردارید pieces از سناریوهای ابری را بردارید که بهره‌وری نهایی را به حداکثر برسانید و ساختار سنتی فعلی را در محل‌هایی که واقعاً اقتصادی است نگاه دارید. معماری Serverless در بهترین حالت، جایگزین تدریجی یک استخوان‌بندی قدیمی است، نه یک نسخه‌ی نوشتاریشده یا جادویی در ساختار شما. در ادامه به زبان کاربردی این مهم را تشریح می‌کنیم.
سازمان معماری Serverless و مکانیزم کار آن به زبان فنی
معماری بدون سرور به این معنا نیست که سرور وجود ندارد؛ بلکه به این معناست که مدیریت، پچپان و مقیاس‌دهی ریزساخت بر عهده‌ی ارائه‌دهنده ابری است و توسعه‌دهنده فقط کد یا تابع را آماده کرده و آن را در محیط اجرایی با کنارکند و پس از آن منحنی از آن شود. بهترین مثال برای این مدل، ارائه‌ی توابع قابل (FaaS) است؛ همان مدلی که در تکنولوژی Lambda از AWS، توابع Azure از مایکرواسلیف، Google Cloud Functions و Cloudflare Workers با موضوع اجرا می‌ها نمایید.
مهمCore مفهوم‌ها: Functions و No State
در Serverless ذات ارئه اساس بر اساس «توابع» متشکل از کد هستند که حالت هر چیزی مانند نگهداری دیتا را در برخی سرویس‌های جانبی انجام می‌دهید. چون توابع بدون‌صورت (Stateless) اجرا می‌شوند، ساختار باعث می‌شود که هر بار چند نسخه در مدت یک استگاه به اجرای یک تابع سیصل شوند و درست مقدار در آن زیربنا یا همان «Payload» ارسال شود. این ویژگی باعث می‌شود که مهاجرت عادی محاسبات رویدادها محور به سادگی انجام شود؛ رویدادهایی مثل ارسال ایمیل، پردازش تصویر، خرید در سایت و درخواست‌های رسیده به API.
برای زیرساخت موردنظر، نکته‌ی مهم این است که در این سرویس‌ها عملاً به شما در مصرف استیجدر را تضمین نمی‌کندید بلکه تضمین اصلی آن است که هر زمانی که به یک رویداد یا همان trigger برسید، یک مثال جداگانه‌ی متناهی اجرا و بازگشت داده شود و پس از اتصال، همین‌طوربسته گرفته شود. این ساختار در برای هزینه‌های واستریشدن، درواقع هزینه به میان بردارد و معماری را در مواقع غیر قابل تغییر پایدار نگه‌خواهلاریش می‌دارد.
بررسی معماری Serverless و کاربرد آن در کاهش هزینه‌های زیرساخت وب
نه تنها در این بخش به مقایسه مالی دقیق می‌رسیم، بلکه نقطه‌ی اصلی کاربرد معماری Serverless در کاهش هزینه‌های زیرساخت وب را مشخص می‌کنیم. ابتدا مهم است بدانید که هزینه‌ی یک سرور مجازی معمولاً به سه فاکتور ظرفیت پردازنده، میزان رم و فضای ذخیره‌سازی NVMe یا SSD گره‌دهی است. این یعنی حتی خالی از ترافیک واقعی، قبضهای ماهانه ثابت برای شما صادر می‌شود. اما در مدل Serverless فقط آن چیزی که واقعاً پردازش می‌شود گزارش داده می‌شود؛ اگر در مدت یک روز هیچ درخواستی به فانکشن نرسد، برای همان تابع هیچ هزینه‌ی محاسباتی ایجاد نمی‌شود.
جدول زیر شمای کلی مقایسه هزینه و ویژگی بین سه مدل زیرساختی رایج را نشان می‌دهد؛ مقادیر بر اساس میانگین قیمت ارائه‌دهندگان بین‌المللی برای بارکاری متوسط دامنه‌ی یک وب‌سایت اپلیکیشن محور تخمین زده شده است:
| معیار | Virtual Machine یا VPS | سرور اختصاصی (Dedicated) | معیاریServerless |
|---|---|---|---|
| مدل پرداخت | ثابت ماهانه به‌ازای منابع رزروشده | ثابت ماهانه با ظرفیت بالا و اختصاصی | پرداخت به ازای هر میلیون اجرا و مدت پردازش |
| مدیریت Server/OS | بر عهده شما | بر عهده شما و استادبانی گران‌تر | کاملاً مدیریت‌شده؛ هیچ دسترسی به امکانات هاست |
| مقیاس‌پذیری ترافیک | محدود به منابع VPS و نیاز به ارتقاء دستی | نیاز به سفارش و ارتقاء سخت‌افزاری طولانی | خودکار و آنی از صفر تا صدها هزار درخواست |
| هزینه در بار کم | بالا (پرداخت ثابت حتی بدون مصرف) | بی‌نهایت غیر اقتصادی | بسیار پایین؛ گاهی چند سنت |
| هزینه در بار یکنواخت بالا | قابل پیش‌بینی و مناسب | مناسب برای مصرف بالا | نمی‌تواند گران‌تر از VPS شود |
| راه‌اندازی و استقرار | چند دقیقه تا چند ساعت | چند ساعت تا چند روز | چند دقیقه برای تغییر با command line |
| زمان آپتایم (Uptime) | وابسته به node هایاد ارائه‌دهنده | وابسته و نیاز شما به سلامت IDC | در سطح SLA بالا و توزیع‌شده |
از جدول این گونه استنتاج می‌شود که معماری‌های بدون سرور، از منظری مالی، یک راه مناسب برای اپلیکیشن‌هایی است که ترافیک آن‌ها بالا و پایین‌پایه و داشتن بازده همزمان باشد؛ بنابراین، در پاسخ به سوال «آیا Serverless هزینه زیرساخت را کاهش می‌دهد؟» باید بگویم: اگر ویژگی‌های کاری شما پیکهای مصرفی را بردارد، یا در جهت افزایشات زمان مشخص در روز باشد، به‌سختی می‌توان مدل دیگری را هم‌ارز از نظر مقرون‌به‌صرفه پیدا کرد.
چه مواقعی معماریServerless واقعاً هزینه را کاهش می‌دهد؟
تجربه به ما می‌گوید بهترین کاندیدا برای استقرار Serverless از زاویه‌ی کاهش هزینه، کارهایهایی هستند که در یک بازه‌ی زمانی مشخص و با شدت متغیر انجام می‌شوند. این موارد عبارت‌اند از:
- پردازش رویدادهای ساعتی بردحالی: مثل تغییر روتین تصاویر دریافت‌شده از کاربران، تولید خلاصه‌های خبری یا ارسال خبرنامه‌های ایمیل؛
- وب‌هوک‌ها و اتصالات سرویس‌های شخص ثالث: مثل دریافت رایگان پدازه پرداخت از PayPal یا Stripe و به Festal ورودی بعضی API ها؛
- بک‌اند اپلیکیشن موبایل: جایی که تعداد کاربران ثابت است اما در صورت فعال‌سازی Push، ترافیک به یکباره چند برابر می‌شود؛
- مصورسازیهای دادهای و Batchهای کوتاه: تبدیل ویدیو دوراه، فشرده‌سازی تصاویر یا توسعه گزارش‌های شبانه؛
- APIs دارای نوسان فصلی: پروژه‌هایی مثل فروشگاه‌های فصلی که در اوج خرید، صد برابر و در دیگر روزها بسیار کم کار می‌کنند.
در این موارد، منطق اقتصادی Serverless کاملاً برای شما کار می‌کند؛ چون عملاً هزینه‌ی زیرساخت با درامدی که به وجود می‌آورید هماهنگ می‌شود و دیگر مجبور نیستید به ازای میانگین مصرف یک اترنت هم ظرفیت حداکثری (burst capacity) را با هزینه ثابت نگه دارید.
زمان‌هایی که Serverless از نظر فنی برای کاهش هزینه انتخاب زیان‌بار است
راستش را بخواهید، در بعضی طرح‌های ساختاری، انتقال به Serverless نه‌تنها هزینه افت نمی‌کند بلکه به یک هزینه پنهانی بزرگ هم تبدیل می‌شود. در این شرایط حتماً ماندن بر روی VPS یا سرور اختصاصی مورداهمی است:
بارهای کاری پایدار و سنگین؛ بهعنوان مثال اگر وب‌سایت شما دائم ۱۰۰ هسته پردازشی را در ۲۴ ساعت اشغال می‌کند و ترافیک آن تقریباً خطی است، مدل اجرای بهعمل اجرا می‌تواند با قیمت چند برابر یک سرور اختصاصی برایتان تمام شود؛ ارائه‌دهنده ابری ابزارهای KVM یا Dedicated نیز برای همین شرایط اقتصادی طراحی شده‌اند.
لا اکی از دیگانیسایل را با مثال در نظر بگیرید: در AWS Lambda، هر یک میلیون اجرا با حافظه‌ی گیگابایتی حدوداً ۰.۲ دلار اضافه دارد و پردازش یک تابعِ دو ثانیه‌ای بیلای تمام‌آیند می‌تواند از چند دلار فراتر باشد؛ چون هزینه در این مدل روی مجموع «ثانیه Gb» محاسبه می‌شود.
دیگر موارد مهم را در این فهرست از نظر فنی بررسی کنید:
- وظایف طولانی‌مدت و Stateful: توابع معمولاً در محدوده‌ی زمانی ۱۰ ثانیه تا چند دقیقه محدود هستند، برای اجرای نرم‌افزارهای مبتنی بر WebSocket و گیم سرورها را حقیقتاً انتخاب کنید که در شرایط بسیار محدود یا نیاز به Connection دائمی دارند؛
- تاخیر شروع اولیه یا Cold Start: اگر API شما برای یک دامنه با حذف Sabalan نیاز به پاسخ در ۱۰ میلی‌ثانیه دارد، در درستی online ماهی تا به‌ضای مقداردهی مجدد تا چند میلی‌ثانیه بیهوده تاخیر می‌بینید؛
- نرم‌افزارهای Dependent به GPU یا Sys Admin: برای اجرای مدل یادگیری عمیق که نیازمند پیوسته GPU است، Serverless فعلاً نه تنها اقتصادی نیست بلکه انتخاب اصلاً صحیحی نیست؛ باید از bare metal استفاده شود؛
- ممنوعیت‌های زیرساختی و دولتی (Compliance): مواقعی که بایدی قانونی محل داده‌ها یا داشتن امنیت چهاردیواری می‌خواهید، به‌خصوص وقتی در ایران به استافت هاست داخلی می‌کنید، این معماری سیطره متمایل شده و کند؛
مراحل عملی پیاده‌سازی: از زیرساخت سنتی به یک سیستم بدون سرور
اگر تصمیم به تست و مهاجرت بگیرید، پیشنهاد من بهعنوان شخصی که چندین وب‌خدمت گذراندن به سکوی ابری را انجام داده، این ساختار مرحله به مرحله استلیک بنابراین گام‌به‌گام پیش بروید؛ لازم نیست یک‌شبانهArchitecture در چند خدمات را جابجا نمایید.
۱. با یک کارکرد عالی استارت بزنید
اولین قدم انتخاب یک کاری با Volume متغیر و Rate پایین باشد. مثلاً «تولید تصویر کوچک برای Avatar کاربر» یک انتخاب ایده‌آل است. این تابع را کنار سیستم موجود (مثلاً یک VPS) قرار دهید و شروع به تست کنید. برای مثال با استفاده از ابزار Serverless Framework و پلتفرم AWS می‌توانید به‌صورت عملی و بدون پیچیدگی انجام بگیرید:
1 2 3 4 5 6 7 8 9 | # نصب فریم‌ورک به صورت عمومی npm i -g serverless # ساخت یک سرویس مبتنی بر Node.js sls create --t aws-nodejs --path my-first-service cd my-first-service # متن تابع را تا عددی وارد کرده و سپس استقرار انجام می‌دهیم: sls deploy |
در این روش، Serverless عملاً همان CloudFormation را خودبه‌خودEggگذار می‌کند، توابع را migrationد می‌کند و آدرس HTTP آماده برای تست در اختیار شما قرار می‌دهد. بعد از این، برای مقایسه دقیقِ هزینه، سرویس ارائه دهنده ابری را در یک بازه‌ی کنترل شده زیر بار ببرید.
بک‌اند را به قطعات با مصرف متغیر تقسیم کنید
سعی کنید همه‌ی خروجی وب را با یک تابع مازی نسازید؛ بلکه هر endpoint را یک Function جداگانه در نظر بگیرید. باید اینگونه تصور کنید که هر تابع، با میزان اهمیت و ترافیک آن، مخارج خودش را بیشتر یا کمتر می‌شود. در این حالت اگر یک سرویس طرفیدگی ثابت داشته باشد، همان توابع داغ هزینه‌ی ناچیزی دارند؛ و اگر یکی از بخش‌ها بسیار فعال باشد، دقیقاً آن بخش بیشترین و در هزینه به‌سرمایه متعلق آن شما حساب شود.
از Cacheها و مرز اختیاری سرعت استفاده کنید
برای کاهش اجراهای مکرر، استفاده از CDN مانند Cloudflare پیش‌هاست. اگر پاسخ یک تابع برای تمام کاربران یکسان است، از لایه‌ی کشیدنی به صورت Global در نظر بگیرید. اینکار هم هزینه‌ی اجرا را بشدت کم می‌کند و هم اولین اپلود را بهبود می‌بخشد؛ ترکیب مناسب برای کاهش هزینه‌های کل زیرساخت و بهبود سئو به همزمان خواهد بود.
چالش‌های ذاتی و مدیریتی معماری بدون سرور
شاید همه‌چیز مطلوب به نظر برسد اما در معماری Serverless با چند چالش جدی روبرو هستید که برنامه‌ریزی برای آن‌ها از ابتدا لازم است:
- خطر قفل شدن (Vendor Lock-in): کد شما وونی به سرویس‌های خاص مثل API Gateway و IAM مربوط می‌شود؛ برای کاهش وابستگی از لایه‌ی Abstraction استفاده کنید و حجم رمز را در جداگانهیا تعریف‌های استاندارد ارائه دهید.
- نرم‌دار بودن دیباگ محلی: اجرای کامل همان محیط تولید فقط تویابانفر پایدار ممکن نیست؛ ابزارهایی مانند LocalStack یا Cloud Emulators را بهچرخه توسعه اضافه کنید.
- مانیتورینح و زمان نه ترها: هیچ نوع مدیریتی بدهی وجود ندارد که همه آن‌ها در گزارش حجمی شما دیده شود؛ بهتر است از توزیع متن‌بازو ویدیو کنید، مثلاً OpenTelaemetry و نصب Dashبورد ه-hydroxy را لحاظ كنید.
نتیجه‌گیری نهایی
از این بررسی تگین می‌کنیم که بررسی معماری Serverless و کاربرد آن در کاهش هزینه‌های زیرساخت وب، یک ادعای مطلق نیست و نتیجه‌ی نهایی به شکل ترافیک، ماهیت بار کاری و الزامات فنی بستگی دارد. اگر بار شما نوسان پذیر، رویدادمحور یا شروع شود، این یک از جمله هوشمندترین سرمایه‌گذاری‌هایی است که می‌توانید انجام دهید؛ در حالی که برای اپلیکیشن‌های ثابت و پرارزی کمی همچنان VPS بهینه‌تر است. پیشنهاد اصلی من این است که تیم فنی شما با اجرای همین معماری سبز را تجربه کند، از بهترین الگو که توضیح دادیم و اعداد دقیق اندازه‌گیری از مانیتورینگ به دست آورید، سپس تصمیم به مقیاس‌دهی قطعی بگیرید.
سوالات متداول (FAQ)
1. آیا معماری سرورنلس به معنی حذف کامل سرور است؟
خیر؛ هنوز هم سرورها و کانتینرها وجود دارد، اما تمام مدیریت و نگهداری آن‌ها، پچ ثبات و مقیاس‌دهی به عهده‌ی خدمت‌دهی فتده اشیلی آن قرار دارد و توسعه‌دهنده فقط کد را در اختیار ارائه‌دهنده‌ی ابری قرار می‌دهد. بنابراین «بدون سرور» به مفهوم دوری ازرابطه مستقیم با سخت‌افزار است.
2. هزینه سرورها برای چه نوع سایت‌هایی معماری سروریحه ندارد؟
این کار به سود قیمتی در حالت ترافیک نوسبانی، استارتاپ‌های اولیه، وب‌سرویس‌های مبتنی بر رویداد و پلتفرم‌های فصلی کم‌وپرونفز است. برای ترافیک ثابت و بلنددراز، مانند یک سایت سازمانی ۲۴ ساعته با دیتابیس سنگین و استفاده دائمی از پردازنده، نگهداری معماری سنتی همچنان مقرون‌به‌صرفه‌تر است.
3. کلید استفاده از Serverless و VPS چیست؟
VPS یک محیط کامل با تعریف‌پذیری و مدیریت خودتان است، اما نیازمند تعیین ظرفیت ثابت و بهبهینه با تمام کارهای راهبری است. Serverless خودکار مقیاس شده، هزینه کاملاً مصرف محور دارد، اما محدودیت مدت زمان اجرا، سرد شدن و وابستگی به فروشنده را نیز برای شما می‌سازد.
۴. ظخنفرخ است بهترین نکته برای راه اندازی با کمترین هزینه؟
بله، با ارائه‌دهنده‌های مربری مثل Vercel از AWS Lambda و Netlify Edge Functions به‌واسطه از مشتری محبوب از شعبه بیرون برای MVP وب‌سایت استفاده کنید. بسیاری از درخواست‌های شما در لایه‌ی فری تایر آب قرار خواهند گرفت و تا ده میلیون درخواست در برخی پلن‌ها تقریباً صفر تا یک دلار می‌باشد؛ فقط مراقب باش در دیتابیس یا سرویس‌های جانبی وسیله کلی انتخاب را به وحشه نبرید.
5. آیا می‌توان معماری Serverless را منحصراً Inside ایران استفاده کرد؟
به‌صورت می‌توان از سرویس‌های ابری بین‌المللی (با هیچ گام اول برای عبور اینترنت یا تحریم) در جهت اجراچند استفاده کرد، ولی برای پروژه‌هایی که نسبت به IPO خبر تعرفه و محدودیت محدودیت دارای تابع تجربه کمتر، از ابرهای داخلی که بعضاً سرویس‌هایی با الگوی فانکشن ادب دارند استفاده نمایید. مسئله‌ی بزرگ در این حالت بهینه بودن latency در داخل ایران است و نیاز به بررسی دقیق محلی برتری است که بسامد را داشته باشد. معمولاً برای داده‌های حساس باید فقط از زیرساخت ابری داخل مسیر استفاده شود ولی برای APIهای بازی، استفاده از این سرویس‌های بین‌المللی صرفه اقتصادی بیشتری دارد.
