Як скоротити витрати на інфраструктуру без втрати продуктивності

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

Основні витрати на інфраструктуру: хостинг, підтримка, масштабування

Розгляд витрат доцільно проводити окремо для локального хостингу та хмарних рішень. Це допоможе сконцентруватися на «вузьких» місцях для кожного виду хостингу.

Витрати на «хмару»

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

Основними витратами, що складають щомісячну статтю витрат на «хмару», будуть наступні:

Сховище даних gp3 EBS (Elastic Block Storage). Це найдешевший тип сховища, в якому максимальна пропускна здатність на екземпляр обмежена і становить 10 ГБ/с. Сума оплати тут складається з двох складових: плата за обсяг сховища + плата за кількість операцій введення/виведення або IOPS (Input/Output Operations Per Second). Це найбільш значуща складова, яка становить приблизно 65% щомісячної суми платежу.

Служба EC2 (Elastic Compute Cloud). Забезпечує для користувача управління орендою віртуальних виділених серверів або екземплярів за передплатою. Кількість серверів розраховується, виходячи з розрахункової завантаженості проекту. У щомісячній статті витрат становить близько 32 % від усіх витрат.

Оплата за трафік  (Transferred data). Ця стаття витрат характерна тільки для хмарного хостингу. Вона складається з оплати за вихідний (egress) і деякі види зовнішнього трафіку, зокрема, між користувачем і провайдером. Багато хмарних провайдерів надають певний безкоштовний ліміт, вище якого йде оплата за кожен ТБ переданих даних. Для Amazon Web Services кожен ТБ понад ліміт коштує близько 90-100 доларів. 

Крім основних щомісячних витрат, як правило, не вдається уникнути і додаткових. До них, зокрема, відносяться:

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

    NAT Gateway;

•     Application Load Balancer (ALB);
•     Web Application Firewall (WAF);
•     Route 53;
•     Amazon S3;
•     AWS Lambda;
•     Simple Queue Service (SQS);
•     Redis Enterprise Cloud;

Річні витрати на підключення та використання тільки одного з них в середньому становитимуть близько $10000. Очевидно, підключення декількох таких сервісів може скласти досить значну суму навіть для великої компанії.
Утримання персоналу, що складає групу FinOps (Financial Operations). Одним з найважливіших завдань при використанні хмарного хостингу є організація ефективного управління складною конфігурацією хостингу та облік витрат. Таке завдання здатні виконувати тільки об'єднані команди IT-фахівців та економістів. За даними звіту за 2025 рік від компанії Flexera, кількість компаній, що мають групу FinOps для управління та оптимізації витрат на «хмару» за останній рік зросла з 51 до 59 %, що говорить саме за себе.    

Витрати на локальний хостинг

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

Наведемо приблизний перелік витрат на щомісячне утримання інфраструктури для найдорожчого виду локального хостингу типу колокейшн (co-location).

Ось цей перелік:
Власне серверне обладнання. Щомісячну виплату можна прийняти рівною вартості закупівлі серверів, поділеної на 60 місяців (5 років – це середній «термін життя» сервера). Ця сума складе приблизно 65% всієї щомісячної виплати. Практика показує, що рівень витрат за цією статтею може бути в 2-5 разів нижчим, ніж для аналогічного обладнання в «хмарі». 

Оренда місця в дата-центрі (DC). Сюди, як правило, входить і оплата електроенергії.

Послуги інтернет-провайдера (ISP) з IP-транзитом.

Волоконна лінія зв'язку dark fiber (DF).

Внутрішнє мережеве обладнання (Network HW).

Останні чотири статті витрат разом становитимуть приблизно 35% від суми місячного платежу.  

Витрати на адміністрування сервера ми сюди не включили, виходячи з наявності в компанії штатного системного адміністратора.

Також слід врахувати, що тут, на відміну від «хмари», плата за трафік не передбачена, що допоможе заощадити майже 5% коштів щомісячних платежів, а також стабілізувати витрати.

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

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

