Привет, Хабр! Меня зовут Валерий Пташкин, я руководитель направления в трайбе «Потребительское Кредитование» в Сбере. Статью я подготовил вместе с моими коллегами — Кириллом Макаровым и Евгением Беляевым.

Наш продукт отвечает за хранение клиентских заявок на потребительские кредиты, заявок кредитного потенциала, автокредитов, ипотечного кредитования и так далее. И в этом году мы перевели работу нашего модуля хранения с Oracle на СУБД Pangolin (сборка PostgreSQL с доработками от СберТеха).

При переезде у нас было несколько критичных требований к СУБД: способность держать достаточно высокую нагрузку (4 тысячи запросов в секунду), при этом иметь время отклика не более 100 мс для 99 % запросов, и обеспечивать максимально высокую доступность нашего сервиса как системы уровня mission critical.

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

Почему СУБД Pangolin?

Несколько лет назад Сбер утвердил стратегию развития. Одним из её векторов стала технологическая независимость и постепенный отказ от иностранного ПО. В 2019 году началась разработка СУБД, которая впоследствии получила название Platform V Pangolin DB, или СУБД Pangolin. Она основана на открытом коде PostgreSQL и включает в себя доработки ядра в части безопасности, производительности, отказоустойчивости и упрощения администрирования. Уже несколько лет команды Сбера переводят свою инфраструктуру на Pangolin. К слову, решение доступно и используется и в других крупных компаниях. Запросить и попробовать своими руками тестовый дистрибутив можно здесь.

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

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

При переезде на СУБД Pangolin не хотелось потерять в надёжности и нагрузке, и мы ожидали что:

• сможем, как и прежде, держать нагрузку до 4000 TPS с учётом среднего размера заявки порядка 100 Кб;

• обеспечим время отклика не более 100 мс для 99,9 % запросов;

• перенесём данные в размере около 30 ТБ в новую БД без потерь;

• проведём максимально бесшовный для наших потребителей переход (уточню, что переключать можно с недоступностью и без неё. Вариант без недоступности подразумевает достаточно большую доработку приложения, чтобы оно «научилось» работать сразу с двумя комплектами баз – с Oracle и с PostgreSQL одновременно. Мы выбрали вариант с небольшой недоступностью, потому что посчитали сложную доработку нецелесообразной);

• и минимизируем недоступность при миграции с одной СУБД на другую.

Скрывать не буду, в профессиональном сообществе встречается мнение, что оригинальный PostgreSQL не рассчитан на серьёзные нагрузки. Поэтому в команде царил некий скептицизм относительно кастомной сборки СУБД Pangolin. Но, забегая вперёд, нас в итоге порадовало то, что в производительности мы не потеряли.

Про конфигурацию

Изначально наша инфраструктура создавалась с прицелом на то, чтобы мы как можно меньше зависели от конкретной реализации СУБД и могли переехать на другую. У нас было два Active Data Guard (ADG)-кластера Oraclе (LEFT\RIGHT CLUSTER) с плечами (Master-Slave) в разных центрах обработки данных, плюс ADG Observer. CRUD-сервисы работали в режиме Active–Active, то есть данные, которые приходили в них, попадали сразу в оба кластера. Оба кластера могли работать параллельно, а согласованность данных при коммите сразу в оба кластера мы контролировали самостоятельно. 

При необходимости выполнения работ один из кластеров мог штатно выводиться из балансировки без недоступности системы. После ввода кластера в балансировку наша собственная реализация программной репликации докатывала заявки во вновь введённый кластер (от Oracle Golden Gate по различным причинам мы отказались).

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

Дальше расскажем про наши этапы миграции.

Подготовка

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

Мы не смогли тогда найти подходящих нам решений для переливаний горячего потока данных из Oracle в Pangolin и разработали собственный сервис — migrator. Но сейчас в Сбере уже доступен инструмент для миграции и репликации данных Platform V GraDeLy, совместимый с СУБД Pangolin.

Можно было бы написать ещё одну небольшую статью о том, как мы искали утилиту для холодного копирования. Скажу только, что мы изучали и самописные утилиты, разработанные в банке, и open source-проекты. В первую очередь нам важна была надёжность и скорость переноса: данные, используемые в Oracle-хранилище, могли сильно устареть за время их переноса, и догонять потом разницу после переключения на СУБД Pangolin пришлось бы слишком долго. В итоге мы остановились на ora2pg.darold.net.
На Хабре уже не раз писали об этом замечательном инструменте. 

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

