Масштабируемый маркетплейс. Как в Secumarket перешли на облачную модель

Secumarket — B2B-маркетплейс систем безопасности и электронных устройств, который развивает российский производитель оборудования — группа компаний «Рубеж». На площадке представлено свыше 450 000 SKU (от англ. stock keeping unit — товарная позиция), ежемесячная аудитория сайта — более 100 000 пользователей.

Рассказываем, почему компания перенесла ИТ-инфраструктуру в облачную среду и к каким результатам это привело.

Проблема

Рабочая инфраструктура платформы Secumarket была размещена на арендованных виртуальных машинах, и процесс её управления не был прозрачным для команд разработки. Это усложняло контроль ресурсов и оперативное масштабирование сервиса, при этом расходы на услуги провайдера превышали плановые показатели.

Кроме того, растущий ассортимент и пользовательский трафик увеличивали нагрузку на системы, что приводило к задержкам в работе сайта. Из-за технических простоев снижалась выручка маркетплейса.

Решение

Компании требовалось оптимизировать затраты на ИТ, а также обеспечить стабильную работу платформы с возможностью гибкого масштабирования под рост нагрузки. Решить эту задачу помогает инфраструктура, построенная на нескольких географически распределённых зонах доступности. Поэтому руководство приняло решение развернуть маркетплейс полностью в облачной среде.

Инфраструктуру перенесли в облако Cloud.ru, пересобрали ключевые процессы разработки и эксплуатации платформы.

Преимущества облачной среды

• IaaS (от англ. infrastructure as a service — «инфраструктура как услуга») позволяет определить точные параметры вычислительных ресурсов и перейти к модели потребления, когда оплачиваются только фактически используемые мощности, при этом инфраструктуру можно быстро масштабировать горизонтально или вертикально.
• Прежняя архитектура платформы требовала использования системы хранения данных Ceph и дополнительных ресурсов для резервирования, синхронизации данных и обеспечения отказоустойчивости — при переходе на управляемые облачные хранилища нет необходимости нести такие накладные расходы.
• Использование GitLab CI открывает доступ к широкому набору инструментов для автоматизации CI/CD (процессов непрерывной интеграции и доставки программного обеспечения), это ускоряет развёртывание новых модулей и выпуск обновлений, сокращая время вывода продукта на рынок.

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

Технологии

• GitLab CI/CD: инструмент для автоматизации тестирования, сборки и развёртывания новых версий сервиса.
• Интеграция с существующим технологическим стеком: он включает кластер Kubernetes (K8S), сервер администрирования и воркер CI/CD, систему хранения данных Ceph, сервер с системой управления базой данных (СУБД) Postgres.
• Фронтенд: библиотека для веб-интерфейсов React 18, фреймворк NextJS 14, библиотека Tanstack React Query, система визуализации данных Greensight design system, инструменты Storybook 7, Emotion CSS-in-JS, язык программирования Typescript 5, менеджер пакетов Yarn 1, платформа NodeJS 22.
• Бэкенд: язык программирования PHP 8.2 и фреймворк для создания приложений Laravel 10, сервер Swoole с пакетом приложений Laravel Octane; базы данных и системы с открытым исходным кодом — PostgreSQL 14, Elasticsearch 8.7 с Kibana 8.7, спецификация OpenAPI Specification 3.0.3 с платформой управления Stoplight и OpenAPI Generator; платформа контейнеризации Docker с k8s 1.19, Helm 3.4; платформы Kafka 2.7, NewRelic, Zabbix, Grafana.

Сложности

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

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

Этапы работы

1. Июнь 2025 года. Аудит текущей инфраструктуры. Анализ предложений разных провайдеров: качество сервисов, количество доступных зон, функциональность платформ, стоимость владения.
2. Июль 2025 года. Проектирование целевой архитектуры. Развёртывание тестового контура в новом облаке. Оценка соответствия новой архитектуры заданным целям. Тестирование работоспособности тестового контура. Миграция приложения и данных. Проверка целостности данных и функциональности приложения.
3. Август 2025 года. Доработки, исправление ошибок. Мониторинг приложения после запуска.

В общей сложности процесс переезда занял 45 дней (с учётом того, что миграция данных продолжалась 20 часов).

Результаты

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

• На 50% сократились операционные расходы. Переход на облачную модель и оптимизация конфигураций позволили убрать избыточные ресурсы и перейти к гибкой модели потребления, что существенно снизило затраты на инфраструктуру.
• 99,95% достиг показатель доступности сервисов. Сайт перестал испытывать задержки в работе при росте нагрузки, что снизило риск потери выручки из-за технических простоев.
• В 1,5 раза ускорился вывод функциональных обновлений. Благодаря переходу на GitLab CI/CD, автоматизации процессов сборки и развёртывания сократилось время на реализацию новых модулей и улучшений платформы.

Следующие шаги

Secumarket продолжает развивать инфраструктуру и процессы для повышения качества обслуживания пользователей.

В ближайших планах:

1. ускорить процессы сборки и развёртывания приложения. Для этого предполагается дальнейшая оптимизация пайплайнов CI/CD, сокращение времени сборки артефактов, повышение степени автоматизации выката обновлений;
2. расширить возможности observability (с англ. «наблюдаемость») системы, чтобы быстрее выявлять отклонения в работе сервисов. Потребуется внедрить централизованное логирование, расширенные метрики мониторинга, полноценную трассировку запросов, инструменты анализа производительности;
3. провести рефакторинг сервисов. Актуализация архитектуры и оптимизация отдельных компонентов позволят уменьшить потребление ресурсов, повысить стабильность системы и ещё больше сократить расходы на инфраструктуру.