Що стосується інших видів локального хостингу, то тут все буде ще простіше і дешевше, оскільки більша частина наведених статей витрат відпадуть самі собою. Залишиться тільки оренда виділеного або VPS-сервера, а також витрати на адміністрування сервера.

Чому багато компаній переплачують за хмарні рішення

Можна виділити кілька причин, через які багато компаній платять за cloud-хостинг понад те, що передбачалося їхніми бізнес-планами.

Наведемо основні з них:

Тарифікація трафіку. Це слабо керована стаття витрат, оскільки щогодинний контроль обсягів переданих даних є досить складним. Його різке збільшення може бути викликане стрибком відвідуваності ресурсу або деякими ймовірнісними причинами, що не залежать від дій Адміністратора або роботи проекту: вірусна або DDoS-атака, нерегламентовані дії провайдера або співробітника компанії (людський фактор) тощо. Практика показує, що в таких випадках буває непросто довести, що оплата за трафік знята неправомірно. Тому краще заздалегідь прописати все в договорі з провайдером. Крім того, сума оплати за кожен ТБ понад безкоштовний ліміт за egress трафік у провайдерів глобального рівня може зашкалювати. Наприклад, у хмарного провайдера Alibaba Cloud вона становить близько $80, у Render – $300, а в Netlify – $550 (!). Оплачувати такі тарифи можуть собі дозволити лише дуже успішні компанії.

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

Недосконала політика провайдерів щодо типів тарифікації. Прийнято вважати, що однією з головних переваг хмарних платформ є спосіб їх оплати за передплатою – тільки після отримання і використання кінцевих обсягів ресурсів. Питання в тому, чи будуть враховані ті ресурси, які не використовувалися. Наприклад, це стосується RAM і CPU віртуальних машин, які не працювали якийсь час. Мало хто знає, що багато провайдерів знімають за це кошти, спираючись на використовуваний ними тип тарифікації, яких всього чотири: Reserved, Allocated, Pay As You Go і Private Cloud. Лише для тарифів Allocated і Pay As You Go передбачена оплата тільки за реально використані ресурси, проте вони присутні лише в публічних «хмарах». На приватних хмарних платформах зазвичай оплачуються всі ресурси орендованих серверів, навіть якщо вони були відключені. Провайдери тут діють на підставі «найдорожчого» і «несправедливого» для клієнтів тарифу Reserved, чим, по суті, нівелюється головна перевага хмарного хостингу – оплата за підпискою.     
          

Оптимізація витрат: «втеча з хмари»

Одна з основних причин вибору хмарного хостингу стартапами – це бажання уникнути великих початкових інвестицій в інфраструктуру або, як кажуть, капітальних витрат CAPEX (Capital Expenditures). Вибираючи «хмару», вони, таким чином, переносять всі ці витрати на операційні витрати або OPEX (Operating Expenditure), що збільшує фінансову гнучкість в управлінні витратами компанії. Однак з часом, без чіткої стратегії управління хмарними витратами, що найчастіше і буває, витрати на хостинг можуть вийти на такий рівень, коли розвиток і навіть саме існування бізнесу можуть стати під загрозою, особливо в разі використання хмарних провайдерів глобального рівня.    
Щоб уникнути плачевних наслідків описаної ситуації, слід використовувати всі доступні шляхи і засоби для налаштування керованого процесу витрат коштів на хостинг.

Наведемо деякі з можливих шляхів оптимізації витрат:

Узгодити в договорі з провайдером використовувані ним типи тарифікації та інші умови списання коштів. Повинні бути враховані всі нюанси, що стосуються виставлених рахунків для оплати хостингу – що і яким чином тарифікується; чи включено ПДВ; чи обмежено зростання цін з часом; які використовуються тимчасові інтервали обліку використовуваних ресурсів для тарифу Pay As You Go (у разі наявності); чи будуть оплачуватися ресурси вимкнених VM тощо.

Створити об'єднану групу FinOps для управління хмарними витратами.

