Помнить всё

Технологии
23956
0
Андрей Григоров, руководитель отдела программных разработок, департамент систем электронного банковского обслуживания, R-Style Softlab
Александр Уханов, старший программист департамента систем электронного банковского обслуживания, R-Style Softlab
Далеко не всегда наше желание помнить все и обо всем соответствует физическим возможностям имеющейся ИТ-инфраструктуры. Да и найти потом нужную информацию в огромном массиве данных бывает непросто и небыстро. Решить эту проблему можно, изменив подход к построению системного журнала.


При разработке систем дистанционного банковского обслуживания стоит помнить, что они должны быть удобны не только клиентам банков, но и работникам кредитных организаций. Например, специалистам служб сопровождения и технической поддержки систем ДБО, которым приходится ежедневно заниматься разбором обращений пользователей. И чтобы быстро понять, как же помочь клиенту, когда «деньги с карты списались, а на счёт не пришли», «захожу в интернет-банк, а вклада нет», «я ничего не нажимал, оно само».., им нужно иметь под рукой правильный инструмент, позволяющий взглянуть на полную картину произошедшего. Таким инструментом является подсистема журналирования (далее для краткости будем называть ее «системным журналом»).

Что хранить в системном журнале?


Для начала определим, какая информация обычно бывает полезна при разборе конфликтных ситуаций, а значит, ее желательно хранить в системном журнале. Конечно, в идеале хотелось бы хранить всё (например, настройки системного журнала InterBank RS позволяют записывать в него информацию о более чем 300 различных типах происходящих в системе событий), однако это требует существенных вложений в инфраструктуру хранения данных. Исходя из опыта внедрений InterBank RS в банках топ-100, можем сказать, что в среднем данные, хранимые в системном журнале, составляют около 95% от всех данных, хранимых в системе ДБО.
При этом зачастую подобные объёмы достигаются уже при включении журналирования только для базовых событий. К такому минимальному обязательному набору информации, подлежащей журналированию, относятся:

  • информация обо всех взаимодействиях системы ДБО со сторонними системами (АБС, процессинговые центры, ГИС ГМП, ГИС ЖКХ, платёжные системы, такие как Qiwi, Contact и др.);
  • сообщения, отправляемые системой ДБО клиентам через SMS, e-mail, мессенджеры;
  • факты изменения в настройках учетных записей пользователей системы ДБО (например, изменение мобильного телефона клиента, смена пароля или логина, изменение прав доступа);
  • информация обо всех пользовательских сессиях (время начала и завершения, IP-адрес, канал доступа, информация об устройстве и используемом ПО);
  • информация о сработавших системах защиты (блокировка пользователей, неудачные попытки аутентификации);
  • информация о программных ошибках, возникающих в системе (например, в форме stacktrace).

Кроме того модуль системного журнала должен обеспечивать ряд функций по обработке сохранённых данных:

  • быстрый (не больше 2-3 секунд) полнотекстовый поиск записей в системном журнале с применением комбинаций различных фильтров (например, по дате события, типу события, конкретному пользователю системы);
  • экспортирование выбранных записей журнала в различные форматы (например, в таблицы MS Excel);
  • предоставление API для получения статистики о хранимых в системном журнале данных;
  • архивирование и резервное копирование.

Эволюция журнализации: от реляционной БД к поисковым движкам и микросервисам

 
В первых версиях InterBank RS для хранения системного журнала использовалась реляционная база данных. Несмотря на простоту реализации (было всего несколько связанных между собой таблиц), подобное решение имело ряд ограничений:

  • в некоторых СУБД функциональность для полнотекстового поиска весьма ограничена, поэтому эффективно реализовать поиск с применением различных способов фильтрации (например, с указанием шаблонов поиска в виде регулярных выражений) не всегда было возможно;
  • для организации эффективного поиска по различным полям таблиц системного журнала приходилось создавать большое количество индексов, что с учётом высокой нагрузки на запись в эти таблицы (количество добавляемых записей может достигать сотен и тысяч в секунду) приводило к существенному росту нагрузки на СУБД, связанной с необходимость поддерживать индексы в актуальном состоянии;
  • модули полнотекстового поиска не всегда входят в стандартную поставку СУБД, поэтому приходилось покупать дополнительные лицензии (например, Oracle Text);
  • выполнение архивирования и резервного копирования системного журнала требовало привлечения администраторов БД.
В основном перечисленные ограничения связаны с универсальностью используемых СУБД, таких как Oracle и Postgres. Они прекрасно справляются с хранением большинства бизнес-данных. Только события системного журнала имеют одно значительное отличие: они неизменны во времени, подобно логам. Таким образом, для системного журнала не имеет значения производительность команды обновления данных (SQL-команда Update), предоставляемой СУБД. Другая характерная особенность — события генерируются системой постоянно и в большом количестве. В итоге системный журнал занимает на диске значительно больше места, чем все остальные бизнес-данные.

Решение этой проблемы предсказуемо и заключается в использовании для системного журнала отдельной СУБД или даже системы, ориентированной на работу с большими объемами статических данных, а самое главное с быстрым поиском.
На данный момент получили распространение несколько поисковых движков: Sphinx, Solr, Elasticsearch. Поскольку вся экосистема InterBank RS построена на Java, мы в первую очередь рассматривали движки на этом языке. Таким образом, список сузился до продуктов — Solr и Elasticsearch. Оба они близки по производительности и используют библиотеку для высокопроизводительного полнотекстового поиска Lucene, но Elasticsearch обладает рядом преимуществ:

  • для взаимодействия с API Elasticsearch предоставляется Java-библиотека;
  • есть в наличии RESTful API с широким набором сервисов;
  • предусмотрены встроенные средства масштабирования;
  • автоматическое создание бэкапов;
  • легкость установки и настройки;
  • подробная документация Elasticsearch и наличии обширного комьюнити в интернете.
