چرا هزینههای ابری از کنترل خارج میشوند؟
بیشتر تیمهای فنی وقتی قبض ماهانه سرویس ابری را میبینند، متعجب میشوند که چرا مبلغ نهایی چند برابر برآورد اولیه است. پاسخ تقریباً همیشه یکسان است: منابعی که خریداری شدهاند اما استفاده نمیشوند، سرویسهایی که بزرگتر از نیاز واقعی انتخاب شدهاند، و نبود سیستمی برای پایش مداوم مصرف. در این مقاله، بهجای توصیههای کلی، سه اقدام مشخص برای کاهش هزینه ابری ارائه میکنیم که میتوانید همین امروز اجرا کنید.
نکته مهم این است که کاهش هزینه به معنای فدا کردن کارایی نیست. برعکس، با حذف منابع بلااستفاده و تنظیم اندازه درست، معمولاً عملکرد بهتری هم دریافت میکنید. بیایید قدمبهقدم پیش برویم.
گام اول: شناسایی منابع بلااستفاده
بیشترین هدررفت هزینه در فضای ابری مربوط به منابعی است که روزها یا هفتهها بدون استفاده روشن ماندهاند. این منابع شامل ماشینهای مجازی خاموش نشده، دیسکهای اورجینال (Snapshot) قدیمی، و IPهای عمومی بدون کاربرد هستند.
ماشینهای مجازی خاموش اما روشن
در بسیاری از تیمها، توسعهدهندهای یک سرور آزمایشی بالا میآورد و بعد از اتمام کار، فراموش میکند آن را خاموش کند. این سرور کوچک شاید ماهانه ۵ تا ۱۰ دلار هزینه داشته باشد، اما اگر چند نمونه از این دست داشته باشید، رقم قابل توجهی میشود.
برای شناسایی این منابع، اگر از OpenStack یا سرویسهای مبتنی بر آن استفاده میکنید، میتوانید با دستور زیر لیست همه نمونهها را همراه با وضعیت و زمان ساخت ببینید:
openstack server list --all-projects --long -c ID -c Name -c Status -c Createdخروجی این دستور به شما نشان میدهد کدام نمونهها هفتهها پیش ساخته شدهاند و هنوز در وضعیت ACTIVE هستند. برای نمونههایی که بیش از ۳۰ روز بدون تغییر ماندهاند، بررسی کنید که آیا واقعاً به آنها نیاز دارید.
اشتباه رایج: خیلی از افراد فکر میکنند خاموش کردن ماشین مجازی هزینه را حذف میکند. در حالی که در اکثر سرویسهای ابری، دیسک متصل به ماشین همچنان هزینه دارد. پس اگر سروری را خاموش میکنید، حتماً دیسک را هم جدا کنید یا کل نمونه را حذف کنید.
Snapshotهای قدیمی و دیسکهای بدون استفاده
Snapshotها ابزار مفیدی هستند، اما اگر هر روز از یک سرور snapshot بگیرید و فقط آخرینها را نگه دارید، هزینه ذخیرهسازی به سرعت بالا میرود. یک snapshot از یک دیسک ۱۰۰ گیگابایتی، ماهانه حدود ۲ دلار هزینه دارد. ده تا از اینها میشود ۲۰ دلار در ماه که فقط برای چیزی است که هیچکس از آن استفاده نمیکند.
برای مشاهده لیست snapshotها در OpenStack:
openstack image list --private -c ID -c Name -c Createdقانون پیشنهادی: فقط ۳ snapshot آخر از هر سرور را نگه دارید و بقیه را حذف کنید. برای اتوماسیون این کار، میتوانید یک اسکریپت cron بنویسید که snapshotهای قدیمیتر از ۷ روز را به صورت خودکار حذف کند.
IPهای عمومی بدون استفاده
هر IP عمومی که به هیچ منبعی متصل نیست، هزینه ماهانه دارد. برای پیدا کردن این IPها:
openstack floating ip list --status DOWNاین دستور IPهایی را نشان میدهد که به هیچ نمونهای متصل نیستند. اگر IP خاصی را برای استفاده آینده نگه داشتهاید، بهتر است آن را رها کنید و بعداً در صورت نیاز، IP جدید بگیرید. هزینه نگهداری یک IP بلااستفاده معمولاً بیشتر از دردسر گرفتن دوباره آن است.
گام دوم: اندازهگذاری درست سرویسها
بعد از حذف منابع بلااستفاده، نوبت به تنظیم اندازه سرویسهایی میرسد که فعال هستند اما بزرگتر از نیاز واقعی انتخاب شدهاند. این مشکل اغلب از ترس کمبود منابع ایجاد میشود: کسی یک سرور با ۸ هسته و ۱۶ گیگابایت رم میگیرد، در حالی که میانگین مصرف CPU آن زیر ۲۰٪ است.
پایش مصرف به مدت یک هفته
قبل از هر تغییری، باید دادههای واقعی مصرف را جمعآوری کنید. اگر از Prometheus و Grafana استفاده میکنید، میتوانید معیارهای زیر را برای هر سرور بررسی کنید:
- میانگین مصرف CPU در بازههای ۵ دقیقهای
- حداکثر مصرف RAM در طول روز
- مصرف I/O دیسک و پهنای باند شبکه
اگر سیستم پایش ندارید، میتوانید از دستور sar در لینوکس استفاده کنید. ابتدا باید آن را فعال کنید:
sudo apt install sysstat
sudo systemctl enable sysstat
sudo systemctl start sysstatبعد از یک هفته، دادههای جمعآوری شده را با دستور زیر مشاهده کنید:
sar -u -f /var/log/sysstat/sa$(date +%d --date='7 days ago')این دستور میانگین مصرف CPU را برای هر روز نشان میدهد. اگر مصرف CPU در تمام هفته زیر ۳۰٪ بوده، به این معنی است که سرور شما حداقل یک اندازه کوچکتر میتواند کار کند.
انتخاب اندازه مناسب
وقتی دادهها را دارید، قانون سادهای را دنبال کنید: اندازهای را انتخاب کنید که حداکثر مصرف واقعی شما، حدود ۷۰ تا ۸۰ درصد ظرفیت آن باشد. این فاصله اطمینان (Headroom) برای نوسانات ناگهانی کافی است، بدون اینکه هزینه اضافی بپردازید.
مثال: اگر سرور فعلی شما ۴ هسته و ۸ گیگابایت رم دارد و میانگین مصرف CPU آن ۱۵٪ و حداکثر مصرف RAM آن ۲ گیگابایت است، یک نمونه با ۲ هسته و ۴ گیگابایت رم انتخاب مناسبی است. این تغییر معمولاً هزینه را ۴۰ تا ۵۰ درصد کاهش میدهد.
اشتباه رایج: فقط به CPU توجه نکنید. اگر برنامه شما حافظهمحور است (مثل دیتابیسهای درونحافظهای)، کاهش RAM میتواند باعث استفاده از Swap و افت شدید کارایی شود. همیشه RAM را بر اساس حداکثر مصرف واقعی تنظیم کنید، نه میانگین.
استفاده از Auto Scaling برای نوسانات
اگر مصرف شما در طول روز نوسان دارد (مثلاً ساعات کاری شلوغ و شب خلوت)، بهجای خرید یک سرور بزرگ برای همیشه، از قابلیت Auto Scaling استفاده کنید. این قابلیت به شما اجازه میدهد در ساعات شلوغی، نمونههای بیشتری بالا بیاورید و در ساعات خلوت، آنها را خاموش کنید.
در OpenStack، میتوانید از Heat برای تعریف سیاستهای مقیاسپذیری استفاده کنید. یک مثال ساده:
heat stack-create -f autoscaling.yaml -P image=ubuntu-22.04 -P flavor=m1.small my-stackفایل autoscaling.yaml باید شامل تعریف گروه نمونهها و سیاستهای افزایش/کاهش بر اساس معیارهای CPU باشد. این کار باعث میشود در ساعات خلوت، هزینه به حداقل برسد.
گام سوم: پایش مستمر و بودجهبندی
بهینهسازی یکباره کافی نیست. اگر سیستم پایش و هشدار نداشته باشید، بعد از چند ماه دوباره هزینهها به همان وضعیت قبل برمیگردد. پایش مستمر، بخش جداییناپذیر کاهش هزینه ابری است.
تنظیم هشدارهای بودجه
بیشتر سرویسهای ابری امکان تعیین سقف هزینه و هشدار دارند. اگر از OpenStack استفاده میکنید، میتوانید از سرویس Ceilometer برای جمعآوری دادههای مصرف و تعریف هشدار استفاده کنید:
ceilometer alarm-threshold-create --name cpu-high --description "CPU usage high" --meter-name cpu_util --threshold 80 --comparison-operator gt --period 600 --statistic avg --evaluation-periods 3 --alarm-action 'log://'این دستور یک هشدار تعریف میکند که اگر میانگین مصرف CPU در سه بازه ۱۰ دقیقهای بالای ۸۰٪ باشد، یک رویداد ثبت میشود. میتوانید بهجای log:// از آدرس وبهوک برای ارسال اعلان به تلگرام یا ایمیل استفاده کنید.
گزارشگیری هفتگی
یک گزارش هفتگی از مصرف منابع تهیه کنید و آن را در جلسه تیم فنی بررسی کنید. این گزارش باید شامل موارد زیر باشد:
- لیست نمونههای فعال و هزینه هر کدام
- میانگین مصرف CPU و RAM برای هر نمونه
- تعداد snapshotها و حجم کل آنها
- IPهای عمومی بدون استفاده
برای تولید خودکار این گزارش، میتوانید از OpenStack CLI و یک اسکریپت ساده bash استفاده کنید که هر هفته اجرا میشود و خروجی را به صورت فایل HTML یا متن در ایمیل ارسال میکند.
بررسی دورهای با تیم
حداقل ماهی یکبار، یک جلسه ۳۰ دقیقهای برای بررسی هزینهها بگذارید. در این جلسه، هر کدام از اعضای تیم باید توضیح دهد که چرا هر سروری که مسئول آن است، هنوز فعال است. این کار ساده، تأثیر شگفتانگیزی در کاهش هزینهها دارد، چون افراد مجبور میشوند درباره ضرورت هر منبع فکر کنند.
جمعبندی و اقدامات فوری
برای شروع کاهش هزینه ابری در زیرساخت خود، این سه اقدام را همین امروز انجام دهید:
- لیست همه نمونههای فعال را بگیرید و نمونههایی که بیش از ۳۰ روز بدون تغییر ماندهاند را بررسی و حذف کنید.
- برای ۵ سرور اصلی خود، مصرف یک هفتهای را پایش کنید و اندازهای را که با حداکثر مصرف واقعی همخوانی دارد انتخاب کنید.
- یک هشدار بودجه تنظیم کنید و گزارش هفتگی مصرف را به ایمیل تیم فنی ارسال کنید.
این سه اقدام به تنهایی میتواند هزینه ماهانه زیرساخت شما را ۳۰ تا ۵۰ درصد کاهش دهد، بدون اینکه تأثیری بر کارایی سرویسها داشته باشد. به یاد داشته باشید که بهینهسازی یک فرآیند مداوم است، نه یک پروژه یکباره. هر ماه ۳۰ دقیقه وقت بگذارید و منابع خود را مرور کنید.
اگر به دنبال زیرساختی هستید که ابزارهای پایش و مدیریت مصرف را به صورت یکپارچه ارائه دهد، سرویسهای ابری ServerNet میتوانند گزینه مناسبی باشند. اما فارغ از انتخاب سرویسدهنده، اصولی که در این مقاله بررسی کردیم در هر پلتفرم ابری قابل اجرا هستند.
دیدگاهها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!