چطور از GreenOps برای بهره‌وری عملیاتی‌ و هم زمان نجات زمین استفاده کنیم؟

نکات کلیدی

• زیرساخت‌های ما علاوه بر هزینه اقتصادی، هزینه زیست‌محیطی هم دارند؛ بخش IT به‌تنهایی مسئول ۱.۴٪ از انتشار کربن در سراسر جهان است.

• فهمیدن اثر نرم‌افزارمان بر محیط‌زیست نیازمند یک رویکرد آگاه از کربن (carbon-aware) است.

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

• با یک افزونه ساده Kubernetes مثل kube-green، می‌توانید منابع cloud را آگاهانه‌تر استفاده کنید، و بدون این‌که لازم باشد روی معماری سیستم‌ها اثر بگذارید، اولین گام را به سمت توسعه سبزتر سیستم‌ها بردارید.

• FinOps و GreenOps مفاهیمی نزدیک به هم هستند؛ مدیریت آگاهانه منابع cloud روی هزینه‌ها هم اثر می‌گذارد. این روزها، ابزارهای FinOps مثل OpenCost با اندازه‌گیری انتشارهای زیرساختی ما یکپارچه شده‌اند و یک نمای کلی جامع فراهم می‌کنند.

بخش فناوری اطلاعات و ارتباطات به‌تنهایی حدود ۱.۴٪ از انتشارهای کلی جهانی را تولید می‌کند. این برابر است با حدود ۱.۶ میلیارد تُن انتشار گازهای گلخانه‌ای تخمینی، که باعث می‌شود هر کدام از ما کاربران اینترنت مسئول حدود ۴۰۰ کیلوگرم دی‌اکسید کربن در سال باشیم.

اثر زیست‌محیطی سیستم‌هایمان را بفهمیم

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

وقتی درباره «کربن» صحبت می‌کنیم، منظورمان همه چیزهایی است که به گرم‌شدن جهانی کمک می‌کنند. برای اندازه‌گیری این، از اصطلاحاتی مثل CO2eq استفاده می‌کنیم، که به ما می‌گوید چه مقدار دی‌اکسید کربن آزاد می‌شود و «شدت کربن» (carbon intensity) اندازه می‌گیرد چه مقدار کربن برای هر واحد برق مصرف‌شده آزاد می‌شود.

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

برای سبزتر کردن نرم‌افزار، می‌توانیم روی سه چیز تمرکز کنیم: کم‌کردن مصرف انرژی، بالا بردن آگاهی درباره انتشار کربن، و استفاده از سخت‌افزار کارآمدتر.

برای کم کردن انتشار کربن بدون کم کردن مصرف واقعی انرژی زیرساخت‌مان، دسترسی به داده‌های شدت کربن دیتاسنترها ضروری است. این اجازه می‌دهد یک راهبرد جابه‌جایی مکانی یا زمانی (spatial یا temporal shifting) راه‌اندازی کنیم، و بنابراین استفاده از منابع انرژی تجدیدپذیر را هرجا که در دسترس هستند در اولویت قرار دهیم.

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

زامبی‌ها واقعی‌اند، و درست آن نزدیکی‌اند

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

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

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

همه‌شان را بکشید و سیاره را نجات دهید

فرض کنید به‌صورت فرضی یک حالت ایده‌آل تنظیم کنیم که همه محیط‌ها تعداد یکسانی pod در حال اجرا روی همان زیرساخت دارند با یک تقاضای محاسباتی ثابت و هم‌پوشان. می‌توانیم ادعا کنیم که با فعال نگه داشتن دائمی محیط‌های توسعه و staging حتی خارج از ساعت‌های کاری، داریم برای ۱۲۸ ساعت از مجموع ۱۶۸ ساعت در هفته منابع بیشتری از آن‌چه لازم است استفاده می‌کنیم، که برابر است با تقریباً ۱۰۳٪ استفاده بیشتر از چیزی که واقعاً مورد نیاز است. به عبارت دیگر، با فعال نگه داشتن همیشگی محیط‌های توسعه و staging، مهندسان عملاً فقط حدود ۲۳٪ از مصرف واقعی آن‌ها را استفاده مفید می‌کنند.

