Оптимізація заліза і ресурсів

Коротке резюме

Оптимізація - це не «прискорити щось одне», а збалансувати продуктивність ↔ вартість ↔ надійність ↔ енергію. Базові кроки: виміряти SLI/SLO і профілі, знайти вузькі місця, «правильно розмірити» потужності, автоматизувати масштабування і закріпити поліпшення в образах/чартах/політиках.

Цілі та принципи

Від UX до заліза: починаємо від SLO (p95 latency, успіх операцій) → шукаємо лімітуючий ресурс.
Правильний розмір (rightsizing): ресурси і типи інстансів під характер навантаження.
Кеш і близькість: зменшуйте «дорогі» походи до сховищ і мереж.
Автоматизація: autoscaling, політики життєвого циклу, IaC.
Спостережуваність: метрики «чотирьох сигналів», профілі CPU/alloc, трейсинг.
Безпека = продуктивність: mTLS/підписи/ліміти - з апаратним прискоренням де можливо.

CPU та планування

Завдання: мінімізувати контеншен і кеш-промахи, врахувати NUMA і переривання.

NUMA-обізнаність: pinning по вузлах ('numactl --cpunodebind --membind'), для БД/брокерів - фіксувати на вузлі.
IRQ/softirq: розподілити по ядрах (RSS/RPS), закріпити гарячі черги за CPU без конкуренції з воркерами.
Гіперпоточність: для «чутливих до латентності» - фіксувати воркери на фізичних ядрах.
Контекст-світчі: зменшувати через довгі черги/батчинги/асинхрон.
Компілятори/JIT: включити PGO/LTO (C/C + +), Graal/HotSpot профілі (Java),'GOMAXPROCS'і виділення воркерів (Go).

Приклади Linux-тюнінгу (фрагменти):

bash
IRQ affinity: bind NIC queue to specific CPU echo 2 >/ proc/irq/XX/smp_affinity # kernel mask
Softirq balance on sysctl -w net network cores. core. netdev_budget=600 sysctl -w net. core. netdev_max_backlog=5000

Пам'ять і управління алокаціями

THP/HugePages: для JVM/DB - зазвичай відключити THP і використовувати hugepages вручну (зменшує TLB-промахи).
NUMA-баланс: для stateful - фіксувати пам'ять на локальному вузлі.

GC/allocator:

JVM: G1/ZGC,'-Xms = -Xmx'рівні, розумний'MaxGCPauseMillis'.
Go: 'GOGC'( почати з 100-200), уникати зайвих алокацій, профілі'pprof'.
Python: використовувати'uvloop','asyncio', C-розширення, пул з'єднань.
Swap/zswap: на проді зазвичай swap off для критичних сервісів; на вузлах загального призначення - zswap для «м'яких» навантажень.

Зберігання та I/O

Типи дисків: NVMe під hot-path, окремі пули для логів/чекапоінтів/темпу.
ФС: XFS для великих файлів/БД-журналів; ext4 для маленьких/універсальних.
RAID/EC: RAID10 для низьких затримок, RAID6/EC - під холодні дані.
I/O-планувальники: `none`/`mq-deadline` для NVMe.
Async/Batch: групуйте записи, використовуйте Write-Behind/Group-Commit.

fio для оцінки (приклад):

bash fio --name=randread --filename=/data/test --size=20G --bs=4k \
--iodepth=64 --rw=randread --ioengine=libaio --numjobs=4 --time_based --runtime=60

Мережа

MTU и offload: 9000 MTU в датацентрі (якщо end-to-end), включити GRO/LRO там, де допустимо.
RSS/RPS/RFS: багатоканальні черги на NIC, розподіл по ядрах; irqbalance - під контроль.
SO_REUSEPORT: масштабовані listen-сокети з розподілом по ядрах.
Клієнтські таймаути і пуллінги: короткі TCP-keepalive, ліміт відкритих конектів, backpressure.
TLS: TLS 1. 3, апаратні інструкції AES-NI, session resumption, OCSP stapling.

Мережевий тюнінг (фрагменти):

bash sysctl -w net. core. rmem_max=268435456 sysctl -w net. core. wmem_max=268435456 sysctl -w net. ipv4. tcp_rmem="4096 87380 134217728"
sysctl -w net. ipv4. tcp_wmem="4096 65536 134217728"

GPU/FPGA/SmartNIC (де доречно)

GPU: інференс антифроду, рекомендації, CV; стежити за'util','mem','sm _ efficiency'.
SmartNIC/eBPF/DPDK: розвантаження L4/L7, фільтрація, телеметрія без переходів в ядро.
Енергопрофілі: фіксувати частоти під стабільну латентність; уникати агресивних power-save.

Додатки та РСУБД

Пули з'єднань: обмежити'max _ conns', застосовувати connection pooling (PgBouncer/Hikari).
Індекси/планувальники: профілі EXPLAIN/ANALYZE, що покривають індекси, партіонування.
Кешування: Redis/ін-процес кеш, CDN для статики, edge-кеш для «гарячих» API.
Ідемпотентність і черги: уникайте каскадів ретраїв, вмикайте dedup.
Gzip/Brotli: компресія відповідей з урахуванням CPU-вартості; вибирайте баланс.

Контейнери та Kubernetes

Requests/Limits и bin-packing

