Как обеспечить высокую производительность системы ДБО, разделив монолит на блоки

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

Привет, меня зовут Максим Приходский, я являюсь ИТ-архитектором систем дистанционного банковского обслуживания (ДБО) в компании R-Style Softlab, входящей в группу Россельхозбанка. Миллионы клиентов банков ежедневно используют наше решение для дистанционного доступа к банковским услугам. Масштабирование с высокой доступностью и быстротой отклика — вот та база, на основе которой строятся системы ДБО. В своей статье я хочу поделиться опытом, как мы усовершенствовали платформу InterBank RS, реализовав в ней возможность горизонтального масштабирования СУБД путем шардирования клиентских данных. Для простоты понимания мы назвали этот способ «многоблочностью».

Суть проблемы

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

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

· Каким образом клиенты будут понимать, на каком блоке им нужно работать?

· Как микросервисы и внешние информационные системы будут понимать, на какой блок отправлять свои вызовы?

· Как операционисты и администраторы системы будут работать с данными клиентов в нескольких блоках?

· Как данные клиента будут перемещаться между блоками?

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

Таким решением стала Централизованная Система Аутентификации (ЦСА) — специальный сервис, задача которого заключается в том, чтобы знать, на каком блоке живут данные того или иного клиента, и отвечать на поставленные выше вопросы. Логически она была разделена на три модуля, которые запускаются как отдельные приложения: модуль аутентификации, модуль маршрутизации и модуль администрирования. Все они опираются на одно и то же хранилище данных, в качестве которого по результатам прототипирования была выбрана NoSQL БД Cassandra. А храним мы, главным образом, соответствие клиентов блокам системы и актуальный набор атрибутов, по которым клиента можно опознать.

Прозрачность многоблочности обеспечивается за счёт того, что ЦСА предоставляет единые точки как для клиентов — в виде страницы аутентификации для всех блоков, так и для других систем — в виде точек интеграции, которые предоставляет модуль маршрутизации, сам решающий, в какой блок ДБО направить запрос.

Как не поскользнуться на камнях

Далее коротко охарактеризуем проблемы и подводные камни, с которыми пришлось столкнуться разработчикам ЦСА и на которые следует обращать внимание при проектировании подобных решений.

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

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

3. Единые справочники и данные администрирования. Хотя клиентские данные различаются от блока к блоку, профили сотрудников, большинство настроек и, главным образом, справочники должны иметь механизмы синхронизации. Более того, работа сотрудников должна быть максимально удобной в контексте нескольких блоков. Но стоит иметь в виду, что некоторых «швов» избежать не получится: администраторы должны будут понимать, что клиенты расположены в нескольких обособленных хранилищах данных. Быстрое переключение между интерфейсами администрирования разных блоков уже существенно улучшает удобство работы. Логичный следующий шаг — репликация или синхронизация между собой справочников разных блоков для случаев, когда это необходимо. Иначе сотрудники вынуждены будут многократно выполнять работу по поддержанию их актуальности.

4. Многоблочная отчётность. Ранее отчёты о работе системы ДБО ФЛ формировались на основе копии базы данных промышленного контура. Однако с введением нескольких блоков появляется необходимость агрегации данных из произвольного количества однородных источников. Для этих целей отлично подошёл разработанный ранее микросервис сбора статистики, который выгружает необходимые отчётные данные из БД монолита и укладывает их в хранилище Elasticsearch. Доработка этого сервиса для сбора данных из нескольких источников позволит видеть статистику в разрезе всей многоблочной системы.

5. Парадокс разработчика. При реализации архитектурно-сложного решения всегда стоит помнить, что его придётся поддерживать, и бремя работы с ним ляжет на плечи всех разработчиков системы. Многоблочность привносит не только новые сущности в архитектуру, но и меняет логику работы с существующими. Отныне разработчики должны держать в голове, что данные клиентов могут быть расположены в разных блоках, и когда мы пишем вызов к монолитному приложению системы, мы должны задаваться вопросом: к какому блоку должно идти обращение. В наше многоблочное решение закладывались принципы удобства и гибкости разработки: то, что может выполняться автоматически, не требуя дополнительных действий от программиста, будет выполняться автоматически, при этом возможность в случае необходимости вмешаться в многоблочную логику сохраняется. Кроме того, при помощи набора параметров запуска система ДБО ФЛ может по-прежнему работать в одноблочном режиме, если запуск многоблочности на локальном стенде разработчика невозможен или нецелесообразен.

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

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