Как производительность Low-code платформы SimpleOne выросла в 16 раз: архитектура, практика и метрики

Производительность Low-code платформы — один из самых спорных вопросов для enterprise-сегмента. Интерпретация настроек «на лету» создает дополнительную нагрузку по сравнению с готовыми решениями, но дает бизнесу гибкость и возможность быстро менять процессы. Работая с крупнейшими заказчиками, мы сделали производительность стратегическим приоритетом и сейчас продолжаем развивать платформу под требования больших компаний. С 2023 года производительность SimpleOne выросла с 68 тысяч до миллиона пользовательских обращений в месяц — это результат системной работы над архитектурой платформы.

Рассказываем о нашем пути и архитектурных решениях, которые позволили увеличить производительность Low-code платформы.

Почему мы выделяем производительность как критичный фактор для корпоративного Low-code

Компании выбирают Low-code платформы, чтобы быстрее автоматизировать бизнес-процессы и снизить зависимость от разработчиков. Однако у такого подхода есть особенность: платформа выполняет код «на лету», в runtime. Система интерпретирует настройки, бизнес-правила и пользовательские скрипты во время работы, а не компилирует их заранее. Такая архитектура создает дополнительную нагрузку по сравнению с готовыми коробочными решениями, и это важно понимать при выборе решений для автоматизации.

Для крупного бизнеса низкая производительность платформ автоматизации становится критичной проблемой. Когда система работает медленно, сотрудники не успевают выполнять бизнес-процессы в установленные сроки, будь то обработка обращений в службе поддержки, согласование документов в юридическом отделе или управление закупками. Автоматизация, которая должна была ускорить процессы, превращается в препятствие.

По опыту наших клиентов, особенно остро проблема проявляется в часы пик — обычно с 10:00 до 15:00. В это время большинство сотрудников активно работает в системе: создают запросы на обслуживание, обновляют статусы задач, формируют отчеты. Нагрузка возрастает в разы, и платформа, которая не адаптирована под нагрузки в тысячи пользователей, может с ней не справиться. Пользователи видят долгую загрузку страниц, система зависает, возникают ошибки в обработке данных, что ведет к неверным результатам бизнес-процессов. В критических случаях автоматизированные процессы могут полностью остановиться.

В итоге низкая производительность сводит на нет все преимущества автоматизации и может полностью обесценить инвестиции в систему. Компания платит за лицензии, тратит время на внедрение, обучает сотрудников, но получает инструмент, который тормозит работу, а не ускоряет.

Крупные компании понимают это и при выборе корпоративной Low-code платформы производительность ставят в приоритет наравне с функциональностью. В enterprise-сегменте стандартная практика — проведение детального нагрузочного тестирования еще на этапе пилотного проекта. Команда SimpleOne совместно с ИТ-департаментами заказчиков моделируют реальные сценарии использования, измеряют время отклика под нагрузкой и проверяют поведение системы в стрессовых условиях. Решение о внедрении принимают только тогда, когда получается подтвердить способность платформы справляться с ожидаемыми объемами данных и количеством пользователей.

Какие метрики мы используем для измерения производительности Low-code платформы

В традиционной разработке термин «производительность» чаще всего связывают с количеством обработанных запросов в секунду (RPS, requests per second), временем выполнения операций, загрузкой процессора и памяти. Однако когда речь идёт о Low-code платформах, подобные показатели теряют самостоятельную ценность.

Причина в самом предназначении Low-code: это не набор REST-интерфейсов, а среда для реализации прикладной бизнес-логики в виде конфигураций на уровне платформы — форм, бизнес-правил, процессов и скриптов. Соответственно, основной единицей «нагрузки» становится уже не технический запрос, а бизнес-сценарий — в нашем случае это было завершённое обращение пользователя через платформу.

Например, в системе управления ИТ-услугами (ITSM) реализованной на Low-code платформе, один такой сценарий может включать:

• авторизацию пользователя и подгрузку его прав;
• визуализацию формы создания запроса (с динамикой, авторасчётами, скрытыми полями);
• создание самой заявки, запуск процесса обработки;
• генерацию и маршрутизацию задачи исполнителю;
• обратные действия исполнителя (назначение, выполнение, отправка отчёта);
• завершение процесса, отправку уведомлений, запись в историю;
• расчёт SLA и внутренних бизнес-индикаторов.

Фактически, один бизнес-сценарий порождает десятки внутренних технических операций, распределённых по компонентам платформы: интерфейсу, процессному ядру, очередям, базе данных, модулям уведомлений и т.д.

Основываясь на нашем опыте мы выделяем основную метрику для измерения производительности — количество обрабатываемых бизнес-сценариев в единицу времени, а не просто RPS или количество пользователей. Например, 80 завершённых обращений от пользователя на портал в минуту 95% SLA — конкретный и воспроизводимый показатель для компаний.

Этапы роста производительности SimpleOne: технологии и результаты

В 2023 году, чтобы соответствовать требованиям крупных российских заказчиков, которые стали чаще обращаться за отечественными решениями для автоматизации, мы начали системную работу над производительностью платформы. Нам предстояло поверить, что Low-code платформа может справляться с задачами уровня enterprise. Расскажем, как мы поэтапно увеличили производительность SimpleOne в 16 раз за полтора года.

Важно отметить, что производство замеров эффективности происходило на стенде с клиенткой логикой — это были бизнес-процессы, которые могут быть настроены у клиента, обеспечивающие автоматизацию его индивидуальных сценариев. Это дополнительно повысило требования к производительности и проведению самого тестирования.

Стартовая точка (август 2023)

