Отчёты, которые считаются ночью: зачем им отдельный сервер

MAATRIX

Каждую ночь на проде запускается тяжёлый расчёт: строятся отчёты за день, гоняется ETL, пересчитывается ML-модель на свежих данных. Днём об этом никто не думает — задача тихо ждёт своего окна. А утром либо приходит алерт о просевшем времени отклика сайта в три часа ночи, либо аналитик жалуется, что отчёт вчера досчитался только к обеду. Первая реакция — подкрутить nice, поставить cgroup-лимиты, сдвинуть окно на попозже. Это работает до определённого момента, а потом перестаёт: расчёт растёт быстрее, чем можно ужать его аппетит к ресурсам общего сервера. Разберём, где проходит эта граница и когда дешевле и надёжнее вынести ночные вычисления на отдельную машину, а не продолжать делить одну.

Чем ночной расчёт отличается от обычной фоновой задачи

Cron-задача, которая раз в час подчищает временные файлы или отправляет уведомления, почти никогда не создаёт проблем: она секунды, максимум минуты, и почти не ест ресурсов. Ночной расчёт отчётов — другое животное. У него три особенности, которые и делают его тяжёлым соседом:

• Он монопольно грузит один ресурс на долгое время. Построение отчёта — это чаще всего один длинный SQL-запрос с агрегацией по всей таблице за день, а то и за месяц. Это минуты, иногда часы непрерывной работы диска и процессора, а не короткий всплеск.
• Ему нужен весь датасет, а не его горячий срез. Веб-приложение работает с последними записями, которые обычно уже в буферном кеше. Отчёт читает историю целиком — а значит, вымывает из кеша страницы, нужные продовому трафику, и заставляет диск работать на пределе IOPS.
• Он растёт вместе с бизнесом, а не линейно. Пока данных мало, отчёт считается за пять минут. Через год объём вырастает в разы, а сложность агрегаций — ещё больше, потому что к отчётам добавляются новые срезы. Ресурсы, которых хватало на старте, перестают хватать незаметно.

Именно третий пункт — причина, по которой попытки «просто ограничить» расчёт cgroup-лимитами или ionice работают только временный период. Лимит, подобранный под сегодняшний объём данных, через полгода снова начинает конфликтовать с продом — просто потому что задача стала тяжелее, а сервер не вырос вместе с ней. О том, как в принципе смягчить конфликт ночных пакетных задач с дневной нагрузкой на общем сервере — окнами, приоритетами, лимитами cgroup — стоит почитать отдельно: там разобран именно этот, более дешёвый первый шаг, до которого имеет смысл дойти прежде, чем выносить расчёт на отдельное железо.

Что именно выносят на отдельный сервер

Не любой ночной cron достоин отдельной машины — экономика имеет смысл только для задач определённого масштаба. На практике на отдельный сервер выносят три типа нагрузки:

1. Построение регулярной отчётности. Ежедневные, еженедельные и ежемесячные отчёты, которые агрегируют данные по всей истории: выручка по когортам, воронки, финансовая сверка. Это классический OLAP-паттерн, который плохо уживается с OLTP-нагрузкой прода на одном движке и одном диске.
2. ETL и подготовка данных. Выгрузка из прод-базы, трансформация, загрузка в аналитическое хранилище — ClickHouse или отдельный PostgreSQL под аналитику. В обоих случаях выгрузка и трансформация — это тяжёлое чтение всей истории, которое логично держать подальше от прод-транзакций.
3. ML-расчёты и переобучение моделей. Ночной retraining на свежих данных, батчевый инференс по всей базе клиентов, построение эмбеддингов. Это уже не просто диск и CPU, а часто ещё и GPU — ресурс, которого на типовом веб-сервере попросту нет, и добавить его туда «немного» нельзя.

Общая черта всех трёх — они не пользуются интерактивным трафиком прода напрямую, читают данные пакетами, и результат нужен не мгновенно, а к утру. Это именно то, что архитектурно можно и стоит развести физически, а не только логически через лимиты.

Экономика: доп. сервер под ночную нагрузку против рисков общего

Решение считается через сравнение двух статей расходов, а не через «на всякий случай возьмём помощнее».

Стоимость отдельного сервера под ночные расчёты. Такой сервер не обязан быть топовым — он занят несколько часов в сутки, а не круглосуточно под пиковой нагрузкой. Для построения отчётов и ETL хватает конфигурации среднего класса с упором в RAM и NVMe, без переплаты за максимальную частоту CPU. Про то, как в принципе подбирается конфигурация под аналитику больших данных — ядра, память, диск — есть отдельный разбор в статье про выделенный сервер для аналитики больших данных; для ML-нагрузки с обучением моделей логика конфигурации своя, с акцентом на GPU и объём видеопамяти — она разобрана в статье про выделенный сервер для машинного обучения.

