سرور اپلیکیشن چیست؟ مشخصات و قیمت بک اند اپ در 2026

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

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

سرور برای اپلیکیشن = آشپزخانه پشت ویترین اپ شما

سرور اپلیکیشن چگونه ارزیابی می‌شود؟

آنچه درباره سرور اپلیکیشن چگونه ارزیابی می‌شود ضرورت دارد، در همین قسمت واکاوی می‌شود.

وقتی کاربر در اپ دکمه «ثبت سفارش» را می‌زند، اپ یک درخواست HTTPS به API می‌فرستد. API درخواست را اعتبارسنجی می‌کند، اطلاعات را در پایگاه داده می‌نویسد، در صورت احتیاج صف پیام یا سرویس تسویه را صدا می‌زند و پاسخی بیشتر وقت‌ها در قالب JSON برمی‌گرداند. همه این مراحل روی سرور بک‌اند اتفاق می‌افتد.

بک‌اند اپلیکیشن را مانند آشپزخانه یک رستوران مدنظر قرار دهید. اپ روی گوشی ویترین و گارسون است که سفارش را می‌گیرد؛ API پیشخوان تحویل سفارش است، پایگاه داده انبار مواد اولیه و کش قفسه‌ای کنار دست آشپز که پرمصرف‌ترین مواد را دم دست نگه می‌دارد. چنانچه آشپزخانه کوچک باشد، ویترین هرچقدر هم زیبا باشد، مشتری منتظر می‌ماند.

اجزای اصلی بک‌اند اپلیکیشن: نکته فنی: API بی وضعیت (Stateless) چنانچه API اطلاعات نشست کاربر را در حافظه همان سرور نگه ندارد و آن را در Redis یا توکن امضاشده بگذارد، بعدها قادر هستید بی بازنویسی کد، چندین نمونه از API را پشت لود بالانسر اجرا کنید. این تصمیم آسان در روز اول، مقیاس‌پذیری آینده را به‌طور چشمگیری آسان‌تر می‌کند.

• API: برنامه‌ای که با Node.js، Laravel، Django، Go یا زبان دیگری نوشته می‌شود و به درخواست‌های اپ پاسخ می‌دهد.
• پایگاه داده: PostgreSQL، MySQL یا MongoDB برای حفظ حساب‌ها، سفارش‌ها و محتوا؛ برای برگزیدن سخت‌افزار آن، راهنمای سرور پایگاه داده و گزینش رم و NVMe را ببینید.
• کش: Redis داده‌های پرتکرار را در حافظه نگه می‌دارد تا پایگاه داده کمتر درگیر شود؛ در نوشته Redis چیست مزایای آن را بخوانید.
• صف و Workerها: کارهای زمان‌بر مانند ارسال اعلان، ایمیل یا پردازش تصویر را از مسیر پاسخ‌گویی به کاربر جدا می‌کنند.
• ذخیره‌سازی فایل: تصاویر پروفایل، ویدیو و فایل‌های آپلودی کاربران که بیشتر وقت‌ها بیشترین حجم را دارند.
• سرویس اعلان (Push): بر پایه معماری رسمی Firebase Cloud Messaging، سرور شما پیام را به FCM می‌دهد و FCM آن را از لایه انتقال اندروید یا سرویس APNs اپل به دستگاه می‌رساند.

اپلیکیشن سرور چه پیش‌نیازهایی دارد؟

اصطلاح «اپلیکیشن سرور» (Application Server) در دنیای نرم‌افزار به لایه‌ای میانی گفته می‌شود که کد برنامه را اجرا می‌کند؛ مانند WildFly یا Apache Tomcat برای برنامه‌های جاوا. در مقابل، وقتی از سرور برای اپلیکیشن موبایل صحبت می‌کنیم، منظور سرور فیزیکی یا مجازی‌ای است که همه این نرم‌افزارها روی آن نصب می‌شوند. به بیان ساده، اپلیکیشن سرور مستأجر است و سرور، ساختمان.

چرا اپ شما به سرور بک‌اند مستقل نیازمند است؛ پاسخ کوتاه چیست؟

شماری از تیم‌ها کار را با سرویس‌های آماده بک‌اند (BaaS) آغاز می‌کنند. این سرویس‌ها برای نمونه اولیه سریع‌اند، ولی با رشد اپ، داشتن سرور مستقل این برتری را به همراه دارد:

