Налаштування AIOps для Capacity Planning (прогнозування ресурсів)

Налаштування AIOps для Capacity Planning (прогнозування ресурсів)

Після запуску сезонного проєкту ви помічаєте, що ноди кластера впираються в ліміти по пам'яті, а автоскейлер не встигає підхопити навантаження — користувачі отримують 503 помилки. Ми стикалися з цим на проєктах з 500+ нод: відтік користувачів, падіння репутації. Це проблема реактивного масштабування. Ми вирішуємо її за допомогою AIOps: будуємо прогнози на основі історичних метрик з Prometheus та машинного навчання. Замість грубого підходу «додамо 20%» використовуємо модель Prophet від Meta — вона передбачає потребу в ресурсах на 30 днів з точністю ±15%. Правильний прогноз економить до 30% бюджету на інфраструктуру, а бізнес-метрики (акції, кількість користувачів) підвищують точність ще на 20–40%. Типовий клієнт з 50 нодами економить $5000 на місяць на хмарних ресурсах.

Які метрики прогнозуємо і звідки беремо дані

Ресурси, які ми плануємо в першу чергу:

• CPU та пам'ять на нодах кластера (Kubernetes node utilization)
• Дисковий простір (особливо для баз даних та логів)
• Пропускна здатність мережі
• IOPS сховища (критично для PostgreSQL, Elasticsearch)
• Кількість подів та ліміти кластера

Як AIOps будує прогноз: Prometheus + Prophet

Типова архітектура для self-hosted:

Prometheus (Thanos/VictoriaMetrics для long-term storage) ↓
remote_read API
Python forecasting service (Prophet / statsmodels) ↓
Прогнози записуються як метрики → Prometheus pushgateway ↓
Grafana dashboard з forecast overlay

Приклад скрипта, який читає утилізацію CPU нод і будує прогноз на 30 днів:

from prophet import Prophet
import pandas as pd
from prometheus_api_client import PrometheusConnect

prom = PrometheusConnect(url="http://prometheus:9090")
data = prom.get_metric_range_data(
    metric_name='avg by (node) (1 - rate(node_cpu_seconds_total{mode="idle"}[5m]))',
    start_time=datetime.now() - timedelta(days=60),
    end_time=datetime.now(),
    chunk_size=timedelta(hours=1)
)

df = pd.DataFrame({"ds": timestamps, "y": values})
model = Prophet(seasonality_mode="multiplicative", weekly_seasonality=True)
model.fit(df)
future = model.make_future_dataframe(periods=30, freq="D")
forecast = model.predict(future)
# forecast[["ds", "yhat", "yhat_lower", "yhat_upper"]]

yhat_upper (верхня межа довірчого інтервалу) — це «песимістичний» сценарій, від якого ми рекомендуємо планувати закупівлю ресурсів.

Чому важливо враховувати бізнес-метрики?

Технічні метрики самі по собі не пояснюють, коли очікувати зростання навантаження. Якщо додати в модель бізнес-дані — кількість активних користувачів, обсяг замовлень, маркетинговий календар (дати акцій, сезонні піки) — прогноз стає точнішим. Ми створюємо regressor в Prophet для кожної бізнес-події:

model.add_regressor('is_black_friday') model.add_regressor('monthly_active_users') 

Дані про MAU беремо з аналітичної БД, події — з бізнес-календаря. Модель сама визначає, наскільки сильно кожен фактор впливає на споживання ресурсів.

Яких помилок уникати при впровадженні?

Типова помилка — використовувати лише тиждень даних для прогнозу. Цього недостатньо для виявлення сезонності. Ми рекомендуємо мінімум 4–8 тижнів, оптимально 3–6 місяців. Друга помилка — ігнорувати бізнес-регресори. Без них модель не зможе передбачити піки від маркетингових акцій. Третя — покладатися лише на середнє значення прогнозу (yhat). Завжди використовуйте верхню межу (yhat_upper) для замовлення ресурсів, щоб уникнути нестачі.

Kubernetes: від прогнозу до автоматичного масштабування

Capacity planning не обов'язково закінчується ручною закупівлею серверів. В Kubernetes прогнози можна підключити до KEDA (Kubernetes Event-Driven Autoscaling) через prometheus scaler — поди будуть масштабуватися проактивно, до настання навантаження.

Для нод-пулу в managed-кластерах (EKS, GKE, AKS) налаштовуємо Cluster Autoscaler або Karpenter з буфером, розрахованим на основі прогнозу. Karpenter зручніший: він замовляє ноди потрібного типу та розміру під передбачуване навантаження.

Що входить в нашу роботу

• Аудит поточних метрик і SLO, оцінка глибини історичних даних (мінімум 4–8 тижнів, оптимально 3–6 місяців)
• Налаштування long-term storage, якщо його немає (Thanos, VictoriaMetrics, Grafana Mimir)
• Розробка forecasting pipeline на Prophet з урахуванням бізнес-метрик (опціонально)
• Інтеграція з KEDA і Cluster Autoscaler / Karpenter
• Налаштування Grafana-дашбордів з forecast overlay та оповіщень («через 14 днів нода вичерпає пам'ять»)
• Навчання вашої команди роботі з дашбордами та інтерпретації прогнозів
• Постпроектна підтримка протягом місяця

Приклад економії: для клієнта з піковим навантаженням в «чорну п'ятницю» ми налаштували прогноз на основі 12 місяців метрик. Результат: зниження витрат на 25% за рахунок відмови від надлишкових резервів (раніше тримали +40% про запас). Прогноз на Prophet показав, що достатньо буфера в 15% з урахуванням бізнес-регресорів.

Підсумковий процес роботи

1. Аналітика: аудит метрик, SLO, бізнес-календаря
2. Проєктування: вибір архітектури (Thanos vs Mimir, Prophet vs statsmodels)
3. Реалізація: розгортання пайплайна, налаштування дашбордів, інтеграція з K8s
4. Тестування: A/B-тест прогнозу на історичних даних, звірка з real-time метриками
5. Деплой: підключення до продакшену, налаштування оповіщень

Терміни та вартість

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

Наш досвід: 7+ років в DevOps, 50+ проєктів з масштабування інфраструктури, сертифіковані спеціалісти AWS та Kubernetes. Гарантуємо точність прогнозу в межах 15% від фактичного споживання.