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

MAATRIX

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

Что сравниваем: пять VPS против одного крупного сервера

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

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

Сравнение имеет смысл делать только при сопоставимых суммарных ресурсах. Пять серверов по 2 vCPU и 4 ГБ ОЗУ против одного сервера на 10 vCPU и 20 ГБ ОЗУ — корректная пара для сравнения. Пять серверов против одного, у которого ресурсов вдвое меньше суммы — это уже другая задача, там сравнивать нечего, крупный проиграет по определению.

Цена за ядро: эффект масштаба поставщика

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

Эффект не универсален и не всегда большой. У части хостеров линейка тарифов почти линейна — младший и старший план отличаются по цене за ядро незначительно, особенно в верхней части линейки, где разница между соседними тарифами часто меньше, чем между младшими планами. У других провайдеров скидка за объём заметна только на выделенных серверах, а на VPS-тарифах её почти нет. Прежде чем делать выводы для конкретного случая, стоит открыть прайс-лист провайдера и вручную посчитать цену за ядро и за гигабайт для нескольких соседних тарифов — универсальной цифры здесь дать нельзя, слишком по-разному устроены линейки у разных хостеров.

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

Вывод по первой метрике простой и в целом ожидаемый: по чистой стоимости железа крупная конфигурация чаще выигрывает или как минимум не проигрывает мелким. Но это только половина уравнения.

Что такое «точка» в инфраструктуре и что она стоит

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

• своя операционная система со своим циклом обновлений безопасности;
• свой набор открытых портов и правил файрвола;
• свой SSH-доступ, свои ключи, своя ротация паролей и учётных записей;
• свой мониторинг диска, памяти, нагрузки, сертификатов;
• своя схема бэкапов и своё расписание их проверки;
• свой IP-адрес, который нужно учитывать в whitelist-ах, DNS-записях, файрволах смежных систем;
• своя точка отказа при аппаратных проблемах на стороне провайдера.

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

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

Час админа: как посчитать вторую половину цены

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

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

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

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

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

Разделение на отдельные машины оправдано, если выполняется хотя бы одно из условий:

1. Сервисы конфликтуют по ресурсам. База данных под нагрузкой съедает всю оперативную память, и в общем окружении это душит соседние процессы — классический сценарий, где один жадный сервис на общем сервере роняет все остальные.
2. Разный профиль безопасности. Публичный веб-фронт и внутренняя аналитика с чувствительными данными разумно держать на разных машинах, чтобы компрометация одной поверхности не давала прямого доступа к другой.
3. Разные требования к доступности. Один сервис требует перезагрузки после каждого обновления ядра, другой должен работать без перерывов — на одном сервере это конфликт, на разных решается независимо.
4. Команда уже умеет управлять флотом машин. Если Ansible, Terraform, единая система мониторинга и алертинга уже настроены и обкатаны, предельная стоимость добавления шестого сервера к пяти существующим — минимальна, почти вся инфраструктурная работа делается один раз и переиспользуется.
5. Нужна независимость по масштабированию. Каждый сервис растёт со своей скоростью, и возможность увеличивать ресурсы отдельно под конкретный сервис — не пересобирая всю монолитную машину — экономит время именно в моменты роста.

Когда выигрывает один крупный сервер — и как посчитать итог

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

Чтобы не спорить абстрактно, стоит свести обе составляющие в одну таблицу и посчитать для конкретного случая:

Формула для итога простая:

Итог = (аренда) + (часы_админа_в_месяц × ставка_часа)

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

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

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

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