Как мы выбирали поставщика СУБД PostgreSQL и внедряем импортонезависимое решение
Всем привет! Меня зовут Александр Чуркин, и я руковожу Управлением корпоративной инфраструктуры Национального клирингового центра (НКЦ).
НКЦ входит в Группу «Московская Биржа». Напомню, мы выполняем функции клиринговой организации и центрального контрагента на финансовом рынке. То есть, берем на себя риски по заключаемым участниками в ходе биржевых торгов сделкам, выступая посредником между сторонами: продавцом для каждого покупателя и покупателем для каждого продавца.
В середине прошлого года мы объявили о квалификационном отборе поставщиков лицензий коммерческой версии СУБД на основе PostgreSQL, а в конце февраля этого года завершили тестирование и определились с выбором в пользу решения — Digital Q.DataBase от компании «Диасофт».
Теперь расскажем о том, как мы проводили предварительный отбор, тестировали отобранные решения, сделали свой выбор и готовимся к переходу на опенсорсную СУБД. Надеемся, что наш опыт поможет и вам!
Таймлайн
Надо сказать, что информационная система, под которую мы выбирали новую СУБД, имеет достаточно долгую историю развития. Асроки по импортозамещению её основного техстека были и есть достаточно сжатые. Наверное, это общая черта проектов, связанных с импортозамещением: когда значимость миграции перевешивает связанные с ней трудозатраты.
Рис. 1. Таймлайн проекта НКЦ по переходу на СУБД PostgreSQL
Отбор
Итак, мы вначале составили критерии отбора систем баз данных, для проведения конкурса как технического, так и финансового. На Рис. 2 указали основные технические критерии.
Рис. 2. Основные критерии для отбора поставщиков СУБД
Эти критерии были разосланы участникам процедуры отбора, чтобы они провели самооценку соответствия своих продуктов нашим критериям. Фактором отбора решений для тестирования служило 100%-ое соответствие критериям. Из полученных предложений мы отобрали четыре решения для дальнейшего тестирования.
Тестирование и выбор
Тестирование продуктов перебором по их «рангу» шло с середины декабря 2023 года по март 2024, когда подводились финальные итоги. Мы тестировали на идентичных стендах с идентичными требованиями и одними и теми же людьми для повторяемости сценариев.
Мы не выбирали какое-то из решений исключительно по технологическим преимуществам, это была совокупность критериев. Нам были важны и себестоимость владения, и качество поддержки, и скорость решения инцидентов, и соответствие требованиям.
Обеспечение высокого уровня доступности было основным из ключевых технологических требований. Ведь данный продукт планируется к использованию для систем высокой критичности, являющихся нашим основным приоритетом. Ниже приведена типовая схема кластеризации (Рис. 3).
Рис. 3. Типовая схема кластеризации
Также мы выполняли различные варианты проверки отказоустойчивости и целостности данных.
По направлению информационной безопасности мы отрабатывали соответствие ГОСТ № 57580.1–2017 ЦЗИ.8 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер».
Из важных элементов, которые мы достаточно долго тестировали — обеспечение целостности данных. Это требование мы сформулировали как «Функционал надежности работы СУБД должен обеспечивать механизм исправления поврежденных данных WAL из буферов в оперативной памяти» и заложили в ТЗ как один из критериев для отбора.
Давайте посмотрим на этот тест более подробно. Тестирование выполнялось следующим способом:
Настраиваем потоковую репликацию.
Включаем параметр qcheck_crc_wal
Создаем таблицу на первичной реплике и вставляем в нее записи.
Проверяем, что репликация работает.
Отключаем кластер на вторичной реплике.
Делаем вставку записи в таблицу на первичной реплике.
Открываем журнал предзаписи на первичной реплике, находим вставленную строку и вносим в нее изменения.
Запускаем вторичную реплику.
Проверяем, что вставленная запись на первичной реплике, которая была изменена в журнале предзаписи на первичной реплике, была доставлена на вторичную реплику в исходном состоянии.
Переходим в журнал на вторичной реплике, находим записи подтверждающие, что запись в журнале предзаписи на первичной реплике повреждена и была восстановлена из WAL buffers:
По совокупности всех критериев и общим итогам конкурса «Диасофт» был признан победителем, а Московская биржа выбрала компанию в качестве предпочтительного поставщика СУБД.
Миграция
В контексте информационной системы, которая была упомянута в начале статьи, мы проводим отказ от технологий Oracle, одна из которых — Database. Поэтому есть два параллельных этапа: доработка прикладного ПО и адаптация базы данных. Они напрямую зависят друг от друга и являются неразрывной частью процесса импортозамещения.
Наш подход по переходу от проприетарных СУБД на импортонезависимые заключается в том, что мы не пытаемся реализовать весь технологический функционал замещаемого продукта. Для обеспечения стабильной работы была проведена адаптация системы: изменена структура данных, сокращены объемы БД с 40 Тб до 10 Тб, налажены процедуры урезания данных. Нашей целью было обеспечение необходимого уровня отказоустойчивости и быстродействия системы.
Общим подходом при замене таких продуктов как Oracle являются процессы, обеспечивающие сокращение объемов данных, которые сохраняются в оперативном доступе, либо деление БД на менее объемные сущности. Такой подход позволяет сохранить необходимую производительность в работе СУБД на основе PostgreSQL.
В НКЦ мы придерживаемся стратегии параллельной эксплуатации и отладки функциональности внедряемой системы относительно боевой. При этом есть определенный период параллельного функционального тестирования.
У нас достаточно сложная и закрытая система. Кроме того, мы вносили изменения в структуру данных. Поэтому команда разработки подготовила собственный «мигратор», позволяющий выполнять процедуры миграции и доливки данных с периодами различной длительности, несмотря на то, что у «Диасофт» есть аналогичные решения. В рамках обеспечения процесса миграции работу выполняют до трех человек со стороны инфраструктуры, плюс команды разработки и эксплуатации.
Мы из выбранного решения используем компоненты, отвечающие за парольные политики, и саму СУБД. То есть, решение в основном используем как OLTP-базу (систему обработки транзакций в реальном времени), а не для расчетов. Все расчеты выполняются в прикладном ПО.
Рекомендуем именно так и подходить. Потому что есть практики, когда на СУБД перекладывают вычислительные функции, используя довольно сложные хранимые компилируемые процедуры. Вот это и станет основной проблемой для тех, кто мигрирует. Так как хранимые процедуры Oracle Database и PostgreSQL используют разные базовые библиотеки, их придется фактически заново писать.
Выводы
Учитывая масштабы, сложность и критичность импортозамещаемой системы, наш подход к отбору и внедрению решений оказался довольно гибким и эффективным.
Выбирая импортонезависимую СУБД мы прогнозировали, что не бывает идеальных продуктов. Поэтому мы старались нивелировать возможные сложности в производительности таких систем улучшением качества решений путем рефакторинга структуры данных при хранении и обработке.
Нам еще много предстоит сделать, в том числе провести нагрузочные испытания внедряемой системы. Сейчас мы готовимся к тому, чтобы оперативно решать возможные проблемы на этапе выхода в промышленную эксплуатацию
