Прискорення стійкої модернізації за допомогою Green IT Analyzer на AWS – блог IBM

Підприємства все більше використовують робочі навантаження з великим об’ємом даних, зокрема високопродуктивні обчислення, штучний інтелект (AI) і машинне навчання (ML). Ці технології стимулюють інновації в їх гібридних багатохмарних подорожах, зосереджуючись на стійкості, продуктивності, безпеці та відповідності. Компанії також прагнуть збалансувати ці інновації з дедалі більшими екологічними, соціальними та управлінськими нормами (ESG). Для більшості організацій ІТ-операції та модернізація є частиною їх мети ESG, і відповідно нещодавнє опитування Foundry, приблизно 60% організацій шукають постачальників послуг, які спеціалізуються на зелених технологіях.

Оскільки звітність про викиди вуглецю стає загальноприйнятою в усьому світі, IBM прагне допомагати своїм клієнтам у прийнятті обґрунтованих рішень, які можуть допомогти задовольнити їхні потреби в енергії та відповідний вплив викидів вуглецю, одночасно зменшуючи витрати. Щоб допомогти у створенні більш стійких ІТ-майданчиків, IBM співпрацює з Amazon Web Services (AWS) для сприяння стабільній модернізації хмарних технологій.

Оскільки компанії прискорюють свою ІТ-модернізацію, щоб прискорити цифрову трансформацію та отримати переваги для бізнесу, з’являється значна можливість. Ця можливість передбачає перебудову ІТ-середовища та портфоліо додатків у бік екологічніших і екологічніших проектів. Такий підхід не тільки сприяє економічній ефективності, але й сприяє досягненню ширших корпоративних цілей сталого розвитку.

Розуміння викидів вуглецю від цифрових технологій

Усі бізнес-програми, створені та запущені IBM, як для зовнішніх, так і для внутрішніх клієнтів, постачаються з a вартість вуглецю, що в першу чергу пов’язано зі споживанням електроенергії. Незалежно від технології, яку IBM використовувала для розробки цих програм або послуг, для їх роботи потрібне апаратне забезпечення, яке споживає енергію.
Викиди вуглекислого газу (CO2), які виробляються мережею електроенергії, відрізняються залежно від методів виробництва. Викопне паливо, таке як вугілля та газ, викидає значну кількість вуглецю, тоді як відновлювані джерела, такі як вітер або сонце, викидають незначну кількість. Таким чином, кожен кіловат (кВт) спожитої електроенергії безпосередньо впливає на певну кількість еквіваленту CO2 (CO2e), що викидається в атмосферу.

Таким чином, зменшення споживання електроенергії безпосередньо призводить до зниження викидів вуглецю.

Вуглецевий слід на практиці

Обчислювальна техніка, сховище й мережа є основними технологічними ресурсами, які споживають енергію в процесі створення програм і послуг. Їхня діяльність потребує активного охолодження та керування просторами центрів обробки даних, у яких вони працюють. Як охоронці стійких ІТ-практик, ми повинні розглянути, як ми можемо зменшити споживання ресурсів у своїй щоденній діяльності.

Центри обробки даних отримують електроенергію від мережі, яка живить їх робочий регіон. Ця потужність керує різноманітним ІТ-обладнанням, таким як сервери, мережеві комутатори та сховища, які, у свою чергу, підтримують програми та послуги для клієнтів. Ця потужність також керує допоміжними системами, такими як опалення, вентиляція та кондиціонування повітря або охолодження, які є важливими для підтримки середовища, яке зберігає апаратне забезпечення в робочих межах.

Шлях вперед до декарбонізації

Модернізація програм стає ключовим для стимулювання інновацій і трансформації бізнесу. IBM Consulting® застосовує структуру AWS Well-Architected для створення Custom Lens for Sustainability для проведення оцінки робочого навантаження для додатків як локально, так і в AWS Cloud. Щоб прочитати про інші ключові сценарії та початкові точки IBM Consulting® Custom Lens for Sustainability, перегляньте публікацію в блозі: Ефективна модернізація додатків за допомогою AWS Cloud.