کنترل تمام‌عیار پشته نرم‌افزاری: ویرایش زبان برنامه‌نویسی، پایگاه داده و پیکربندی سیستم‌عامل را خودتان برمی‌گزینید. کارایی قابل پیش‌بینی: روی سرور اختصاصی، منابع با مشتری دیگری تقسیم نمی‌شود و زمان پاسخ API در ساعات اوج ثابت‌تر می‌ماند. قیمت قابل برنامه‌ریزی: بار مالی منابع پردازشی با رشد شمار درخواست‌ها خودبه‌خود بالا نمی‌رود؛ تنها ترافیک مصرفی را جداگانه زیر نظر بگیرید. مالکیت داده: داده کاربران روی زیرساختی می‌ماند که خودتان کنترل می‌کنید.

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

چنانچه بین این دو مدل مردد هستید، نوشته تفاوت سرور ابری و اختصاصی معیارهای برگزیدن را کنار هم گذاشته است.

نگاهی دقیق به منابع لازم برای API و

برای تصمیم‌گیری بهتر، نخست منابع لازم برای API را دقیق‌تر می‌شناسیم.

• CPU (CPU): بیشتر APIها به ورودی و خروجی (I/O) وابسته‌اند و وقتشان صرف انتظار برای پایگاه داده می‌شود، ولی پردازش تصویر، رمزنگاری و تولید گزارش CPU چشمگیری می‌خواهد. در Node.js هر فرایند کد جاوااسکریپت را روی یک رشته اصلی اجرا می‌کند؛ پس برای بهره‌گیری از همه هسته‌ها ضروری است چندین نمونه از API را هم‌زمان اجرا کنید.
• رم (RAM): رم بین API، کش و پایگاه داده تقسیم می‌شود. اسناد فنی PostgreSQL برای سرور اختصاصی پایگاه داده با 1GB رم یا بیشتر، میزان اولیه shared_buffers را 25% حافظه توصیه می‌کند و می‌گوید بعید است تخصیص بیش از 40% نتیجه بهتری بدهد؛ چون PostgreSQL به کش سیستم‌عامل هم متکی است. Redis هم داده‌هایش را در رم نگه می‌دارد و لازم است برایش سقف حافظه تعیین کنید.
• دیسک و ذخیره‌سازی: پایگاه داده اپ پر از خواندن و نوشتن‌های کوچک و تصادفی است و این دقیقاً جایی است که NVMe نسبت به هارد مکانیکی و SSD ساتا برتری دارد. فایل‌های کاربران را از پایگاه داده جدا نگه دارید و برایشان نسخه پشتیبان مستقل داشته باشید. تفاوت فناوری‌ها را در سنجش هارد NVMe و SSD ببینید.
• شبکه و پهنای باند: پاسخ‌های JSON حجم کمی دارند، ولی دانلود تصویر و ویدیو، بروزرسانی محتوای درون‌برنامه‌ای و اعلان‌های هم‌زمان برای کاربران زیاد، مصرف شبکه را بالا می‌برند. API عمومی ممکن است مقصود حمله قرار بگیرد؛ پس پورت پرسرعت و حفاظت شبکه را جدی بگیرید و درباره انواع حمله در نوشته حمله DDoS چیست بخوانید.
• جدول مسیر رشد زیرساخت بک‌اند اپلیکیشن: جدول زیر یک الگوی رایج معماری را نشان می‌دهد، نه عدد قطعی. مرز هر مرحله را نتیجه مانیتورینگ و آزمون بار اپ شما تعیین می‌کند.

مقیاس‌پذیری، ایمنی و قیمت سرور؛ آنچه باید بدانید

این قسمت به مقیاس‌پذیری، ایمنی و بها سرور می‌پردازد و نکات کلیدی آن را روشن می‌کند.

مقیاس عمودی یا افقی چگونه ارزیابی می‌شود؟

در مقیاس عمودی (Scale Up) همان سرور را قوی‌تر می‌کنید: رم، هسته یا دیسک بیشتر. این شیوه آسان است و به تغییر کد احتیاج ندارد، ولی سقف دارد. در مقیاس افقی (Scale Out) سرور جدید اضافه می‌کنید و بار را بین آن‌ها تقسیم می‌کنید؛ این مسیر به API بی وضعیت و یک لایه توزیع بار نیازمند است.