Провести оптимізацію служб і відмовитися від «зайвих» сервісів хмарного провайдера. Як показує практика, невелика оптимізація працюючих сервісів може значно скоротити витрати. Наприклад, відключивши логування в сервісі AWS CloudWatch, можна заощадити кілька тисяч доларів на рік, зберігаючи при цьому можливості моніторингу ресурсу. Якщо для взаємодії з СУБД проекту використовувати VPC Peering замість дорогого AWS NAT Gateway, то економія складе близько $10000 на рік. При цьому NAT Gateway буде продовжувати використовуватися для зв'язку з мережею Інтернет з приватної підмережі в AWS, але вже не буде забирати ваші кошти.  

По можливості використовувати змішану модель інфраструктури хостингу. Доцільно частину сервісів перенести з «хмари» на локальний хостинг. Наприклад, це стосується сховищ статичних даних AWS S3, які, як ми вже переконалися, в «хмарі» мають дуже високу ціну.

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

Перехід на VPS як спосіб стабілізувати та знизити витрати

Оренда хмарного хостингу у провайдерів глобального рівня, таких як Amazon, Microsoft Azure, Alibaba, Vercel та багатьох інших, вимагає серйозних грошових витрат, які можуть становити близько $100 тис. на рік і більше, залежно від масштабів проєкту. Небагато українських компаній можуть собі це дозволити. Тому виходом для них може стати звернення до «малих» хмарних провайдерів, тарифи яких більш доступні для малого та середнього бізнесу, або ж вибір одного з видів локального хостингу.

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

Тому, на наш погляд, при прийнятті рішення про вибір типу хостингу для свого веб-проекту потрібно керуватися наступними тезами:

• Для нескладного веб-сайту з нечастими змінами однозначно підійде один з варіантів локального хостингу – shared або VPS. Він обійдеться в кілька разів дешевше аналогічного майданчика на «хмарі».
• Для високонавантаженого шаблонного ресурсу з помірною кількістю змін ідеальним варіантом може стати локальний VPS або виділений сервер з додатковим майданчиком для резервування. У цьому випадку рівень витрат також буде помітно меншим, ніж у «хмарі».
• Для сайту промислового банку, урядової або фінансової організації вибір однозначний – тільки локальний хостинг. Це пов'язано з питаннями забезпечення безпеки, які неможливо вирішити на жодній хмарній платформі. Варіантами тут можуть бути VPS-, Dedicated-сервер або co-location залежно від рівня бюджету та потреб проекту.   
• Для сайту веб-розробників з численними віддаленими гілками Git-репозиторію, CI/CD-конвеєром, алертами, бекапами та безліччю додаткових сервісів підходять як локальний (VPS- або Dedicated-сервер), так і хмарний («мала хмара») варіанти хостингу.
• Для високопродуктивного сервісу зі складною інфраструктурою, що охоплює кілька регіонів, наприклад, мультивендорного мультиплейсу, основним варіантом буде «публічна хмара», наприклад, той же Azure або Amazon. Такий вибір визначається однією з істотних особливостей «хмари» – розподіленістю її архітектури, що дозволяє балансувати навантаження між серверами. Тому тут без нього ніяк не обійтися.

Як підібрати VPS для оптимізації бюджету

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

Для цього потрібно виконати наступне:

1. Оцінити потреби сайту в серверних ресурсах, спираючись на технічну документацію від розробників;
2. Зайти на сайт локального хостинг-провайдера і вибрати найбільш підходящий тарифний план для VPS;
3. Замовити безкоштовний тестовий період для оцінки продуктивності обраної конфігурації сервера;
4. Розгорнути сайт на VPS-сервері, і за допомогою відомого ПЗ протестувати його роботу;
5. У разі виявлення помилок звернутися до розробника для їх усунення;
6. Якщо тестовий період пройшов успішно, оформити замовлення на VPS з обраною конфігурацією;
7. Оплатити замовлення і провести роботи з налаштування сервера для оптимізації роботи сайту і забезпечення безпеки – налаштування кешування, логування, бекапи тощо.