Всем привет! Меня зовут Александр Чуркин, и я руковожу Управлением корпоративной инфраструктуры Национального клирингового центра (НКЦ).

НКЦ входит в Группу «Московская Биржа». Напомню, мы выполняем функции клиринговой организации и центрального контрагента на финансовом рынке. То есть, берем на себя риски по заключаемым участниками в ходе биржевых торгов сделкам, выступая посредником между сторонами: продавцом для каждого покупателя и покупателем для каждого продавца.

В середине прошлого года мы объявили о квалификационном отборе поставщиков лицензий коммерческой версии СУБД на основе PostgreSQL, а в конце февраля этого года завершили тестирование и определились с выбором в пользу решения – Digital Q.DataBase от компании «Диасофт».

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

Таймлайн

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

Отбор

Итак, мы вначале составили критерии отбора систем баз данных, для проведения конкурса как технического, так и финансового. На Рис.2 указали основные технические критерии.

Эти критерии были разосланы участникам процедуры отбора, чтобы они провели самооценку соответствия своих продуктов нашим критериям. Фактором отбора решений для тестирования служило 100%-ое соответствие критериям. Из полученных предложений мы отобрали четыре решения для дальнейшего тестирования.

Тестирование и выбор

Тестирование продуктов перебором по их «рангу» шло с середины декабря 2023 года по март 2024, когда подводились финальные итоги. Мы тестировали на идентичных стендах с идентичными требованиями и одними и теми же людьми для повторяемости сценариев.

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

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

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

По направлению информационной безопасности мы отрабатывали соответствие ГОСТ № 57580.1-2017 ЦЗИ.8 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер».

Из важных элементов, которые мы достаточно долго тестировали – обеспечение целостности данных. Это требование мы сформулировали как «Функционал надежности работы СУБД должен обеспечивать механизм исправления поврежденных данных WAL из буферов в оперативной памяти» и заложили в ТЗ как один из критериев для отбора.

Давайте посмотрим на этот тест более подробно. Тестирование выполнялось следующим способом:

1. Настраиваем потоковую репликацию.

2. Включаем параметр qcheck_crc_wal

3. Создаем таблицу на первичной реплике и вставляем в нее записи.

4. Проверяем, что репликация работает.

5. Отключаем кластер на вторичной реплике.

6. Делаем вставку записи в таблицу на первичной реплике.

7. Открываем журнал предзаписи на первичной реплике, находим вставленную строку и вносим в нее изменения.

8. Запускаем вторичную реплику.

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

10. Переходим в журнал на вторичной реплике, находим записи подтверждающие, что запись в журнале предзаписи на первичной реплике повреждена и была восстановлена из WAL buffers:

По совокупности всех критериев и общим итогам конкурса «Диасофт» был признан победителем, а Московская биржа выбрала компанию в качестве предпочтительного поставщика СУБД.

Миграция

В контексте информационной системы, которая была упомянута в начале статьи, мы проводим отказ от технологий Oracle, одна из которых – Database. Поэтому есть два параллельных этапа: доработка прикладного ПО и адаптация базы данных. Они напрямую зависят друг от друга и являются неразрывной частью процесса импортозамещения.

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

Общим подходом при замене таких продуктов как Oracle являются процессы, обеспечивающие сокращение объемов данных, которые сохраняются в оперативном доступе, либо деление БД на менее объемные сущности. Такой подход позволяет сохранить необходимую производительность в работе СУБД на основе PostgreSQL.

В НКЦ мы придерживаемся стратегии параллельной эксплуатации и отладки функциональности внедряемой системы относительно боевой. При этом есть определенный период параллельного функционального тестирования.

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

Мы из выбранного решения используем компоненты, отвечающие за парольные политики, и саму СУБД. То есть, решение в основном используем как OLTP-базу (систему обработки транзакций в реальном времени), а не для расчетов. Все расчеты выполняются в прикладном ПО.

Рекомендуем именно так и подходить. Потому что есть практики, когда на СУБД перекладывают вычислительные функции, используя довольно сложные хранимые компилируемые процедуры. Вот это и станет основной проблемой для тех, кто мигрирует. Так как хранимые процедуры Oracle Database и PostgreSQL используют разные базовые библиотеки, их придется фактически заново писать.

Выводы

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

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

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