Подбор ресурсов для OpenBPM Engine

Этот материал описывает, как оценивать размеры окружения для OpenBPM Engine: от серверных ресурсов до места в базе данных.

Рекомендации на этой странице относятся к OpenBPM Engine и к сценариям, где процессный движок использует реляционную базу данных для реальных и исторических данных.

Что влияет на требования к окружению

Для запуска OpenBPM Engine не требуется какое-то специфическое железо. Основные требования определяются двумя факторами:

  1. стеком, в котором запускается приложение: контейнером, application server и сопутствующими компонентами;

  2. тем, что выполняется в delegation code, например в service task.

Например, при вызовах SOAP Web Services или при сложных вычислениях в Java больше CPU времени тратится именно в пользовательском коде, а не в самом движке.

Самый надёжный способ получить корректные цифры для конкретного проекта — провести нагрузочное тестирование на окружении, максимально близком к production. Если есть сомнения, лучше закладывать это в проект заранее. Для генерации нагрузки к REST API удобно использовать, например, JMeter.

С точки зрения OpenBPM Engine особенно важны следующие параметры:

  • Средняя частота старта экземпляров процессов. Именно она формирует общую нагрузку на систему. Если новый экземпляр стартует раз в несколько секунд, минут или часов, отдельный sizing обычно не требуется. Если запускается более 100 экземпляров в секунду, к подбору ресурсов нужно подходить внимательно.

  • Средняя длительность жизненного цикла экземпляра процесса. Она показывает, сколько активных экземпляров одновременно будет находиться в runtime-базе. Это почти не влияет на CPU нагрузку движка, но заметно влияет на поведение базы данных: время выполнения запросов, размер индексов и стоимость их обновления.

  • Wait states. Если процесс проходит целиком без остановок на wait state, он может вообще не записываться в runtime-базу, что резко снижает нагрузку.

  • Количество параллельных подключений. Этот фактор влияет на количество одновременных запросов к базе данных и на размер thread pool.

  • Типовые запросы. Если вы ищете задачи или экземпляры только по id или business key, нагрузка обычно небольшая. Если же активно используются запросы по нескольким process variables одновременно, это сильнее нагружает базу данных.

  • Уровень истории. Конфигурация истории напрямую влияет на объём записываемых исторических данных и на требуемое место в базе.

Подбор серверных ресурсов

Производительность и масштабирование

OpenBPM Engine обычно хорошо масштабируется благодаря небольшому размеру временной памяти. Состояние процессов хранится в базе данных, поэтому при необходимости можно добавлять новые экземпляры процессного движка, например узлы кластера, чтобы повысить пропускную способность.

Естественным ограничением такой архитектуры чаще всего становится база данных, а не сам движок.

Высокая доступность

Для высокой доступности рекомендуется использовать как минимум две машины. Им не обязательно образовывать полноценный кластер application server. Достаточно двух одинаково настроенных узлов, работающих с одной и той же базой данных.

Виртуализация

OpenBPM Engine можно запускать в виртуализированных окружениях. В этом случае особенно важно внимательно следить за фактически доступными CPU, памятью и производительностью дисковой подсистемы, поскольку ресурсы часто разделяются между несколькими системами.

Классы серверов

Жёстких универсальных рекомендаций по конфигурации нет, но удобно использовать условные классы серверов:

  • Small: типичный небольшой сервер, например 1-2 CPU и 1-8 GB RAM

  • Medium: типичный средний сервер, например 2-4 CPU и 4-16 GB RAM

  • Large: типичный крупный сервер, например 4-64 CPU и 16-128 GB RAM

Для большинства проектов достаточно класса Small.

Имеет смысл смотреть в сторону Medium, если:

  • у вас стартует более 100 экземпляров процессов в секунду;

  • в delegation code есть CPU-intensive логика;

  • приложение или окружение имеют дополнительные требования, не связанные напрямую с движком.

Место на диске

В зависимости от выбранного контейнера обычно требуется порядка 500 MB - 1 GB дискового пространства. Практически стоит закладывать не менее 2 GB, чтобы оставался запас под логи и диагностику проблем.

Требования к базе данных

Выбор базы данных

Для production-окружений имеет смысл использовать зрелую промышленную реляционную СУБД. На практике хорошие результаты обычно показывают PostgreSQL и Oracle. Также многое зависит от качества администрирования конкретной базы и от характерных для проекта запросов.

H2 редко применяется в production-сценариях с высокой нагрузкой, поэтому использовать её как ориентир для sizing не стоит. Но у нее есть неоспоримое преимущество в виде режима работы in memory, что может оказать решающую роль в некоторых кейсах.

Как оценивать необходимый размер базы

Требуемый размер базы данных зависит прежде всего от следующих факторов:

  • Конфигурация истории. Если история отключена, в базе остаются только текущие реальные данные, и объём хранения заметно снижается.

  • Переменные процесса. Все переменные процесса должны сохраняться в базе, часто в сериализованном виде, например как JSON. При уровне истории FULL при каждом изменении переменной дополнительно создаются записи в исторических таблицах значений.

При расчёте требуемого объёма важно заранее определить, будет ли выполняться регулярная очистка исторических данных, например через очистку истории.

Фактически занимаемое место сильно зависит от конкретной СУБД и её конфигурации, поэтому универсальной формулы здесь нет. Вместо этого полезно отталкиваться от контрольного сценария и затем адаптировать оценку под свой проект.

Пример сценария оценки

В качестве ориентировочного примера можно рассмотреть процесс обработки счетов со следующими допущениями:

openbpm engine sizing

  • 25% экземпляров попадает на дополнительную проверку;

  • 10% экземпляров завершается после проверки;

  • используется конфигурация истории - FULL;

  • запускается 40 000 экземпляров процессов;

  • 33 000 экземпляров завершается и удаляется из runtime;

  • 7 000 экземпляров остаётся активными;

  • база данных развёрнута на Oracle 12c Enterprise Edition под Linux.

Для такого сценария получаются следующие ориентировочные значения:

Область Количество экземпляров Место на диске Расчётный объём на один экземпляр Примечание

Runtime

6 989

28,375 MB

4,157 KB

Около половины объёма занимает индексация

История

39 953

766,375 MB

19,642 KB

Объём сильно зависит от конфигурация истории

Итого

-

794,75 MB

-

-

Как практическое правило, перед оценкой полезно собрать такие входные данные:

  • число экземпляров процессов в день;

  • среднее число выполненных задач на один экземпляр;

  • суммарный размер переменных на один экземпляр;

  • среднее число обновлений переменных.

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

Ниже приведён упрощённый пример расчёта для реального сценария.

Дано:

  • ожидаемое число экземпляров процессов в месяц: 300 000;

Допущения:

  • нагрузка равномерно распределена по 20 рабочим дням;

  • нагрузка равномерно распределена по 8 рабочим часам;

  • процесс в основном состоит из user task и почти не содержит service task;

  • среднее время жизни экземпляра процесса составляет около двух дней.

Расчёт:

  • 15 000 новых экземпляров в день;

  • 1 875 новых экземпляров в час;

  • 31 новый экземпляр в минуту;

  • примерно один новый экземпляр каждые 2 секунды.

Для такого сценария обычно достаточно сервера класса Small.

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0).

Оригинал документации: https://docs.camunda.io