Как рассчитать реальный предел SaaS

SaaS-продукты, да и не только они, конечно, редко падают красиво. Они делают это медленно и нервно. Вот у вас всё работает, а потом… Сначала интерфейс начинает «думать» пару секунд. Затем отчеты в ERP считаются почти минуту. Дальше в пиковые часы API как будто заболевает Альцгеймером. Под конец квартала база начинает ловить блокировки. При этом если смотреть формально – ничего не сломано. Прод жив, но не покидает ощущение, что вся система будто на пределе.

Опираясь на наш опыт аудита SaaS-систем (от ERP-гигантов до HR-tech стартапов), мы пришли к выводу, что в 70-80% случаев проблемы масштабирования растут не из нехватки «железа», а из ошибок в моделировании нагрузки. Количество пользователей в системе прекрасно известно всей команде, но мало кто понимает, какая нагрузка на самом деле живет внутри продукта.

Ничего не ломается, но всё тормозит

Техническая точка невозврата случается, когда на радость бизнесу продажи растут, но есть нюанс – новые клиенты приходят быстрее, а архитектура за такими темпами не успевает. Проект обрастает новыми модулями, интеграциями, аналитикой. И наверх идут отчеты о том, как все хорошо выглядит. А вот внутри система начинает вести себя странно, потому что никто до конца не понимает Point of Saturation¹.

У этой ситуации две стороны — бизнес и техничка.

1.Бизнес-уровень. В системах вроде ERP, BI или КЭДО продукт работает с крупными компаниями или госзаказчиками. SLA под ФЗ-44/223 далеко не формальность.

Когда мы говорим о SLA или нагрузочном тестировании для клиентов из этой сферы, нужно понимать:

• По 44-ФЗ если ваш софт упадет и нарушит сроки, прописанные в госконтракте, компанию-поставщика могут внести в РНП (Реестр недобросовестных поставщиков). Это фактически «волчий билет» на рынке госзакупок на 2 года.
• По 223-ФЗ видим, что требования к отказоустойчивости могут быть прописаны в договоре очень детально, и штрафные санкции там часто намного выше рыночных, так как крупные корпорации оценивают свои убытки от простоя в миллионы рублей в минуту.

2. Технический уровень. Команда видит симптомы заболевания, то есть деградации: медленные SQL-запросы, длинные релизы без нормальной тестовой документации и падения API в пиках.

Большинство инструментов мониторинга показывают текущее состояние. Но так уж устроено, что SaaS-продукт живет будущей нагрузкой.

Из чего на самом деле состоит нагрузка SaaS

В инженерной культуре топовых SaaS-сервисов нагрузку никогда не меряют «в человеках», простите. Давайте воспользуемся понятием Resource-Heavy Operation (RHO). Нагрузка смахивает на многослойный пирог, в котором есть такие слои, как:

1. Пользовательская активность. И это не общее количество аккаунтов, а одновременные сессии и частота операций. Нужно учитывать RPS².
2. Тяжелая бизнес-логика. Формирование отчетов, расчет зарплаты, агрегации. Один фоновый экспорт данных в ERP может потреблять в 45 раз больше I/O³ ресурсов БД, чем стандартный API-вызов на чтение профиля.
3. Интеграции. Взаимодействие с 1С, СМЭВ или партнерскими системами. Они могут создавать до 50% всех задержек.
4. Слой данных. Большая база = большая боль. Если продукт старше пары лет, БД стала узким местом, поверьте. Тяжелые JOIN⁴ и блокировки определяют предел масштабирования.
5. Фоновые процессы. Очереди задач, ETL⁵ и индексация… При росте нагрузки они начинают конкурировать с пользователями за CPU и память.

Как рассчитать нагрузку: от «юзеров» к стоимости сценария

Вместо упрощенных метрик мы используем модель, учитывающую вес каждой операции:

N = (U х C) х S х P 

Где

• U – общее количество пользователей.
• C – это коэффициент одновременной активности.
• S (Scenario Cost) – так называемая «стоимость» сценария. Вес конкретной бизнес-операции в ресурсах системы. Это по итогу самое главное и есть.
• P – пик-фактор (например, конец отчетного периода).

Смысл формулы простой. Система должна выдерживать не просто пользователей, а пиковую комбинацию сценариев. Например, в ERP 3000 пользователей, 800 одновременных сессий, 1000 отчетов в час. Если конец месяца увеличивает активность в пять раз, архитектура должна выдержать именно этот момент. Можете посчитать сами

Средняя нагрузка здесь вообще ничего не говорит.

Рабочий кейс, как пример. Команда ERP готовилась к 5 000 юзеров. Но аудит показал, что один процесс «Закрытие отчетного периода» генерирует нагрузку, эквивалентную 15 000 RPS. Система была готова к людям, но не была готова к бухгалтерии.

Архитектурная ловушка SaaS, если одна база для всего

Почти все SaaS-продукты начинают одинаково. Создаётся база данных. В ней живет всё: операционные данные, аналитика, отчеты, интеграции, история операций. На ранней стадии это абсолютно нормальная архитектура. У этого свои плюсы, ведь она проста. Ее легко поддерживать. Она быстро развивается. Но по мере роста продукта в этой модели появляется скрытая проблема. Операционные сценарии и аналитические сценарии начинают конкурировать за одни и те же ресурсы.

Например, пользователь открывает карточку клиента. Это быстрый транзакционный запрос. Одновременно с ним другой пользователь запускает сложный управленческий отчет, который может сканировать миллионы строк, выполнять тяжелые JOIN, строить агрегации… В результате тяжелые аналитические запросы начинают занимать CPU, блокировать таблицы, забивать I/O, и вся система начинает вести себя соответственно – интерфейс «подвисает», API отвечает медленнее, в очередях задач растет задержка. При этом формально база работает.

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

