---
title: Гігабайт для п'ятдесяти мегабайт
subtitle: Чому тисячі дрібних проєктів створюють великий хибний попит на обчислення і що з цим робити
description: Обробка даних сьогодні дорожча, ніж будь-коли раніше — і справа не лише в грошах. Яка частина орендованих потужностей справді виконує корисну роботу?
tag: Concept
date: 2026-09-08
author: Glab Strizhkov
readingTime: 7 хв читання
---

Обробка даних сьогодні дорожча, ніж будь-коли раніше — і справа не лише в грошах. За оцінками Міжнародного енергетичного агентства, у 2024 році центри обробки даних спожили близько 415 терават-годин електроенергії — приблизно 1,5 відсотка від світового споживання. Цей показник зростає на 12 відсотків щороку, а згідно з базовим сценарієм IEA, до 2030 року подвоїться і становитиме близько 945 терават-годин. У США розширення центрів обробки даних становитиме половину загального зростання попиту на електроенергію. Простіше кажучи, те, що раніше було лише однією зі статей у рахунку за комунальні послуги планети, стає одним із головних навантажень на енергосистему.

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

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

Почнемо з того, що невідповідність «орендовано» і «використано» — не мої здогадки, а вимірюваний факт індустрії.

Щороку Flexera State of the Cloud опитує сотні технічних керівників і щоразу фіксує, що значна частина витрат на хмарні технології є невиправданою. У 2026 році ця частка становила 29%; у 2019–2020 роках — 30%; у 2021 році — 32%; у 2022–2023 роках — 28%; а з 2024 по 2025 рік — 27%. Стабільність цього показника тут головний сигнал: це не збій, це структурна риса. За розрахунком Gartner, 675 мільярдів доларів витрачено ні на що. За оцінкою Harness (FinOps in Focus 2025) — 44,5 мільярда за один рік.

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

Проблема стає ще очевиднішою, якщо розглянути її на рівні апаратного забезпечення. Дослідження McKinsey показало, що сервери в корпоративних центрах обробки даних рідко завантажені більше ніж на 6% від своєї потужності. А дослідження Джонатана Кумі (Стенфорд) у співпраці з Anthesis Group виявило, що 30% з них перебувають у «коматозному стані». Ці сервери споживали електроенергію, але не виконували жодної корисної роботи протягом півроку або довше. У глобальному масштабі це становить 10 мільйонів серверів, або 30 мільярдів доларів витрат на простої. Інститут Uptime незалежно дійшов до схожих цифр.

Галузь уже давно систематично платить за те, чим не користується. Інстанс з 1 гігабайтом оперативної пам'яті для розміщення бази даних хоббі-проєкту, що фактично потребує 50 мегабайт, — це не виняток, а мініатюрна версія цієї проблеми.

Тут виникає заперечення: «Ну і що? Провайдер продає пам'ять із запасом і віддасть мій надлишок іншому. Ніхто нічого не втрачає». Звучить переконливо, але таке твердження є хибним.

У 2007 році Луїс Барросо та Урс Хьольце з Google у своїй статті «The Case for Energy-Proportional Computing» сформулювали проблему, яка й досі турбує нас: ідеальна машина не споживала б енергії без навантаження. Але реальне обладнання на це не здатне. Вимірювання показують, наскільки далеко воно від цього ідеалу. Згідно з даними Міністерства енергетики США, типове навантаження сервера становить 10–15%. Проте енергоспоживання сервера в режимі простою досягає 60–80% від його енергоспоживання під навантаженням. Більш актуальні дані показує бенчмарк SPECpower проєкту Kepler у CNCF, а саме від 20% до 60% від максимального значення, залежно від покоління апаратного забезпечення. Важливо пам'ятати про цей факт: 10-кратне зменшення навантаження не призводить до 10-кратного зменшення енергоспоживання; воно залишається ближчим до середини максимального діапазону.

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

При такому підході важливо бути чесним із собою. Ідея не є новою. Спільна пам'ять та обчислення реалізовані в Neon та PlanetScale, а тисячі невеликих екземплярів SQLite працюють на спільній інфраструктурі — Cloudflare D1. Ущільнена оркестрація робочих навантажень — це рутинна робота для оркестраторів, таких як Kubernetes.

Тож проблема не є технічною, а полягає в дефолтах та стимулах. Чому принцип «1 проєкт — 1 інстанс» залишається стандартом для стартапу, проєкту, що розробляється, або навіть пет-проєкту? Тому що саме так написано в більшості мануалів та туторіалів, орієнтованих на широку аудиторію. Тому що scale-to-zero здається «просунутою» магією. Тому що ніхто особисто не несе відповідальності за порожній гігабайт — він просто губиться в рахунку за хостинг.

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

Повернемось до того, з чого почали. Наближається день, коли центри обробки даних споживатимуть 3% світової електроенергії, а в певних районах забезпечать половину всього приросту попиту на електроенергію. На фоні цього розмова перестає бути розмовою про економію 5 доларів на послугах хостингу. Тепер це розмова про інженерну етику: ми звикли замовляти із запасом. Цей запас оплачується електроенергією і виробництвом заліза.

Хибний попит знижується не героїчними рішеннями, а роботою над «звичками за умовчанням». Розраховувати реальну потребу, не замовляти всліпу. Вибирати scale-to-zero там, де навантаження спорадичне, а в пет- та інших видів проєктів схожого масштабу воно завжди спорадичне.

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

## Джерела

- [Barroso & Hölzle — “The Case for Energy-Proportional Computing” (IEEE Computer, 2007)](https://doi.org/10.1109/MC.2007.443)
- [eWeek — “30% of servers worldwide sit idle, report says”](https://www.eweek.com/servers/30-percent-of-servers-worldwide-sit-idle-report-says/)
- [Forbes Councils — “Strategies to manage cloud spend post cloud-boom”](https://councils.forbes.com/blog/strategies-to-manage-cloud-spend-post-cloud-boom)
- [Spendark — “State of Cloud Waste 2026”](https://spendark.com/blog/state-of-cloud-waste-2026)
- [CNCF TAG Environmental Sustainability — “Idle power matters”](https://tag-env-sustainability.cncf.io/blog/2024-06-idle-power-matters)
- [Flexera — “Cloud value is rising while AI waste grows”](https://www.flexera.com/about-us/press-center/flexera-finds-cloud-value-is-rising-while-ai-waste-grows)