У цьому дописі в блозі ми докладно аналізуємо, щоб оцінити, реалізувати рекомендації та проаналізувати вплив монолітної програми, що працює на AWS, на викиди вуглецю через призму екологічності.

Green IT Analyzer: комплексна платформа декарбонізації ІТ

Платформа Green IT Analyzer дозволяє клієнтам перетворити свої традиційні ІТ на більш енергоефективні, екологічно чисті ІТ. Виконуючи функцію єдиного центру, він вимірює, звітує, створює базові показники та надає уніфіковану панель керування вуглецевим слідом у гібридному хмарному середовищі, включаючи приватні центри обробки даних, загальнодоступну хмару та пристрої користувачів. Платформа може вимірювати вуглецевий слід ІТ-сфери як на рівні деталізації, так і на рівні віртуальної машини (VM). Це допомагає визначити гарячі точки енергії або вуглецю для розробки дорожньої карти оптимізації. Техніка оцінки вуглецю, яку він використовує, відповідає парниковий газ (ПГ) принципи для сектору інформаційних і комунікаційних технологій.

Методологія на основі місцезнаходження

Щоб зрозуміти викиди вуглецю від ІТ-робочих навантажень, потрібно ознайомитись із кількома ключовими поняттями та показниками. Ось огляд високого рівня:

• Вуглецевий слід (CFP): Концепція вуглецевого сліду є центральною для нашого аналізу. CFP представляє загальну кількість CO₂ та еквівалентні викиди ПГ, пов’язані з живленням центру обробки даних, починаючи з базового вимірювання CFP, що перевищує або дорівнює нулю. Це важливий показник для оцінки впливу роботи центру обробки даних на навколишнє середовище.
• Ефективність енергоспоживання (PUE): Іншим важливим показником є ​​ефективність використання енергії. PUE вимірює енергоефективність центру обробки даних, розраховану шляхом ділення загальної енергії об’єкта на енергію, споживану ІТ-обладнанням. Цей розподіл дає коефіцієнт, який вказує на ефективність: PUE, близький до 1 (одиниці), означає високу ефективність, тоді як більш високі значення вказують на більші витрати енергії.
  Формула: PUE = (загальна енергія об’єкта)/(енергія, споживана ІТ-обладнанням)
• Інтенсивність вуглецю (CI): Нарешті, ми розглядаємо інтенсивність вуглецю. CI вимірює викиди вуглецю в грамах на кіловат-годину (г/кВт-год) від виробництва електроенергії, яка живить центр обробки даних. Цей показник залежить від джерела енергії. Мережі, що працюють на вугіллі, можуть мати КІ більше 1,000 г/кВт-год, тоді як мережі, що живляться від відновлюваних джерел, таких як вітер і сонце, повинні мати КІ ближче до нуля. (Сонячні батареї мають деяку кількість CFP, але набагато менше порівняно з викопним паливом.)

Давайте розглянемо головне завдання клієнта. Кожна організація прагне досягти нульових викидів, і ІТ відіграють вирішальну роль у досягненні плану сталого розвитку. Це може включати зменшення вуглецевого сліду самого ІТ-майну — особливо актуально для фінансових клієнтів із високим рівнем викидів ІТ-або створення стійкої платформи, яка працює на екологічно чистих ІТ.

Старі монолітні програми, які зазвичай працюють на платформах на основі віртуальних машин у локальних центрах обробки даних або публічних хмарах, є ключовою сферою уваги. Виникає важливе питання: як ми можемо зменшити споживання ІТ-ресурсів цими старими монолітними програмами, які зазвичай займають 20–30% усього ІТ-портфоліо? Енергоефективніше переходити від монолітних програм на основі ВМ до більш енергоефективної архітектури на основі мікросервісів, що працює на контейнерній платформі. Однак важливо оцінювати кожен випадок окремо, оскільки універсальний підхід не завжди ефективний.

