Как организовать доступ к данным в real-time?

В этой статье мы, архитекторы Tarantool и эксперты компании “Мобиус Технологии”, расскажем, с какими трудностями сталкиваются компании при росте нагрузок и объема данных, а также, как с их решением помогают продукты экосистемы Tarantool.

Материал подготовлен по мотивам онлайн-вебинара VK Tech и Мобиус Технологии «Доступ к данным в режиме реального времени».

Вызовы в проектировании высоконагруженных систем

Объем данных, генерируемых пользователями, непрерывно растет. Это дает компаниям возможность агрегировать данные, анализировать их и на основе результатов аналитики улучшать свои продукты.

Однако увеличение потоков данных повышает требования к ИТ-системам компаний: они должны справляться с большим количеством запросов, оставаясь доступными.

Таким образом, проектируя высоконагруженные ИТ-системы, компании сталкиваются с определенными трудностями и вызовами. Среди них:

• построение сервисов, работающих в режиме реального времени;
• обеспечение доступности данных для поддержания непрерывности бизнес-процессов;
• агрегация данных из разрозненных источников;
• масштабирование приложений с монолитной архитектурой;
• сокращение Time-to-market продуктов и сервисов.

Ответить на эти вызовы можно двумя способами:

• Полностью перестраивать ИТ-ландшафт под новые нагрузки. Подход эффективный, но сложный — требуется много времени, большая команда и ресурсы. А при наличии чувствительных legacy-систем, такие изменения могут быть вовсе невозможны.
• Использовать дополнительные инструменты, которые помогут ускорить обработку данных и добавить нужные параметры в исходные сервисы без изменения архитектуры Core-систем.

Второй вариант часто выгоднее, потому что требует меньше усилий и инвестиций. А реализовать его можно практически при любой архитектуре ИТ-системы.

Инструменты для основных вызовов

Реализовать упомянутую оптимизацию можно с помощью «внешних» компонентов, способных выполнять задачи Middleware-слоя или core-систем.

Таковым является Tarantool — решение класса middleware, которое позволяет ускорить сервисы и снизить нагрузку на core-cистемы.

Примечание: Подробнее о том, как решения класса middleware ускоряют цифровое развитие бизнеса можно прочитать здесь.

Он сочетает в себе сервер приложений, хранилище с гибкой схемой данных и средства масштабирования. Tarantool применяется в банковском секторе, ритейле, телекоме и других отраслях для эффективного создания высоконагруженных приложений.

Появление и развитие экосистемы

Tarantool всегда развивался эволюционно: от простой in-memory базы данных к полноценной платформе с хранилищем, application-сервером и функционалом масштабирования и обеспечения отказоустойчивости. При этом, основным драйвером развития всегда были запросы пользователей и желание предоставить им инструменты для закрытия основных потребностей.

Примечание: Подробнее о предпосылках создания Tarantool и истории его эволюции от внутреннего продукта до enterprise-инструмента можно прочитать здесь.

Tarantool Cartridge

Так, после того, как решение начали активно использовать компании enterprise-уровня, мы начали получать запрос на инструмент для быстрого и простого запуска кластеризованного хранения.

В ответ на этот запрос мы, команда Tarantool, разработали новый фреймворк. Так в «портфеле Tarantool» появился Tarantool Cartridge. Это фреймворк для разработки кластерных приложений на основе Tarantool и vshard. Он обеспечивает репликацию, шардирование и занимается управлением конфигурацией узлов кластера. То есть разработчику остается только написать бизнес-логику приложений.

Следующим этапом развития фреймворков для централизованного управления кластерами стал Tarantool Cluster Manager (TCM) — инструмент внутри версии Tarantool 3.0. С его помощью кластеры любого типа и сложности могут настраиваться через единый отказоустойчивый модуль конфигурации через графический интерфейс. Подробнее о 3.0 и TCM — в статье.

Change Data Capture

Постепенно пул задач Tarantool расширялся. Среди прочего, была важная задача о средствах инвалидации при использовании его в качестве кэша, чтобы быть уверенными в актуальности данных. Подобных механизмов много, но нам было важно интегрировать его с Tarantool или даже «зашить» в инструмент, чтобы пользователь мог получить нужные функции «из коробки».

Здесь нам помогло наличие в Tarantool механизма сохранения данных на диск в виде журнала и принципа захвата изменения данных, когда данные из журнала последовательно применяются или переносятся в другое место. Фактически на этом реализована репликация.

Используя эти возможности «ядра», мы разработали новый инструмент экосистемы — Change Data Capture. Это репликатор, который забирает данные из основной СУБД, не нагружая ее, и дает возможность провести миграцию в другую базу или внешние системы. Таким образом, Tarantool CDC решает и задачу оптимизации расходов, позволяя разделять дешевое («холодное») и более дорогое («горячее») хранение.

Важно, что Tarantool CDC дает возможность агрегировать данные из разных источников без остановки БД, обрабатывать их, строить кеши и витрины.

Tarantool DB

Пул сценариев, в которых можно применять продукты экосистемы Tarantool, становился больше, но скорость разработки приложений была недостаточно высокой. Отчасти — из-за необходимости учить и использовать Lua-код. Это влияло на time-to-market и было проблемой для компаний, у которых нет своих разработчиков.

Чтобы снизить порог входа, команда Tarantool разработала «коробочное» решение, в которое «упаковала» нужные функции и инструментарий для деплоя. Клиенты получили инструмент с интерфейсом, включающим все необходимые функции для работы с данными, и возможность оперативно развернуть кластер, который может сразу использоваться и взаимодействовать с другими приложениями.

