Привет, Хабр! На связи Егор Сапун, руководитель направления сертификации инфраструктуры Рег.облака.
Shared CPU и выделенный — не вопрос «лучше или хуже». Это два разных инструмента, и ошибка чаще всего одна: берут не тот под задачу. В этой статье попытаемся разобраться, какая конфигурация сервера и для каких задач подходит лучше всего.
Навигация по тексту:
Stateless-сервисы и веб-приложения с непредсказуемым трафиком → shared CPU
OLAP и аналитические запросы с жесткими SLA → выделенный CPU
Системы с персональными данными в аттестованном контуре → выделенный CPU
Как устроены shared- и dedicated-сервисы
В стандартной облачной продуктовой линейке провайдер обычно предлагает vCPU — виртуальные ядра, которые гипервизор нарезает из физических. Один физический поток может обслуживать несколько vCPU разных клиентов одновременно. Соотношение vCPU к физическим потокам — коэффициент переподписки (overcommit ratio). Значение 2:1 или 4:1 — стандартные показатели. Это рабочая модель, основанная на статистике: большинство ВМ не нагружают процессор одновременно и на полную. Пока нагрузка распределена неравномерно — shared CPU работает предсказуемо.
В линейке с выделенным CPU физические ядра фиксируются за конкретной ВМ и не делятся с соседями — это гарантирует стабильную производительность вне зависимости от активности других клиентов на хосте.
Ключевое понятие здесь — steal time: процент времени, когда vCPU хочет работать, но физического ядра нет, потому что его занял другой поток. Именно он объясняет нерегулярные просадки производительности, которые сложно воспроизвести: проблема возникает тогда, когда соседи на хосте активны, и исчезает, когда они простаивают.
Stateless-сервисы и веб-приложения с непредсказуемым трафиком → shared CPU
Фронтенд, API-серверы, микросервисы с горизонтальным масштабированием — нагрузка здесь по природе своей неравномерна. Пики сменяются затишьем, запросы короткие. Shared CPU справляется с этим хорошо: пока одна ВМ обрабатывает всплеск, соседние простаивают, и физические ядра достаются тем, кому нужны прямо сейчас.
Модель переподписки работает в пользу клиента именно здесь: ресурсы используются эффективно, нагрузка распределяется по времени.
Dev/staging-окружения → shared CPU
Dev- и staging-окружения редко работают под постоянной нагрузкой. Тесты запускаются по расписанию или вручную, в остальное время ВМ простаивает. Периодические просадки производительности здесь некритичны — они не влияют ни на пользователей, ни на SLA. Shared CPU — очевидный выбор для всех окружений, которые не являются продуктивными.
Batch-обработка без жесткого расписания → shared CPU
ETL-процессы, импорт данных, ночные отчеты, генерация выгрузок — если задача не требует завершения к конкретному моменту, небольшой steal time на результат не влияет. Задача выполнится чуть дольше, но это приемлемо.
Исключение — batch-задачи с жестким SLA или те, что блокируют другие процессы до своего завершения. Здесь уже стоит смотреть на выделенный CPU.
OLTP-нагрузки и транзакционные СУБД → выделенный CPU
PostgreSQL, MySQL, Oracle, 1С — транзакционные системы чувствительны к задержкам на уровне планировщика. Транзакция держит блокировки: пока она ждет CPU, другие транзакции стоят в очереди. Steal time в 10–15% превращается в непредсказуемые всплески latency, которые пользователи чувствуют как «база иногда тупит».
При этом средние показатели могут выглядеть нормально — проблема проявляется в хвостах распределения (p95, p99). Если эти значения входят в SLA или напрямую влияют на пользовательский опыт, shared CPU создает структурный риск.
OLAP и аналитические запросы с жесткими SLA → выделенный CPU
Долгие агрегации и джойны по большим таблицам при переподписке могут выполняться в разы дольше расчетного времени — именно в тот момент, когда соседи на хосте тоже активны. Если дашборд должен открываться за секунды, а не за минуты, нестабильность CPU недопустима. Для аналитики без жестких SLA, которая запускается по расписанию и не блокирует пользователей, shared CPU вполне подойдет.
ERP, CRM, финансовые системы → выделенный CPU
Они работают поверх СУБД и добавляют собственный прикладной слой с синхронными запросами. Задержка на уровне базы умножается на задержку в приложении — пользователь видит зависания интерфейса. Чем длиннее цепочка синхронных вызовов, тем сильнее нестабильность CPU влияет на итоговый отклик.
Системы с персональными данными в аттестованном контуре → выделенный CPU
Отдельный случай, где вопрос производительности пересекается с compliance.
В аттестованном облаке по 152-ФЗ работают системы с повышенными требованиями к защите: набор сертифицированных средств защиты информации, подтвержденные типовые конфигурации инфраструктуры. До недавнего времени это означало компромисс — либо compliance, либо гарантированная производительность. Теперь эти два требования можно закрыть в рамках одного контура.
Выделенный CPU в аттестованном облаке — это выбор для продуктивных систем с реальной нагрузкой: СУБД, ERP, финансовые системы, высоконагруженные веб-приложения, которые обрабатывают персональные данные. Физические ядра фиксируются за конкретной ВМ без переподписки — производительность стабильна вне зависимости от соседей на хосте, а вся инфраструктура остается в аттестованном контуре.
Так что в итоге?
Shared CPU — правильный выбор там, где нагрузка неравномерна, просадки некритичны и нет жестких требований к latency: stateless-сервисы, dev/staging, batch без SLA.
Выделенный CPU оправдан там, где нестабильность производительности становится проблемой: транзакционные СУБД, системы с синхронными запросами к базе, аналитика с жесткими SLA, а также любые продуктивные системы в аттестованном контуре 152-ФЗ. А конфигурации Shared CPU, выделенного CPU и выделенного CPU в аттестованном облаке 152-ФЗ можно посмотреть на сайте Рег.облака.
Вопросы по выбору конфигурации для вашего проекта — пишите в комментариях, разберем!
