Обработка данных в режиме реального времени с помощью CDC и использование Change Data Capture архитектуры, управляемой событиями
Обзор
Macquarie Group, глобальная группа в сфере финансовых услуг, постоянно работает над внедрением событийно-ориентированной архитектуры с целью обеспечения 100% обработки событий в режиме реального времени.
Для достижения данной цели специалисты компании, работающие с данными, проектируют платформы данных с учетом необходимости использования микросервисов, взаимодействующих меду собой с помощью событий. Каждый микросервис передает свои события в общий поток, а также сохраняет определенные данные в хранилище данных.
Самая распространенная трудность при получении данных из используемых приложений заключается в том, что эти приложение является готовым продуктом, который нельзя модифицировать. Поэтому способа интеграции существующих приложений с новыми микросервисами на уровне приложений просто-напросто не существует.
Поскольку мы хотим, чтобы наши микросервисы были гибкими, устойчивыми и управлялись сообщениями, нам нужно отправлять обновленные данные всем нижестоящим службам в режиме реального времени.
Чтобы решить эту проблему, наша команда инженеров из подразделения BFS Wealth реализовала шаблон поиска событий с использованием так называемого Change Data Capture (CDC) - современной техники, позволяющей передавать обновления базы данных в виде событий, которые могут быть использованы последующими сервисами.
Минимально жизнеспособный продукт (MVP) и проектные решения
CDC – это процесс обнаружения, захвата изменений, внесенных в данные в БД, и их передачи в последующие процессы или системы в режиме реального времени. Это современная технологическая возможность, которую предлагают серверы баз данных, позволяющая перехватывать операции обновления данных из журнала транзакций базы данных. Этот журнал транзакций может быть использован для публикации потока событий с помощью двух различных механизмов, а именно Debezium и AWS DMS.
Для того чтобы реализовать жизнеспособную событийно-ориентированную модель, необходимо выбрать соответствующие технологии, принимая во внимание актуальную технологическую экосистему компании, и определиться с тем, каким способом лучше всего получить MVP.
Чтобы получить желаемый MVP, наши дата-инженеры решили сделать следующее:
- Поддержка CDC
Убедившись в том, что наша БД и ее конкретная версия поддерживают CDC, мы изучили все возможные последствия влияния процедур производственных процессов на CDC. При этом мы обнаружили, что после включения CDC на 5 SQL Server 2019, если CDC не доступен для какого-либо администрирования, заново его включить не получится. Мы попытались обновить версию БД и применить определенные исправления, доступ к которым открыт только для администратора системы. Поскольку наша база данных была полностью готовым продуктом, обновление ее версии повлекло бы за собой обширное тестирование и увеличение времени выхода новых услуг на рынок. Поэтому мы проанализировали все за и против остановились на более безопасном варианте, а именно на применении исправлений для хранимых процедур CDC. Стоит отметить, что при работе на AWS RDS только служба поддержки AWS могла бы реализовать аналогичное решение.
- Потоковая передача событий
И AWS DMS, и Debezium обладают рядом важнейших преимуществ. Так, одной из уникальных возможностей AWS DMS является способность переключаться с репликации базы данных на CDC в определенный момент времени. Хотя в данном случае нам не требовалась единовременная синхронизация двух источников данных перед переходом на CDC, AWS DMS оказался полезным для нас в других областях. AWS DMS может направлять поток событий в AWS Kinesis или Amazon MSK (или Apache Kafka). Управляемый AWS сервис может обеспечить высокую надежность системы, если Ваши последующие сервисы находятся в облаке AWS. В нашем случае использование этих сервисов было сопряжено с большими трудозатратами. Что касается Debezium, он построен на концепции коннекторов с открытым исходным кодом. Различные платформы потоковой передачи событий и обмена сообщениями встраивают в свои версии коннекторов реализацию Debezium с открытым исходным кодом, специфичную для каждой БД. Некоторые из этих коннекторов (например, Solace или Google Pub/Sub) могут быть развернуты и запущены в виде контейнеров самостоятельно, а другие, такие как Kafka, работают поверх кластера Kafka Connect (подробнее об этом мы расскажем чуть позже). Мы выбрали Debezium в первую очередь для того, чтобы наш стек не зависел от каких-либо облачных технологий.
- Совместимость с базами данных и коннекторами
Выбор платформ для потоковой передачи событий просто огромен: AWS Kinesis, Amazon MSK и Apache Kafka для AWS DMS; Solace, Apache Kafka и Google Pub/Sub для Debezium. Однако в зависимости от базы данных, из которой Вы хотите передавать события, для Debezium доступно не так уж и много вариантов. Например, на момент написания этой статьи для MS SQL были доступны только коннекторы Debezium Solace и Kafka (скоро появится коннектор Pub/Sub). Мы выбрали настройку коннектора Debezium, так как это было относительно просто с учетом нашего технологического стека на тот момент.
- Wrangler или постпроцессор
Поскольку события CDC основаны на схемах баз данных, для преобразования этих событий в более понятные бизнес-события необходимо выполнить дополнительную обработку в платформе потоковой передачи событий. Kafka вполне можно расценивать как платформу для добавления таких дополнительных постпроцессоров. Однако в нашем случае мы предпочли создавать события CDC в виде готовых данных для того, чтобы не нуждаться в постпроцессорах.
Достижение устойчивости и правильного уровня абстракции
Поскольку Debezium является open-source решением, мы рассматривали множество разных способов внедрить его в корпоративную систему Macquarie. Можно было запустить его как отдельное приложение (сервер) на выбранном нами компьютерном движке, но для нас было предпочтительнее использовать коннекторы, созданные такими платформами, как Kafka или Solace.
Ниже приведено краткое сравнение обёрток Solace и Kafka для Debezium:
Как показано выше, этот Solace можно запустить в виде контейнера на выбранной Dами платформе Kubernetes. Поскольку на тот момент мы уже работали с платформами Kubernetes (GKE), нам не составляло никакого труда реализовать данное решение. Однако оно требовало наличия постоянного хранилища на кластере для хранения смещения данных. Это было для нас достаточно проблематично, поскольку мы не хотели создавать постоянное хранилище на нашей платформе GKE. Поэтому мы решили перейти на коннектор Kafka.
Большинство платформ для обмена сообщениями и потоковой передачи данных для интеграции предоставляют SDK. Использование данного набора вполне оправданно, особенно если Вы разрабатываете что-то очень специфическое, требующее более пристального и детального контроля. Однако при использовании проприетарных SDK переключение между двумя разными брокерами сообщений может быть достаточно сложной задачей. Для большинства случаев существует более оптимальное решение, реализованное командой Spring Cloud, благодаря которому мы переключили реализацию нашего решения с Solace на Kafka в течение одного дня.
Модель имеет большое значение, поэтому измеряйте, контролируйте и оптимизируйте Ваш процесс
Возвращаясь к обоснованию целесообразности использования CDC в качестве механизма обработки событий в режиме реального времени, в первую очередь стоит упомянуть обеспечение оптимальной пропускной способности всей системы при пиковом трафике. Поэтому важно не только измерять, оценивать и оптимизировать текущую пиковую нагрузку, но и учитывать увеличение нагрузки в ближайшем будущем. На диаграмме ниже показана упрощенная версия взаимодействий, реализованная в нашей системе:
Несколько решений, которые помогли нам сделать вышеописанную конструкцию более эффективной:
- Масштабируемость вычислений — запуск контейнеров в Kubernetes позволяет нам масштабировать вычисления;
- Микросервисы без состояния — каждый запрос не зависит от предыдущего, что удобно для горизонтального масштабирования;
- Database оптимизирована для чтения/записи — несмотря на то, мы по-прежнему используем реляционную базу данных, мы храним данные в денормализованном виде в столбцах в формате JSON. Кроме того, мы по-прежнему используем поиск по индексам, но избегаем записи в нескольких таблицах;
- Промежуточное программное обеспечение для обмена сообщениями — в BFS для запуска рабочих нагрузок Kubernetes мы все чаще используем облако Google. Кроме того, для нас очень важно и то, что такие сервисы, как Google Pub/sub, специально созданы для того, чтобы оптимизировать потоковую передачу сообщений при повышенных нагрузках. Cloud Pub/Sub был разработан с учетом необходимости обработки больших объемов сообщений. Это также означает и то, что при увеличении пропускной способности значительно улучшается latency. С другой стороны, данный сервис является не самым оптимальным решением в том случае, если пропускная способность сообщений слишком мала. Учитывая этот аспект Pub/sub, некоторые компании, такие как Spotify, пошли дальше и создали свой собственный async-клиент для того, чтобы воспользоваться всеми преимуществами сверхнизких задержек при высокой пропускной способности. В нашем случае пропускная способность была достаточно высокой, никаких дополнительных мер не требовалось, и все же мы смогли улучшить некоторые из наших процессов, которые теперь завершаются в 10 раз быстрее.
Важно отметить, что мы измеряли и настраивали вышеуказанные параметры, тестируя производительность системы при использовании наших API. Мы использовали инструмент под названием Gatling, чрезвычайно мощный инструмент тестирования различных сценариев использования с помощью простых конфигураций кода.
Наблюдаемость данных
Настройка наблюдаемости данных очень важна для повышения производительности работы разработчиков. Существует множество способов, с помощью которых мы настраиваем наблюдаемость для того, чтобы получить всеобъемлющее представление о работе приложений:
- Отслеживание влияния CDC на производительность базы данных. При любом снижении производительности Вы получите характерные предупреждения:
- Отслеживание производительности Kafka. Есть как оповещения, касающиеся инфраструктуры, так и оповещения о доставке сообщений:
- Мониторинг промежуточного ПО для обмена сообщениями. Дашборд и оповещения. Для работы с Pub/sub доступно множество оповещений:
- Отслеживание телеметрии.
Заглядывая в будущее
Важно подчеркнуть, что CDC требует постоянной тонкой настройки по мере того, как мы постепенно включаем данную технологию во все большее количество таблиц. Существуют и другие альтернативы, которые более просты в реализации, но обеспечивают обработку только в режиме, близком к режиму в реальном времени.
В нашем случае технология CDC позволила избежать необходимости использования пакетной обработки данных и ускорить переход к сквозной обработке данных, что поспособствовало применению "надежных данных" в рамках всей компании. Кроме того, в архитектуре, управляемой событиями, микросервисы записывают данные в локальную базу данных и публикует соответствующие события для последующих систем. Паттерн Transactional Outbox является предпочтительным решением для реализации подобных сценариев. В связи с этим в данный момент мы также тестируем возможность использования CDC для реализации Transactional Outbox в наших будущих проектов. Мы будем очень рады поделиться с Вами результатами нашей работы!
