Системные требования и сайзинг

Назначение

Страница предназначена для архитекторов, DevOps-инженеров и заказчиков, которые планируют инфраструктуру UniBPM.

Приведённые конфигурации являются стартовыми ориентирами, а не гарантированными пределами производительности. Итоговый sizing определяется по пиковой процессной, пользовательской, API- и интеграционной нагрузке, объёму данных и срокам хранения.

Архитектура и границы расчёта

Пользовательские запросы проходят через публичный слой доступа к Frontend и Application API. Внешние системы могут взаимодействовать с публичным API или Integration Runtime, а обмен событиями между компонентами выполняется через Kafka.

Прикладной слой (application layer) состоит из отдельных компонентов: Frontend, Application API, Process Engine и, когда он используется, Integration Runtime. Application API и Process Engine имеют разные профили нагрузки и отдельные логические хранилища PostgreSQL для Business Data и Process Data.

PostgreSQL, Kafka и Identity Provider могут размещаться внутри контура UniBPM либо предоставляться внешней платформой. Если они не включены в выбранный профиль развёртывания, их ресурсы оцениваются отдельно. Ресурсы внешнего AI provider и локальных AI-моделей также не входят в базовые профили.

Минимальные системные требования

Минимальная конфигурация предназначена для ознакомления, Demo и функционального тестирования без требований высокой доступности.

Рекомендуемые стартовые профили

CPU и RAM относятся только к application layer. Выбор строки по числу пользователей недостаточен: профиль необходимо проверить по process steps/second, API_peak, размеру payload, вложениям и retention.

Для Enterprise инфраструктура, HA/DR, RPO/RTO и ресурсы платформенных сервисов определяются архитектурой заказчика и подтверждаются отдельным capacity plan.

Как оценить нагрузочный профиль

Сначала заполните sizing worksheet для реального пикового периода. Среднее значение за сутки не заменяет профиль пикового окна.

Процессная нагрузка

process steps/day = P_day × A

process steps/second = (P_day × A × K) / peak_window_seconds

peak_window_seconds — длительность реального пикового окна. Нагрузку нельзя равномерно распределять по 24 часам, если основные операции выполняются в течение 8–12 часов. Коэффициент K выбирается по ожидаемым всплескам и затем уточняется по метрикам.

Пользовательские задачи

human tasks/second = (T_day × K) / peak_window_seconds

Параметр C дополнительно влияет на число параллельных HTTP/WebSocket-соединений, конкурентные запросы к API и connection pools.

API-нагрузка

Если известен фактический или прогнозируемый API_peak, используйте его напрямую. Если известен только суточный объём:

API requests/second = (API_requests_day × K) / peak_window_seconds

Для интеграций также учитываются payload, timeout, retries, concurrency и ограничения внешних систем.

Вложения

attachment data in retention period =
    F_day × S_file × business_days_per_year × retention_years

required attachment storage =
    attachment data in retention period × reserve_factor

Резерв учитывает рост, индексы, служебные данные и операционный запас. Backup рассчитывается отдельно в соответствии с принятой политикой хранения.

В текущей конфигурации продукта вложения могут храниться в PostgreSQL, поэтому их объём существенно влияет на размер базы, IOPS, время backup и восстановления. reserve_factor уточняется по фактическому росту данных.

Данные процессов

Не используйте универсальный коэффициент «байт на процесс»: размер зависит от BPMN-моделей, числа задач, переменных и истории.

Безопасный способ оценки:

1. измерить прирост базы на тестовом стенде за выбранный период;
2. сопоставить прирост с числом созданных process instances и задач;
3. скорректировать результат на R_process;
4. применить резерв;
5. подтвердить расчёт нагрузочным тестом.

estimated process storage =
    measured average storage per process instance
    × process instances in retention period
    × reserve_factor

measured average storage per process instance определяется на репрезентативных BPMN-моделях с характерными variables и payload.

AI-нагрузка

AI-функции оцениваются по AI_peak, размеру контекста, выбранной модели, latency и rate limits, а не только по числу пользователей.

При внешнем AI provider основные вычисления выполняются вне application layer, но UniBPM использует ресурсы для подготовки контекста, сетевых соединений и обработки ответов. Для локальной модели GPU, CPU, RAM и storage рассчитываются отдельно и не входят в базовые профили UniBPM.

Пример расчёта

Исходный профиль:

Расчёт:

process steps/day = 10 000 × 12 = 120 000

process steps/second = 120 000 × 3 / 28 800 = 12.5

human tasks/second = 2 000 × 3 / 28 800 ≈ 0.21

attachment data = 100 × 2 MiB × 250 рабочих дней
                = 50 000 MiB ≈ 48.8 GiB в год

Объём вложений указан без backup, индексов и резерва. Для системы с операциями во все календарные дни вместо 250 используется фактическое число рабочих дней в году.

Результат не является обещанием производительности. По нему выбирается стартовый профиль, который затем проверяется нагрузочным тестом с реальными BPMN-моделями, payload, интеграциями и профилем вложений.

Границы применимости

• значения являются стартовыми ориентирами, а не гарантированной ёмкостью;
• ресурсы внешних PostgreSQL, Kafka, Identity Provider, AI provider и monitoring оцениваются отдельно;
• вложения, retention, payload и пиковая нагрузка могут значительно изменить sizing;
• production sizing подтверждается representative load test.

Масштабирование

Наличие нескольких реплик само по себе не подтверждает HA. Для Enterprise требования к отказоустойчивости и восстановлению определяются архитектурой заказчика.

Подтверждение конфигурации

Нагрузочный тест должен воспроизводить пиковое окно, а не равномерный среднесуточный поток. В сценарий включаются реальные BPMN-модели, пользовательские задачи, характерные process variables, API, интеграции и вложения.

Во время теста контролируются throughput и latency, CPU/RAM, JVM, connection pools, PostgreSQL IOPS и рост данных, Kafka lag, ошибки и ограничения внешних сервисов. Стартовый профиль принимается только после проверки целевой нагрузки с требуемым запасом и повторного теста после изменения архитектуры или ключевых моделей процессов.