Производительность Low-code платформы — один из самых спорных вопросов для enterprise-сегмента. Интерпретация настроек «на лету» создает дополнительную нагрузку по сравнению с готовыми решениями, но дает бизнесу гибкость и возможность быстро менять процессы. Работая с крупнейшими заказчиками, мы сделали производительность стратегическим приоритетом и сейчас продолжаем развивать платформу под требования больших компаний. С 2023 года производительность SimpleOne выросла с 68 тысяч до миллиона пользовательских обращений в месяц — это результат системной работы над архитектурой платформы.
Рассказываем о нашем пути и архитектурных решениях, которые позволили увеличить производительность Low-code платформы.
Почему мы выделяем производительность как критичный фактор для корпоративного Low-code
Компании выбирают Low-code платформы, чтобы быстрее автоматизировать бизнес-процессы и снизить зависимость от разработчиков. Однако у такого подхода есть особенность: платформа выполняет код «на лету», в runtime. Система интерпретирует настройки, бизнес-правила и пользовательские скрипты во время работы, а не компилирует их заранее. Такая архитектура создает дополнительную нагрузку по сравнению с готовыми коробочными решениями, и это важно понимать при выборе решений для автоматизации.
«Несмотря на принципиальные ограничения Low-code платформ, они дают бизнесу гибкость и возможность быстро менять процессы. Наша задача как разработчиков платформы — сделать так, чтобы эта гибкость не шла в ущерб производительности»
Дмитрий Дмитренко
Технический директор SimpleOne
Для крупного бизнеса низкая производительность платформ автоматизации становится критичной проблемой. Когда система работает медленно, сотрудники не успевают выполнять бизнес-процессы в установленные сроки, будь то обработка обращений в службе поддержки, согласование документов в юридическом отделе или управление закупками. Автоматизация, которая должна была ускорить процессы, превращается в препятствие.
По опыту наших клиентов, особенно остро проблема проявляется в часы пик — обычно с 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 — конкретный и воспроизводимый показатель для компаний.
Читайте ранний большой обзор Low-code платформы SimpleOne на Хабре
Этапы роста производительности SimpleOne: технологии и результаты
В 2023 году, чтобы соответствовать требованиям крупных российских заказчиков, которые стали чаще обращаться за отечественными решениями для автоматизации, мы начали системную работу над производительностью платформы. Нам предстояло поверить, что Low-code платформа может справляться с задачами уровня enterprise. Расскажем, как мы поэтапно увеличили производительность SimpleOne в 16 раз за полтора года.
Важно отметить, что производство замеров эффективности происходило на стенде с клиенткой логикой — это были бизнес-процессы, которые могут быть настроены у клиента, обеспечивающие автоматизацию его индивидуальных сценариев. Это дополнительно повысило требования к производительности и проведению самого тестирования.
Стартовая точка (август 2023)
Исходная архитектура: монолитная система с единой базой данных для чтения и записи. Все компоненты платформы — веб-интерфейс, API, фоновые процессы — обращались к одной PostgreSQL базе. При любой операции система сначала записывала данные, затем сразу же читала их для отображения пользователю.
Показатели производительности: В ходе нагрузочных сессий была зафиксирована стартовая пиковая производительность на уровне ≈6 обращений в минуту. По итогам анализа системная команда сформировала план инициатив, направленных на масштабирование системы и внедрение паттерна CQRS.
Основные ограничения: база данных стала единственным узким местом всей системы. Процессор и память серверов приложений простаивали, но PostgreSQL работал на пределе возможностей. Каждый запрос на чтение блокировал ресурсы, которые могли понадобиться для записи новых данных.
Первый этап — горизонтальное масштабирование API монолита + разделение чтений и записей по узлам БД (май 2024)
Технологические изменения:
Начали маршрутизировать запросы на чтение к репликам баз данных, а операции записи оставили на основном сервере. Команды, которые изменяют данные, теперь обрабатываются отдельно от запросов, которые только читают информацию. Исключение составляют запросы на чтение внутри транзакций — они по-прежнему выполняются на основной базе для обеспечения консистентности данных.
Переключили репликацию баз данных с режима failover на активное использование для распределения нагрузки. Мастер-база принимает все операции записи и синхронизирует изменения с репликами. Настроили автоматическую синхронизацию с минимальной задержкой.
Разделили роли у узлов системы: выделили отдельные серверы для обработки операций чтения и записи. Все запросы на чтение направили на реплики: формирование отчетов, загрузка списков обращений, поиск по базе знаний. Мастер-база используется только для записи новых данных и обновления существующих записей.
Масштабировали API за счет добавления реплик БД для распределения нагрузки на чтение между несколькими серверами баз данных.
Практический результат: достигнута пиковая производительность ≈41 пользовательское обращение в минуту, что соответствует приросту ≈580% относительно начального уровня. Время отклика страниц сократилось в среднем на 60%, пользователи перестали замечать задержки при работе с отчетами.
«Во время нагрузочного тестирования мы постепенно увеличивали количество виртуальных пользователей, начали со 100, дошли до 250, затем вышли на плато тестирования. После дальнейшего добавления виртуальных пользователей система начала деградировать, поэтому на этом этапе мы зафиксировали показатель в 460 тысяч обращений как максимальный»
Дмитрий Дмитренко
Технический директор SimpleOne
Почему сработало: мы разгрузили основную базу данных и устранили главное бутылочное горлышко. Теперь чтение данных не конкурирует с записью за одни и те же ресурсы. Система может одновременно обрабатывать новые обращения и формировать аналитические отчеты без взаимного влияния на производительность.
Второй этап — внедрение PgBouncer и оптимизация монолита (декабрь 2024)
Технологические изменения:
На основе серии нагрузочных тестирований выявили новые бутылочные горлышки в архитектуре системы. Несмотря на внедрение CQRS и репликации, производительность упиралась в ограничения работы с соединениями к базе данных.
Внедрили PgBouncer для монолита — промежуточный слой между приложением и PostgreSQL, который управляет пулом постоянных соединений. Провели ряд оптимизаций для кешей: настроили многоуровневое кеширование данных, оптимизировали время жизни кеша для различных типов запросов, внедрили предварительную загрузку часто используемых данных в память.
Разделили компоненты системы по зонам ответственности для более точечного масштабирования. Выделили отдельные серверы для обработки HTTP-запросов от пользователей, фоновых задач и планировщиков заданий. Настроили балансировщик нагрузки для распределения трафика между компонентами.
«Главный урок, который мы извлекли за полтора года работы над производительностью — нужно измерять систему под реальной нагрузкой, а не гадать на кофейной гуще. Когда мы внедряли PgBouncer, проблема была неочевидной: ресурсы серверов не утилизировались полностью, но производительность не росла»
Дмитрий Дмитренко
Технический директор SimpleOne
Практический результат: достигнут новый максимум ≈97 пользовательских обращений в минуту, что составило прирост ≈136% по сравнению с предыдущим этапом. Система стала стабильнее работать при пиковых нагрузках, когда одновременно активны несколько тысяч агентов (исполнителей обращений).
Почему сработало: устранили скрытую нагрузку от постоянного создания и закрытия соединений с базой данных, оптимизировали работу с памятью через кеширование. Получили возможность точечно наращивать мощности без переплаты за неиспользуемые ресурсы — можем добавлять вычислительные мощности там, где они действительно нужны.
Общий результат
Увеличение производительности в 16 раз за полтора года — с 68 тысяч до 1 000 000 пользовательских обращений в месяц.
Подтверждение результатов: независимое тестирование заказчиком с аналогичной методологией.
Промежуточный контроль: регулярные синхронизации с заказчиком раз в квартал для отслеживания прогресса и корректировки планов. Каждый этап сопровождался детальным отчетом о достигнутых показателях и планах дальнейших улучшений.
|
О важности правильной кастомизации Помимо архитектурных улучшений платформы, мы обнаружили еще один важный фактор, влияющий на производительность — качество Low-code конфигураций, которые создают сами клиенты. Гибкость платформы позволяет реализовывать бизнес-процессы разными способами, но не все подходы одинаково эффективны с точки зрения производительности. В рамках работы с заказчиком мы провели аудит их Low-code конфигураций и выявили узкие места в реализации критичных бизнес-сценариев. Оказалось, что некоторые процессы были настроены неоптимально: избыточные обращения к базе данных внутри циклов, неэффективные правила фильтрации данных, дублирование логики в разных компонентах системы. После оптимизации клиентской бизнес-логики — без изменений в архитектуре платформы — производительность критичных для заказчика сценариев выросла более чем на 15%. Это подтвердило важность не только технической оптимизации самой платформы, но и профессионального подхода к проектированию бизнес-процессов. |
Планы на будущее: следующий уровень производительности
Внедрение event-driven подходов позволит более эффективно утилизировать ресурсы через асинхронную обработку событий. Вместо синхронного выполнения всех операций платформа будет обрабатывать события в фоновом режиме, освобождая интерфейс для пользователей и распределяя нагрузку во времени. При этом современные технологии оркестрации обеспечат эластичность системы и автоматическое масштабирование по настроенным алгоритмам и метрикам.
Резюме
За полтора года работы над производительностью SimpleOne мы прошли путь от 68 тысяч до миллиона пользовательских обращений в месяц — рост в 16 раз. Этот результат стал возможен благодаря системной работе над архитектурой платформы.
Основные улучшения:
внедрили элементы CQRS и разделили операции чтения и записи на архитектурном уровне;
переключили репликацию баз данных на активное использование для распределения нагрузки;
внедрили PgBouncer для эффективного управления пулом соединений с базой данных;
оптимизировали многоуровневое кеширование данных;
разделили компоненты системы по зонам ответственности для точечного масштабирования.
Платформа доказала способность справляться с нагрузками enterprise-уровня и обеспечивать время отклика, приемлемое для корпоративных пользователей. Горизонтальное масштабирование позволяет системе расти вместе с бизнесом клиента — компании не нужно менять платформу при увеличении штата или расширении процессов, достаточно добавить вычислительные мощности в нужных компонентах архитектуры.
Результаты подтверждены независимым нагрузочным тестированием на мощностях крупного заказчика. Мы продолжаем работу над архитектурными улучшениями, каждое обновление основано на анализе реальных нагрузок и обратной связи от клиентов Enterprise-сегмента.