Исходная архитектура: монолитная система с единой базой данных для чтения и записи. Все компоненты платформы — веб-интерфейс, API, фоновые процессы — обращались к одной PostgreSQL базе. При любой операции система сначала записывала данные, затем сразу же читала их для отображения пользователю.

Показатели производительности: В ходе нагрузочных сессий была зафиксирована стартовая пиковая производительность на уровне ≈6 обращений в минуту. По итогам анализа системная команда сформировала план инициатив, направленных на масштабирование системы и внедрение паттерна CQRS.

Основные ограничения: база данных стала единственным узким местом всей системы. Процессор и память серверов приложений простаивали, но PostgreSQL работал на пределе возможностей. Каждый запрос на чтение блокировал ресурсы, которые могли понадобиться для записи новых данных.

Первый этап — горизонтальное масштабирование API монолита + разделение чтений и записей по узлам БД (май 2024)

Технологические изменения:

• Начали маршрутизировать запросы на чтение к репликам баз данных, а операции записи оставили на основном сервере. Команды, которые изменяют данные, теперь обрабатываются отдельно от запросов, которые только читают информацию. Исключение составляют запросы на чтение внутри транзакций — они по-прежнему выполняются на основной базе для обеспечения консистентности данных.
• Переключили репликацию баз данных с режима failover на активное использование для распределения нагрузки. Мастер-база принимает все операции записи и синхронизирует изменения с репликами. Настроили автоматическую синхронизацию с минимальной задержкой.
• Разделили роли у узлов системы: выделили отдельные серверы для обработки операций чтения и записи. Все запросы на чтение направили на реплики: формирование отчетов, загрузка списков обращений, поиск по базе знаний. Мастер-база используется только для записи новых данных и обновления существующих записей.
• Масштабировали API за счет добавления реплик БД для распределения нагрузки на чтение между несколькими серверами баз данных.

Практический результат: достигнута пиковая производительность ≈41 пользовательское обращение в минуту, что соответствует приросту ≈580% относительно начального уровня. Время отклика страниц сократилось в среднем на 60%, пользователи перестали замечать задержки при работе с отчетами.

Практический результат: достигнут новый максимум ≈97 пользовательских обращений в минуту, что составило прирост ≈136% по сравнению с предыдущим этапом. Система стала стабильнее работать при пиковых нагрузках, когда одновременно активны несколько тысяч агентов (исполнителей обращений).

Почему сработало: устранили скрытую нагрузку от постоянного создания и закрытия соединений с базой данных, оптимизировали работу с памятью через кеширование. Получили возможность точечно наращивать мощности без переплаты за неиспользуемые ресурсы — можем добавлять вычислительные мощности там, где они действительно нужны.

График производительности системы во время нагрузочного тестирования в продуктиве заказчика

Общий результат

Увеличение производительности в 16 раз за полтора года — с 68 тысяч до 1 000 000 пользовательских обращений в месяц.

Подтверждение результатов: независимое тестирование заказчиком с аналогичной методологией. 

Промежуточный контроль: регулярные синхронизации с заказчиком раз в квартал для отслеживания прогресса и корректировки планов. Каждый этап сопровождался детальным отчетом о достигнутых показателях и планах дальнейших улучшений.

О важности правильной кастомизации

Помимо архитектурных улучшений платформы, мы обнаружили еще один важный фактор, влияющий на производительность — качество Low-code конфигураций, которые создают сами клиенты. Гибкость платформы позволяет реализовывать бизнес-процессы разными способами, но не все подходы одинаково эффективны с точки зрения производительности.

В рамках работы с заказчиком мы провели аудит их Low-code конфигураций и выявили узкие места в реализации критичных бизнес-сценариев. Оказалось, что некоторые процессы были настроены неоптимально: избыточные обращения к базе данных внутри циклов, неэффективные правила фильтрации данных, дублирование логики в разных компонентах системы.

После оптимизации клиентской бизнес-логики — без изменений в архитектуре платформы — производительность критичных для заказчика сценариев выросла более чем на 15%. Это подтвердило важность не только технической оптимизации самой платформы, но и профессионального подхода к проектированию бизнес-процессов.

Планы на будущее: следующий уровень производительности

Внедрение event-driven подходов позволит более эффективно утилизировать ресурсы через асинхронную обработку событий. Вместо синхронного выполнения всех операций платформа будет обрабатывать события в фоновом режиме, освобождая интерфейс для пользователей и распределяя нагрузку во времени. При этом современные технологии оркестрации обеспечат эластичность системы и автоматическое масштабирование по настроенным алгоритмам и метрикам. 

Резюме

За полтора года работы над производительностью SimpleOne мы прошли путь от 68 тысяч до миллиона пользовательских обращений в месяц — рост в 16 раз. Этот результат стал возможен благодаря системной работе над архитектурой платформы.

Основные улучшения:

• внедрили элементы CQRS и разделили операции чтения и записи на архитектурном уровне;
• переключили репликацию баз данных на активное использование для распределения нагрузки;
• внедрили PgBouncer для эффективного управления пулом соединений с базой данных;
• оптимизировали многоуровневое кеширование данных;
• разделили компоненты системы по зонам ответственности для точечного масштабирования.

Платформа доказала способность справляться с нагрузками enterprise-уровня и обеспечивать время отклика, приемлемое для корпоративных пользователей. Горизонтальное масштабирование позволяет системе расти вместе с бизнесом клиента — компании не нужно менять платформу при увеличении штата или расширении процессов, достаточно добавить вычислительные мощности в нужных компонентах архитектуры.

Результаты подтверждены независимым нагрузочным тестированием на мощностях крупного заказчика. Мы продолжаем работу над архитектурными улучшениями, каждое обновление основано на анализе реальных нагрузок и обратной связи от клиентов Enterprise-сегмента.