Делим сервер по нагрузке, а не по красоте: что разъезжается первым

MAATRIX

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

Почему «логично на бумаге» — не то же самое, что «первое узкое место»

На одном сервере несколько процессов делят четыре ресурса: оперативную память, дисковый ввод-вывод, процессорное время и сетевые сокеты. Архитектурная логика подсказывает разделять их по типу нагрузки — «база отдельно, потому что это статeful-сервис», «очереди отдельно, потому что это фоновая работа». Это разумная долгосрочная цель, но она ничего не говорит о том, что именно вызывает проблемы у вас сегодня.

На практике конкуренция за ресурсы редко распределяется поровну между компонентами. Часто один процесс методично выедает буферный кеш файловой системы, вытесняя из него страницы, нужные соседям, — и тогда именно он первый кандидат на переезд, независимо от того, «логично» это по архитектуре или нет. В другом проекте тот же самый компонент годами живёт мирно рядом с остальными, потому что просто не успевает вырасти до объёмов, при которых начинает мешать.

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

Первой чаще всего уезжает база данных

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

Реляционная СУБД (PostgreSQL, MySQL) держит в оперативной памяти буферный пул — кеш страниц данных и индексов, от размера которого напрямую зависит, полетит запрос из памяти или уйдёт на диск. Чем больше памяти отдано под буферный пул, тем быстрее база — это в её интересах забирать себе как можно больше доступной RAM. Приложение со своей стороны хочет памяти под собственные процессы, соединения, кеши рантайма. Когда оба на одном сервере, они физически спорят за одни и те же гигабайты: при нехватке памяти проигрывает либо буферный пул базы (растёт число обращений к диску, замедляются запросы), либо процессы приложения (начинается своп или их убивает OOM killer).

Признаки, что база уже начала конкурировать с приложением за ресурсы сервера, стоит смотреть не на глаз, а по метрикам:

# Доля памяти под файловый/буферный кеш и реальный своп
free -m

# Активность свопа за интервал — ненулевые si/so означают нехватку памяти
vmstat 2 5

# Загрузка диска и время ожидания I/O по устройствам
iostat -xz 1 5

Если iowait в iostat стабильно заметен именно в моменты пиковой нагрузки на приложение, а не сам по себе, — это симптом, что база и приложение соревнуются за один и тот же диск. Второй характерный сигнал — рост времени ответа обычных, не самых тяжёлых запросов к базе именно в момент всплеска активности веб-процессов, а не при росте объёма самих данных.

Разделение базы на отдельный сервер решает это напрямую: у базы появляется своя память под буферный пул, свой диск под I/O и свой процессор под планировщик запросов, не деля их с процессами приложения. Побочный эффект — сеть между приложением и базой становится отдельным звеном, которое раньше было localhost-вызовом внутри одной машины, а стало сетевым запросом. Эту связь стоит закрыть отдельно, не полагаясь на то, что «база теперь просто не видна снаружи по умолчанию», — про это приватная сеть между своими серверами.

Отдельно стоит сказать про размер конфигурации при переезде: сервер под базу обычно рассчитывают не «сколько было раньше», а исходя из объёма данных и рабочего набора (working set) — какая доля базы реально читается и пишется активно, а не лежит холодным архивом. Перенос базы почти всегда сопровождается пересмотром выделенной ей памяти, а не переносом «один в один» тех же цифр, что были в общей конфигурации.

Следом обычно уезжают тяжёлые фоновые и batch-задачи

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

Причина, по которой они чаще уезжают раньше кеша, — характер их нагрузки. В отличие от базы, которая давит ровно и предсказуемо пропорционально трафику, фоновые задачи создают скачки: воркер очереди простаивает, пока задач нет, а затем разом забирает пачку — и на несколько секунд или минут выедает столько CPU и памяти, сколько ему разрешено. Если такой воркер живёт на том же сервере, что и веб-процессы, каждый такой всплеск бьёт по времени ответа обычных пользовательских запросов, причём не постоянно, а рывками — что как раз и описывает симптом «сайт тормозит не всегда, а рывками» с самого начала статьи.

Проверить это можно по корреляции во времени, а не по абсолютным цифрам нагрузки:

# Снимок процессов, отсортированный по потреблению CPU — ловить сразу после жалобы на тормоза
ps aux --sort=-%cpu | head -20

# Интерактивный мониторинг с историей — удобно поймать сам момент скачка
htop

Если в момент, когда сайт «подвис», в списке процессов оказывается воркер очереди или batch-скрипт, съедающий заметную долю CPU или память, — это прямое указание, что источник рывков не база и не веб-сервер, а фоновая обработка. Второй косвенный признак — глубина самой очереди задач растёт волнами, а не равномерно: это видно по длине очереди в брокере (Redis, RabbitMQ, встроенная таблица задач) в динамике, а не в моменте.

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

