Привет, Хабр! Меня зовут Андрей, я директор департамента внутренних систем ЮMoney. Эту статью я подготовил в соавторстве с Владиславом, руководителем группы разработки и сопровождения автоматизированной банковской системы (АБС) в ЮMoney. Недавно мы завершили один из главных этапов импортозамещения ИТ-инфраструктуры: вместе с АО «ПрограмБанк» полностью перевели нашу АБС «ПрограмБанк.АБС» на ОС Linux и СУБД PostgreSQL.
За время проекта мы:
переписали с Transact-SQL на PL/pgSQL и протестировали более 32 000 строк SQL-кода;
перенесли базу объёмом более 5 ТБ;
выполнили конвертацию данных в 64 потока.
В статье расскажу о технической стороне миграции: как мы строили новую инфраструктуру и переносили данные, почему автоматической конвертации кода не хватило и как мы справлялись с падением производительности. Статья может быть полезна архитекторам, разработчикам и техническим руководителям, которым предстоит перенести нагруженную систему на другой технологический стек.
Зачем мы затеяли миграцию и как строили новую инфраструктуру
Помимо требований регулятора, у нас были и свои причины:
Снизили зависимость от иностранных вендоров. После ухода зарубежных компаний из России многие банки столкнулись с прекращением технической поддержки и обновлений. Импортозамещение позволяет избежать ситуаций, когда доступ к обновлениям или решению критических проблем блокируется.
Повысили безопасность. Открытый стек снижает зависимость от проприетарного зарубежного ПО и даёт больше контроля над инфраструктурой.
Обеспечили долгосрочную устойчивость и развитие. Такой подход делает затраты на поддержку предсказуемыми (используется бесплатно распространяемое программное обеспечение с открытым исходным кодом) и позволяет адаптировать решения под специфические задачи банка, не завися от внешних факторов.
Но сначала новому стеку нужна была своя инфраструктура, и её подготовка стала первым этапом проекта. Действующая АБС работала на Windows, а новая должна была работать на Linux, поэтому мы развернули параллельную инфраструктуру, включая тестовые стенды. Для этого понадобилось дополнительное оборудование, и его закупка превратилась в отдельную часть проекта: команда собирала и анализировала системные требования и следила за подготовкой инфраструктуры.
В новый стек вошли:
АБС на Linux вместо действующей версии на Windows;
PostgreSQL на Linux вместо MS SQL Server на Windows;
тестовые стенды для нового стека;
вспомогательное ПО, без которого инфраструктура не работает.
Смена основного стека потянула за собой и вспомогательные компоненты: резервное копирование, логирование, балансировку, архивирование, криптографию и другие элементы тоже пришлось адаптировать под новую среду. Настройкой серверов и программного обеспечения со стороны ЮMoney занимался департамент эксплуатации.
Так инфраструктура для новой АБС создавалась параллельно с действующей. На ней строились все следующие этапы: миграция данных, адаптация бизнес-логики и тестирование нового стека.
Как мы переносили данные
Следующим крупным этапом стал перенос данных из MS SQL в PostgreSQL. Исходная база занимала больше 5 ТБ, но переносить её целиком не понадобилось. Мы выполнили частичную конвертацию и взяли только данные за последние пять лет, так что после миграции база весила чуть больше 1 ТБ. Это сократило объём переносимых данных и время простоя при финальной миграции.
Конвертировали утилитой вендора в 64 параллельных потока. Стоит добавить, что вендор дорабатывал утилиту под наши требования, в том числе под многопоточность. Но время ушло не только на сам перенос: минимум треть всей миграции заняло построение индексов. Ещё нужно было убедиться, что данные перенесены полностью и без искажений. Проверить всё целиком невозможно, поэтому ключевые показатели сверяли с помощью специальных механизмов.
В итоге миграция данных у нас не свелась к простой конвертации базы из одной СУБД в другую. Нужно было определить объём переноса, выполнить конвертацию, построить индексы и отдельно проверить результат.
Почему автоматической конвертации кода оказалось недостаточно
При переходе с MS SQL на PostgreSQL бизнес-логику пришлось перенести с Transact-SQL на PL/pgSQL. Работы оказалось много: мы переписали и протестировали более 32 000 строк кода. Это запросы, хранимые процедуры и функции, которые используются в более чем 200 бизнес-процессах.
Мы пробовали инструменты автоматической конвертации, в том числе на базе ИИ, но их качества не хватило, чтобы сделать всё автоматически. Большая часть задач требовала участия и контроля человека.
Отдельной сложностью стала производительность. Иногда даже корректно работающую логику приходилось переписывать, потому что из-за особенностей PostgreSQL она выполнялась слишком медленно. Поэтому много времени ушло на анализ, адаптацию и тестирование кода, причём проверяли его не абстрактно, а на наших собственных бизнес-процессах.
Как мы решали проблемы производительности
После перехода на PostgreSQL часть операций, которые на MS SQL выполнялись быстро, заметно замедлилась. Например, массовая обработка платежей стала занимать в 2–5 раз больше времени. Модуль подписи и вовсе начал работать в 10 раз медленнее, однако это одна из немногих проблем, вызванных не сменой СУБД, а переходом с Windows на Linux. Её решал вендор, поскольку она находилась в его зоне ответственности.
Оптимизировать всё сразу мы не стали: ранжировали бизнес-процедуры по частоте использования и объёму данных. Начали с тех, что работают с миллионами платежей, и адаптировали каждую из них.
Местами код переписывали вручную: на многих участках автоматические конвертеры были бессильны. Иногда мы привлекали коллег из других команд, а именно системных администраторов с большой экспертизой в работе с PostgreSQL, и по их рекомендациям донастраивали оборудование. В итоге по ключевым процедурам мы вышли на целевые показатели, а кое-где производительность даже выросла.
Моделирование: две системы на одном потоке
Миграцию мы построили на дублировании бизнес-логики. Развернули отдельный вычислительный контур, в котором новая система обрабатывала те же транзакции, что и действующая. Обе системы работали параллельно на одном потоке входных данных.
Моделирование решало три задачи:
сверка бизнес-показателей: совпадают ли финансовые результаты;
сверка технических показателей: укладывается ли время обработки в допустимые пределы;
отработка действий команды, чтобы в день переключения каждый точно знал, что делать.
Новая система работала автономно минимум неделю. За это время мы сравнивали метрики с текущей АБС, измеряли производительность и оценивали общую готовность. На каждой итерации мы фиксировали расхождения, устраняли их и запускали цикл заново. Моделирование повторяли несколько раз, пока не убедились, что несколько тысяч процессов работают корректно.
Так мы заранее проверили не только новую систему, но и саму процедуру перехода. К финальной миграции все шаги должны были быть отработаны, а их выполнение — укладываться в несколько часов. На случай проблем мы подготовили пошаговый план отката.
Кульминация проекта и как мы уложились в несколько часов
Время на финальную миграцию было жёстко ограничено. Остановить АБС на сутки мы не могли: у платежей строгие сроки обработки, поэтому переключение должно было уложиться в считанные часы. В этом нам помогло то, что новая система уже работала параллельно с действующей, а все основные сценарии мы отработали на новом контуре во время моделирования.
Принимать решения о переходе к следующему шагу нам помогали простые, но информативные отчёты по критическим точкам. На случай проблем был пошаговый план отката: до определённого этапа можно было вернуться к рабочей схеме. После точки невозврата откат становился невозможен.
Поэтому в процессе катовера мы не тратили время на проверку системы с нуля. Достаточно было пройти по составленному плану и проконтролировать результат каждого на каждом из шагов, что помогло сэкономить драгоценное время.
Итог
Переход оказался таким же масштабным, каким выглядел с самого начала. И теперь у нас есть:
стек без зависимости от закрытых лицензий зарубежных вендоров,
больше контроля над инфраструктурой и безопасностью
и возможность дорабатывать решения под свои задачи.
А главное, мы убедились: даже нагруженную банковскую систему можно перенести на другой стек без длительной остановки, если подготовиться и отрепетировать каждый шаг.
Что мы можем порекомендовать, если вы только планируете такой переход
Закладывайте параллельную инфраструктуру и время на закупку оборудования.
Не переносите абсолютно всё без необходимости. Определите, какой объём данных реально нужен в новой системе.
Особое внимание уделите моделированию: чем больше благодаря нему будет проверено, тем спокойнее пройдёт момент переключения.
Заранее продумайте план отката, определите точки невозврата и метрики по которым вы будете принимать решение о продолжении раскатки.
Но техническая часть только одна сторона такой миграции. Как организовать моделирование и параллельную работу двух систем, подготовить команду, спланировать финальное переключение и продумать действия на случай проблем, расскажем во второй статье. Там посмотрим на проект с точки зрения организации и подготовки к переходу.
Если остались вопросы, задавайте их в комментариях, мы с командой обязательно ответим.