Решается эта проблема обычно тремя вариантами:

Можно разделить OLTP и аналитику. Операционные запросы остаются в основной базе.  Аналитика уходит в отдельный контур.

Или использовать асинхронные расчеты, когда тяжелые операции переносятся в фоновые задачи.

Либо внедрить предварительную агрегацию, когда часть расчетов выполняется заранее. Это уменьшает нагрузку в моменты, когда пользователи открывают отчеты или дашборды.

Почему это нельзя игнорировать при моделировании нагрузки? Если аналитика и транзакционные операции живут в одном контуре, система может выдерживать обычную пользовательскую активность.Но в моменты, когда запускаются тяжелые отчеты, нагрузка меняется резко. И вот в этот момент лезут симптомы, которые многие команды списывают на «временные тормоза»: деградация/Альцгеймер API, зависание интерфейса, рост времени SQL-запросов. Поэтому при расчете нагрузки SaaS важно учитывать не только пользователей, но и архитектуру обработки данных. Иногда именно она определяет реальный предел системы.

Отраслевые профили нагрузки

• ERP и учетные системы.  Главный риск для них это БД. Основная нагрузка идет от расчетов и работы с огромными таблицами.
• BI-системы потребляют CPU и память. Нагрузка формируется аналитическими выборками и рендерингом дашбордов.
• У различных CRM более равномерная нагрузка, но с резкими скачками во время импорта данных или массовых рассылок.
• HR-tech и КЭДО (кадровый электронный документооборот). Самые агрессивные пики приходятся на массовое подписание документов, или когда кадровые кампании поднимают нагрузку в 5-8 раз за считанные минуты.

Одна из распространенных ошибок при расчете нагрузки использовать одинаковую модель для всех типов продуктов. Но профиль нагрузки у ERP, CRM или HR-систем отличается радикально.

Что здесь важно, давайте разберем подробнее. В ERP нагрузку чаще всего создают несколько тяжелых операций, а не тысячи пользователей. В CRM, наоборот, каждая операция легкая, но их очень много. В HR-системах и КЭДО большую роль играют пакетные сценарии. А в EdTech система может спокойно работать весь день, но «взорваться» во время массового тестирования или экзамена.

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

В большинстве SaaS-систем 10-15% сценариев создают до 80% нагрузки. При моделировании важно сначала найти самые тяжелые операции, а уже потом считать пользователей.

Миграция и Performance Regression Gap

Сейчас многие команды проходят через переезд с AWS/Azure на Yandex Cloud, Selectel или миграцию на Astra Linux и Postgres Pro. 

Критическая точка. Мы регулярно фиксируем так называемую Performance Regression Gap. Это ситуация, когда после миграции те же самые сценарии начинают нагружать систему на 30-40% сильнее. Среди причин, конечно, особенности работы ядра ОС, драйверов или сетевых задержек в новой инфраструктуре. К тому же без предварительного синтетического моделирования этот разрыв «вымывает» запас прочности архитектуры еще до того, как в систему зайдет первый клиент.

Что дает аудит, или оbservability-first testing

Для нас нагрузочное тестирование не остается разовым отчетом в PDF. Фактически это внедрение o bservability-инструментария⁶. «Положить» систему могут многие, но мы параллельно еще и настраиваем APM (Application Performance Monitoring), чтобы команда видела деградацию API в реальном времени.

Частые находки:

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

Когда пора звать внешнюю экспертизу?

Мы уже не раз говорили о том, что аудит нагрузки часто больше как страховка, нежели лечение. Если вы заметили, что:

• продукт начал замедляться и интерфейс «фризит» в пики,
• планируется резкий рост + выход на крупных B2B-заказчиков с жестким SLA,
• есть миграция инфраструктуры + нужно подтвердить работоспособность на новом стеке,

Мы заходим в проект за 48 часов, обеспечиваем полный цикл от расчета мощностей до настройки авто-метрик и обучения вашей команды. Единственные на рынке, мы предлагаем не просто «руки», а создание вашей внутренней корпоративной школы QA через наш УЦ, чтобы вы перестали зависеть от дорогого найма. 

Key Takeaways

1. Не считайте людей, считайте операции. Один «тяжелый» отчет может стоить как тысяча кликов.
2. Моделируйте пики, а не среднее. Средняя температура по больнице не поможет, когда в систему одновременно зайдут все сотрудники компании-клиента.
3. Закладывайте риск миграции. Переезд на Astra Linux или Postgres Pro требует специфических регрессов.
4. Внедряйте Observability. Вы должны видеть точку насыщения системы за месяцы до того, как она станет критической.

Ваш SaaS готов к следующему этапу роста?

Запишитесь на аудит нагрузки и получите расчет модели вашей системы и план масштабирования.

1. Point of Saturation (точка насыщения) – состояние архитектуры, при котором добавление новых вычислительных ресурсов (CPU, RAM) перестает увеличивать производительность. ↩︎
2. RPS (Requests Per Second) – количество запросов к серверу в секунду. Базовая метрика интенсивности трафика ↩︎
3. I/O (Input/Output) – операции ввода-вывода. Нагрузка на дисковую подсистему или сеть, критически важная для баз данных. ↩︎
4. JOIN – операция в SQL для объединения данных из двух и более таблиц. При больших объемах данных «тяжелые» JOIN-ы становятся главной причиной тормозов БД. ↩︎
5. ETL (Extract, Transform, Load) – процессы сбора данных из разных источников, их преобразования и загрузки в хранилище (обычно для аналитики). ↩︎
6. Observability – концепция «наблюдаемости», когда по внешним метрикам (логи, трассировки) можно полностью восстановить внутреннее состояние системы без её остановки. ↩︎