Чому бізнес відходить від публічної хмари на користь власної інфраструктури: досвід і поради експерта
За даними дослідження Cloudian, три чверті компаній за останні два роки перевели частину робочих навантажень із публічної хмари у власну інфраструктуру. Це змушує бізнес ретельніше аналізувати, де оптимальніше розміщувати сервіси, скільки коштує їхня експлуатація і як саме обрана інфраструктура позначається на продуктивності.
Федір Плотніков, Principal DevOps & Cloud Infrastructure Leader, розпочав кар’єру в Україні понад 20 років тому. За цей час він працював із IT-інфраструктурою у різних сферах і реалізовував міжнародні проєкти: від банківських систем у Globant до телекомунікаційної мережі Syniverse та глобальних сервісів мобільної безпеки. У його портфоліо — оптимізація хмарної інфраструктури та підвищення ефективності інженерних процесів, зокрема для компаній зі списку Fortune 500. Наприклад, модернізація CI/CD дозволила скоротити час розгортання ПЗ з 8–10 годин до менш ніж однієї. В інтерв’ю для Dilo DevOps-експерт Федір Плотніков пояснює, як вибір хмарної архітектури впливає на витрати бізнесу, продуктивність сервісів і їхнє масштабування.
Чому навіть потужний сервер не гарантує блискавичну роботу сервісу?
Потужність — це далеко не єдиний фактор, який визначає швидкодію сервера. Навіть якщо обладнання обробляє запити блискавично, користувач може стикатися із затримками через:
- мережеві затримки;
- географічне розташування серверів;
- особливості роботи конкретного застосунку.
Особливо це помітно в глобальних продуктах. Працюючи з AdTranquility — сервісом у сфері VPN і мобільної безпеки — Федір відповідав за стратегію DevOps, планування інфраструктури та оптимізацію витрат. Розширюючи географію, вони стикнулися з обмеженнями великих хмарних провайдерів. У деяких регіонах Азії й Океанії не було потрібної інфраструктури або ціни були надто високими.
Щоб розв’язати проблему, залучили регіональних провайдерів паралельно до великих хмарних платформ. Це дало змогу:
- визначати інфраструктуру відповідно до географії користувачів і технічних вимог;
- оптимізувати вартість ресурсів;
- заощадити до 40% завдяки FinOps-ініціативам.
Крім цього, автоматизували глобальну VPN/WireGuard-мережу у 12 регіонах.
Коли хмарні рішення стають надто дорогими для бізнесу?
Зростання витрат може пояснюватися різними факторами, серед яких:
- неоптимальне використання ресурсів — вони простоюють;
- застосунок споживає більше обчислювальної потужності, ніж потрібно;
- значні витрати на передачу даних між системними компонентами.
Перехід на власні сервери не завжди вирішує проблему, адже власна інфраструктура вимагає обслуговування, підтримки та забезпечення безпеки, а це – додаткові витрати на обладнання і персонал. Тому важливо ретельно розібратися, які процеси призводять до високих витрат. Іноді просте налаштування поточної інфраструктури здатне знизити витрати, не вдаючись до повного перенесення системи.
Чи всі компоненти продукту потребують однакової кількості ресурсів?
Потреби залежать від функцій і навантаження кожного конкретного модуля. Наприклад, під час розпродажу в інтернет-магазині різко зростає кількість відвідувачів, і сторінки каталогу починають гальмувати. Підвищення кількості серверів для застосунку іноді не змінює ситуацію, бо виявляється, що вузьким місцем є база даних, яка не справляється з навантаженням.
У цьому випадку ресурси потрібно сконцентрувати саме на «вузькому» компоненті. Окреме масштабування різних частин системи допомагає уникнути необґрунтованих витрат на надлишкові потужності там, де вони не потрібні.
Коли вигідно поєднувати хмару з власними серверами?
Гібридна інфраструктура має сенс, якщо системні компоненти мають різні вимоги до розміщення або навантаження. Наприклад:
- хмара дозволяє швидко масштабуватися у разі пікового трафіку;
- власні сервери використовують для зберігання чутливих даних або систем із суворими регуляторними вимогами.
Проте цей підхід ускладнює підтримку: слід організувати безпечний обмін даними між середовищами і забезпечити їхню узгоджену роботу. Тому потрібно ретельно зважувати переваги, додаючи до них потенційні додаткові витрати. Іноді простіше і вигідніше залишитися в одному середовищі.
Як уникнути простою бізнесу через відмову одного сервера?
Якщо сервіс критично потрібен для операцій, варто заздалегідь продумати сценарії на випадок збою: чи зможе система безперервно обробляти завдання, швидко відновити дані і вийти на роботу без тривалих простоїв.
Наприклад, при роботі з маркетинговою платформою на основі n8n команда зіткнулася з ризиком зупинки процесів через «єдину точку відмови». Платформа обробляла заявки з сайту, передавала їх у CRM і запускала автоматичні повідомлення.
Розглядали три варіанти:
- Посилити один сервер — але це не розв’язує проблему відмови точки.
- Запровадити Kubernetes — однак це додавало змалий масштаб завдання надлишкову операційну складність.
- Використати керовані сервіси AWS — обрали цей шлях.
Вони запустили застосунок через ECS Fargate, зберігали дані на RDS, використали черги для обробки завдань та описали інфраструктуру через Terraform, розбивши середовища на розробку, тестування та production. Завдяки цьому зменшили залежність від одного сервера і забезпечили обробку завдань навіть при тимчасових збоях окремих компонентів.
Як оцінити, чи дійсно зміни покращили роботу сервісу?
Важливо порівнювати показники, які стосуються конкретної проблеми, що була:
- Наприклад, якщо раніше сторінки завантажувалися повільно — порівнюють час відповіді до і після змін.
- Якщо виникали затримки між заявками і CRM — перевіряють швидкість обробки і кількість помилок.
Також важливо оцінювати систему за схожих умов, які призводили до проблем. Адже сервіс може бути швидким при низькому навантаженні, але залежати від кількості запитів і сповільнюватися в пікові моменти. Такий підхід допомагає не лише покращувати окремі метрики, а й усувати справжні причини збоїв.
Що врахувати, щоб інфраструктура витримала зростання продукту?
Плануючи масштабування, слід розуміти, які саме компоненти виявляться «вузькими місцями». Ось найпоширеніші виклики:
- зростання кількості користувачів може призвести до дефіциту обчислювальних ресурсів;
- база даних може перестати справлятися з кількістю запитів;
- інтеракція між модулями може сповільнитися.
Наприклад, якщо база даних уже функціонує на межі можливостей, збільшення серверів застосунку нічого не змінить. Важливо заздалегідь виявити «вузькі місця» і прорахувати, як навантаження зміниться з подальшим ростом, щоб вчасно із цим впоратися, не нашкодивши користувачам.
