Як спланувати міграцію бізнес-застосунків у хмару (Частина IІ)

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

Публічна чи приватна хмара?

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

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

Можливості кастомізації

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

Обсяги споживаних ресурсів

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

Керування даними

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

Інтеграція із застарілими застосунками

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

Масштабування

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

Вартість володіння

У моделі IaaS до певної конфігурації розміри регулярних платежів за порівнянних обсягів ресурсів будуть нижчими, ніж у Private Cloud. З невеликою кількістю ресурсів у останнього буде вищою сукупна вартість володіння внаслідок появи інсталяційного платежу. Якщо IT-інфраструктура досягла таких розмірів, що її доцільно виносити у приватну хмару, розмір щомісячного платежу здебільшого буде нижчим, ніж при сплаті аналогічного обсягу ресурсів у публічній хмарі.

Відповідність специфічним вимогам

В IaaS ви можете встановлювати ОС та застосунки, в той час, як у Private Cloud у вас буде прямий доступ до апаратної частини IT-інфраструктури та гіпервізору. Це важливо, якщо ви плануєте отримати більше інструментів для контролю та керування, а також самостійно займатись адмініструванням, щоб оптимізувати інфраструктуру під конкретні бізнес-задачі.

Критерії оцінки застосунків

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

Архітектура

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

Застосунки з багаторівневою архітектурою

Багато бізнес-застосунків створюються з використанням декількох рівнів, що дозволяє відокремити основні модулі від додаткових функцій. Так виглядає архітектура у трирівневому застосунку:

• рівень управління даними, що включає реляційні та інші компоненти баз даних;
• рівень бізнес-логіки, який використовує платформу застосунків чи контейнери (Java EE/Microsoft.NET);
• рівень подання, що відповідає за взаємодію з інтерфейсами користувача або іншими зовнішніми системами.

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

Вертикально- і горизонтально-масштабовані застосунки

Вертикально-масштабовану (scaling up) архітектуру мають застосунки, які можуть отримувати користь внаслідок виділення додаткових ресурсів (переважно процесорної потужності та пам’яті) на одному й тому ж сервері чи вузлі.

Горизонтально-масштабовану (scaling out) архітектуру мають застосунки, які можуть отримувати користь внаслідок збільшення кількості серверів чи вузлів. Відповідно, коли навантаження виросте, потрібно розгорнути додаткові вузли, а коли потреба в ресурсах зменшиться, невикористані сервери/вузли можна буде відключити. Такі застосунки з’явилися пізніше вертикально-масштабованих, а період їхнього активного поширення пов’язаний з масовим переходом на архітектуру х86.

Географічна доступність

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

Профілювання застосунків

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

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

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

Планування міграції

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

Чому важливо довірити реалізацію проєкту професіоналам

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

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

Резюме

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

Стратегія охолодження ЦОД для епохи AI