بر پایه اسناد فنی Nginx، این نرم‌افزار به‌صورت پیش‌فرض درخواست‌ها را به شیوه Round-robin بین سرورها پخش می‌کند و روش‌های least_conn و ip_hash را هم دارد. با پارامترهای max_fails و fail_timeout، سرور معیوب موقتاً از چرخه خارج می‌شود. برای مفاهیم پایه، نوشته لود بالانسر چیست را بخوانید.

در مقیاس بزرگ‌تر، Kubernetes با HorizontalPodAutoscaler شمار نمونه‌های API را بر اساس مصرف CPU، حافظه یا معیارهای سفارشی تغییر می‌دهد و بر پایه اسناد فنی رسمی، به‌طور پیش‌فرض هر 15 ثانیه معیارها را مرور می‌کند. ولی Kubernetes پیچیدگی عملیاتی چشمگیری دارد و برای بیشتر تیم‌های کوچک، Docker Compose روی یک یا دو سرور بسنده است.

دیتابیس؛ گلوگاه همیشگی: API را شدنی است به‌راحتی تکثیر کرد، ولی پایگاه داده بیشتر وقت‌ها اولین گلوگاه است. سه راه‌حل رایج وجود دارد: کش کردن پاسخ‌های پرتکرار در Redis، افزودن Replica فقط‌خواندنی برای گزارش‌ها و جستجوها، و بهینه‌سازی ایندکس‌ها و کوئری‌ها. ایمنی داده را هم جدی بگیرید؛ ۱۰ اقدام لازم ایمنی دیتابیس نقطه آغاز خوبی است.

ایمنی API: 📚 از منابع معتبر در فهرست OWASP API Security Top 10 ویرایش 2023، رتبه اول به «Broken Object Level Authorization» رسیده است؛ یعنی کاربری بتواند با تغییر شناسه در درخواست، داده کاربر دیگری را ببیند. ریسک «Unrestricted Resource Consumption» هم در همین فهرست آمده و یادآوری می‌کند که نبود محدودیت درخواست، هم قیمت را بالا می‌برد و هم خطر از کار افتادن سرویس را. همه ارتباط‌ها تنها از طریق HTTPS و نسخه‌های به‌روز TLS انجام شود. سطح دسترسی هر endpoint را روی سرور مرور کنید، نه تنها در ظاهر اپ. برای ورود، ارسال کد تأیید و endpointهای پرهزینه محدودیت نرخ درخواست (Rate Limiting) تعریف کنید. کلیدها و رمزها را در متغیرهای محیطی یا ابزار اداره اسرار نگه دارید و هرگز در فایل نصبی اپ قرار ندهید. پایگاه داده و Redis را تنها روی شبکه داخلی قابل استفاده بگذارید، نه روی IP عمومی.

عوامل تعیین‌کننده بار مالی: ◀ گونه سرور: سرور مجازی، ابری یا اختصاصی؛ هرچه منابع اختصاصی‌تر باشد، بار مالی ثابت بالاتر و کارایی قابل پیش‌بینی‌تر است. ◀ شمار سرورها: جداسازی دیتابیس، کش و API قیمت را بالا می‌برد، ولی ریسک خرابی هم‌زمان را کم می‌کند. ◀ ترافیک: حجم تصاویر و ویدیوهایی که کاربران دریافت می‌کنند، اصلی‌ترین عامل مصرف است. ◀ لایسنس‌ها: چنانچه از Windows Server یا نرم‌افزار تجاری بهره‌گیری کنید، به بار مالی اضافه می‌شود. ◀ نیروی فنی: زمان لازم برای نگهداری، مانیتورینگ و بکاپ؛ یا بهره‌گیری از خدمات کانفیگ و اداره سرور.

سرور داخل ایران برای اپ‌های داخلی

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

⚠ محدودیت سرویس‌های خارجی

سرویس‌هایی مانند FCM و APNs یا درگاه‌های تسویه خارجی به ارتباط بین‌الملل نیازمندند. در زمان اختلال، ارسال اعلان از این مسیر ممکن است متوقف شود؛ پس برای پیام‌های حیاتی مانند کد تأیید، مسیر جایگزینی مانند پیامک داخلی به حساب بیاورید.

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

