Разделение транзакционной и аналитической нагрузки с Tarantool

• Физически разделить транзакционную (OLTP) и аналитическую (OLAP) нагрузки: вместо 1 монолитного кластера — 3 изолированных контура.

• Исключить влияние тяжёлых аналитических отчётов на поток котировок инвестиционного бизнеса банка.

• Гарантировать жёсткие SLA для высокочастотных операций: система обслуживает 400 000 котировок в час, проверка пула из 50 000 ордеров

• Изолировать команды разработки: дефект одной команды не должен затрагивать смежные продукты.

• Ускорить выпуск релизов и масштабировать контуры независимо друг от друга.

• Мигрировать без потери данных и простоя бизнеса.

2026

• Нагрузка: стабильная обработка 400 000 котировок в час, проверка пула из 50 000 ордеров, расчёт кросс-котировок.

• SLA: тяжёлая аналитика больше не влияет на поток котировок, пиковые деградации устранены.

• Релизы: подготовка ускорилась в 2–3 раза.

• Архитектура: 3 независимых контура, каждый масштабируется по своему профилю нагрузки.

• Эффект: предотвращены финансовые и репутационные потери банка от задержек процессинга.

Tarantool

В проекте не используются решения из каталога Global CIO

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

Транзакционное Ядро функционировало на базе единого кластера Tarantool. Система обеспечивала потоковую обработку котировок в реальном времени, формирование индикативных цен, учет клиентских лимитов и построение аналитических отчетов. С развитием функционала совмещение разнородных нагрузок — быстрой транзакционной (OLTP) и тяжелой аналитической (OLAP) — в рамках монолитной архитектуры стало критическим узким местом. Выполнение объемных аналитических запросов приводило к кратковременным пиковым деградациям в высокочастотных процессах, обрабатывающих основной транзакционный поток котировок. Для этих процессов установлен предельно жесткий SLA, и любые задержки в процессинге создавали угрозу прямых финансовых и репутационных потерь для банка. 

Для устранения архитектурного конфликта был проведен глубокий рефакторинг: монолитный кластер транзакционного ядра был декомпозирован на три изолированных контура. Мы физически развели транзакционный поток (OLTP) и аналитический процессинг (OLAP), распределив их по независимым кластерам. Внедрение включало развертывание новых сред, разработку кастомных скриптов для безопасной миграции данных и бесшовное переключение внешних интеграций с системами-потребителями. Важнейшим инженерным достижением стала реализация перехода: благодаря детальному планированию, все работы были выполнены с первой попытки без потери данных и абсолютно незаметно для бизнес-пользователей. При изначально выделенном технологическом окне в 48 часов, команда успешно завершила весь цикл работ всего за 8 часов. 

Архитектурное разделение позволило изолировать команды разработчиков: локальные дефекты одной команды больше не влияют на смежные проекты, а риск каскадного сбоя сведен к нулю. Кроме того, закрыты уязвимости промышленной среды, а процесс подготовки релизов ускорился в 2-3 раза, что радикально улучшило показатель Time-to-Market для новых продуктов. Выполнена оптимизация масштабирования: теперь кластеры можно расширять независимо, опираясь на профиль нагрузки, что заложило базу для эффективного управления инфраструктурой.

Россия