پاسخ کوتاه
VPS داکر باید مجموع limit سرویس‌ها، فضای Image و Volume، I/O دیتابیس و حاشیه Restart هم‌زمان را پوشش دهد.
کانتینرها منابع را ایجاد نمی‌کنند؛ بدون limit یک سرویس می‌تواند RAM یا CPU میزبان را مصرف کند. فضای /var/lib/docker و Logها نیز باید ظرفیت و Rotation داشته باشند.
چرا یک عدد ثابت جواب نمی‌دهد؟
دو برنامه با تعداد کاربر برابر می‌توانند منابع کاملاً متفاوتی بخواهند. Cache، تعداد Request هم‌زمان، Query، اندازه پاسخ، Job پس‌زمینه و درصد نوشتن در دیتابیس روی مصرف اثر می‌گذارند. بنابراین «بازدید ماهانه» یا نام Framework به‌تنهایی ورودی خوبی برای خرید نیست.
هدف باید تجربه کاربر و پایداری باشد: p95 زمان پاسخ، نرخ خطا، زمان Queue، ظرفیت Connection و زمان بازیابی. منابع وسیله رسیدن به این هدف‌اند، نه خود هدف.
بار کاری خود را توصیف کنید
یک روز عادی و یک ساعت پیک را جدا بنویسید. تعداد Request، کاربر هم‌زمان، حجم و رشد داده، نسبت خواندن به نوشتن، Jobهای زمان‌بندی‌شده و Dependencyهای خارجی را مشخص کنید. همچنین معلوم کنید چه مقدار قطعی قابل قبول است.
اگر سرویس موجود دارید، حدس نزنید؛ حداقل یک هفته متریک بگیرید. اگر پروژه جدید است، با سناریوی کوچک Load test و فرضیات صریح شروع کنید تا بعداً بتوانید آن‌ها را با داده واقعی جایگزین کنید.
منابع را چطور کنار هم ببینیم؟
CPU سریع برای کار تک‌رشته‌ای، Core بیشتر برای کار موازی، RAM برای Working set و Cache، دیسک کم‌تأخیر برای I/O و شبکه مناسب برای کاربر و Dependency لازم است. گلوگاه یکی از این‌ها می‌تواند بقیه منابع آزاد را بی‌اثر کند.
- برای چند سرویس کوچک 2–4 vCPU و 4–8 GB نقطه شروع رایج است.
- Volume دیتابیس روی دیسک کم‌تأخیر باشد.
- Memory limit و healthcheck برای سرویس‌ها تعریف کنید.
نقطه شروع و روش اندازه‌گیری
مصرف هر Container را با docker stats اندازه بگیرید، limit و reservation تعیین و حداقل ۲۰ درصد ظرفیت آزاد برای Pull و Restart نگه دارید.
پلنی انتخاب کنید که Resize آن روشن و کم‌ریسک باشد. پس از راه‌اندازی، CPU هر Core، available memory و Swap، latency دیسک، Connectionها و p95 پاسخ را در پیک ثبت کنید. عدد شروع حکم نهایی نیست؛ یک فرض مهندسی قابل آزمون است.
Load test درست چه شکلی است؟
سناریو باید رفتار واقعی را تقلید کند: ترکیب Endpointها، Login، Cache warm/cold، خواندن و نوشتن و زمان فکر کاربر. افزایش بار را مرحله‌ای انجام دهید و نقطه‌ای را ثبت کنید که latency یا error به‌سرعت رشد می‌کند.
تست را روی Production فعال و بدون سقف اجرا نکنید. داده آزمایشی، محدودیت نرخ، پنجره مشخص و مانیتورینگ کامل لازم است. نتیجه باید علاوه بر حداکثر ظرفیت، حاشیه امن و رفتار زمان خرابی Dependency را نشان دهد.
هزینه واقعی و قابلیت اطمینان
قیمت پلن فقط بخشی از هزینه است. Backup، ترافیک خروجی، IP، License، مانیتورینگ، زمان نگهداری و هزینه قطعی را هم حساب کنید. گاهی دو سرور متوسط با Failover از یک سرور بسیار بزرگ ارزش عملیاتی بیشتری دارند.
همچنین دامنه خرابی را بشناسید. چند ماشین روی یک میزبان، چند دیسک در یک Array یا Backup در همان حساب ممکن است ظاهراً چند نسخه باشند اما از یک حادثه مشترک آسیب ببینند.
چه زمانی ارتقا یا مهاجرت کنیم؟
اگر در چند پیک متوالی CPU یا I/O اشباع، available memory کم، Swap فعال، Queue رو به رشد یا p95 خارج از هدف دارید و بهینه‌سازی واضحی باقی نمانده، ارتقا منطقی است. برای بار فصلی، مقیاس‌پذیری موقت ممکن است بهتر از خرید ظرفیت دائمی باشد.
پیش از مهاجرت، Benchmark مقصد، روش انتقال داده، زمان همگام‌سازی، TTL، Cutover و Rollback را آزمایش کنید. تصمیم ظرفیت بدون برنامه مهاجرت می‌تواند ریسک بیشتری از کمبود فعلی ایجاد کند.
اشتباه رایج
محاسبه RAM فقط از جمع مصرف عادی، بدون درنظرگرفتن Build، Restart و Page Cache، در زمان استقرار OOM ایجاد می‌کند.
منابع بیشتر می‌توانند یک Query بد، Memory leak یا معماری تک‌نقطه‌ای را مدتی پنهان کنند؛ اما مشکل را حذف نمی‌کنند. هزینه را فقط وقتی بالا ببرید که داده نشان دهد گلوگاه واقعاً همان منبع است.
پرسش‌های مهمی که قبل از اقدام باید جواب دهید
برای اینکه پاسخ «برای Docker چه VPSی مناسب است؟» فقط در حد اطلاعات عمومی نماند، ابتدا وضعیت فعلی خود را با عدد توصیف کنید: نسخه سیستم‌عامل یا نرم‌افزار، تعداد کاربر هم‌زمان، مصرف معمول و اوج منابع، حجم و رشد داده، محدودیت شبکه و بیشترین قطعی قابل قبول. بدون این اطلاعات ممکن است توصیه‌ای که از نظر فنی درست است، برای محیط شما انتخاب مناسبی نباشد.
دو سؤال بعدی مستقیماً از نکات این موضوع می‌آیند: «برای چند سرویس کوچک 2–4 vCPU و 4–8 GB نقطه شروع رایج است.» در زیرساخت شما چگونه اندازه‌گیری یا تأیید می‌شود؟ و «Volume دیتابیس روی دیسک کم‌تأخیر باشد.» چه اثری روی کاربر، هزینه یا مسیر بازیابی دارد؟ پاسخ را در قالب شواهدی مانند خروجی فرمان، نمودار متریک، نتیجه آزمون یا مستند ارائه‌دهنده ثبت کنید؛ اتکا به حافظه و حدس برای تصمیم عملیاتی کافی نیست.
یک برنامه عملی کم‌ریسک
کار را با ثبت وضعیت فعلی و یک معیار موفقیت آغاز کنید. سپس پیشنهاد اصلی این راهنما را در کوچک‌ترین محیط نماینده اجرا کنید: مصرف هر Container را با docker stats اندازه بگیرید، limit و reservation تعیین و حداقل ۲۰ درصد ظرفیت آزاد برای Pull و Restart نگه دارید. نتیجه را در حالت عادی و در یک سناریوی خطا یا فشار کنترل‌شده بسنجید. اگر معیار بهتر نشد، به‌جای افزودن تغییرات بیشتر، فرض اولیه را بازبینی کنید.
پیش از اعمال تغییر در سرویس اصلی، روش بازگشت، مسئول تصمیم و زمان توقف را روشن کنید. این هشدار را نیز به‌عنوان شرط توقف در نظر بگیرید: محاسبه RAM فقط از جمع مصرف عادی، بدون درنظرگرفتن Build، Restart و Page Cache، در زمان استقرار OOM ایجاد می‌کند. پس از اجرا، نتیجه، نسخه‌ها و تنظیمات مؤثر را مستند کنید و یک زمان بازبینی تعیین کنید؛ تغییر بدون پایش ممکن است امروز سالم به نظر برسد اما در پیک بعدی شکست بخورد.
- برای چند سرویس کوچک 2–4 vCPU و 4–8 GB نقطه شروع رایج است.
- Volume دیتابیس روی دیسک کم‌تأخیر باشد.
- Memory limit و healthcheck برای سرویس‌ها تعریف کنید.
جمع‌بندی و چک‌لیست خرید
برای پاسخ به «برای Docker چه VPSی مناسب است؟» این موارد را کنار هم بگذارید: بار عادی و پیک، معیار latency و خطا، CPU، RAM، I/O، شبکه، رشد داده، Backup، دامنه خرابی، امکان Resize و هزینه کل. با یک نقطه شروع منطقی آغاز کنید و زمان بازبینی را از همان روز اول تعیین کنید.
- برای چند سرویس کوچک 2–4 vCPU و 4–8 GB نقطه شروع رایج است.
- Volume دیتابیس روی دیسک کم‌تأخیر باشد.
- Memory limit و healthcheck برای سرویس‌ها تعریف کنید.