В итоге мы разработали и подготовили отдельную инсталляцию для работы с СУБД Pangolin и новым сервисом горячей миграции.

Затем нам требовалось провести нагрузочное тестирование этой инсталляции. Pangolin «из коробки» неплохо настроен на то, чтобы переваривать серьёзную нагрузку, но, как говорится, «7 раз нагрузочное тестирование, один раз — переезд…». Не припомню, чтобы на этом этапе нас что-то серьёзно блокировало. Схема БД у нас простая, поэтому ехало всё «в лоб»: где-то подкрутили пулы соединений, немного подшаманили pg_xact, смотрели, как работает наш сервер миграции.

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

Первый этап: холодное копирование

Для холодного копирования мы воспользовались утилитой ora2pg.darold.net. Её главным достоинством для нас стало то, что она поддерживает параллельное копирование (это ускорило процесс в 3–4 раза). Можно дозировать нагрузку (например, сначала схема, затем данные) и гибко настраивать под разные условия.

Настройка выполняется установкой необходимых параметров в конфигурационном файле ora2pg.conf. Мы разгоняли Ora2Pg несколько дней, подбирая нужные параметры на нагрузочном стенде. Указывать их нет большого смысла, так как всё сильно зависит от железа и количества данных. В целом, стоит обращать внимание на следующее:

#Количество потоков, в которые вы будете записывать данные в БД-приёмник
JOBS ХХ;

#Количество потоков, с которым будем читать данные из БД-источника (работает только в связке с параметром DEFINED_PK)
ORACLE_COPIES  ХХ;

#и уровень параллелизма
DEFAULT_PARALLELISM_DEGREE ХХ.

Учитывайте, что это долгая операция, её необходимо запускать по-особому, чтобы ничего не прерывало работу скрипта. С учётом наших объёмов с самыми крупными нашими потребителями мы укладывались в сутки со скоростью переливки 5-10 тысяч операций в секунду. 

Итого: подбираем настройки Ora2Pg на нагрузочном стенде и приступаем к холодному копированию.

Во время старта работ наше хранилище работает с обоими плечами кластера ADG. Выводим левое плечо из-под нагрузки и переливаем из него данные на левое плечо СУБД Pangolin. Аналогично поступаем с правым плечом. После того как данные «слиты», восстанавливаем работу плеч Oracle. 

Копирование таких объёмов данных занимает много времени. Мы закладывали на каждого из потребителей до двух суток, в зависимости от объёма.

После копирования важно сравнить количество заявок :).

Второй этап: меняем базы местами

Для начала восстанавливаем штатную работу Oracle, чтобы выровнять заявки в левом и правом плече. Ведь пока велись работы, левую базу вывели из-под нагрузки и она стала отставать от правой. Ждём, пока данные выровняются.

Доливаем текущие данные из Oracle в СУБД Pangolin. Пока мы копировали данные, здесь наши базы разъехались. На помощь приходит ранее упомянутый migrator, который отвечает за согласованность данных между базами Oracle и Pangolin. Включаем «горячий» поток миграции, чтобы выровнять данные.

Далее переключаемся на режим работы с одним кластером Oracle (из двух) и одним кластером СУБД Pangolin. Поднимаем наши сервисы репликации, чтобы реплицировать левую базу Pangolin в правую. Тушим сервисы хранилища. Перенастраиваем их на Pangolin и поднимаем. Здесь нам был важен порядок, но не будем углубляться в него. Важно заметить, что не обошлось без кратковременной недоступности, примерно в течение поднятия подов (8 минут). 

На последнем этапе миграции включаем обратный поток данных в нашем сервисе миграции. Теперь данные мигрируют из СУБД Pangolin в Oracle. Сервис умеет работать в обе стороны! Это могло бы понадобиться нам для отката в случае аварии. Хорошо, что не понадобилось :). У вас тоже должен быть такой сервис.

Послесловие

В целом у нас всё прошло довольно гладко. Хотя нет :). Почти всё.

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

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

Но главной трудностью было добиться, чтобы недоступность сервисов длилась не дольше 10 минут (хотя в план заложили побольше). Получилось — все работы вели ночью, и обычно период недоступности не превышал 5-8 минут. Так, благодаря проектированию инфраструктуры и разработанным заранее сервисам мы поменяли одну базу на другую буквально на ходу. 

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

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

P.S. Отдельная благодарность Кадеркаеву Дамиру, Сергею Сельдемирову и нашему СТО Руслану Ширванову за смелые идеи, архитектуру решения и поддержку :).