Brandquad в Yandex Cloud: поиск архитектуры для удобного обновления приложения

Brandquad работает с крупными компаниями, которые производят или продают большое количество продуктов (L’oreal, Unilever, Nestle, X5 Retail Group и другими) и хотят хранить подробную информацию о них одном месте.

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

Стартап запустился в 2015 году в Москве. Сегодня компания работает в России, ОАЭ и Франции. В системе Brandquad хранятся и обрабатываются данные более 600 брендов и 30 млн SKU. Данные о товарах передаются по 2000 каналам, в том числе — для Яндекс.Маркет, Ozon и других крупных онлайн- и офлайн-ритейлеров. Суммарно клиенты Brandquad экономят до 100 000 рабочих часов за счет автоматизации управления контентом.

За четыре года работы Brandquad сложилась архитектура, которая не позволяла удобно обновлять приложение. Поэтому сначала встала задача так изменить архитектуру, чтобы оптимизировать этот процесс и гарантировать качество продукта для серьёзных клиентов.
Приложение написано на Python с использованием фреймворка Django и библиотеки AsyncIO, основная БД — PostgreSQL. Для сервиса очередей используется Redis, но идет переход на RabbitMQ. Также в стек входят поисковый движок Elasticsearch, Node.js для фронтенда, часть микросервисов написана на Go.

При поиске путей решения задачи удобного обновления круг смежных проблем расширился:

• Сложность обновления Stateless приложений, развёрнутых на ВМ в Docker/Compose.
• Кастомные настройки на некоторых аккаунтах еще больше снижали удобство обновления.
• Низкая утилизация ресурсов по причине разноплановости аккаунтов с разной нагрузкой и разными пиками, что лишает возможности балансировки.
• Синхронные REST-запросы (микросервисная архитектура подразумевала, что запросы к микросервисам идут в формате REST-запросов).
• Общая сложность инфраструктуры в целом.
  *Uptime 93%.

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

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

Brandquad сформулировал свои требования к провайдеру сервиса Managed Service for Kubernetes^®:

• Надёжность работы.
• Лояльность к клиенту и отсутствие vendor lock.
• Нативный Kubernetes «из коробки».
• Надёжное хранение объемных данных.
• Скорость работы серверов.
• Скорость доступа из РФ.
• Минимальная сложность освоения платформы.
• Приемлемая стоимость.

При выборе облачной платформы оценивались международная «большая тройка», два российских провайдера и еще два зарубежных решения. В пользу Yandex Cloud сыграло расположение серверов на территории РФ, соответствие требованиям № 152-ФЗ и низкий пинг, который важен для российских клиентов.

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

С точки зрения экономики отмечено четыре преимущества:

• Оплата с расчетного счёта в РФ.
• Прозрачное ценообразование и удобный калькулятор.
• Расходы на хранение данных значительно дешевле, чем у других провайдеров.
• Расчётные затраты на Kubernetes в Yandex Cloud ниже, чем у других аналогов.

Переезд в Yandex Cloud происходил в то время, когда управляемый сервис для Kubernetes находился в стадии technical preview. Сложности этого периода на сегодня успешно решены. Пришлось поменять некоторые процессы внутри в управлении продуктом и командой.

Архитектура приложенияАрхитектура приложения

При переходе с Docker архитектура приложения была переведена на Multi-tenant, что удовлетворяло текущим потребностям за счет возможности балансировать нагрузку.

Управление ресурсамиУправление ресурсами

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

Рабочий процессРабочий процесс

В ходе реализации проекта пришлось изменить процесс обновления, разработки и тестирования, построить CI/CD систему.

Обучение командыОбучение команды

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

После миграции используется 3 кластера Kubernetes, 27 инстансов, 650 GB RAM, 132 cores CPU, 20 TB Yandex Object Storage. Проект был реализован в один этап буквально за неделю силами двух человек.

После завершения проекта инфраструктура стала масштабируемой и управляемой, а затраты на нее снизились. Для клиентов Brandquad самым важным стали переезд платформы в РФ и повышение стабильности работы всей системы.

Технические итоги так или иначе связаны с переходом на Kubernetes:

• На Kubernetes развёрнуто Statefull multi-tenant приложение.
• Налажен CI/CD для stage (готовится процесс для prod окружений).
• Повышена утилизация ресурсов за счёт управляемости.
• Убрано большинство синхронных REST-запросов, что положительно сказалось на отзывчивости приложений.
• Реализованы масштабирование и балансировка.
• Uptime доведен до 99,5% (из них 0,45% — это проблемы софта), то есть повысился на 6,5%.

В планах на ближайшее будущее более подробное разбиение микросервисов на большее количество по ролям. В работе на платформе Yandex Cloud планируется использовать автомасштабирование нод под потребности ресурсов, подключить больше управляемых сервисов (Managed Service for PostgreSQL, Yandex Managed Service for Redis^™, Yandex Managed Service for ClickHouse), интегрировать сервис анализа и визуализации данных DataLens в бизнес-процессы.