راه‌حل مرحله‌ای است: پایگاه داده به سرور اختصاصی با هارد NVMe منتقل می‌شود، پاسخ endpointهای پرتکرار مانند برگه اصلی در Redis کش می‌شود، ارسال اعلان‌ها به صف با نرخ کنترل‌شده سپرده می‌شود و برای endpointهای حساس محدودیت درخواست تعریف می‌شود. سپس مانیتورینگ منابع ادامه پیدا می‌کند تا گلوگاه بعدی پیش از بحران دیده شود.

سرور HPE ProLiant DL360 Gen9 با دو CPU Xeon E5-2680 v4 (در مجموع ۲۸ هسته و ۵۶ رشته) و 64GB رم Registered ECC DDR4 هارد 1TB NVMe از سری Samsung 980/990 PRO برای دیتابیس‌های پرتراکنش پورت 10Gbit/s روی شبکه‌ای با آپلینک 100Gbit حفاظت DDoS با گنجایش 100Gbit/s، فایروال سخت‌افزاری و ایمنی چندلایه نصب خودکار سیستم‌عامل و تحویل آنی پس از تسویه. کنترل‌پنل کنترل با ری‌استارت، کنسول KVM و نصب مجدد سیستم‌عامل خرید IPv4 اضافه از کنترل‌پنل کاربری و محاسبه ترافیک تنها بر اساس دانلود، با آپلود بدون هزینه مشاوره پیش از خرید با گروه فنی ۲۴ ساعته و واکاوی تنظیم ساختار سفارشی (رم، دیسک یا نسل دیگر) از طریق تیکت یا تماس.

⚠ محدودیت را هم بدانید

CPU Xeon E5-2680 v4 در سه‌ماهه اول 2016 عرضه شده و Intel آن را از 30 ژوئن 2022 در وضعیت پایان به‌روزرسانی‌های سرویس قرار داده است. این سرور برای بیشتر APIها و دیتابیس‌ها بسنده است، ولی چنانچه بار شما به تک‌هسته به‌شدت قوی یا نسل جدیدتر CPU احتیاج دارد، تنظیم ساختار سفارشی از طریق تیکت یا تماس مرور می‌شود.

بیشتر بدانید: آموزش نصب داکر روی اوبونتو 24.04، گزینش سرور سایت پربازدید برای ویرایش وب اپ و برپاسازی میل سرور سازمانی برای ایمیل‌های تأیید و اطلاع‌رسانی

بار مالی سرور برای اپلیکیشن به؛ پاسخ کوتاه چیست؟: به گونه سرور (مجازی، ابری یا اختصاصی)، شمار سرورها، حجم ترافیک، لایسنس نرم‌افزارها و زمان نیروی فنی برای حفظ تابع است. عدد ثابتی نمی‌توان گفت؛ اپی که ویدیو پخش می‌کند با اپ یادداشت‌برداری هم‌اندازه، نیازهای یکسره متفاوتی دارد. برترین روش، آغاز کوچک و رشد منابع بر اساس داده مانیتورینگ است.

درباره برای شروع، سرور مجازی بسنده چه باید دانست؟: برای MVP و ماه‌های اول، سرور مجازی بیشتر وقت‌ها بسنده و به‌صرفه است. وقتی مصرف CPU یا دیسک پایگاه داده در ساعات اوج به سقف می‌رسد یا به منابع ثابت و بی اشتراک احتیاج دارید، زمان مهاجرت پایگاه داده یا کل بک‌اند به سرور اختصاصی رسیده است.

اپلیکیشن سرور چگونه ارزیابی می‌شود؟: اپلیکیشن سرور نرم‌افزاری مانند WildFly یا Apache Tomcat است که کد برنامه‌های جاوا را اجرا می‌کند و روی خود سرور نصب می‌شود. چنانچه بک‌اند شما با Node.js، Laravel یا Django نوشته شده، بیشتر وقت‌ها به آن احتیاج ندارید و محیط اجرای همان زبان بسنده است. خرید جداگانه هم لازم نیست؛ بیشتر این نرم‌افزارها متن‌باز هستند.

