Енергоефективна архітектура

1) Базові принципи

1. Energy as a First-Class Metric. Джоулі/запит, Вт/ядро, кВт· год/ТБ-місяць - такі ж KPI, як p95 і вартість.
2. Carbon-/Energy-Aware Orchestration. Графік навантаження і розміщення завдань враховують CO₂-інтенсивність мережі і дата-центрів.
3. Data Minimization. Менше даних → менше CPU/IO → менше енергії та охолодження.
4. Right-sizing & Right-placing. Підбираємо правильний тип і розмір ресурсу і розміщуємо ближче до користувача/даних.
5. Simplicity Wins. Зайва абстракція і чатовость = додаткова енергія.

2) Метрики та моделі

2. 1 Інфраструктурні

PUE (Power Usage Effectiveness): 'PUE = Загальна енергія ЦОД/Енергія IT-навантаження'( чим ближче до 1 - тим краще).
CUE (Carbon Usage Effectiveness): 'CUE = CO₂e/Енергія IT'.
WUE (Water UE): літри води на кВт· год - важливо для регіонів з дефіцитом води.

2. 2 Прикладні

J/req (джоулі на запит): `E_req = ∫ P(t) dt / N_req`.
kWh/ETL-джобу, kWh/млн повідомлень, kWh/навчання моделі.
SO₂e/ficha або SO₂e/polzovatel: 'CO₂e = kWh × grid_factor (час, регіон)'.

2. 3 Модель вуглецю

carbon(req) = energy(req) grid_emission_factor(region, time)
energy(req) = cpu_j + mem_j + io_j + net_j

Де'grid _ emission _ factor'змінюється по годині і регіону (карбон-обізнане планування).

3) Апаратура і рівень виконання

Архітектури CPU: ARM/Graviton/RISC-V часто дають найкраще «W/перф» для мережевих і Java/Go-навантажень; x86 залишається сильним для високих тактів і деяких SIMD.
GPU/TPU/інші прискорювачі: на ML/векторній аналітиці часто дають краще «Дж/операцію», якщо батчирувати і тримати високу утилізацію.
DVFS и power capping: динамічне зниження частоти і обмеження TDP під некритичні завдання.
Сплячий режим/авто-гасіння: агресивні «idle» політики для воркерів і фонів.
Пам'ять: NUMA-локальність і зниження сторінкових промахів зменшують енерговитрати шини і кешів.

4) Архітектурні патерни

4. 1 Мікросервіси без «чатовості»

Скоротіть RPC-хопи: агрегаційні шлюзи, композитні ендпоінти.
gRPC/HTTP/2/3 замість чатуватого REST.
Batch + Async: склеюйте дрібні операції.

4. 2 «Теплі» і «холодні» шляхи

Для рідкісних, важких запитів - as-needed інфраструктура (on-demand, функції/серверлесс).
Гарячі шляхи - довго живуть з'єднання і пули.

4. 3 Кешування з coalescing

Coalescing запитів запобігає шторми кеш-промахів.
Stale-while-revalidate: віддаємо застаріле, економимо похід у витік.

4. 4 Тиринг сховищ

Hot/Warm/Cold/Archive: NVMe → SSD → об'єктне із затримкою → льодовик.
Автоматичний ILM/TTL: менше спінів/IO → менше енергії.

4. 5 Карбон-обізнаний планувальник (Carbon-Aware)

Переносяться в часі джоби (ETL, аналітика, тренування) - на «зелені» годинники/регіони.
Регіональний egress доріг по кВт· год і CO₂ - агрегуйте локально.

python def schedule(job):
windows = get_green_windows(job.region_candidates, next_48h)
pick = argmin(windows, key=lambda w: w.grid_factor job.energy_estimate / w.capacity)
enqueue(job, region=pick.region, start=pick.start)

4. 6 Дедуплікація і компресія «з розумом»

Компресія економить мережу/диск, але варто CPU. Застосовуйте адаптивно: великі корисні навантаження, низький CPU-контур.

5) Ефективність коду та даних

Алгоритміка: знизити асимптотику> тюнінгу. Профілюйте «гарячі точки».
Виділення пам'яті: оренда буферів, пули об'єктів - менше GC/енергії.
Формати: бінарні протоколи, колонічні формати (Parquet/ORC) для аналітики, зіпф-розподіл ключів враховуйте при кешуванні.
I/O: пакетування, векторизація, асинхронне введення/виведення.
Стрімінг vs повні скани: push-down фільтрів до джерела даних.
Функції на краю (edge): пред-агрегація, відкидання шумових подій.

E_req ≈ (cpu_ms W_cpu/ms) + (mem_ms W_mem/ms) +
(io_read_mb W_io/mb + io_write_mb W_io/mb) +
(egress_mb W_net/mb)

6) ML і дані: енерго-патерни

Архітектура моделей: невеликі/спеціалізовані моделі, дистиляція, квантування (int8/4-bit), sparsity.
Тренінг: батч-розмір ↗ утилізацію, mixed precision (FP16/BF16), чекпоінти, рання зупинка.
Інференс: batch + мікробатчі, компіляція (TensorRT/ONNX Runtime), тритон-сервер з дінам. батчингом.
Фічі і фіч-стор: кешування часто використовуваних фіч, деградація якості замість перевантаження витоку.