Ці критерії можна використовувати для вибору кандидатів на трансформацію програми:

• Програми з більш ніж 70% -80% Утилізація процесора

• Програми відчувають сезонні сплески під час транзакцій, наприклад, у переддень Різдва, Дівалі та інші державні свята

• Програми з щоденні сплески транзакцій у певний час, наприклад, посадка на борт авіакомпанії рано вранці чи ввечері

• Деякі бізнес-компоненти в рамках монолітних програм, які демонструють стрибки використання

Аналіз стану монолітних програм

Розглянемо приклад простої програми e-Store, що працює на AWS у віртуальній машині Elastic Compute Cloud (EC2). Ця програма, e-CART, зазнає сезонних навантажень і була повторно розміщена (підйомно-зміщена) з локальної на примірник AWS EC2. Такі монолітні програми, як цей, об’єднують усі бізнес-функції в єдиний блок, який можна розгортати.

У наступній таблиці описано ключові характеристики застарілих програм e-Store.

Викиди вуглецю під час робочого навантаження безпосередньо пов’язані зі споживанням таких ресурсів, як обчислювальна техніка, сховище та мережа, причому обчислення часто є найважливішим фактором. Це залежить від характеристик робочого навантаження; наприклад, у медіа чи потоковій індустрії передача даних через мережу та зберігання великих неструктурованих наборів даних споживає значну енергію.

На графіку показано схему використання ЦП, коли мінімальна активність користувача відбувається в монолітній програмі, що працює в одному екземплярі EC2.

Ми використали платформу Green IT Analyzer, щоб провести вуглецевий облік поточного стану монолітної програми, порівнюючи його з цільовим станом тієї самої програми після перетворення на архітектуру мікросервісу, що працює на Amazon Elastic Kubernetes Services (EKS) платформи.

Крок 1: Комплексний аналіз вуглецевого сліду монолітних застосувань

По-перше, ми зосереджуємось на вивченні поточного вуглецевого сліду монолітного робочого навантаження за різних умов експлуатації. Це дає нам базову лінію для визначення областей для покращення.

Давайте розрахуємо приблизний вуглецевий слід для нашого монолітного робочого навантаження, коли у нас є мінімальні транзакції користувачів і 45% використання ЦП:

• PUE зі сходу США 1d AZ: 1.2
• CI: 415.755 грам CO2/кВт-год

A. Приблизний обчислення вуглецю за відсутності активності користувача:

• Споживана енергія: 9.76 г/Вт при 45% використання
• Години роботи при такому ж навантаженні: 300 год
• Розрахункові викиди вуглецю за 300 годин = PUE × CI × енергія, споживана робочим навантаженням
• = [(1.2 × 415.755 × 9.76) × 300] ÷ 1,000 = 1,460.79 грам CO2e

B. Приблизні викиди вуглецю з 500 одночасними користувачами:

У сценарії, коли транзакції пікового рівня створювалися відповідно до нефункціональних вимог (NFR), щоб перевірити здатність системи підтримувати щоденні піки, використання ЦП зросло до 80% під час одночасної активності користувача. Ця ситуація ініціювала правило автоматичного масштабування, налаштоване на активацію при 80% завантаженні ЦП. Правило передбачає додаткові віртуальні машини, щоб гарантувати, що навантаження на кожну віртуальну машину залишається нижче 60%. Тоді балансувальник навантаження ефективно розподіляє навантаження між існуючими та новими віртуальними машинами.

Завдяки автоматичному масштабуванню нових екземплярів EC2 стала доступною додаткова віртуальна машина t2.large, що призвело до падіння середнього використання до 40%.

