Почта Банк мигрировал 200 млн файлов с Minio на российское S3-хранилище в рабочем режиме
Почта Банк завершил внедрение отечественного объектного хранилища «Закрома», которое заменило зарубежную систему Hitachi Content Platform и open-source решение Minio S3. Российская платформа предоставила гарантированную консистентность данных, совместимость с Kubernetes и плавный перенос информации без прерывания работы сервисов. В этой статье рассказывается о выборе S3-платформы и архитектурных задачах, с которыми столкнулся банк.
От Hitachi и Minio к отечественному S3-решению
В 2022 году Почта Банк начал пересматривать архитектуру систем хранения информации. В инфраструктуре использовалась платформа Hitachi Content Platform (HCP) и несколько файловых хранилищ для документов и данных сервисов. Однако изменения внешних условий, возрастание технологических рисков и одновременный переход ИТ-ландшафта на микросервисную архитектуру потребовали новых решений.
Hitachi HCP было решено оставить для контуров разработки менее критичных систем — платформа уже была развернута и продолжала функционировать. Для производственных систем требовалось новое целевое хранилище, способное работать в контейнерной среде, масштабироваться под реальные нагрузки и, что особенно важно, соответствовать политике импортозамещения. Объёмы документов и файловых данных постоянно увеличивались, а требования к доступности и сохранности информации в банковских сервисах оставались высочайшими. Также в банке возникла необходимость замены Minio S3 из-за существенных ограничений community-версии (как правило, это бесплатный вариант, поддерживаемый силами открытого сообщества).
При переходе на Kubernetes традиционные файловые хранилища превратились в архитектурное препятствие. В контейнерной инфраструктуре они нуждаются в сложных процедурах подключения, обладают ограниченной масштабируемостью и нередко приводят к сбоям. Распределённые файловые системы либо не обеспечивали нужной устойчивости к отказам, либо были чрезмерно сложны в управлении. Кроме того, большинство из них были зарубежными продуктами, что не соответствовало целям импортозамещения.
В такой ситуации логичным фокусом стало объектное хранилище с S3 API — и организация начала подбор отечественного S3-совместимого решения.
Подход на основе S3 естественно лег в основу микросервисной архитектуры: стандартный HTTP-интерфейс, независимость от конкретных носителей данных, возможность масштабирования по мере роста. Однако для банковских задач ключевым оказался не просто факт совместимости с S3, а гарантированная строгая консистентность. Документы, создаваемые во внутренних банковских системах и передаваемые клиентам через мобильные и онлайн-каналы, должны быть доступны сразу после сохранения и всегда в последней версии. Сценарии с отложенной синхронизацией и eventual consistency (согласованностью в конечном счёте) для банка были непригодны.
Критерии выбора: пилотное тестирование, консистентность и открытость к сотрудничеству
Именно на этом этапе проявились различия между решениями. В одном из тестируемых хранилищ, несмотря на заявленную высокую производительность, обнаружились проблемы с согласованностью данных: файл мог быть записан на один узел, но при чтении с другого оказывался недоступным до завершения процесса синхронизации. Для банковских процессов, где одна служба формирует документ, а другая должна мгновенно предоставить его клиенту, такая ситуация была недопустимой. В S3-хранилище ЗАКРОМА.Хранение подобные случаи были исключены на уровне архитектуры: запрос автоматически перенаправлялся к узлу с актуальной версией объекта, обеспечивая немедленный доступ к данным после записи.
Важным аспектом выбора стала задача переноса данных. Первоначально в банке предполагали, что миграцию между разными типами хранилищ придётся реализовывать собственными силами. Это потребовало бы отдельного проекта, создания собственных инструментов, длительных испытаний и увеличило бы сроки внедрения. В «Закрома.Хранение» механизм переноса данных из другого S3 или файлового хранилища уже был реализован как встроенная функция. Для Почта Банка это стало существенным плюсом: команда смогла сконцентрироваться на проектировании архитектуры и разработке прикладных сервисов.
Существенное значение имела и модель развертывания: «Закрома» дают возможность запустить хранилище на собственной инфраструктуре банка, встроив управляющие модули в контур Kubernetes. Это позволило эластично масштабироваться в соответствии с реальными запросами и избежать резервирования лишних мощностей «про запас». Банк смог увеличивать производительность в часы пиковой активности и освобождать ресурсы после её спада, оптимально распределяя нагрузку на оборудование между разными корпоративными приложениями.
Бесперебойная миграция: как перенесли 200 миллионов файлов
Перенос данных был выстроен поэтапно и выполнялся в фоновом режиме. Основную трудность создавало огромное количество мелких файлов и глубокая иерархия каталогов. Изначально сетевое хранилище подключалось к S3 «Закрома.Хранение» по протоколу CIFS, что влекло за собой сетевые накладные расходы, присущие этому протоколу. В процессе пробного переноса архитектуру доработали: агенты переместили ближе к источникам данных, а процедуру сканирования разделили на 10 параллельных потоков. Эти корректировки не затронули бизнес-системы банка и помогли ускорить миграцию без прерывания работы сервисов. Тем не менее, файловая система сетевого хранилища отдавала данные с низкой скоростью, и полное копирование примерно 200 млн файлов заняло около полутора месяцев.
Краеугольным камнем плавного перехода стал режим проксирования запросов, внедрённый в «Закромах». Он позволил перевести банковские сервисы на работу с S3 ещё до окончания полного перемещения данных. Если нужный документ уже находился в новом хранилище, он отдавался оттуда; если же нет — система прозрачно обращалась к прежнему источнику. Для прикладных систем и конечных пользователей этот механизм остался совершенно незаметным. Фактическое переключение в промышленной эксплуатации заняло порядка 30 минут и не потребовало длительных технологических окон.
Итоги и архитектура
В результате проекта Почта Банк приобрёл единое S3-хранилище для документов и данных информационных систем. Значительно сократилась неоднородность систем хранения, упростилась их эксплуатация, а ИТ-команды получили прогнозируемую архитектуру с гарантированной согласованностью данных. Для обеспечения отказоустойчивости S3-хранилище «Закрома» развёрнуто в мультикластерном режиме в двух ЦОД с георепликацией данных. Немаловажным аспектом также стала возможность полагаться на поддержку отечественного вендора, готового оперативно реагировать на запросы и внедрять в продукт новые функции, отвечающие потребностям крупной финансовой организации.
Данный пример демонстрирует, что выбор S3-хранилища для банка — это не просто смена технологии, а архитектурное решение, напрямую определяющее отказоустойчивость, масштабируемость и скорость развития цифровых сервисов. В этом проекте решающими факторами выбора стали именно совокупность архитектурных преимуществ «Закромов», готовность продукта к промышленной эксплуатации и зрелость команды разработки.
