Serverless چیست؟ آشنایی با معماری بدون سرور و AWS Lambda

فرض کنید قرار است یک API ساده برای ثبت سفارش یا ارسال ایمیل ایجاد کنید. نوشتن کد شاید فقط چند ساعت زمان ببرد، اما پس از آن با فهرستی از کارهای دیگر روبه‌رو می‌شوید: تهیه سرور، استقرار برنامه، مدیریت مقیاس‌پذیری، مانیتورینگ، به‌روزرسانی سیستم‌عامل و رسیدگی به زیرساخت.

معماری Serverless این روند را تغییر می‌دهد. به‌جای مدیریت سرور، تنها کد موردنیاز نوشته می‌شود و اجرای آن به ارائه‌دهنده سرویس ابری سپرده می‌شود. برنامه فقط زمانی اجرا می‌شود که درخواستی دریافت کند و منابع نیز متناسب با همان درخواست تخصیص داده می‌شوند.

در این مقاله با مفهوم Serverless آشنا می‌شویم، نحوه عملکرد آن را بررسی می‌کنیم و می‌بینیم چگونه می‌توان با استفاده از AWS Lambda بدون مدیریت مستقیم سرورها، سرویس‌های مقیاس‌پذیر و کاربردی ایجاد کرد.

Serverless چیست؟

با وجود نام Serverless (ترجمه تحت لفظی آن بدون سرور می‌شود)، هیچ برنامه‌ای بدون سرور اجرا نمی‌شود. سرورها همچنان وجود دارند، اما مسئولیت تهیه، پیکربندی، نگهداری و مقیاس‌پذیری آن‌ها از دوش توسعه‌دهنده برداشته شده و بر عهده ارائه‌دهنده سرویس ابری قرار می‌گیرد.

در معماری Serverless، توسعه‌دهنده به‌جای مدیریت زیرساخت، روی نوشتن منطق برنامه تمرکز می‌کند. کد در قالب توابع یا سرویس‌هایی مستقل مستقر می‌شود و تنها زمانی اجرا می‌شود که یک رویداد (Event) آن را فعال کند: برای مثال دریافت یک درخواست HTTP، آپلود فایل، ارسال پیام به صف یا اجرای یک زمان‌بندی مشخص.

یکی دیگر از ویژگی‌های مهم این معماری، پرداخت بر اساس میزان استفاده است. برخلاف سرورهای سنتی که حتی در زمان بدون ترافیک نیز هزینه دارند، در Serverless معمولا تنها برای مدت‌زمان اجرای کد و منابع مصرف‌شده هزینه پرداخت می‌شود.

Serverless چگونه کار می‌کند؟

در معماری Serverless، برنامه به‌جای اینکه به‌صورت دائمی روی یک سرور در حال اجرا باشد، در قالب Functionهای مستقل مستقر می‌شود. هر Function تنها زمانی اجرا می‌شود که یک رویداد آن را فراخوانی کند.

برای مثال، فرض کنید یک Function برای پردازش فرم ثبت‌نام کاربران نوشته‌اید. زمانی که کاربر فرم را ارسال می‌کند، درخواست به سرویس Serverless ارسال می‌شود. ارائه‌دهنده ابری منابع موردنیاز را در همان لحظه آماده می‌کند، Function را اجرا می‌کند و پس از پایان کار، منابع آزاد می‌شوند.

به‌صورت خلاصه، روند اجرا به این شکل است:

1. یک رویداد (Event) مانند درخواست HTTP، آپلود فایل یا دریافت پیام رخ می‌دهد.
2. سرویس Serverless Function مرتبط با آن رویداد را شناسایی می‌کند.
3. منابع موردنیاز برای اجرای Function به‌صورت خودکار تخصیص داده می‌شود.
4. کد اجرا شده و نتیجه به درخواست‌کننده بازگردانده می‌شود.
5. پس از پایان اجرا، منابع آزاد می‌شوند و تا رویداد بعدی نیازی به اجرای دائمی برنامه نیست.

این مدل باعث می‌شود برنامه تنها در زمان نیاز از منابع استفاده کند. همچنین اگر تعداد درخواست‌ها افزایش پیدا کند، سرویس ابری می‌تواند چندین نسخه از همان Function را به‌صورت خودکار اجرا کند تا بار بین آن‌ها توزیع شود، بدون اینکه توسعه‌دهنده نیازی به پیکربندی سرور یا افزایش ظرفیت داشته باشد.

به همین دلیل، Serverless به گزینه‌ای محبوب برای ساخت APIها، Webhookها، پردازش فایل‌ها و بسیاری از سرویس‌های رویدادمحور تبدیل شده است. سرویس‌هایی که نیاز دارند بدون درگیر شدن با مدیریت زیرساخت، به‌سرعت توسعه پیدا کنند و در صورت افزایش ترافیک، به‌صورت خودکار مقیاس‌پذیر شوند.

