Три причини правильно вкладати спати хмарні сервіси

Привіт, я Антон Грішко, Cloud Architector у Profisea Labs, і ми говоримо про FinOps. Цей новітній підхід управління хмарними середовищами містить ефективні практики, які допомагають бізнесам розуміти витрати на хмару та максимально їх оптимізувати.

При слові «хмара» власники ІТ-інфраструктури, у найкращому випадку, уявляють хмарне середовище, де ідеально налаштовані сервіси працюють як годинник, забезпечуючи швидке зростання бізнесу. Але, на жаль, у більшості випадків як бізнес /IT-менеджери (CTO, CFO, CIO), так і інженери (DevOps, Developers, QA specialists та інші), відчуватимуть гострий головний біль через аномально завищені витрати на хмару і той факт, що робота хмар 24/7 ніяк не зменшує ці самі витрати.

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

Розгляньмо три причини не того, чи це необхідно (думаю, цей момент всім досить зрозумілий), а чому планувати розклад ресурсів потрібно правильно, не витрачаючи купу часу, нервів.

Вони відпочивають, ви економите

Провідні постачальники хмарних послуг (CSPs) стягують плату за фактичну роботу машин, і це означає, що якщо інстанс спить, гроші не витрачаються. Настільки просте і водночас геніальне рішення — планування годин сну для ваших ресурсів, коли вони не використовуються. Принаймні 40% (і навіть більше) ресурсів будь-якої організації, здебільшого виробничі процеси, як-от розробка чи контроль якості, потрібні протягом певних годин дня, тому регулярна робота машин, пов’язаних з цими процесами, буквально викидає гроші у смітник.

Наведемо приклад: усі ваші машини розробки запускалися о 9:00 і зупинялися о 17:00 щодня. В результаті ви отримуєте рахунок лише за 8 годин замість 24 годин. Проста математика! Скажу більше — ці сервіси можна не лише вимикати вночі та у вихідні, але й протягом робочого дня. ефективно це робити можна, виявивши нові години марнотратства за допомогою алгоритмічного сканування штучним інтелектом (ШІ).

Клауд платформи на базі ШІ аналізують моделі використання системи та поведінки користувачів і надають унікальні рекомендації щодо стримування зростання хмарних рахунків і економії хмарного бюджету.

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

Зупинити, запустити та знову повторити — та скільки ж можна!

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

Процес планування розкладу активності машин, скажімо, у Google Cloud включатиме такі основні кроки:

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

Ото процес! Тут виникає логічне запитання — чи завжди фахівцям доводиться планувати вручну, чи у них є напрацьовані рішення для виконання цієї виснажливої ​​роботи? Добре розроблений планувальник має бути повністю керованим і автоматизованим, що дозволяє планувати не лише computing power інстанси та інші сервіси, але й майже будь-які завдання, включаючи batch jobs, big data jobs та всі операції хмарної інфраструктури.

Крім того, добре розроблений планувальник хмарних сервісів працює як єдина інформаційна панель, що дозволяє користувачам контролювати процеси та керувати всіма своїми завданнями автоматизації з одного місця і допомагає DevOps-командам зосередитися на проблемах вищого рівня, а не на базових «зупини-запусти» роботах.

Мультисервіси = Мультиекономія

Що стосується широкого спектра розробок планування від різних приватних організацій, їхні рішення в основному призначені для зупинки/ запуску інстансів обчислювальної потужності, таких як Amazon EC2, Google Compute Engines та Azure VMs, таким чином обмежуючи можливості економії.

Щоб зрозуміти цінність мультисервісного планування та проілюструвати, як воно працює, наведемо приклад скажімо, Amazon ECS на AWS Fargate. Ціни AWS Fargate базуються на vCPU, пам’яті, операційних системах, архітектурі CPU і ресурсах зберігання, які утворюються від початку завантаження контейнера до завершення Amazon ECS, стягуючи додаткову плату для інших послуг AWS або передачі даних.

Якщо взяти конкретний варіант використання, служба використовує 10 завдань ECS з 1 vCPU і 2 ГБ пам’яті під керуванням Windows протягом години на місяць без перерви у вихідні.

Розрахунки будуть такими:

Ви можете використовувати консоль Amazon ECS, якщо вам потрібно зупинити виконання завдань. Ось процедура:

  • Відкрийте консоль Amazon ECS.
  • В області навігації виберіть Кластери.
  • На сторінці Кластери виберіть кластер.
  • На сторінці імені кластера виберіть вкладку Завдання.
  • Щоб зупинити одне чи кілька завдань, виберіть завдання, а потім виберіть «Зупинити», «Зупинити вибране». Щоб зупинити всі завдання, виберіть «Зупинити всі».
  • На сторінці підтвердження зупинки введіть «Зупинити» та виберіть «Зупинити».

Знову досить марудний процес. Уявіть, що ви були занадто завалені завданнями або відверталися кудись. Від цього ніхто не застрахований! Таким чином, одна додаткова година подвоїть ваші платежі з $47,25 до $94,5. А що, якщо ресурс працював неймовірну кількість годин у вихідні дні, 48 годин? Ви порахуйте! Ось яким «чарівним» чином зростають витрати на хмарні сервіси.

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

Далі буде

Постачальники хмарних послуг прагнуть допомогти своїм клієнтам скоротити частину витрат на хмару. Але, на жаль, це лише крапля в морі. Flexera стверджує, що компанії марно втрачають в середньому 35% на хмарні сервіси.

Отже, підсумуємо:

  • планування годин сну для ваших ресурсів, коли вони не використовуються, є ефективним методом зменшення витрат на хмару;
  • щоб бути ефективним, планування має бути легким і плавним процесом;
  • хмарні інструменти та інші інструменти на ринку в основному забезпечують можливості планування для потужних обчислювальних машин, таких як EC2, Google Compute Engines і Azure VM. Однак більшої частини хмарної економії можна досягти завдяки мультисервісному плануванню із залученням різноманітних ресурсів, від систем контейнерного ядра до повного спектра баз даних.

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

Сподіваюсь, ця інформація була корисною. До нових зустрічей!

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Привіт) про Finops цікаво, гляну твої статті, чи є на medium? А з компанією колись знайомились, цікаво бачити чим займаються (софт он написали).

Я хз для якої інфраструктури це акуально — переважно все має працювати 24/7.
Для всього іншого є «маленьке звірятко» яке періодично моніторить клоуд і пинає девопсів/девів на тему «нахрена вам цей ресурс?».

як мінімум для НеПрод Енвів цілком актуально

якщо у вас команда працює в одній локації

Ну если на дев энвах ранятся автотесты — найтли раны или регрессии, то и им спать противопоказано.

Интересно, что автор никак не затронул вопрос «просыпания», был опыт, когда когда утром первые запросы просто не проходили, приходилось писать warmup тесты, чтоб пинать апи по 5-10 раз.

Дякую за коментар. Питання про «пробудження» енвів дуже цікава тема і доволі велика. Обовязково напишу про це окрему статью

Підписатись на коментарі