Этим продуктом стал Tarantool DB — инструмент для простого создания и работы с БД, имеющий поддержку интерфейса доступа по протоколам Redis и IPROTO.

Одно из преимуществ Tarantool DB — повышенные гарантии надежности за счет синхронной репликации на уровне кластеров, поддержки Tarantool Clusters Federation, WAL и других функций.

Кейсы применения продуктов Tarantool для работы с данными в real-time

Инструменты из «продуктового портфеля» Tarantool используются в разных кейсах и сценариях. Разберем несколько примеров, уже внедренных и работающих в проде больших компаний.

Сервис аутентификации

На уровне сервиса важно разграничивать доступные пользователям «зоны». Для этого надо узнавать пользователей, аутентифицировать их.

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

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

Один из наших клиентов выбрал для этих задач Tarantool DB. Инструмент применен в сервисе аутентификации для централизованного хранения сессий пользователей и токенов аутентификации, и работает с нагрузкой:

• более 20 млн записей;
• до 2 тысяч одновременных сессий;
• до 2 тысяч запросов в секунду.

При этом Tarantool DB обеспечивает скорость отклика менее 100 мс и закрывает два сценария:

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

В этом кейсе компания развернула Tarantool DB на двух ЦОДах с кворумной синхронной репликацией между инсталляциями (уменьшает риск потери данных), а в архитектуру решения также добавила шлюз аутентификации и сервис SSO. Примечание: Не всегда надо строить кэширующий слой для хранения токенов. Как правило, это целесообразно в ситуациях, когда, например, использовать JWT или mTLS нет возможности.

Золотая запись

В современных архитектурах данные не только хранятся разрозненно, но и могут пересекаться в разных системах. Со временем это может начать влиять на скорость доступа к данным. Поэтому их желательно агрегировать в едином хранилище с обеспечением консистентности. Здесь две сложности:

• поскольку данные могут пересекаться, надо настраивать механизмы дедубликации;
• из-за большого объема данных часто сложно выбрать единоверный способ их шардирования.

Как пример, запросы от call-центра могут приходить по номеру телефона, а от систем лояльности — только по номеру карты лояльности. И все запросы должны быть обработаны одинаково быстро.

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

Один из наших клиентов использовал Tarantool CDC при построении такого хранилища золотых записей. Сам Tarantool CDC применен в качестве промежуточного слоя между системами-источниками и хранилищем. Такой «трансфер» помогает ускорить обмен данными и снять нагрузку с ядра системы.

Клиент также добавил в реализацию слой, который хранит индексы для быстрого поиска основного идентификатора записи и уже по нему обращается в хранилище золотых записей. Это снижает количество запросов к core-компоненту. Примечание: Tarantool поддерживает коннекторы на Java и Go. О них можно почитать здесь. Есть и большой пул коннекторов, поддерживаемых комьюнити — от Perl до C#. Также можно настроить интеграцию инструмента со всеми классическими брокерами сообщений (например, RabbitMQ или Kafka).

Принятие решений в реальном времени

Функционал обработки данных в реальном времени и мгновенной подготовки «ответов» пользователю активно используют:

• в ритейле — для выявления закономерностей и предложения релевантных товаров на основе только что совершенных действий или покупок;
• в финансовой сфере — для отслеживания транзакций и своевременной блокировки мошеннических действий;
• в производстве — для мониторинга данных с датчиков и IoT-устройств и анализа корректности выполняемых процессов. Но строить такие системы сложно:
• большие потоки записей;
• агрегирующие запросы чтения;
• высокие требования к задержке ответа.

В итоге из-за специфических вводных данных и сценариев нельзя работать с чисто аналитическими или чисто транзакционными БД — надо решение «на стыке» для гибридной транзакционно-аналитической обработки данных (HTAP, Hybrid transaction/analytical processing).

Такой инструмент есть и у Tarantool — Tarantool Column Store. Это in-memory колоночная СУБД для транзакционно-аналитической обработки данных в реальном времени.

Среди сценариев применения Tarantool Column Store:

• Customer Journey Management/Customer Interactions Activities;
• АСУ ТП;
• антифрод.

Один из крупных банков уже интегрировал Tarantool Column Store в свое решение для антифрода и успешно пилотирует его.

Примечание: Флагманским решением в HTAP-хранении принято считать SAP HANA. Но SAP HANA — большое приложение со сложной «обвязкой», которое не всегда удобно использовать и администрировать. Поэтому Tarantool Column Store — отличная альтернатива SAP HANA, когда нужен именно движок хранения. К тому же Tarantool Column Store — отечественная разработка, что исключает уход решения с российского рынка.

Итоги: как бороться с типовыми вызовами

На вызовы, возникающие при построении высоконагруженных систем, уже придуманы решения. Например:

• для реализации сервисов и приложений, работающих в реальном времени, желательно строить «горячее» хранилище с низкой задержкой (Latency);
• для обеспечения доступности данных важно заботиться о масштабировании и отказоустойчивости сервисов;
• для работы с данными из разрозненных источников оптимально строить агрегирующее хранилище;
• для поддержки динамического роста приложений с монолитной архитектурой можно строить кэширующий слой;
• в сокращении TTM и экономии помогает гибкая разработка, уменьшение «зоопарка» технологий и переход на микросервисы.

Продукты экосистемы Tarantool можно использовать при реализации решений для каждого из этих сценариев (и не только). Многозадачность «продуктового портфеля» Tarantool позволяет пользователям не «раздувать» штат, а прокачивать экспертизу в одном инструменте, не «распыляясь» на целый «зоопарк», который поддерживать часто сложно и дорого.