با این مثال ساده، روشن است که مقدار منابعی که شرکت‌های مهندسی هر روز هدر می‌دهند چقدر قابل‌توجه است. خوشبختانه، درمان این موضوع چیزی بیشتر از چند خط پیکربندی و نصب یک Kubernetes operator روی کلاسترهایمان نمی‌خواهد. kube-green یک add-on برای Kubernetes است که وقتی نصب شود، به شما اجازه می‌دهد منابع Kubernetes را وقتی نیاز نیستند به‌صورت خودکار خاموش کنید و وقتی نیاز هستند دوباره آن‌ها را روشن کنید، همه به‌صورت خودکار تنها با پیکربندی کردن CRD به نام SleepInfo.

با فقط چند خط پیکربندی مثل آن‌هایی که در تصویر قبلی هستند، می‌توانید تعریف کنید که همه فاصله‌ نام‌ها روی کلاستر که kube-green دارند فقط از دوشنبه تا جمعه و فقط در ساعت‌های ۸ صبح تا ۸ شب در منطقه زمانی Rome در دسترس باشند.

با نسخه فعلی kube-green، هم استقرارها و هم CronJobs قابل مدیریت هستند، اما با نسخه بعدی همه منابع Kubernetes پشتیبانی خواهند شد.

در مورد استقرارها، برای متوقف کردن منبع، ReplicaSet روی صفر تنظیم می‌شود و سپس برای راه‌اندازی مجدد به مقدار قبلی‌اش برگردانده می‌شود. برعکس، برای معلق کردن CronJobs، آن‌ها به‌عنوان معلق علامت‌گذاری می‌شوند.

در پیکربندی‌های SleepInfo، همچنین می‌توانید منابعی را مشخص کنید که نباید معلق شوند، مثل “my-deployment” در پیکربندی نمونه‌ای که بالاتر ارائه شده است.

داده، نه فقط کلمات: یک گزارش استفاده واقعی از kube-green در دنیای واقعی

پیکربندی زیر از kube-green استفاده شد تا ۴۸ تا از ۷۵ namespace خارج از ساعت‌های کاری معلق شوند، در حالی که همه استقرارهایی با نام api-gateway فعال نگه داشته شدند.

یک کلاستر با این اندازه، که بدون kube-green کار می‌کند، به‌طور متوسط ۱۰۵۰ pod را مدیریت می‌کند با مقدار منابع تخصیص‌یافته برابر با ۷۵ GB حافظه و ۴۵ CPU. از نظر مصرف واقعی منابع، کلاستر مصرف ۴۵ GB حافظه و ۴.۵ CPU را ثبت می‌کند، و تقریباً ۲۲۲ کیلوگرم CO2 در هفته به محیط‌زیست منتشر می‌کند.

با پیکربندی SleepInfo روی این کلاستر، می‌توانیم تعداد کل podها را ۶۰۰ تا کم کنیم، و آن را به ۴۵۰ برسانیم. حافظه تخصیص‌یافته به ۳۰ GB کاهش می‌یابد، و CPUها به فقط ۱۵ کاهش می‌یابد. با kube-green، همچنین کاهش در مصرف منابع هم داریم، با کاهش مصرف حافظه به ۲۱ GB و کاهش CPUها به ۱، که به انتشار تقریباً ۱۳۹ کیلوگرم CO2 منجر می‌شود.

استفاده از kube-green روی این کلاستر در طول هفته مطالعه منجر شد به این‌که تقریباً ۸۳ کیلوگرم CO2eq کمتر به محیط‌زیست منتشر شود، که ۳۸٪ کمتر از چیزی است که تحت شرایط عادی منتشر می‌کردیم. این اعداد وقتی برای کل سال برون‌یابی شوند حتی چشمگیرتر می‌شوند، و به حدود ۴۰۰۰ کیلوگرم CO2eq کمترِ منتشرشده به‌واسطه استفاده ساده از kube-green منجر می‌شود.

برای این‌که تصویر واضح‌تر شود، این کاهش معادل انتشار کربنِ یک خودروی متوسط است که تقریباً ۱۶٬۰۰۰ کیلومتر سفر کند.