امکان دارد بک‌اند اپلیکیشن را روی چه پیش‌نیازهایی دارد؟: برای API آسان PHP ممکن است کار کند، ولی بیشتر وقت‌ها همخوان نیست. میزبانی اشتراکی اجازه اجرای فرایندهای دائمی مانند Node.js، WebSocket یا Workerهای صف را نمی‌دهد، منابع با دیگران مشترک است و دسترسی root ندارید. برای اپ جدی، دست‌کم یک سرور مجازی با دسترسی تمام‌عیار لازم است.

Firebase بهتر؛ پاسخ کوتاه چیست؟: Firebase و سرویس‌های مشابه برای نمونه اولیه سریع‌اند و حفظ سرور ندارند. در مقابل، بار مالی آن‌ها به میزان بهره‌گیری وابسته است، به ارتباط بین‌الملل نیازمندند و کنترل کمتری روی داده می‌دهند. شماری از تیم‌ها از ترکیب هر دو کار می‌کنند: FCM برای اعلان و سرور بک‌اند اختصاصی برای API و پایگاه داده.

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

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

از کجا بفهمم سرور فعلی چه پیش‌نیازهایی دارد؟: چندین نشانه رایج: مصرف CPU یا رم در ساعات اوج نزدیک سقف است، زمان انتظار دیسک (iowait) بالا رفته، کوئری‌های کند در لاگ پایگاه داده زیاد شده و زمان پاسخ API در لحظات شلوغ چندین برابر می‌شود. ابزارهای مانیتورینگ این نشانه‌ها را پیش از شکایت کاربران نشان می‌دهند.

جمع‌بندی؛ بک‌اند اپلیکیشن باثبات با رشد مرحله‌ای زیرساخت: بک‌اند هر اپ موبایل از API، دیتابیس، کش، صف و سرویس اعلان ساخته می‌شود و گزینش سرور برای اپلیکیشن یعنی تأمین منابع صحیح برای همین اجزا. پایگاه داده بیشتر وقت‌ها اولین گلوگاه است؛ پس رم کافی، هارد NVMe و کش Redis بیشترین اثر را روی سرعت اپ دارند. منابع: OWASP API Security Top 10 (2023)؛ NGINX: Using nginx as HTTP load balancer؛ PostgreSQL Documentation: Resource Consumption؛ Kubernetes: Horizontal Pod Autoscaling؛ Firebase Cloud Messaging: FCM architectural overview؛ Docker Docs: What is Docker?.

نکات کلیدی این مطلب

• سرور اپلیکیشن چگونه ارزیابی می‌شود
• منابع لازم برای API
• مقیاس‌پذیری، ایمنی و بها سرور

پرسش‌های پرتکرار

درباره اپلیکیشن سرور چه باید دانست؟

اصطلاح «اپلیکیشن سرور» (Application Server) در دنیای نرم‌افزار به لایه‌ای میانی گفته می‌شود که کد برنامه را اجرا می‌کند؛ مانند WildFly یا Apache Tomcat برای برنامه‌های جاوا. در مقابل، وقتی از سرور برای اپلیکیشن موبایل صحبت می‌کنیم، منظور سرور فیزیکی یا مجازی‌ای است که همه این نرم‌افزارها روی آن نصب می‌شوند. به بیان ساده، اپلیکیشن سرور مستأجر است و سرور، ساختمان.

درباره چرا اپ شما به سرور بک‌اند مستقل احتیاج دارد چه باید دانست؟

شماری از تیم‌ها کار را با سرویس‌های آماده بک‌اند (BaaS) آغاز می‌کنند. این سرویس‌ها برای نمونه اولیه سریع‌اند، ولی با رشد اپ، داشتن سرور مستقل این برتری را به همراه دارد:

درباره مقیاس عمودی یا افقی چه باید دانست؟

در مقیاس عمودی (Scale Up) همان سرور را قوی‌تر می‌کنید: رم، هسته یا دیسک بیشتر. این شیوه آسان است و به تغییر کد احتیاج ندارد، ولی سقف دارد. در مقیاس افقی (Scale Out) سرور جدید اضافه می‌کنید و بار را بین آن‌ها تقسیم می‌کنید؛ این مسیر به API بی وضعیت و یک لایه توزیع بار نیازمند است.

درباره قیمت سرور برای اپلیکیشن به چه باید دانست؟

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