Поделиться
Почта Банк перенес 200 млн файлов c Minio на российское S3‑хранилище без остановки сервисов
Почта Банк завершил переход на отечественное объектное хранилище «Закрома», заменив им иностранную платформу Hitachi Content Platform и open-source (бесплатное открытое ПО) S3 Minio. Новое хранилище обеспечило строгую консистентность данных, интеграцию с 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 еще до завершения полной миграции данных. Если запрашиваемый документ уже находился в новом хранилище, он возвращался оттуда; если нет — система прозрачно обращалась к старому источнику. Для прикладных сервисов и конечных пользователей этот процесс был полностью незаметен. Фактическое переключение в промышленной среде заняло около получаса и не потребовало длительных технологических окон.
Результаты и архитектура
В результате проекта Почта Банк получил единое S3-хранилище для документов и данных информационных систем. Существенно снизилась разнородность хранилищ, упростилась эксплуатация, а ИТ-команды получили предсказуемую архитектуру с гарантированной консистентностью данных. Для обеспечения катастрофоустойчивости S3-хранилище «Закрома» развернуто в мультикластерном режиме на двух ЦОД с георепликацией данных. Немаловажным фактором стала и возможность опираться на поддержку российского вендора, готового оперативно реагировать на запросы и добавлять новые возможности в продукт под потребности крупной финансовой организации.
Этот кейс показывает, что выбор S3-хранилища для банка — это не вопрос замены технологии, а архитектурное решение, напрямую влияющее на устойчивость, масштабируемость и скорость развития цифровых сервисов. В этом проекте именно совокупность архитектурных свойств «Закрома», готовность продукта к промышленной эксплуатации и зрелость команды стали ключевыми факторами выбора.
Короткая ссылка