AWS Lambda چیست؟

وقتی صحبت از Serverless می‌شود، اولین نامی که مطرح می‌شود AWS Lambda است. این سرویس که توسط آمازون ارائه شده، به شما اجازه می‌دهد کدهای خود را بدون تهیه یا مدیریت سرور اجرا کنید. کافی است Function موردنظر را ایجاد کنید، باقی مسئولیت‌ها، از آماده‌سازی زیرساخت گرفته تا مقیاس‌پذیری و مدیریت منابع، بر عهده AWS خواهد بود.

در Lambda، هر Function یک واحد مستقل از کد است که برای انجام یک وظیفه مشخص نوشته می‌شود. این Function می‌تواند با زبان‌هایی مانند پایتون، جاوااسکریپت (Node.js)، جاوا، Go، سی‌شارپ و چند زبان دیگر توسعه داده شود. هر بار که رویدادی مرتبط با Function رخ دهد، AWS آن را اجرا کرده و نتیجه را به سرویس درخواست‌کننده بازمی‌گرداند.

یکی از نقاط قوت Lambda، یکپارچگی آن با سایر سرویس‌های AWS است. برای مثال، می‌توان یک Function را طوری تنظیم کرد که با دریافت یک درخواست از API Gateway اجرا شود، پس از آپلود فایل در Amazon S3 فعال شود، به تغییرات یک جدول در DynamoDB واکنش نشان دهد یا پس از دریافت پیام از Amazon SQS پردازش موردنظر را انجام دهد. این ارتباط نزدیک میان سرویس‌ها، ساخت معماری‌های رویدادمحور را بسیار ساده‌تر می‌کند.

از نظر هزینه نیز Lambda مدل متفاوتی نسبت به سرورهای سنتی دارد. هزینه بر اساس تعداد دفعات اجرا و مدت‌زمان اجرای Function محاسبه می‌شود. اگر Function هیچ درخواستی دریافت نکند، هزینه‌ای بابت اجرای آن پرداخت نخواهید کرد. به همین دلیل، AWS Lambda برای APIهای کم‌ترافیک، Webhookها، پردازش فایل، اتوماسیون وظایف و بسیاری از سرویس‌هایی که اجرای دائمی نیاز ندارند، انتخابی مناسب محسوب می‌شود.

ساخت اولین Function در AWS Lambda

برای آشنایی با نحوه کار AWS Lambda، یک Function ساده ایجاد می‌کنیم که پس از فراخوانی، یک پیام JSON برمی‌گرداند. این مثال ساده است، اما مراحل اصلی کار با Lambda را نشان می‌دهد.

ابتدا وارد AWS Management Console شوید و از بخش Lambda روی Create function کلیک کنید. در صفحه ایجاد Function، گزینه Author from scratch را انتخاب کرده و موارد زیر را مشخص کنید:

• Function name: hello-lambda
• Runtime: Python 3.14 (یا جدیدترین نسخه موجود)
• Execution role: ایجاد یک نقش جدید با دسترسی‌های پیش‌فرض

پس از ایجاد Function، ویرایشگر کد AWS نمایش داده می‌شود. کد پیش‌فرض را با نمونه زیر جایگزین کنید:

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "body": "Hello from AWS Lambda!"
    }

در این کد، lambda_handler نقطه ورود (Entry Point) برنامه است. هر بار که Lambda اجرا شود، AWS دو پارامتر در اختیار این تابع قرار می‌دهد:

• event شامل اطلاعات رویدادی است که باعث اجرای Function شده است.
• context اطلاعاتی درباره محیط اجرا، زمان باقی‌مانده و شناسه درخواست را در اختیار برنامه قرار می‌دهد.

پس از ذخیره تغییرات، روی Deploy کلیک کنید تا نسخه جدید Function منتشر شود.

اکنون می‌توانید بدون نیاز به ساخت API یا سرویس دیگر، Function را آزمایش کنید. از تب Test یک Test Event جدید ایجاد کرده و آن را اجرا کنید. اگر همه چیز به‌درستی انجام شده باشد، نتیجه‌ای مشابه زیر مشاهده خواهید کرد:

{
  "statusCode": 200,
  "body": "Hello from AWS Lambda!"
}

با همین چند مرحله، اولین Function شما روی زیرساخت AWS اجرا شده است، بدون اینکه ماشین مجازی ایجاد کرده باشید، وب‌سروری نصب کرده باشید یا تنظیمات مربوط به مقیاس‌پذیری را انجام داده باشید. در ادامه، این Function را به یک API واقعی متصل می‌کنیم تا از طریق درخواست‌های HTTP نیز قابل دسترسی باشد.