7) Мережа та протоколи

Keep-alive, HTTP/3, QUIC, мінімізація handshake.
CDN + edge-кеші: коротше маршрути → менше кВт· год.
Стиснення з профілем: zstd/бротлі для великих ресурсів, без компресії для маленьких/CPU-дорогих шляхів.
Багаторегіональне дублювання - тільки при реальній необхідності RTO/RPO.

8) Телеметрія і «енерго-обсервабіліті»

8. 1 Збір

Лічильники енергії/потужності (IPMI/RAPL/Node Exporter power), телеметрія GPU/TPU.
На рівні додатку: атрибуція J/req - через семплювання часу CPU/IO і калібрувальні коефіцієнти.
Кореляція з трасуваннями: `energy_j`, `carbon_g`, `grid_factor`, `region`.

8. 2 Метрики та алерти

Energy per SLI: `J/p95`, `J/txn`.
Carbon budget: місячні ліміти CO₂e по продуктах.
Drift: зростання'J/req'> X% від базлайну.

9) CI/CD, гейти і тестування

Perf-smoke + Energy-smoke на PR: короткий сценарій, збір'J/req'і регрес-гейт.
Базлайни енергії: зберігаємо еталон (флеймграфи CPU/GPU, J/req).
Policy as Code: заборона деплоя, якщо'Δ J/req> 10%'без затвердженого винятку.
Хаос + енерго-моделі: деградація залежностей не повинна підвищувати J/req понад ліміти (шейдинг/деградація замість ретрай-штормів).

10) Управління навантаженням і часом

Зрушення в часі (load shifting): неінтерактивні завдання - в «зелений» годинник.
Динамічне SLO: для фонів можна збільшувати латентність заради економії енергії.
Пріоритизація: критичні запити отримують «енерго-квоти», низький пріоритет - відкладається.

python if energy_budget.low() and req.priority == "low":
return 429_DEFER process(req)

11) Безпека, приватність і комплаєнс

Шифрування з апаратним прискоренням (AES-NI/ARMv8 Crypto) - менше CPU/Вт.
PII мінімізація знижує навантаження на зберігання/аналітику.
Логи: семплювання, маскування і TTL - економить енергію збору/зберігання.

12) Анти-патерни

Надмірна мікросервісність і «чати» між сервісами.
Глобальна реплікація «про всяк випадок».
Нульові TTL кеша і заборона stale.
Повні скани без фільтрів/індексів/партій.
Постійні ретраї без джиттера → мережеві шторми.
Використання «великої моделі» там, де вистачить евристики.
Важкі формати логів і «все логуємо назавжди».

13) Міні-рецепти та приклади

13. 1 Адаптивна компресія відповіді

python def maybe_compress(resp, cpu_load, size):
if size > 641024 and cpu_load < 0.6:
return compress_zstd(resp, level=5)
return resp # мелкие/дорогие по CPU ответы не сжимаем

13. 2 Евристика батчингу інференсу

python batch = collect_until(max_items=64, max_wait_ms=8)
result = model.infer(batch) # ↑ утилизация ускорителя, ↓ Дж/запрос

13. 3 ILM/TTL для подій

yaml dataset: events lifecycle:
- hot: 7d  # NVMe
- warm: 90d # SSD + zstd
- cold: 365d # object store
- delete

13. 4 Карбон-обізнаний ETL

python co2 = kwh_estimate(job) grid_factor(region, now())
if co2 > job.threshold and job.deferable:
delay(job, until=next_green_window())
else:
run(job)

14) Чек-лист архітектора

1. Визначені SLI по енергії (J/req, kWh/джобу) і вуглецю (gCO₂e/req)?
2. Чи є модель атрибуції енергії за сервісами/фічами/тенантами?
3. Карбон-обізнаний планувальник для переносяться завдань впроваджений?
4. Мікросервіси мінімізують чатовость (агрегація, батчі, gRPC/HTTP3)?
5. Кеші з coalescing і режимом stale-while-revalidate налаштовані?
6. Сховища товані, ILM/TTL включені, формати даних оптимальні?
7. ML: дистиляція/квантування/батчинг/компіляція інференсу використовуються?
8. У CI/CD є енерго-smoke, базлайни і гейти на Δ J/req?
9. Edge/CDN/регіональне розміщення мінімізують egress і маршрути?
10. Включені DVFS/power-capping/idle для воркерів?
11. Логи/метрики/трейси семплюються і мають ретеншн за важливістю?
12. Документовано «зелений» runbook: що відключати/деградувати при дефіциті енергії?

Висновок

Енергоефективна архітектура - це не «остання оптимізація», а стратегічний шар якості: від алгоритмів і форматів до розміщення в «зеленому» регіоні і гейтів в CI/CD. Вимірюйте джоулі, плануйте з урахуванням вуглецю, спрощуйте взаємодії, тируйте дані і використовуйте прискорювачі там, де це знижує «Дж/операцію». Так ви отримаєте платформу, яка швидше, дешевше і екологічніше - без компромісу щодо продуктової цінності.