Разделять сервисы или просто докупить памяти: развилка ценой в одну зарплату

MAATRIX

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

Почему это не техническая развилка, а экономическая

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

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

Именно поэтому сравнивать варианты «сколько стоит апгрейд» против «сколько стоит разделение» по одной строке счёта за хостинг — методологическая ошибка. Честное сравнение выглядит так:

Ни один из вариантов не «правильнее» другого по умолчанию — оба имеют свою область применимости, и дальше разберём, как её определить для конкретной ситуации.

Метафора «одной зарплаты»: как считать реальную стоимость разделения

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

Что входит в реальную стоимость, которую легко забыть при быстром решении «давайте разделим»:

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

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

Когда апгрейд — разумный выбор, а не откладывание проблемы

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

Апгрейд — разумный выбор, когда выполняются оба условия:

1. Проблема действительно в нехватке ресурса, а не в конкуренции компонентов за него. Если памяти или CPU физически не хватает на всех — простое увеличение объёма снимает проблему целиком, независимо от того, сколько сервисов крутится на сервере.
2. Апгрейд решает проблему на приемлемый срок. Если после увеличения ресурсов сервер спокойно работает многие месяцы, а не упирается снова через две-три недели — это не временная заплатка, это адекватное решение для текущего масштаба проекта.

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

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

Когда разделение оправдано: явная конкуренция за ресурс

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

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

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

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

# Загрузка CPU по ядрам за последние сутки — есть ли постоянные пики под 100%
mpstat -P ALL 1 5

# Использование памяти и своп — регулярно ли уходите в своп под нагрузкой
free -h
vmstat 1 5

# Топ процессов по памяти и CPU в момент нагрузки
top -o %MEM

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

Гибридный путь: апгрейд как временная мера перед разделением

Апгрейд и разделение не обязательно взаимоисключающие варианты в моменте — часто разумно использовать апгрейд как временную меру, которая покупает время на спокойную подготовку к разделению, вместо того чтобы делать миграцию в панике посреди инцидента.

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

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

Стоит только не путать «временную меру» с «навсегда отложенным решением» — если проблема конкуренции компонентов реальна, апгрейд её не решит, а просто даст больше времени на подготовку к тому решению, которое действительно нужно.

Практический план принятия решения

Собрать всё сказанное в последовательность конкретных шагов, которую можно применить к своей ситуации:

1. Проверьте метрики, а не ощущения. Загрузка CPU, память, своп, дисковый I/O за период, когда сервер «тормозит». Определите, действительно ли не хватает ресурса в целом, или конкретный процесс методично выедает ресурс у соседей в определённые моменты.
2. Проверьте потолок тарифа. Есть ли у вашего провайдера план мощнее текущего? Если да и апгрейд решает проблему по метрикам из пункта 1 — это самый быстрый и дешёвый путь.
3. Если апгрейда достаточно — берите его. Не усложняйте архитектуру ради архитектуры. Заложите в план ревизию через несколько месяцев: если апгрейд снова не хватает — это уже сигнал вернуться к пункту 1 с вопросом «почему».
4. Если конкуренция компонентов подтверждена метриками, а не предположением — считайте стоимость разделения честно. Часы на планирование, миграцию, тестирование, разбор багов после переезда, плюс постоянный операционный налог от двух серверов вместо одного. Сравните эту сумму с ценой апгрейда за сопоставимый период.
5. Если разделение оправдано — не делайте его в панике. Используйте текущий (возможно, только что апгрейженный) сервер как буфер по времени, спланируйте перенос спокойно, с тестовым прогоном и планом отката.

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

Если по итогам этого разбора вы решили, что вам всё же нужно разделение, — практическая механика самого переноса (как разнести базу и приложение по двум серверам без потери данных и с минимальным простоем) разобрана отдельно в статье про переезд с одного VPS на два. Если же вы только запускаете проект и решаете, сколько ресурсов закладывать заранее, чтобы позже не пришлось выбирать между этими двумя путями в спешке, — см. статью сколько ресурсов брать на старте проекта.

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