اتصال AWS Lambda به API Gateway

تا اینجا Function را به‌صورت مستقیم از داخل کنسول AWS اجرا کردیم. اما در بسیاری از پروژه‌ها، هدف این است که کاربران یا سایر سرویس‌ها بتوانند از طریق یک درخواست HTTP این Function را فراخوانی کنند. این وظیفه بر عهده Amazon API Gateway است.

API Gateway درخواست‌های HTTP را دریافت می‌کند، آن‌ها را به Lambda ارسال می‌کند و پاسخ Function را دوباره به کلاینت برمی‌گرداند. به این ترتیب، Function شما مانند یک API معمولی در دسترس خواهد بود.

برای اتصال Lambda به API Gateway مراحل زیر را انجام دهید:

1. وارد صفحه Function در AWS Lambda شوید.
2. از بخش Add Trigger، گزینه API Gateway را انتخاب کنید.
3. یک API جدید از نوع HTTP API یا REST API ایجاد کنید.
4. تنظیمات را ذخیره کرده و Trigger را اضافه کنید.

پس از انجام این مراحل، AWS یک آدرس عمومی در اختیار شما قرار می‌دهد. با ارسال درخواست به این آدرس، Function اجرا شده و پاسخ آن بازگردانده می‌شود.

برای مثال، اگر آدرس API به شکل زیر باشد:

https://example.execute-api.us-east-1.amazonaws.com/

با ارسال یک درخواست ساده:

GET https://example.execute-api.us-east-1.amazonaws.com/

پاسخی مشابه زیر دریافت خواهید کرد:

{
  "statusCode": 200,
  "body": "Hello from AWS Lambda!"
}

در پروژه‌های واقعی، API Gateway امکانات بیشتری نیز در اختیار شما قرار می‌دهد، از جمله تعریف مسیرهای مختلف (Routes)، استفاده از متدهای HTTP مانند GET و POST، اعتبارسنجی درخواست‌ها، احراز هویت، محدود کردن تعداد درخواست‌ها (Rate Limiting) و انتشار نسخه‌های مختلف API. به همین دلیل، ترکیب API Gateway و AWS Lambda یکی از رایج‌ترین الگوها برای ساخت APIهای Serverless محسوب می‌شود.

مزایا و معایب Serverless

مانند هر معماری دیگری، Serverless نیز نقاط قوت و محدودیت‌های خود را دارد. انتخاب این معماری زمانی منطقی است که مزایا و معایب آن با نیازهای پروژه هم‌خوانی داشته باشد.

یکی از مهم‌ترین مزایای Serverless این است که توسعه‌دهنده زمان خود را صرف مدیریت زیرساخت نمی‌کند و می‌تواند روی توسعه قابلیت‌های برنامه تمرکز داشته باشد. همچنین مقیاس‌پذیری خودکار باعث می‌شود سرویس بتواند بدون نیاز به پیکربندی دستی، افزایش یا کاهش ترافیک را مدیریت کند.

در مقابل، این معماری همیشه بهترین انتخاب نیست. برای مثال، Cold Start می‌تواند در برخی سناریوها باعث افزایش زمان پاسخ اولین درخواست شود. همچنین اگر پروژه به اجرای طولانی‌مدت، کنترل کامل روی سیستم‌عامل یا پیکربندی‌های خاص نیاز داشته باشد، استفاده از سرورهای سنتی یا کانتینرها گزینه مناسب‌تری خواهد بود.

به همین دلیل، Serverless را نباید جایگزین همه مدل‌های استقرار دانست؛ بلکه باید آن را ابزاری دانست که در شرایط مناسب، توسعه و نگهداری نرم‌افزار را ساده‌تر و سریع‌تر می‌کند.

منظور از Cold Start چیست؟

یکی از مفاهیم مهم در Serverless، به‌خصوص در AWS Lambda، موضوع Cold Start است. این اتفاق زمانی رخ می‌دهد که یک Function برای اولین بار یا پس از مدتی عدم استفاده اجرا می‌شود.

در این حالت، ارائه‌دهنده سرویس باید یک محیط اجرای جدید برای Function ایجاد کند، کد را در آن بارگذاری کند و سپس درخواست را اجرا کند. این فرآیند باعث می‌شود اولین اجرای Function کمی کندتر از حالت عادی باشد.

در مقابل، زمانی که Function به‌تازگی اجرا شده یا در حالت آماده (Warm) قرار دارد، درخواست‌ها بدون این مرحله اولیه پردازش می‌شوند و سرعت پاسخ‌گویی بالاتر است.

به‌طور خلاصه:

• Cold Start: ایجاد محیط اجرا + بارگذاری کد + اجرای Function = زمان پاسخ بیشتر

• Warm Start: استفاده از محیط آماده = زمان پاسخ کمتر