Стоит сделать оговорку: не любая фоновая задача создаёт такую проблему. Лёгкие периодические джобы (отправить пару писем, обновить статус) обычно не заметны на фоне остальной нагрузки и годами живут на общем сервере без последствий. Разделять стоит именно тяжёлые и/или пакетные задачи — там, где всплеск потребления ресурсов реально сопоставим с ресурсами, которые нужны основному трафику.

Кеш часто может подождать — но не всегда

Redis и подобные in-memory кеши часто остаются на общем сервере дольше, чем база и фоновые задачи, — и это не случайность, а следствие их устройства при умеренном объёме данных.

Пока объём кешируемых данных небольшой, Redis потребляет предсказуемое и скромное количество памяти, а нагрузка на CPU у него минимальна — операции чтения/записи по ключу дешёвы по своей природе. В этом состоянии кеш не создаёт заметной конкуренции ни за память, ни за диск, ни за процессор — и спокойно живёт рядом с приложением и даже с базой, если она ещё не выделена.

Ситуация меняется по мере роста объёма данных в кеше или интенсивности операций. Здесь стоит следить конкретно за:

# Реальное потребление памяти Redis и служебные накладные расходы
redis-cli INFO memory

# Активность операций в секунду — резкий рост говорит о росте нагрузки на CPU кеша
redis-cli INFO stats | grep instantaneous_ops_per_sec

Момент, когда кеш стоит выносить отдельно, — не фиксированный объём в гигабайтах (у разных проектов он будет своим, и называть тут конкретную цифру как универсальный порог было бы нечестно), а момент, когда used_memory из INFO memory начинает заметно давить на общий бюджет памяти сервера, либо когда операции с диском (снапшоты RDB, дозапись AOF) начинают конкурировать за I/O с базой. Второй сигнал — процесс Redis начинает регулярно попадать в верхние строчки htop по CPU, чего для лёгкого кеша быть не должно.

Есть и обратная ситуация, о которой часто забывают: кеш, оставленный на общем сервере дольше, чем следовало, иногда обгоняет по риску даже базу — если ему не задан явный лимит памяти (maxmemory) и политика вытеснения (maxmemory-policy), он может расти, пока не начнёт вытеснять из памяти всё остальное, включая буферный кеш той же базы. Это отдельная и частая причина внеплановых инцидентов, не связанная напрямую с ростом полезной нагрузки.

Как определить порядок именно для вашего проекта

Типовой порядок «база → тяжёлые фоновые задачи → кеш» подтверждается на практике достаточно часто, чтобы быть разумной отправной точкой, но не заменяет проверку по факту. Метод простой: вместо того чтобы копировать чужую архитектуру, нужно найти, что чаще всего реально вызывает проблемы именно на вашем сервере, — и разделять в этом порядке, каким бы он ни оказался.

Практический чек-лист:

1. Зафиксировать момент проблемы — не «сайт иногда тормозит», а конкретные временные отметки по логам мониторинга или жалобам пользователей.
2. Поднять метрики сервера за эти отметки, а не за случайный интервал. Загрузка CPU по процессам, память и своп, iowait по дискам, длина очередей — всё это нужно с историей, иначе момент проблемы будет упущен к тому времени, когда вы откроете top.
3. Найти процесс, чья кривая совпадает с моментом проблемы, а не просто занимает больше всего ресурсов в среднем. Компонент, который ровно потребляет много ресурсов постоянно, может быть не источником проблемы, а просто крупным потребителем — интереснее тот, чья нагрузка скачет синхронно с жалобами.
4. Проверить гипотезу изоляцией, если это возможно без риска для прода: временно ограничить ресурсы подозреваемого процесса через cgroups или systemd (MemoryMax=, CPUQuota=) и посмотреть, вернулась ли проблема в том же виде.
5. Разделять именно то, что подтвердилось метриками, а не то, что первым в списке типового порядка.

Отдельно стоит подчеркнуть: сама по себе высокая загрузка компонента — не автоматический повод его выносить. Вопрос не «что нагружено сильнее всего», а «что из-за конкуренции за общие ресурсы сервера мешает остальным». Разбор именно такой путаницы — когда искали тормоза не там, где реальная причина оказалась в очереди за CPU у соседнего процесса, а не в самом коде, — есть в статье про три недели поиска тормозов, которые упирались в очередь за CPU. Общий подход к тому, кто и как нагружает сервер, если непонятно, с чего начать диагностику, разобран в статье как узнать, кто нагружает сервер.

Когда не стоит разделять превентивно

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

У одного сервера есть свои проблемы (конкуренция за ресурсы, единая точка отказа), но и свои преимущества, которые легко потерять из виду в погоне за «правильной» многосерверной схемой:

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

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

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

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