در این مورد استفاده مشخص، همان‌طور که توسط snapshotهای متریک‌های مصرف منابع نشان داده شده است، استفاده از kube-green اجازه داده کاهش قابل‌توجهی در بهره‌برداری منابع رخ دهد، که امکان downscaling تعداد نودها در کلاستر را فراهم می‌کند. به‌طور متوسط، ۴ نود در طول شب و آخر هفته‌ها متوقف می‌شوند، که هر کدام اندازه‌ای برابر با ۲ هسته CPU و ۸ GB حافظه دارند.

این چندین مزیت می‌آورد، نه فقط کاهش انتشار CO2 بلکه صرفه‌جویی هزینه‌ای مستقیم و متناسب برای کلاستر ما. این به این دلیل است که ساختار قیمت‌گذاری کلاسترها در ارائه‌دهندگان اصلی cloud معمولاً بر اساس تعداد نودهای استفاده‌شده است. با scale down کردن تعداد نودها وقتی نیاز نیستند، ما عملاً هزینه اجرای کلاستر را کاهش می‌دهیم.

آینده kube-green

پروژه kube-green دائماً در حال تکامل است، و همان‌طور که قبلاً اشاره شد، ما همین حالا داریم روی بهبودهایی کار می‌کنیم که kube-green را ابزار بهتری می‌کند، و امیدواریم که دنیا را هم جای بهتری کند.

در انتشار بعدی kube-green، همه منابع موجود در Kubernetes پشتیبانی خواهند شد. به‌جای این‌که مستقیماً روی منابع مشخص عمل شود، امکان تعریف قوانین برای زمان‌بندی خاموش‌کردن و احتمالاً روشن‌کردن هر منبع در زمان‌های تعریف‌شده وجود خواهد داشت.

با این بسته‌ها، پشتیبانی kube-green محدود به فقط استقرار‌ها و CronJobs نخواهد بود، بلکه به ReplicaSets، Pods، StatefulSets، و هر CRD سفارشی دیگری هم گسترش خواهد یافت.

ما در حال آزمایش راهکارهایی هستیم که به kube-green اجازه می‌دهند با operatorهای دیگر مثل Crossplane تعامل کند. این امکان می‌دهد خاموش‌کردن و روشن‌کردن دوباره کل قطعه‌های زیرساخت که از طریق این ابزار مدیریت می‌شوند زمان‌بندی شود.

هر کسی که می‌خواهد دیدگاه‌هایش را به اشتراک بگذارد یا مستقیماً با ایده، کد، یا محتوا به پروژه کمک کند می‌تواند به مخزن در GitHub نگاه کند یا مستقیماً با ما تماس بگیرد.

منابع‌تان را آگاهانه مصرف کنید: آن‌چه را نیاز دارید، وقتی نیاز دارید نگه دارید

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

GreenOps اجازه می‌دهد با اثر ناچیز روی معماری‌هایمان، اثر مثبت قابل‌توجهی روی محیط‌زیست داشته باشیم. با حداقل تلاش اضافی، می‌توانیم مطمئن شویم کلاسترهای ما منابع را خیلی کارآمدتر و بدون اتلاف استفاده می‌کنند.

با رویکردهای مدرن، می‌توانیم راهبرد GreenOps خود را پیاده‌سازی کنیم بدون این‌که مدیریت حجم کارهایمان را به‌طور شدید تغییر دهیم، در حالی که هم‌زمان اثرات مثبت روی هزینه‌های زیرساخت‌مان به دست می‌آوریم. GreenOps و FinOps مفاهیم به‌شدت مرتبطی هستند، و اغلب، منطقی‌سازی منابع از منظر پایداری به صرفه‌جویی روی صورتحساب‌های cloud ما منجر می‌شود.

برای گرفتن تصمیم‌های آگاهانه، ضروری است دیدپذیری نسبت به هر دو مورد داشته باشیم: هزینه‌های کلاسترهایمان و انتشارهای CO2eq آن‌ها به محیط‌زیست. به همین دلیل، بسیاری از ابزارهای پایش هزینه، مثل OpenCost، رهگیری انتشارِ هزینه کربن را در سراسر Kubernetes و هزینه‌کرد cloud معرفی کرده‌اند.

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