Импортозамещение СУБД в Федеральном казначействе: переход ГИС ГМП на Postgres Pro Shardman

Заказчик

Федеральное казначейство отвечает за обеспечение исполнения бюджетов, организацию государственных и муниципальных платежей, ведение части государственных учетных и платежных систем. Одним из ключевых инструментов является Государственная информационная система государственных и муниципальных платежей (ГИС ГМП).

Задачи заказчика

ГИС ГМП предназначена для централизованного размещения и получения информации, необходимой для уплаты государственных и муниципальных услуг, пошлин, штрафов и налогов. Система обеспечивает взаимодействие «администраторов начислений» (ведомств, формирующих счета) и финансовых организаций (банков, через которые граждане и юрлица производят оплату).

Показатели назначения ГИС ГМП:
● Более 48000 зарегистрированных участников;
● 4,8 млрд уведомлений о событиях с начислениями и платежами;
● 1 млн начислений ежедневно на 20 млрд рублей;
● Порядка 5000 обрабатываемых транзакций в секунду.

История проекта

Ядром ГИС ГМП до недавнего времени являлась СУБД Oracle. Общий объем базы данных достигал 240 ТБ, из которых 180 ТБ приходилось на пользовательские данные и около 60 ТБ — на индексы.

Ключевая задача проекта заключалась в переводе ГИС ГМП на российский технологический стек в рамках программы импортозамещения. При этом требовалось обеспечить работу системы федерального значения без простоев и потери данных.

Выбор решения, процесс миграции и оптимизации производительности

Федеральное казначейство предъявляло жесткие требования к новой СУБД: поддержка критически больших объемов данных (200+ ТБ), горизонтальное масштабирование, отказоустойчивость, соответствие регуляторным требованиям и перспектива роста до петабайтного уровня.

Выбор был сделан в пользу Postgres Pro Shardman — распределенной отечественной СУБД, способной обрабатывать данные объемом до 2 ПБ. Адаптацию прикладного ПО и интеграционной платформы SmartVista Integration Platform выполняла компания «БПС Инновационные программные решения». Адаптация включала в том числе и перенос имеющейся в Oracle части бизнес-логики из СУБД на уровень прикладного ПО. Миграцию баз данных осуществляла компания PTЛабс.

Процесс миграции включал несколько этапов:

1. Копирование накопленных данных и параллельный перенос изменений.

2. Параллельная работа систем на Oracle и Shardman: «параллельный импорт» входящих данных и поэтапное переключение запросов на обновленную версию с контролем производительности и корректности возвращаемых данных.

3. Фактический переход на новую СУБД при сохранении возможности возврата на старую версию в случае выявления проблем на завершающих этапах.

4. Вывод Oracle из эксплуатации.

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

Сложности и особенности реализации

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

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

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

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

Также потребовалась доработка прикладного ПО: переписывание сложных SQL-запросов, а в некоторых случаях — разделение сложных операций на несколько последовательных шагов для учета специфики распределенной среды.

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

Результаты

В результате проекта основной и резервный кластеры Oracle RAC (Real Application Cluster), всего четыре сервера, каждый содержал по 192 двухпоточных ядра и 3 Тб оперативной памяти, были полностью заменены на кластер Postgres Pro Shardman, включающий 40 серверов (19 мастеров, 19 реплик и 2 резервных узла). Общий объем базы данных удалось сократить на 50 ТБ за счет оптимизации структуры и пересмотра накопленных данных. Производительность системы выросла, количество отказов существенно уменьшилось.

Одновременно были обновлены версии прикладного ПО и операционных систем в соответствии с требованиями ФСТЭК. Также обеспечена высокая отказоустойчивость и возможность горизонтального масштабирования до уровней, необходимых для работы государственных систем.

Проект, несмотря на свою исключительную сложность, является успешным: обновленная система ГИС ГМП демонстрирует лучшую производительность и отказоустойчивость по сравнению с решением на СУБД Oracle. При этом переход на новую систему прошел без остановки ГИС ГМП, что само по себе на рекордных объемах данных в сотни терабайт является действительно большим достижением, — отмечает Михаил Терехов, архитектор решений компании Postgres Professional.