Requests = «гарантія», Limits = «стеля». Невірні Limits по CPU → throttling і p99.
Враховуйте burst-навантаження (піки турнірів/матчів) - запас в p95.
Bin-packing: розділяйте пули вузлів (latency-crit, batch, GPU, spot). Використовуйте топологію (anti-affinity, spread).

Автомасштабування

HPA за кастомними метриками (RPS/p95, а не CPU).
VPA для «довгоживучих» і «непікових» ворклоадів.
Cluster Autoscaler + окремі node-групи (on-demand/spot).
KEDA для подієвих навантажень (черги, Kafka, cron).

Планувальник і менеджери

CPU Manager: 'static'для пінінгу повних ядер latency-критичним подам.
Topology Manager: вирівнювання за NUMA.
HugePages/Device Plugins: для БД/низької латентності і GPU/FPGA.

Приклад HPA (latency-aware, крізь адаптер метрик):

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: api-gw }
spec:
scaleTargetRef:
apiVersion: apps/v1 kind: Deployment name: api-gw minReplicas: 6 maxReplicas: 60 metrics:
- type: Pods pods:
metric:
name: http_latency_p95_ms target:
type: AverageValue averageValue: 120

FinOps і вартість

Профілі тарифів: підібрати інстанси по CPU/RAM/диску/мережі (compute-optimized, memory-optimized, storage-optimized).
Spot/Preemptible: для batch/стейджингу/кешів з мультизонною надмірністю.
Reservation/Savings: резерви на 1-3 роки для «постійної» частини.
Гаряче/холодно: tiered-storage, об'єктка для архівів, ретеншн логів.
Idle-ресурси: нічні/вікенд-зупинки не-критичних оточень.

Енергоефективність (GreenOps)

Power profiles: performance vs balanced по сервісах.
Ко-розміщення: ущільнення в «холодні» години, вимикання невикористовуваних вузлів.
KPI: ват на запит, р95/ват, CO₂ -метрики провайдера.

Спостережуваність і тестування

Метрики: CPU steal/throttle, `cycles/instructions`, LLC miss, RSS/working set, page faults, disk lat p95/99, NIC drops, retransmits.
Трейсинг: розподілені трейси для «золотих шляхів».
Профілювання: eBPF/Perf/Flamegraphs, `pprof`/YourKit/JFR.
Навантажувальні тести: SLO-орієнтовані, з реальним mix операцій, фазою «прогріву», fault-ін'єкцією.

PromQL (ідеї):

promql
CPU throttling доля sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)
/ sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)

Network loss sum (rate (node_net_dropped_total[5m])) by (instance)

Чек-лист оптимізації

Визначені SLO і «золоті шляхи» (API/платежі/виплати).
Профілі CPU/alloc/IO/мережі зібрані, знайдені top-N вузьких місць.
NUMA/IRQ/RSS налаштовані на latency-критичних вузлах.
THP off (при необхідності), hugepages для БД/Java-сервісів.
NVMe під гарячі дані, XFS/IO-sched налаштовані, fio-бенч підтверджений.
Мережевий стек: MTU, RPS/RFS, SO_REUSEPORT; таймаути/пули.
Kubernetes: Requests коректні, Limits не душать, HPA по бізнес-метриках, VPA/CA включені.
Кешування і CDN на «дорогих» шляхах; Redis/edge-кеш.
FinOps: rightsizing/резерви/spot-пули; зупинка idle-оточень.
Автотести продуктивності в CI, регресії на p95/p99.

Специфіка для iGaming/фінтех

Піки за розкладом: турніри/матчі/акції → «еластичний» пул фронтів, перед-прогрів кешів/CDN, HPA по RPS/латентності.
Платежі та виплати: окремі «золоті» IP/домени, пріоритетні черги, ізоляція ресурсів (taints/tolerations), резерв по базі.
Антибот/антифрод: heavy-моделі - на GPU-воркерах; онлайн-скоринг ≤ 50 мс p95; кеш фічей.
Регуляторика: незмінні логи і шифрування не повинні ламати SLO - включайте апаратні прискорення і асинхронні пайплайни.

Міні-плейбуки

Латентність ↑ після релізу:

1. Звірити burn-rate SLO; 2) профілі'cpu/alloc'; 3) відкат/фічфлаг; 4) збільшити репліки/API-кеш; 5) RCA і фіксація тесту.

Пікове навантаження (матч/турнір):

1. Прогріти CDN/кеш; 2) підняти minReplicas; 3) включити burst-ліміти; 4) рознести черги; 5) включити read-only-режим для другорядних функцій.

Типові помилки

Limits CPU «задушують» пікові ворклоади → високий p99.
Неправильний пул вузлів: змішують latency-критичні і batch.
Відсутність NUMA/IRQ-налаштувань на БД/брокерах.
«Лікуємо симптоми» (додаємо CPU) замість виправлення алгоритмів/кешів/SQL.
HPA по CPU замість по RPS/latency → скейлиться пізно.
Немає тестів продуктивності в CI → регресії в проді.

Підсумок

Оптимізація - це системна робота: вимірюйте SLI/SLO, профілюйте, виправляйте алгоритми, налаштовуйте залізо (NUMA/IRQ/IO/мережу), «правильно розмірьте» ресурси і автоматизуйте масштабування. Закріплюйте поліпшення в шаблонах (образи, чарти, політики), контролюйте вартість і енергію - і ваша платформа залишиться швидкою, економною і стійкою навіть в екстремальні піки.