Integration Patterns: Репликация и очередь сообщений

Хочу поделиться примером интеграции нескольких систем в одном из приложений, которое мы недавно разрабатывали. Я покажу проблемы и подходы, которые мы применяли. Думаю отдельные приёмы могут быть полезны в ваших проектах.

Суть системы в предоставлении аналитики пользователям из большого объема структурированной информации. Работать с аналитикой пользователи могут с помощью набора фильтров. Меняя фильтры, пользователь видит разлиные графики, таблицы и т.п. Данные нужны для анализа и принятия важных решений, поэтому должны быть точными и поступать своевременно.

Сложность была в том, чтобы достаточно быстро обрабатывать большие объемы данных. База данных проекта размером порядка 700 ГБ, среднее количество записей в основных таблицах около 100 млн.

Я намернно уберу многие детали, чтобы показать только суть проблем и решений.

Уточнять, что это за проект и кто заказчик я не могу по NDA.

Версия 1.0 - Репликация и предрасчеты

Первое решение, которое было реализовано:

Основные этапы работы версии 1.0:

1. Из сторонней системы идет репликация определенных данных
2. Триггеры перехватывают вставку, удаление и обновление данных, делают расчеты и заполняют денормализованные таблицы в БД проекта. Важно, что они ставят флаг измененным записям, это нужно для следующего шага. (Статья на эту тему Intergration Patterns: Shared DB, state machine и очередь сообщений)
3. Сервисы предрасчетов раз в период времени делают выборку данных, которые отмечены, как измененные. Сервисы насчитают все возможные комбинации, которые может запросить пользователь с помощью фильтров. Насчитанные данные попадают в БД для выборок. На последнем этапе сервис сбрасывает флаг изменения у записей в проекте, т.к. они теперь обработаны.
4. Веб-приложение реализует бизнес-логику и осуществляет работу пользователя с системой
5. На последнем этапе пользовтаель взаимодействует с веб-приложением через браузер, где ему отображается набор возможных фильтров, графики, таблицы и другие данные. При изменении фильтров все данные перестраиваются

Проблемы версии 1.0:

• Долго выполняется денормализация в триггерах. Расчет и вставка в денормализованные таблицы не успевали за поступающими через репликацию данными.
• Выставление флага об изменении данных работало очень долго. Плюс сервисы, которые обрабатывали данные с этим флагом, должны были флаг сбрасывать, возникали взаимоблокировки.
• С такой цепочкой обработки показать новые данные пользователям получается только со значительной задержкой.
• Подготовка данных для новых пользователей занимала несколько суток вместо нескольких минут, как требовалось.
• Невозможно было масштабировать на многих пользователей, т.к. узким местом были обработка триггерами и пересчет данных.

В таком варианте реализация заняла около года командой из 6 программистов. С этого момента проект передали нам.

Версия 2 - Очередь и масштабирование

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

Новая версия делалась короткими итерациями и небольшой командой. За первые 3 месяца было сделано примерно 10 различных прототипов, перепробованы различные идеи по ускорению и масштабированию. Все их перечислять будет слишком затратно, если будут предложения в комментариях и мы такое уже пробовали, то я объясню почему решение может не сработать. Наконец была найдена архитектура, которая привела к нужным характерискам.

Основные этапы работы версии 2.0:

1. Из сторонней системы идет репликация определенных данных. В идеале нам нужно было заменить репликацию из сторонней БД на очередь, но продавить это решение в сторонней команде оказалось невозможно по политическим причинам.
2. Изменение данных по-прежнему обрабатывается триггерами, но уже иначе. Триггеры отправляют изменения сразу в очередь через CLR-функции. Для очередей мы выбрали RabbitMQ, нас устроила его скорость работы (до 2500 сообщений в секунду) и надежность.
3. Обработку новых данных осуществляли сервисы, которые были подписаны на очереди. В этом месте мы могли довольно просто масштабироваться. Плюс, обработка новых данных в управляемом коде сделала возможным извещать пользователей о новых данных в их отчетах через SignalR.
4. Данные, обработанные сервисами, не считались заранее, а записывались в отдельные БД для каждого пользователя. В этих БД было всего несколько денормализованных таблиц, заточенных под быстрые выборки. Таким образом, пользователям не нужно было ждать пересчета, они могли видеть новые данные сразу при их поступлении. При работе с базами данных, их оптимизации и профилировании помог прекрасный блог SomewhereSomehow's SQL Server notes, рекомендую к прочтению. БД пользователей могли быть размещены на разных серверах, что позволяло безболезненно наращивать клиентскую базу.
5. Дальше в веб-приложении формировались запросы и отсылался JSON на клиента. Также были проанализированы различные способы работы с данными на стороне веб-приложения. В частности мы перешли с NHibernate на Dapper.
6. Часть данных на сторону клиента стали передаваться через SignalR, было уменьшено общее кол-во ajax-запросов из-за ограничения браузеров.

Такая реализация оказалась очень удачной для решаемой задачи, но в результате пришлось внести несколько существенных изменений.

Первоначальное заполнение БД

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

Версия 3 - Service Broker и оптимизация системы

При тестировании системы на pre-production серверах обнаружилась проблема, когда репликация переставала работать. Дело было в том, что CLR-функции довольно медленно отправляли данные из MSSQL в RabbitMQ. Частично это было из-за скорости работы CLR-функции, но в основом из-за того, что RabbitMQ был на отдельном сервере. Это уменьшало скорость отправки сообщений через сеть. В моменты, когда сеть между серверами отваливалась, у нас падала и репликация.

Решение было найдено с помощью вставки в архитектуру системы еще одного брокера очереди, на этот раз встроенного в MSSQL - Service Broker. Это позволило ускорить обработку входящих изменений, т.к. работа с Service Broker с того же СУБД была очень быстрой и надежной. Когда мы не могли читать данные, то очередь просто копиласть на сервере БД и работа всей системы не останавливалась.

Небольшие изменения были сделаны для оптимизации трафика между сервисами. Триггеры стали отправлять не только идентификаторы, но и измененные данные. Таким образом, последующие сервисы имели всю необходимую информацию и не делали дополнительные запросы обратно в БД проекта. В триггеры была добавлена проверка, что во время репликации изменились только значимые колонки, чтобы не было лишних срабатываний.

Выводы

Проект вышел в релиз через 8 месяцев с командой из 3 программистов и 3-5 человек в отделе тестирования.

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