Стоимость масштабирования: что дороже — вверх или вширь

MAATRIX

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

Два пути роста: что значит «вверх» и «вширь»

Вертикальное масштабирование (scale up) — это апгрейд одной машины: было 4 vCPU / 8 ГБ RAM, стало 8 vCPU / 16 ГБ. Приложение не замечает разницы — оно как работало на одном сервере, так и работает, просто у него теперь больше ресурсов. С точки зрения инфраструктуры это самый простой путь: в панели провайдера меняете тариф, сервер перезагружается, через пару минут работаете дальше.

Горизонтальное масштабирование (scale out) — это добавление ещё одной (и ещё, и ещё) машины той же или похожей конфигурации, а перед ними — балансировщик нагрузки (HAProxy, Nginx, облачный LB), который распределяет запросы между серверами. Приложение уже не может считать, что оно одно: если оно хранит сессии пользователей в памяти процесса или пишет файлы на локальный диск, при обращении к другому серверу пользователь эту сессию или файл не найдёт. Значит, горизонтальный рост почти всегда требует доработки приложения — вынести сессии в Redis, файлы в общее хранилище (S3-совместимое или NFS), а состояние базы данных развести на мастер и реплики.

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

Что дороже за единицу дополнительной мощности

Ключевая ошибка при сравнении — считать общую стоимость сервера, а не стоимость прироста мощности. Тариф на 8 vCPU не в два раза дороже тарифа на 4 vCPU — обычно дороже непропорционально, потому что в старших конфигурациях провайдер закладывает наценку за более редкое и дорогое железо (больше памяти на сокет, NVMe вместо SATA, выделенные ядра вместо overselling на младших тарифах).

Смотреть нужно не на абсолютную цену, а на удельную — сколько стоит один дополнительный vCPU или гигабайт RAM на каждой ступени апгрейда:

Это иллюстрация закономерности, а не прайс конкретного провайдера — у вас цифры будут другими, и это надо проверять по актуальному прайс-листу вашего хостера. Суть в форме кривой: до середины линейки цена растёт почти пропорционально ресурсам, а на топовых конфигурациях — заметно быстрее. Причина простая: топовые тарифы физически ограничены количеством серверов в дата-центре, которые вообще способны дать 32+ vCPU и десятки гигабайт RAM на одной машине, и провайдер закладывает в цену дефицитность этого железа.

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

Сложность внедрения: один клик против переделки архитектуры

Вертикальный апгрейд в классическом VPS — это в буквальном смысле смена тарифа в панели и перезагрузка. После неё стоит проверить, что система увидела новые ресурсы:

# сколько ядер видит система
nproc

# сколько памяти доступно
free -h

# если диск тоже увеличили — расширяем раздел и файловую систему
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1      # для ext4
# или
sudo xfs_growfs /              # для xfs

Больше делать почти ничего не нужно — разве что перепроверить лимиты в конфигах сервисов, которые были жёстко прописаны под старое железо (например, worker_processes auto; в Nginx сам подхватит новое число ядер, а вот max_connections в PostgreSQL или innodb_buffer_pool_size в MySQL, если они были выставлены вручную под старый объём RAM, нужно поднять руками).

Горизонтальный путь начинается с вопроса, который часто всплывает только на практике: а приложение вообще умеет жить на нескольких серверах? Проверочный список:

• Сессии. Если веб-фреймворк хранит сессии в файлах или в памяти процесса — нужно перенести их в Redis или БД, иначе пользователя после каждого запроса будет «перекидывать» между серверами и разлогинивать.
• Загруженные файлы. Файлы, которые пользователи загружают через форму, должны попадать в общее хранилище (S3-совместимое, например MinIO, или сетевой диск), а не на локальный диск одного из серверов.
• Фоновые задачи и очереди. Если крон-задачи или воркеры завязаны на конкретный сервер, при масштабировании нужно решить, кто и где их выполняет — иначе задача выполнится N раз вместо одного.
• База данных. Сама БД в горизонтальной схеме обычно остаётся на одном (или паре с репликацией) сервере — растят вширь чаще всего именно веб-слой и слой приложения, а не БД.

Дальше — настройка самого балансировщика. Минимальный конфиг HAProxy для двух бэкендов:

frontend web_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    server web1 10.0.0.11:8080 check
    server web2 10.0.0.12:8080 check

Это не разовая правка — дальше вам нужно поддерживать деплой на несколько машин одновременно (обычно через CI/CD или Ansible), следить, чтобы конфиги на серверах не расходились, и добавить /health эндпоинт в приложение, чтобы балансировщик понимал, живой сервер или нет. Разовая трудоёмкость выше на порядок, чем у вертикального апгрейда, зато один раз настроенная схема добавляет следующие серверы уже почти без усилий.

Отказоустойчивость: почему горизонталь надёжнее по своей природе

Здесь разница принципиальная, а не количественная. При вертикальном масштабировании у вас всегда один сервер — точка отказа. Апгрейд тарифа обычно требует перезагрузки (простой от нескольких секунд до пары минут, в зависимости от провайдера), а любой аппаратный сбой хост-ноды укладывает весь сервис целиком, пока не поднимется резервная копия.

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

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

Потолок роста: где заканчивается вертикаль

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

Практическая разница в том, как выглядит следующий шаг роста:

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

Методика: когда пора переходить с вертикали на горизонталь

Правило простое: считайте не абсолютную цену тарифа, а удельную стоимость следующего шага — сколько стоит единица прироста мощности (условно, 1 vCPU или 1 ГБ RAM) при переходе с текущего тарифа на следующий:

удельная_стоимость_шага = (цена_нового_тарифа − цена_текущего_тарифа) / (ресурс_нового − ресурс_текущего)

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

Дополнительные признаки, что пора горизонтально:

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

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

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

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