این موضوع عمدتا در سرویس‌هایی که ترافیک کم یا نامنظم دارند بیشتر دیده می‌شود. در پروژه‌های واقعی، برای کاهش اثر Cold Start از روش‌هایی مثل نگه‌داشتن Function در حالت گرم (Provisioned Concurrency) یا طراحی معماری مناسب استفاده می‌شود.

Serverless برای چه پروژه‌هایی مناسب است؟

Serverless زمانی بیشترین ارزش را ایجاد می‌کند که برنامه از رویدادها (Events) تشکیل شده باشد یا حجم درخواست‌ها در طول زمان ثابت نباشد. در چنین شرایطی، اجرای خودکار Functionها و مقیاس‌پذیری لحظه‌ای می‌تواند هزینه و پیچیدگی مدیریت زیرساخت را کاهش دهد.

از رایج‌ترین کاربردهای Serverless می‌توان به موارد زیر اشاره کرد:

• REST API و Backend سرویس‌های وب و موبایل
• Webhook برای دریافت رویداد از سرویس‌هایی مانند GitHub یا Stripe
• پردازش فایل پس از آپلود در فضای ذخیره‌سازی ابری
• اجرای Jobهای زمان‌بندی‌شده (Cron Jobs)
• پردازش پیام از Queueها و سیستم‌های Event-Driven
• پردازش داده در پروژه‌های IoT و تحلیل لاگ‌ها

در مقابل، برخی پروژه‌ها گزینه مناسبی برای Serverless نیستند. برای مثال، برنامه‌هایی که به اجرای مداوم و طولانی‌مدت نیاز دارند، سرویس‌هایی که اتصال دائمی مانند WebSocket برقرار می‌کنند یا نرم‌افزارهایی که به کنترل کامل روی سیستم‌عامل و سخت‌افزار وابسته هستند، معمولا عملکرد بهتری روی سرورهای سنتی یا کانتینرها دارند.

به بیان ساده، هرچه برنامه بیشتر بر پایه رویدادها و درخواست‌های مستقل طراحی شده باشد، احتمال اینکه Serverless انتخاب مناسبی برای آن باشد نیز بیشتر است.

Serverless یا سرور سنتی؟

انتخاب بین Serverless و سرورهای سنتی بیشتر از آنکه یک انتخاب فنی صرف باشد، به نوع پروژه و الگوی ترافیک آن وابسته است. هر دو مدل مسئله را حل می‌کنند، اما با رویکردهای کاملا متفاوت.

در سرورهای سنتی، یک ماشین (یا کانتینر) همیشه در حال اجرا است. توسعه‌دهنده مسئول نصب، نگهداری، مقیاس‌پذیری و مانیتورینگ آن است. این مدل کنترل کامل می‌دهد، اما هزینه و پیچیدگی نگهداری را نیز به همراه دارد.

در مقابل، Serverless این مسئولیت‌ها را به ارائه‌دهنده سرویس منتقل می‌کند. کد فقط هنگام نیاز اجرا می‌شود و زیرساخت به‌صورت خودکار مدیریت می‌شود. این تفاوت، در عمل روی هزینه، مقیاس‌پذیری و سرعت توسعه اثر مستقیم دارد.

در عمل، انتخاب بین این دو مدل همیشه صفر و یکی نیست. بسیاری از سیستم‌های مدرن از ترکیب هر دو استفاده می‌کنند، برای مثال، بخش APIها روی Serverless اجرا می‌شود، در حالی که سرویس‌های پردازش سنگین یا Real-time روی سرورهای اختصاصی یا کانتینرها قرار دارند.

در نتیجه، Serverless را باید به‌عنوان یک ابزار در کنار سایر معماری‌ها دید، نه جایگزینی کامل برای آن‌ها.

جمع‌بندی

Serverless یک مدل اجرایی است که تمرکز را از مدیریت زیرساخت به سمت توسعه منطق برنامه منتقل می‌کند. در این معماری، کد به‌صورت Functionهای مستقل اجرا می‌شود و تنها در زمان وقوع رویداد فعال می‌گردد.

AWS Lambda یکی از شناخته‌شده‌ترین پیاده‌سازی‌های این مدل است که همراه با سرویس‌هایی مانند API Gateway امکان ساخت APIهای مقیاس‌پذیر بدون مدیریت سرور را فراهم می‌کند.

این معماری برای پروژه‌های رویدادمحور، APIهای سبک، پردازش‌های کوتاه‌مدت و سیستم‌هایی با ترافیک متغیر انتخاب مناسبی است. با این حال، در سناریوهایی که نیاز به اجرای طولانی‌مدت یا کنترل کامل روی محیط وجود دارد، مدل‌های سنتی همچنان گزینه بهتری هستند.