• Розрахункові викиди вуглецю для цього сценарію, коли обидві ідентичні віртуальні машини працюють протягом 300 годин = PUE × CI × енергія, споживана робочим навантаженням
• = {[(1.2 × 415.755 × 9.76) × 300] × 2} ÷ 1,000 = 2,921.59 грам CO2e

Крок 2: Реалізація рекомендацій щодо сталого розвитку

На цьому етапі досліджується низка рекомендацій щодо сталого розвитку та їх практичне впровадження для монолітного застосування. Ми використовуємо оцінку Custom Lens для стійкості, щоб керувати цими рекомендаціями.

По-перше, ми розглядаємо декомпозицію монолітних програм на реактивні мікросервіси на основі дії. Цей підхід адаптовано до сезонної поведінки програми та різноманітних моделей використання, що особливо корисно в періоди піку, наприклад у святкові сезони, коли трафік зростає та спостерігається зосередження на перегляді артефактів, а не на внутрішніх транзакціях.

По-друге, план передбачає зменшення споживання енергії шляхом планування пакетної обробки в періоди простою, особливо коли мережа центру обробки даних працює на екологічно чистій енергії. Цей підхід спрямований на економію енергії шляхом мінімізації тривалості довгострокових транзакцій.

Нарешті, стратегія підкреслює важливість вибору гнучкої платформи, такої як AWS EKS або Red Hat® OpenShift® на AWS (ROSA), яка здатна динамічно масштабувати ресурси на основі мережевого трафіку. Такий вибір платформи допомагає забезпечити оптимізований розподіл ресурсів і є вигідним для розміщення реактивних мікросервісів на основі дій.

Підводячи підсумок, можна сказати, що запропоновані стратегії включають декомпозицію мікросервісів, узгоджену з шаблонами використання, енергоощадне планування транзакцій і вибір гнучкої платформи для підвищення ефективності додатків і використання ресурсів.

Програма, перетворена на мікросервіси, показана на зображенні:

Тепер давайте розрахуємо викиди вуглецю після трансформації монолітної програми в архітектуру на основі мікросервісів, дотримуючись принципів екологічного дизайну, одночасно рефакторинг програми під егідою сталої модернізації.

A. Розрахунковий облік вуглецю без або з невеликими навантаженнями:

• Робочий вузол: 2 × t2.середній
• Завантаження: 10% (при відсутності навантаження на додаток)
• Споживана енергія: 6 г/Вт при 5% використанні
• ПУЕ (1.2) і КІ (415.755 грам CO₂/кВт-год) залишаються незмінними, оскільки ми продовжуємо використовувати ту саму зону доступності.
• Годинники: 300
• Розрахункові викиди вуглецю за 300 годин = PUE × CI × енергія, споживана робочим навантаженням
• = [(1.2 × 415.755 × 6) × 300] ÷ 1,000 = 1,796 грам CO₂e

Спостереження: Коли система не навантажена, програма, що працює на віртуальній машині, є більш ефективною, ніж мікросервіси, що працюють на кластері EKS.

B. Розрахунковий облік вуглецю під час пікового навантаження:

Подібно до навантажувального тестування монолітних програм, ми включили 500 користувачів і запустили одночасні транзакції, щоб відповідати вимогам NFR у створених нами мікросервісах.

• Робочий вузол: 2 × t2.середній
• Підвищене використання через навантаження: від 10% до 20%
• Споживана енергія: 7.4 г/Вт при 20% використанні
• ПУЕ і КІ залишаються колишніми.
• Годинники: 300
• Розрахункові викиди вуглецю за 300 годин = PUE × CI × енергія, споживана робочим навантаженням
• = [(1.2 × 415.755 × 7.4) × 300] ÷ 1,000 = 2,215.14 грам CO₂e

Тут відбулося автоматичне масштабування пакетів для служб інтерфейсу користувача, але послуги кошика не потребували додаткових ресурсів для масштабування. У монолітних програмах необхідне масштабування всієї платформи незалежно від того, які бізнес-функції чи послуги вимагають більше ресурсів, що призводить до збільшення використання на 20%.

