Системные требования
Данный документ описывает системные требования к платформе Бипиум, а также предоставляет рекомендации по настройке серверной инфраструктуры и выделению ресурсов.
Введение
Область применения
Платформа Бипиум поддерживает различные модели развертывания, включая контейнерные среды, системы оркестрации и запуск в виде системных сервисов.
Термины, сокращения и обозначения
Термин | Описание |
API | Интерфейс взаимодействия клиента с приложением. |
PostgreSQL | Свободная объектно-реляционная система управления базами данных (СУБД) с открытым исходным кодом. |
Redis | Сверхбыстрая, резидентная (работающая в оперативной памяти) NoSQL система управления базами данных с открытым исходным кодом. |
S3 | Объектное хранилище, позволяющее хранить практически неограниченные объемы данных (файлы, изображения, бэкапы) в «плоской» структуре, где каждый объект (файл + метаданные) находится в бакете (контейнере). |
RPS | Запросы в секунду (requests per second). |
CRUD | Это аббревиатура, обозначающая четыре базовые функции для работы с данными: Create (Создание), Read (Чтение), Update (Обновление) и Delete (Удаление) |
Ссылки
IEEE Std 830-1998 - Спецификация системных требований\
Архитектура и компоненты системы Бипиум\
Документация PostgreSQL\
Документация Redis\
Общее описание системы
Обзор системы
Платформа Бипиум представляет собой веб-приложение для автоматизации и управления бизнес-процессами с возможностью интеграции с внешними информационными системами через API.
Система построена по модульному принципу и включает в себя несколько взаимодействующих компонентов, обеспечивающих обработку, хранение данных и интеграцию с внешними сервисами.
Архитектура системы
Платформа реализует распределённую архитектуру и включает следующие логические компоненты:
Сервер API и приложение (Bpium)
Сервер исполнения процессов (BPM)
Объектное хранилище (S3)
Сервер баз данных (PostgreSQL)
Сервер Redis
Подробное описание архитектуры системы приведено в статье «Архитектура и компоненты».
Модели развертывания
Система поддерживает различные модели развертывания в зависимости от инфраструктуры:
контейнерные среды (например, Docker)
системы оркестрации контейнеров (например, Kubernetes)
запуск в виде системных сервисов операционной системы (например, systemd в Linux или Windows Services)
Выбор модели развертывания определяется требованиями инфраструктуры и эксплуатационной средой.
Классы пользователей
Система может использоваться следующими категориями пользователей:
администраторы системы (управление конфигурацией и доступами)
конечные пользователи (работа с функциями платформы)
внешние системы (интеграция через API)
Допущения и ограничения
При эксплуатации системы предполагается:
наличие подготовленной инфраструктуры для выбранного способа развертывания
доступность сетевого взаимодействия между компонентами
Системные требования
В таблицах указаны системные требования рассчитанные на:
100 активных пользователей:
Средняя нагрузка: ~2 RPS
Обычная нагрузка (P95): ~5–6 RPS
Пиковая нагрузка: до ~15 RPS
стандартные бизнес-операции (CRUD, API запросы, процессы BPM)
Общие аппаратные требования
Таблица содержит общие системные требования, применимые ко всем компонентам системы.
Компонент | Минимальные | Рекомендуемые |
CPU | 4 vCPU | 8 vCPU |
RAM | 8 GB | 16 GB |
Disk | 20 GB SSD | 50+ GB SSD |
Рекомендуемые аппаратные требования к компонентам системы
Компонент | CPU | RAM | Disk |
Сервер API и приложения (Bpium) | 2 vCPU | 2 GB | 5 GB SSD |
Сервер исполнения процессов (BPM) | 2 vCPU | 4 GB | 10 GB SSD |
Объектное хранилище (S3) | 1 vCPU | 1 GB | 50+ GB SSD |
Сервер баз данных (PostgreSQL) | 2 vCPU | 8 GB | 50+ GB SSD |
Сервер Redis | 1 vCPU | 1 GB | 5 GB SSD |
Рекомендуемые параметры PostgreSQL (postgresql.conf):
Параметр | Рекомендуемое значение | Описание параметра |
| 100 | Максимальное количество одновременных подключений. Ограничивается для предотвращения избыточного потребления памяти. |
| 2GB | Основной кэш PostgreSQL. Влияет на производительность чтения. ~25% RAM (например, 2 GB при 8 GB). |
| 40MB | Память на одну операцию (sort/hash). Умножается на количество соединений → важно не завышать. |
| 1GB | Используется для операций VACUUM, CREATE INDEX. Можно увеличивать при редких heavy-операциях. |
| 6GB | Оценка доступного кеша (PostgreSQL + ОС). Используется планировщиком запросов. ~70–75% RAM. |
| 1.1 | Стоимость случайного чтения. На SSD уменьшается для улучшения планов запросов. |
| 200 | Количество параллельных операций ввода-вывода. Увеличивает производительность на SSD. |
| 16MB | Буфер WAL. Обычно достаточно значения по умолчанию или немного выше. |
| 0.9 | Распределяет нагрузку записи checkpoint во времени. Уменьшает пики IO. |
| 1GB | Минимальный размер WAL-файлов. |
| 4GB | Максимальный размер WAL перед checkpoint. Больше → меньше checkpoint, но больше диск. |
| 8 | Общее количество фоновых процессов. = CPU cores |
| 2 | Максимум параллельных воркеров. = CPU cores |
| 4 | Параллелизм одного запроса. |
| 2 | Параллелизм операций обслуживания (index, vacuum). |
Требования к программному обеспечению
Операционная система
Бипиум поддерживает следующие операционные системы:
Операционная система | Версия |
Linux (Ubuntu) | 20.04+ |
Linux (Debian) | 11+ |
Windows | 10, 11, Server |
База данных PostgreSQL
Для работы системы требуется PostgreSQL версии 14.
Система хранения задач Redis
Для работы системы требуется Redis версии 6 и выше.
Сетевые требования
Сетевые взаимодействия компонентов
Система требует наличия сетевого взаимодействия между компонентами.
Необходимо обеспечить доступность сервисов по соответствующим портам.
Порты, указанные в таблице, приведены как значения по умолчанию и могут быть изменены в конфигурации компонентов системы.
Источник | Назначение | Порт (по умолчанию) |
API сервер | PostgreSQL | 5432 |
API сервер | Сервер исполнения процессов (BPM) | 2030 |
Сервер исполнения процессов (BPM) | S3 | 2020 |
Сервер исполнения процессов (BPM) | PostgreSQL | 5432 |
Сервер исполнения процессов (BPM) | API сервер | 3000 |
Сервер исполнения процессов (BPM) | Redis | 6379 |
Требования безопасности
Шифрование данных
Передача данных между компонентами системы должна осуществляться с использованием защищённых протоколов (HTTPS, TLS 1.2 и выше).
Управление секретами
Конфиденциальные данные (пароли, ключи, токены) не должны храниться в открытом виде в конфигурационных файлах.
Рекомендуется использование механизмов безопасного хранения секретов (например, переменные окружения, внешние хранилища секретов).
Сетевые ограничения
Доступ к внутренним компонентам системы должен быть ограничен на уровне сети.
Должны быть открыты только необходимые порты для взаимодействия компонентов.