Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Оптимізація ІТ-інфраструктури: з чого почати та як уникнути проблем у процесі

Привіт! Я Антон Василенко, Head of Solution Group в N-iX. У N-iX моя команда допомагає клієнтам компанії знайти оптимальні рішення проблем за допомогою технологій та спеціальних інструментів, як-от Discovery-фаза, розробка прототипу, бізнес-аналіз тощо. Ми надаємо клієнтові план архітектури, пропонуємо стек технологій, дизайн продукту, розрахунок часу та витрат.

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

Для зручності я поділив текст на три частини:

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

Які переваги оптимізації інфраструктури

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

Також існує комбінований підхід (використання і серверу, і хмари), який розгляну пізніше.

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

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

Для деяких компаній перехід на хмарну інфраструктуру — це чудовий шлях оптимізації витрат. Наприклад, один з наших клієнтів в N-iX — міжнародний стримінговий сервіс — потребував рішення, яке б було дешевше утримувати та витримувало високе навантаження в 36 мільйонів унікальних відвідувачів та понад 10 мільярдів запитів на тиждень. Ми обрали оптимізацію шляхом створення Kubernetes кластеру у хмарі AWS. Наші розробники створили 30 мікросервісів, утримання яких обходиться клієнту приблизно у 2000 USD щомісяця.

Для порівняння, неоптимізована архітектура, що складалась з EC2 OnDemand instances, обходилась нашому в клієнту більше ніж у 38000 USD на місяць.

Також у команди N-iX був такий випадок: послуги клієнта працювали в EC2 instances через службу ECS. Однак після того, як ми проаналізували схеми використання послуг, періоди пікового навантаження та витрати на управління середовищем, запропонували клієнту замінити екземпляри EC2 на Farate, безсерверне рішення, яке не вимагає управління базовою інфраструктурою серверів. В результаті рішення допомогло клієнту значно заощадити.

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

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

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

Власне, аудит і є першим етапом оптимізації інфраструктури.

Які є ключові етапи оптимізації інфраструктури?

Аудит

Цей етап допомагає зрозуміти, наскільки доцільно оптимізувати інфраструктуру у вашому випадку.

Під час цього етапу DevOps-експерти аналізують, як використовується хмара. Або адміністратори аналізують, як працює сервер. Для цього зазвичай використовують такі інструменти, як AWS Audit Manager від Amazon. Цей інструмент збирає метрики, які потім можна проаналізувати. Для прикладу, якщо аналіз показав, що система ніколи не використовує понад 6 Гб пам’яті з 16 доступних, то це привід для оптимізації шляхом зменшення обсягу пам’яті.

Планування нової або оптимізованої інфраструктури

Оскільки є багато підходів до оптимізації інфраструктури, планування стає дуже важливим аспектом. Серед основних підходів до оптимізації — зменшення кількості машин, зменшення пам’яті, об’єднання сервісів в кластери та інші.

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

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

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

Наприклад, в системі є бізнес-процес, який запускається на початку місяця і працює один день. В інші дні він не використовується. В такому випадку недоцільно зберігати його on-premise і платити за нього весь місяць. Краще зберігати його у хмарі та платити лише за декілька днів на місяць, коли він і використовується.

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

Імплементація плану оптимізації

Якщо просто, імплементація — це перенесення аплікацій з одних машин на інші. Як я вже писав, оптимізація on-premise інфраструктури — це переважно зменшення кількості машин.

Щодо хмари, то, згідно з класифікацією, є 6 основних варіантів міграції:

  • Рехостинг/Re-host (lift and shift).
  • Реплатформінг/Re-platform (lift, tinker, and shift).
  • Модернізація/Modernize.
  • Переписування/Rewrite.
  • Викинути та купити готове/Drop and shop.
  • Залишити так, як є/Retain.

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

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

Рехостинг — найпростіший з методів, оскільки він не вимагає зміни коду, а тому займає найменше часу. Однак у довгостроковій перспективі цей метод не передбачає швидкого масштабування та додаткової продуктивності. Зазвичай цей метод не дає оптимізації інфраструктури, а можливо, і здорожить її.

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

Одна з найбільших телеком-компаній Європи — Lebara, клієнт N-iX, мігрувала свої дані на хмару саме за допомогою реплатформінгу. В результаті вони змогли значно покращити масштабування. Крім того, перехід на хмару допоміг скоротити витрати на інфраструктуру на 25–30%.

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

Переписування — це складніший процес перетворення застосунків з адаптацією до хмарної інфраструктури. Залежно від типу аплікації можна суттєво скоротити витрати на інфраструктуру.

Drop and shop — тут все просто, якщо на ринку є застосунки, які вас задовольняють, то краще купити їх, ніж створювати свої. Зазвичай це так само зменшить ціну інфраструктури.

Retain — це пасивний метод, оскільки міграція не потрібна. Ви зберігаєте програми як є, де вони є.

Які складнощі можуть виникнути в процесі оптимізації

Складнощі оптимізації я теж умовно поділяю на складнощі on-premise і хмари.

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

Крім того, складністю є унікальність кожної інфраструктури. Це стосується і on-premise, і хмарної інфраструктури.

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

Збереження знань на проєкті в ІТ-аутсорсингу

Отже, щоб провести успішну оптимізацію інфраструктури, необхідно:

  1. Здійснити детальний аудит системи.
  2. Знайти спосіб оптимізації, який найкраще відповідає потребам вашого проєкту.
  3. Імплементувати його.

Якщо є питання — ставте їх у коментарях!

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному3
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

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