Спостереження: Давайте порівняємо обидва сценарії.

1. Коли система неактивна або має постійний профіль навантаження протягом годинника: Коли навантаження майже відсутнє, монолітні програми споживають менше ресурсів і майже викидають 18% менше вуглецю, ніж програми на основі мікросервісів, розміщені в кластері EKS.
2. Коли система працює на повному або змінному навантаженні: Коли система перебуває на повному навантаженні, є a 24% зниження CO₂ викиди на платформі Kubernetes порівняно з робочим навантаженням на основі віртуальної машини. Це пов’язано з використанням меншої кількості ядер і нижчим використанням. Ми можемо перемістити більше робочих навантажень в одному кластері та звільнити більше ядер від інших програм, щоб отримати значніші переваги.

Цей сценарій є прикладом того, як IBM^® Спеціальна оцінка сталого розвитку на робочому навантаженні AWS допомагає розробити шлях сталої модернізації та зменшити загальний вуглецевий слід вашої ІТ-сфери.

Інструкція до дій

Для організацій, які цінують сталість, відповідальне обчислення та екологічні ІТ не просто життєво важливі; вони цілком здійсненні. ІТ-лідери можуть досягти цих цілей, займаючись екологічно чистою діяльністю, яка охоплює ІТ-стратегію, операції та платформи.

• Озеленення ваших ІТ-платформ: Використовуйте рефакторинг для переміщення програм у публічну хмару. Перенесення робочих навантажень у загальнодоступну хмару без їх оптимізації для цього середовища може збільшити експлуатаційні витрати та знизити стійкість. Натомість покращте робочі навантаження, щоб вони були більш інтегрованими у хмару, рефакторингуючи програми на основі таких факторів, як їх життєвий цикл, частота оновлення та розгортання, а також критичність для бізнесу.
• Оптимізація неактивної ємності віртуальної машини та інших невикористаних хмарних ресурсів: увімкніть спостереження на рівні інфраструктури для виявлення неактивних віртуальних машин у вашій ІТ-сфері. Запровадьте автоматизацію на основі правил, щоб вживати коригувальних дій, наприклад видаляти неактивні віртуальні машини та пов’язані з ними ресурси, які більше не обслуговують бізнес-функції. Крім того, оптимізуйте розмір віртуальної машини на основі мережевого трафіку за допомогою автоматичного масштабування.
• Створення ресурсів за потреби: Хоча хмарні ресурси є еластичними, ви отримуєте обмежену ефективність, якщо розгортаєте робочі навантаження на фіксовані ресурси, які працюють безперервно, незалежно від використання. Визначте можливості надання та видалення ресурсів за потреби, наприклад використання планування віртуальної машини або еластичних функцій у хмарних службах.
• Контейнерне робоче навантаження: Використовуючи контейнерну платформу замість традиційного середовища віртуальної машини, ви можете скоротити річні витрати на інфраструктуру до 75%. Контейнерні платформи дозволяють ефективно планувати контейнери в кластері віртуальних машин на основі їхніх вимог до ресурсів.
• Модернізація ваших монолітних програм до архітектури на основі мікросервісів: Виберіть реактивні мікросервіси відповідно до ваших потреб: реактивні мікросервіси для виклику на основі подій для оптимізації використання ресурсів, керовані подіями мікросервіси для асинхронного виклику або мікросерверні мікросервіси для виконання однієї функції на основі потреб.

Структура IBM Consulting Green IT Transformation, Custom Lens for Sustainability і платформа Green IT Analyzer спільно допомагають клієнтам на шляху декарбонізації. Обидва фреймворки допомагають оцінити робоче навантаження, визначити важелі оптимізації, які можуть знизити споживання енергії, і створити дорожню карту модернізації додатків, яка дозволить вам досягти своїх цілей сталого розвитку.

Дізнайтеся більше про послуги IBM Consulting для AWS Cloud.