Масштабирование Zeebe: как Т-Банк добился 100 процессов в секунду и победил каскадные сбои

Команда разработки кредитных продуктов для физических лиц в Т-Банке провела масштабное нагрузочное тестирование workflow-движка Zeebe, который является основой Camunda 8. Целью было проверить, способен ли этот движок заменить устаревшую Camunda 7 в высоконагруженных системах. В ходе тестов инженеры столкнулись с каскадными сбоями, но после анализа ресурсов и тюнинга конфигураций добились стабильной обработки до 100 процессов в секунду. Результаты показывают, что многие стереотипы о медлительности и нестабильности Zeebe устарели.

Как проходило нагрузочное тестирование Zeebe

Тестирование проводилось на кластере из трех брокеров Zeebe (версия 8.3.1) с использованием Kubernetes. Начальная конфигурация была основана на стандартных рекомендациях: 4 ядра CPU, 16 ГБ RAM на брокер, хранилище на SSD. В качестве нагрузки использовался симулятор, генерирующий до 200 одновременных процессов с разными ветвлениями. На первых же тестах при нагрузке около 50 процессов в секунду начались каскадные сбои: один брокер выходил из строя, его нагрузка перераспределялась на другие, что приводило к их перегрузке и отказу всего кластера.

Инженеры выяснили, что корень проблемы — в неоптимальных настройках кэшей и лимитах памяти. Zeebe интенсивно использует off-heap память для хранения состояний процессов, и при превышении лимитов начинались длительные паузы garbage collection, которые блокировали обработку. После серии экспериментов были подобраны параметры: размер кэша для состояний (zeebe.broker.flow.cache.maxSize) увеличен до 256 МБ, а лимит off-heap памяти (zeebe.broker.flow.memoryLimit) установлен на 12 ГБ. Также оптимизировали количество потоков обработки (zeebe.broker.flow.processingThreads) с 4 до 8.

Предыстория и контекст

Camunda 7 долгое время была стандартом для workflow-движков в Java-экосистеме, но её архитектура не рассчитана на горизонтальное масштабирование. Zeebe, напротив, изначально проектировался как распределенный движок для микросервисной архитектуры. Однако ранние версии Zeebe (до 8.x) действительно страдали от проблем с производительностью и стабильностью, что породило негативные отзывы. В версии 8.3 были значительно улучшены механизмы управления памятью и распределения нагрузки, но практических кейсов масштабирования в публичном доступе было мало.

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

Почему возникают каскадные сбои в Zeebe?

Каскадный сбой в распределенной системе возникает, когда отказ одного узла вызывает цепную реакцию. В Zeebe это часто связано с исчерпанием ресурсов на оставшихся узлах после выбытия одного. В ходе тестов Т-Банка выяснилось, что стандартные настройки не учитывают пиковое потребление памяти при перераспределении партиций. Когда один брокер падает, его партиции перераспределяются между оставшимися, что резко увеличивает нагрузку на их off-heap память. Если лимиты установлены без запаса, происходит переполнение и падение следующего брокера. Решение — увеличить запас по памяти на каждом узле и настроить более агрессивное кэширование, чтобы снизить количество операций чтения с диска при перераспределении.

Технические подробности: архитектура и тюнинг

Zeebe использует архитектуру на основе партиций: каждый процесс распределяется по партициям, которые реплицируются между брокерами. Для достижения 100 процессов в секунду инженеры Т-Банка настроили 8 партиций на кластер из 3 брокеров. Ключевым параметром оказался размер журнала (logSegmentSize): увеличение с 512 МБ до 1 ГБ снизило частоту слияния сегментов и уменьшило IO-нагрузку. Также были изменены настройки экспортера: отключен экспорт в Elasticsearch для тестового стенда, что сократило накладные расходы на 15%.

Важным открытием стало влияние настройки zeebe.broker.gateway.longPolling.enabled. При включенном long polling шлюз дольше удерживает соединения с клиентами, что увеличивает количество одновременных запросов, но снижает задержки. Включение этой опции увеличило пропускную способность на 20% при нагрузке свыше 80 процессов в секунду. Также было обнаружено, что использование SSD с низкой задержкой (NVMe) критично: на обычных SSD производительность падала на 30% из-за задержек записи в журнал.

Кого затронет и как

Результаты тестирования в первую очередь полезны командам, которые используют Camunda 7 и рассматривают миграцию на Camunda 8. Для российских компаний, особенно в финансовом секторе, где требования к импортозамещению высоки, Zeebe может стать альтернативой проприетарным решениям. Разработчики, которые настраивают Zeebe, могут применить описанные параметры для повышения стабильности. Бизнес-заказчики получают подтверждение, что Zeebe способен обрабатывать высокие нагрузки без сбоев.

Для команд, которые уже используют Zeebe, но сталкиваются с нестабильностью, тесты Т-Банка дают конкретные рекомендации: увеличить off-heap лимиты, настроить кэши, использовать NVMe-диски. Важно также правильно рассчитывать количество партиций: их должно быть не меньше, чем количество брокеров, но избыточное количество (более 10 на брокер) увеличивает накладные расходы на синхронизацию.

Что будет дальше

Т-Банк планирует продолжить тестирование с более высокими нагрузками (до 500 процессов в секунду) и исследовать поведение Zeebe при частичной потере узлов. Также рассматривается возможность использования Zeebe в production для одного из кредитных конвейеров. В сообществе Camunda ожидается выход версии 8.4 с улучшенной поддержкой многорегиональных развертываний, что может еще больше повысить отказоустойчивость.

Итог

Опыт Т-Банка доказывает, что Zeebe при правильной настройке способен стабильно обрабатывать 100 процессов в секунду на небольшом кластере. Каскадные сбои преодолимы за счет грамотного управления памятью и кэшами. Для компаний, которые ищут масштабируемый workflow-движок с открытым исходным кодом, Zeebe — жизнеспособный вариант, особенно в версии 8.3 и новее.