Стоимость рисков от общего сервера. Сюда входит не только прямой инцидент (просевший отклик сайта ночью, если у вас есть ночные заказы или международная аудитория в других часовых поясах), но и скрытые издержки: время инженера на подбор и постоянную подстройку лимитов cgroup, задержка самих отчётов, если расчёт не укладывается в окно и переезжает на день, риск полной остановки сервиса при баге в расчёте. Отдельно стоит посчитать цену простоя, если он всё же случается, — методика такого расчёта разобрана в статье о цене простоя на пике, и она применима не только к распродажам, но и к любому пику, включая ночной, если у бизнеса есть активность в это время.

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

Как физически развести данные между серверами

Ключевой вопрос выноса — не «где считать», а «откуда брать данные», не создавая при этом нагрузку на прод хуже исходной.

Реплика базы данных. Самый частый вариант — поднять read-реплику прод-БД на втором сервере и строить отчёты по ней. Для PostgreSQL это штатная потоковая репликация (streaming replication), которая почти не грузит мастер — WAL передаётся асинхронно, а тяжёлые запросы полностью изолированы на реплике:

# на мастере, postgresql.conf
wal_level = replica
max_wal_senders = 5
wal_keep_size = 1GB

# на реплике, при первом старте
pg_basebackup -h master_host -D /var/lib/postgresql/data -U replicator -P -R

Отчёты и ETL читают данные с реплики, а не с мастера — прод вообще не замечает нагрузку от построения отчёта.

Отдельное аналитическое хранилище. Если объём и характер запросов оправдывают ClickHouse или отдельный OLAP-контур, данные выгружаются пакетами по расписанию — раз в час или раз в сутки, в зависимости от требуемой свежести отчётов. Это уже не репликация в реальном времени, а батчевый ETL, который сам по себе легче для сети и мастер-базы, чем постоянный поток изменений.

Приватная сеть между серверами. Трафик между продом и аналитическим сервером не должен идти через публичный интернет — и по соображениям безопасности, и ради скорости. Как поднять приватную сеть между своими серверами внутри одного дата-центра или между локациями — разобрано отдельно; в контексте ночных расчётов это тот же принцип: реплика и ETL общаются с мастером по внутренней сети, а не по внешнему IP.

Что переносить не нужно. Сама бизнес-логика приложения и таблицы, не участвующие в отчётности, остаются на проде. Переносится только то, что реально читает большие объёмы: витрины для BI-инструментов, сырые данные для ML-пайплайна, промежуточные таблицы ETL.

Практическая схема запуска ночного расчёта на отдельном сервере

Когда данные разведены, сам ночной запуск строится по понятной схеме:

1. Расписание сдвинуто относительно реплики. Реплика должна успеть догнать мастер до старта расчёта — иначе отчёт считается по неполным данным. Пауза в 15-30 минут между условным «концом дня» и стартом job обычно достаточна, но её стоит проверить по факту лага репликации на своих объёмах.
2. Мониторинг лага репликации отдельно от мониторинга самого расчёта. Это две разные точки отказа: реплика может отстать из-за сетевых проблем, а расчёт — упасть из-за бага в самом запросе. Смешивать их в один алерт не стоит.
3. Идемпотентность расчёта. Если job упал на середине, повторный запуск не должен задваивать данные в итоговом отчёте. Это база пакетной обработки, но именно на ночных задачах про неё чаще всего забывают, потому что «раньше на одном сервере как-то работало».
4. Уведомление о готовности, а не просто лог. Аналитик или дашборд должны узнавать, что отчёт готов, не через ручную проверку логов в 9 утра, а через уведомление или статус в системе мониторинга.

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

Когда отдельный сервер не нужен

Честно: для большинства проектов ночной расчёт прекрасно живёт на общем сервере годами. Отдельная машина оправдана не по умолчанию, а при совпадении нескольких признаков:

• Расчёт регулярно вылезает за границы выделенного окна и начинает задевать утренний трафик.
• Объём данных для отчётов растёт быстрее, чем растёт сам прод-сервер по апгрейдам.
• В плане появляется ML-нагрузка, которой нужен GPU — ресурс, который на типовом веб-сервере физически негде взять.
• Есть требование по разделению доступа: аналитикам нельзя давать прямой доступ к прод-базе, а к реплике на отдельном сервере — можно.
• Инцидент от ночного расчёта на проде уже случался хотя бы раз, и повторение стоит дороже аренды второго сервера.

Если ни один из пунктов не про вас, а расчёт исправно укладывается в ночное окно — вкладываться стоит не в новое железо, а в более аккуратные лимиты и расписание на существующем сервере. Разделение сервера должно идти за реальной конкуренцией за ресурсы, а не за «на всякий случай» — этот принцип разобран отдельно в статье делим сервер по нагрузке, а не по красоте, и он в равной мере применим и к дневным, и к ночным задачам.

Частые вопросы