چطور هزینهٔ زیرساخت استارتاپ را کم کنیم بدون این‌که سرویس کند شود

هزینهٔ زیرساخت معمولاً از کجا نشت می‌کند؟

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

نکتهٔ مهم این است که کاهش هزینه با «ارزان‌تر خریدن» شروع نمی‌شود؛ با «دیدن» شروع می‌شود. تا وقتی ندانید هر ریال صرف چه منبعی می‌شود و آن منبع چقدر واقعاً استفاده می‌شود، هر تصمیمی برای کاهش هزینه شبیه حدس است. و حدس در زیرساخت معمولاً به یکی از دو نتیجه می‌رسد: یا هزینهٔ اضافه، یا سرویس کند و ناراضی شدن کاربران.

منابع رایج نشت هزینه

سرورهای فراموش‌شدهstaging و دموهای بی‌استفاده

پلن بزرگ‌تر از نیازخرید بر اساس حدس، نه داده

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

دیسک پر از بکاپ و لاگبدون سیاست نگهداری

گام اول: مصرف واقعی را اندازه بگیرید

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

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

گام دوم: منابع بیکار و فراموش‌شده را حذف کنید

محیط‌های staging که ماه‌هاست کسی به آن‌ها سر نزده، سرورهای دمو برای مشتری‌ای که قرارداد را امضا نکرد، دیسک‌های اضافه‌ای که بعد از حذف سرور باقی مانده‌اند و IPهای رزروشدهٔ بی‌استفاده، نمونه‌های رایج منابع فراموش‌شده‌اند. برای هر منبع یک مالک مشخص تعیین کنید و یک قانون ساده بگذارید: هر منبعی که مالک ندارد یا مالکش نمی‌تواند کاربردش را توضیح دهد، پس از بکاپ گرفتن خاموش می‌شود.

نام‌گذاری منظم هم کمک بزرگی است. اگر نام سرور شامل پروژه، محیط و مالک باشد، مثلاً shop-staging-ali، در بازبینی ماهانه به‌سرعت می‌فهمید چه چیزی لازم است و چه چیزی نیست. این عادت کوچک، هزینهٔ تصمیم‌گیری را تقریباً صفر می‌کند.

گام سوم: برای کارهای موقت سرور ساعتی بگیرید

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

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

کار موقت روی سرور ماهانه یا ساعتی

سرور ماهانه

• هزینهٔ روزهای بیکاری
• مناسب سرویس همیشه روشن
• فراموش شدن آسان

در برابر

سرور ساعتی

• پرداخت فقط برای مدت استفاده
• مناسب تست، دمو و ساخت
• حذف پس از پایان کار

گام چهارم: ترافیک خروجی را با کش و CDN کم کنید

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

پیش از CDN، بهینه‌سازی ساده هم اثر دارد: فشرده‌سازی متن با gzip یا brotli، تبدیل تصاویر به فرمت‌های سبک‌تر و تنظیم هدرهای کش. روش فعال‌سازی فشرده‌سازی در مقالهٔ gzip و brotli در Nginx و راهکارهای کاهش هزینهٔ پهنای باند در مقالهٔ کاهش هزینهٔ پهنای باند با CDN آمده است. برای مقایسهٔ پلن‌های CDN کلودیفای هم به صفحهٔ CDN سر بزنید.

گام پنجم: اندازهٔ سرور را با داده تنظیم کنید

کوچک‌سازی سرور، پس از جمع‌آوری داده، کم‌خطرترین راه صرفه‌جویی است. اگر سروری در اوج مصرف هم به نیمی از ظرفیت CPU و رم نمی‌رسد، احتمالاً پلن کوچک‌تر کافی است. اما چند نکته را فراموش نکنید: رم را بر اساس مصرف بدون کش بسنجید، برای رشد چندماههٔ آینده حاشیه بگذارید و پیش از کوچک‌سازی، از سرور بکاپ یا اسنپ‌شات بگیرید.

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

گام ششم: بکاپ، لاگ و دیسک را مدیریت کنید

فضای دیسک یکی از منابعی است که بی‌صدا پر می‌شود. لاگ‌هایی که چرخش ندارند، بکاپ‌هایی که هرگز پاک نمی‌شوند و ایمیج‌های قدیمی داکر می‌توانند شما را به خرید دیسک بزرگ‌تر وادار کنند. یک سیاست نگهداری ساده تعریف کنید: مثلاً بکاپ روزانه برای یک هفته، هفتگی برای یک ماه و ماهانه برای چند ماه. لاگ‌ها را با logrotate بچرخانید و ایمیج‌های بی‌استفادهٔ داکر را به‌صورت دوره‌ای پاک کنید.

اگر سرور با خطای پر شدن دیسک مواجه شد، روش پیدا کردن فایل‌های حجیم و آزادسازی فضا در مقالهٔ خطای No space left on device آمده است. این کار گاهی نیاز به ارتقای دیسک را کاملاً از بین می‌برد.

چرخهٔ ماهانهٔ کاهش هزینه

گام هفتم: لوکیشن را بر اساس مخاطب انتخاب کنید

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

برخی تیم‌ها معماری ترکیبی را انتخاب می‌کنند: سرور اصلی نزدیک مخاطب و سرور کمکی برای کارهایی که به منابع بین‌المللی نیاز دارند. این ترکیب اغلب هم سریع‌تر و هم اقتصادی‌تر از یک سرور بزرگ در یک لوکیشن است.

یک عادت ماهانه برای همیشه

کاهش هزینه یک پروژهٔ یک‌باره نیست. ماهی یک بار، نیم ساعت وقت بگذارید و فهرست منابع را با صورت‌حساب مقایسه کنید. هر منبع جدیدی که اضافه شده، مالک و کاربرد دارد؟ مصرف سرورها نسبت به ماه قبل چه تغییری کرده؟ آیا سرور موقتی هست که باید حذف می‌شد؟ همین بازبینی منظم، از تکرار نشت‌های قدیمی جلوگیری می‌کند و به تیم کمک می‌کند بودجه را برای رشد واقعی محصول نگه دارد.

سؤالات متداول