Кейс 3. Прогноз потребления ресурсов сервера

Этот кейс находится на стыке машинного обучения и DevOps. В отличие от предыдущих примеров, здесь речь идёт не о бизнес-объектах и не о людях, а о системе – сервере или сервисе, который работает под нагрузкой.

Такие задачи встречаются повсеместно: от внутренних микросервисов до высоконагруженных API. И что важно – линейные модели здесь используются не "для учебника", а как реальный baseline в production.

Суть кейса

Представим сервис, который обрабатывает пользовательские запросы. Нам нужно предсказать, какую нагрузку на CPU или RAM он будет испытывать в ближайшее время, чтобы заранее принять решение об auto-scaling или throttling.

Мы используем следующие признаки:

• количество запросов в минуту

• средний размер ответа

• количество активных пользователей

• количество фоновых задач / cron jobs

• время суток, представленное числом (например, 0–23) В реальных системах время суток чаще кодируют циклически (sin/cos) или бинарными признаками (day/night), однако для baseline-модели мы будем используется упрощённое числовое представление

Цель – предсказать загрузку CPU (в процентах) или потребление памяти.

С точки зрения ML это классическая задача регрессии с числовыми признаками и числовой целевой переменной.

Почему это реалистичный кейс

Во-первых, линейные модели очень часто используются как baseline в DevOps-аналитике. Они быстрые, устойчивые и легко интерпретируются.

Во-вторых, этот кейс отлично демонстрирует важность feature engineering. Например, время суток само по себе – слабый признак, но в сочетании с нагрузкой может хорошо отражать дневные и ночные паттерны.

В-третьих, такие модели реально применяются для auto-scaling, особенно там, где сложные модели избыточны или слишком дороги в обслуживании.

Реалистичный сценарий использования

Данные для обучения обычно поступают из инфраструктурных источников:

• метрики CPU, RAM и RPS – из Prometheus

• дополнительные параметры – из логов или APM

• агрегация – за фиксированные интервалы времени (например, 1 минута)

Модель может переобучаться регулярно – раз в десятки минут или часы, в зависимости от динамики нагрузки. Предсказание используется системой оркестрации (Kubernetes, autoscaler) или внутренним monitoring-tool.

Важно, что здесь модель часто живёт долго и работает "на фоне", а не как разовый аналитический эксперимент.

Формализация задачи

Каждое наблюдение описывается вектором:

$$\mathbf{x} = (x_1, x_2, x_3, x_4, x_5)$$

Где:

• $x_1$ – количество запросов в минуту

• $x_2$ – средний размер ответа

• $x_3$ – количество активных пользователей

• $x_4$ количество фоновых задач / cron jobs

• $x_5$ – время суток

Модель линейной регрессии:

$$\hat{y} = w_1 x_1 + w_2 x_2 + w_3 x_3 + w_4 x_4 + w_5 x_5 + b$$

где $\hat{y}$ – предсказанная нагрузка CPU в процентах.

Реализация с RubixML

В этом кейсе мы снова используем библиотеку, потому что в инфраструктурных задачах важны стабильность и поддерживаемость кода.

Подготовка данных

use Rubix\ML\Datasets\Labeled;
use Rubix\ML\Regressors\LinearRegression;

// [requests_per_min, avg_response_size, active_users, cron jobs, hour]
$samples = [
    [1200, 15, 300, 15, 14],
    [800, 10, 200, 9, 2],
];

$targets = [
    75.0, // CPU %
    40.0,
];

$dataset = Labeled::build($samples, $targets);

Каждая строка здесь – агрегированная метрика за один временной интервал. Количество строк в примере сокращено для наглядности.

Обучение модели

$model = new LinearRegression();
$model->train($dataset);

Обучение занимает миллисекунды и может спокойно выполняться регулярно.

Предсказание нагрузки

$futureMetrics = [1000, 12, 250, 10, 16];
$cpuLoad = $model->predict($futureMetrics);

echo "Ожидаемая загрузка CPU: " . round($cpuLoad[0], 1) . "%\n";

// Результат: 
// Ожидаемая загрузка CPU: 69.2%

Такое предсказание может использоваться как дополнительный сигнал в логике auto-scaling или при принятии решений об изменении ресурсов.

Интерпретация коэффициентов

Как и в предыдущих кейсах, линейная модель ценна своей интерпретируемостью.

$weights = $model->weights();
$bias = $model->intercept();

print_r($weights);
echo "Bias: $bias\n";

// Результат: 
// Array (
//    [0] => 0.075903414748609
//    [1] => 0.33433830738068
//    [2] => -0.17070814035833
//    [3] => 0.19324654340744
//    [4] => 1.573189586401
// )
// Bias (intercept): 5.1899118423462

Интерпретация обычно выглядит так:

• коэффициент при запросах в минуту отражает базовую нагрузку от RPS

• коэффициент при размере ответа показывает влияние сетевых и сериализационных накладных расходов

• количество активных пользователей часто коррелирует с конкуренцией за ресурсы

• количество фоновых задач может показывать, как съедаются ресурсы параллельно с основной нагрузкой

• время суток может отражать фоновые процессы или особенности дневных пиков

Такая модель позволяет не только предсказывать, но и понимать, почему растёт нагрузка. Однако нужно понимать, что интерпретация коэффициентов корректна при условии, что признаки не находятся в сильной корреляции и модель обучена на репрезентативном объёме данных.

Обучение "на лету" и concept drift

В DevOps-кейсе данные со временем меняются. Добавляются новые фичи, меняется профиль трафика, появляются кэши и оптимизации. В инфраструктурных системах это проявляется как data drift и изменение зависимости между метриками (concept drift в инженерном смысле).

Линейная модель здесь удобна тем, что её можно:

• регулярно переобучать на свежих данных

• использовать скользящее окно последних метрик

• быстро заменить или пересобрать без сложной инфраструктуры

Даже если модель становится неточной, она деградирует плавно и предсказуемо.

Ограничения модели

Линейная регрессия не умеет ловить резкие скачки, нелинейные эффекты и saturation-поведение (например, когда CPU упирается в 100%).

Но именно поэтому она хороша в качестве отправной точки. Если линейная модель уже даёт полезный сигнал – усложнять систему стоит только при реальной необходимости.

Выводы по кейсу

Этот кейс показывает, что машинное обучение может быть естественной частью инфраструктуры. Без нейросетей, без GPU и без сложных пайплайнов.

Линейная регрессия здесь выступает как инженерный инструмент: простой, объяснимый и достаточно надёжный. В DevOps-мире это часто важнее максимальной точности.

Чтобы самостоятельно протестировать этот код, установите примеры из официального репозитория GitHub или воспользуйтесь онлайн-демонстрацией для его запуска.