На основании перечисленных критериев было принято решение использовать Elasticsearch для построения нового системного журнала.

Архитектура системного журнала претерпела значительные изменения. Теперь это не реляционная база данных, а целый программный комплекс, состоящий из узлов Elasticsearch, экземпляров микросервиса и брокеров сообщений Active MQ (рис. 1). Все компоненты поддерживают горизонтальное масштабирование и могут быть запущены в нескольких экземплярах для обеспечения отказоустойчивости и увеличения пропускной способности.

Рис1_Принципиальная схема взаимодействия.png

Рис. 1. Принципиальная схема взаимодействия компонентов системного журнала

В процессе работы InterBank RS всегда поддерживает соединение, как минимум, с одним экземпляром брокера сообщений, который используется для взаимодействия между компонентами системы ДБО. Каждое событие InterBank RS снабжает меткой времени и помещает в JMS-очередь системного журнала. К этой очереди одновременно могут быть подключены несколько экземпляров микросервиса системного журнала (их число не ограничено технически). Забирая сообщение, микросервис хранит его в памяти до накопления некоторого количества событий, и после записывает в Elasticsearch. Как показала практика, использование пакетного режима значительно увеличивает скорость записи событий в Elasticsearch.

При формировании страницы с результатами поиска InterBank RS выполняет запрос к микросервису системного журнала, который обращается за данными к кластеру Elasticsearch. Для оптимального распределения запросов поиска, между экземплярами микросервиса функционирует балансировщик HAProxy, работающий в режиме leastconn.

Создание резервных копий и восстановление данных


 Доступ к данным системного журнала крайне неравномерный. Зачастую прикладным администраторам необходимо выполнить поиск за текущий день или неделю, реже — за месяц. Чем старее данные, тем меньше вероятность обращения к ним. Но даже самые давние данные должны быть доступны для поиска. В системном журнале на основе реляционной СУБД для оптимизации размера БД требовалось ограничивать период хранения (например, тремя месяцами). Остальные записи находились в виде резервных копий (бэкапов). Регулярное экспортирование/импортирование части таблиц выполнялось вручную и требовало привлечения системного администратора. Таким образом, сотрудник банка не мог получить из системного журнала старые записи оперативно и без согласований.

В новом системном журнале реализованы удобные механизмы создания резервных копий и импортирования данных из репозитория. В первую очередь реализована схема разделения данных по времени: каждый день создается новый индекс в терминологии Elasticsearch (рис. 2).

Рис2_Организация хранения данных 4x.png Рис. 2. Организация хранения данных

Резервирование превратилось в лёгкую процедуру: по окончании дня автоматически создается резервная копия индекса прошедшего дня и помещается в репозиторий, который является общим для всех узлов Elasticsearch.
Администраторы могут установить продолжительность существования данных в оперативной части системного журнала (остальные данные будут находиться в репозитории).

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

Рис3_Страница-системного-журнала-в-АРМ-Работника.png

Рис. 3. Страница системного журнала в АРМ Работника

Размер данных


По статистике 90% записей в системный журнал приходится на взаимодействие InterBank RS с внешними системами. Обычно содержимым таких записей являются XML-документы. Одной из особенностей формата XML с точки зрения хранения является его избыточность, то есть возможность сжатия.

Давайте сравним размеры системного журнала в Oracle и Elasticsearch (рис. 4). В обоих хранилищах наблюдается линейная зависимость между объемом записываемых событий и размером хранилища, однако системный журнал на основе Elasticsearch показывает в 2,4 раза большую эффективность при использовании типичных данных.

Рис4_Сравнение размера системного журнала в Oracle и Elasticsearch.png

Рис. 4. Сравнение размера системного журнала в Oracle и Elasticsearch

Масштабируемость и отказоустойчивость


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

Отличия нового системного журнала


  • В заключение перечислим топ-5 важных характеристик нового системного журнала, которые выгодно отличают его от предыдущей реализации. Сниженная нагрузка на СУБД, которая теперь занимается обработкой только учетных данных пользователей InterBank RS и данных, относящихся к бизнес-транзакциям.
  • Возросшая скорость поиска информации в системном журнале за счет использования дневных индексов; расширенные возможности по настройке фильтрации (маски, регулярные выражения, нечеткий поиск).
  • Удобный интерфейс для администратора системы ДБО, позволяющий организовать архивирование и восстановление из архива интересующих данных.
  • Возможность горизонтального масштабирования: для увеличения пропускной способности системного журнала достаточно добавить новый экземпляр микросервиса системного журнала и узел в кластер Elasticsearch.
  • Более предсказуемое распределение нагрузки между узлами системы ДБО: очередное сообщение, записываемое в журнал, берёт в обработку тот экземпляр микросервиса, который свободен на текущий момент.
В то же время из-за изменившейся архитектуры системного журнала процесс его первичного развертывания стал быть сложным, появилась необходимость выделять мощности для новых компонентов системы.

Созданное нами решение уже подтвердило свою эффективность на практике. На сегодняшний день оно находится в промышленной эксплуатации у одного из наших клиентов (банка из топ-10), где ежедневно регистрируется более 5 млн событий, а общий размер системного журнала превышает 3ТБ.

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

Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2016 2017