Сеть магазинов модной одежды lady & gentleman CITY перенесла свою инфраструктуру в облако. Ярослав Нечепоренко, руководитель веб-отдела, рассказывает, какие сервисы использует ритейлер и как они оптимизируют работу бизнес-приложений.
Как было
На старте инфраструктура нашего магазина представляла собой «монолит». Тогда мы взяли коробочное решение «Битрикс», чтобы ускорить запуск проекта. Систему развернули на железных серверах, которые арендовали в трех крупных дата-центрах. Такой подход не потребовал серьезных финансовых затрат и позволил оперативно протестировать гипотезу — захотят ли клиенты покупать у нас одежду онлайн? Так, долгое время все работало хорошо, и продажи шли.
Но с ростом пользовательской базы мы начали замечать недостатки монолитной инфраструктуры. Она была «неповоротливой» — для масштабирования приходилось докупать дополнительные серверы, настраивать кластеры. Эти задачи занимали не меньше одного дня. Также нам приходилось самостоятельно следить за «здоровьем» оборудования и своевременно его обслуживать.
Возникали проблемы и с разработкой новых сервисов. Программисты и тестировщики не могли оперативно вносить изменения в монолит с legacy-кодом. Так, добавление новой курьерской службы, а также подключение дополнительных платежных провайдеров заняло у нас продолжительное время. Тестировщики не могли писать автоматические тесты, и весь QA проводился вручную.
Еще мы готовили к запуску мобильное приложение. Оно должно было увеличить объем продаж и частоту покупок, а также расширить функциональные возможности за счет интеграции виртуальной примерочной и функций дополненной реальности.
Во время разработки мы хотели переиспользовать некоторые сервисы, поэтому перешли на микросервисную архитектуру.
Как стало
Миграция на микросервисную архитектуру проходила параллельно с разработкой фронтовой части мобильного приложения. Перед нами стояли три ключевые задачи:
перенос интернет-магазина в облако,
автоматизация процессов CI/CD,
оптимизация ресурсов компании.
Мы остановили свой выбор на сервисах SberCloud Advanced. Специалисты облачного провайдера совместно с нашими руководителями отдела системного администрирования, сисадминами и девопсами провели миграцию инфраструктуры за четыре месяца.
Сделали упор на автоматизацию, подход Infrastructure-as-Code (IaC) — позволяет управлять инфраструктурой с помощью конфигурационных файлов — и архитектуру на Kubernetes. Первым делом разделили сервисы по бизнес-назначению, чтобы с ними было удобнее работать и переиспользовать в других проектах. Мы воспользовались подходом DDD (Domain Driven Design) и выделили такие категории: каталог, авторизация, доставка, резервирование, оплата, доступность товара, уведомления, возвраты, розничные магазины, хранение файлов и другие.
Далее, подключили облачные сервисы, которые отвечали за решение задач в отмеченных категориях.
RDS for PostgreSQL. Тут мы храним каталог интернет-магазина. Одно из преимуществ сервиса — read-реплики. Они реплицируют данные с сервера БД в режиме «только для чтения» и позволяют нам справляться с наплывом трафика в праздники. В то же время провайдер самостоятельно мониторит состояние экземпляров БД и предлагает резервное копирование. Так мы можем оперативно восстановить данные в случае сбоя.
Cloud Container Engine. Автоматизирует управление приложениями в кластерах Kubernetes. Например, мы его используем для развертки мобильного приложения по API. Сервис также решает проблему отказоустойчивости и масштабируемости во время маркетинговых акций в магазине. Ежедневно на сайт заходит более 25 тыс. пользователей. Этот показатель возрастает примерно в 2–3 раза в периоды повышенного сезона. При скачке трафика система автоматически подключает дополнительные контейнеры и отключает их, когда пик проходит. В итоге мы платим только за те ресурсы, которые действительно используем (модель pay-as-you-go).
Хотя при настройке сервиса нам пришлось привлечь стороннюю экспертизу — для автоматического деплоя из Gitlab. В классическом сценарии это довольно тривиальная задача, но наши QA-инженеры тестировали новые функции в динамических окружениях. Разработчикам приходилось учитывать этот момент, что отнимало время от других важных задач.
Cloud Search Service. Это — поисковая система на основе Elasticsearch, которую мы используем для хранения и обработки логов — например, при авторизации, добавлении товаров в корзину, завершении покупки. Эта информация помогает нам реагировать на инциденты и выявлять аномалии в работе интернет-магазина. Чтобы подключить сервис, было достаточно указать необходимые вычислительные мощности и бандл с настройками логирования каждого сервиса.
Мы решили не использовать сервис для обработки каталога, так как он построен на основе Open Distro for Elasticsearch. С ним есть сложности — нет разделения логов по типу хранения: hot, warm или cold. В результате все записи лежат в «горячем» состоянии, что сказывается на объемах потребляемых ресурсов. В то же время настройка политик Open Distro — муторный процесс, а сам сервис не поддерживает нужные нам плагины. И в будущем мы планируем заменить его классическим Elasticsearch на виртуальных машинах.
Distributed Cache Service for Memcached. Он пришел на замену отдельному «железному» серверу, на котором хранились все данные. Распределенный сервис кеширования снижает нагрузку на внешние БД. Когда клиент покупает товар в онлайн-магазине, он начинает прописывать адрес доставки в форме. В этот момент на сервис DaData поступает запрос для подбора релевантного адреса. Каждое обращение стоит денег, а сервис SberCloud позволяет сохранить прошлые запросы и экономить при росте количества заказов во время акций и праздников.
В облаке SberCloud Advanced мы также используем сервисы API Gateway, FunctionGraph и Distributed Message Service for Kafka. Первый обеспечивает связность между сервисами. Мы изначально пишем не микросервисы, а достаточно крупные приложения, а потом их делим. Мы прячем их за API Gateway и модифицируем маршруты — так, внешние системы не видят подмены. FunctionGraph нужен для быстрого запуска кода в бессерверной среде и обработки легких и сиюминутных запросов к базам данных — например, получить список магазинов. Нужные топики он читает из Kafka, который мы используем как шину данных. Она обеспечивает нам event driven архитектуру.
Однако стоит заметить, что не все сервисы находятся в облаке — наша инфраструктура гибридная. On premise работает 1С и кассовое оборудование — это требование внутренней службы безопасности.
Какие планы
Если говорить о цифрах, то миграция в облако SberCloud Advanced на микросервисную архитектуру увеличила скорость работы сайта lgcity.ru — только за счет кеширования на 20%. При этом темпы доставки бизнес-приложений в продакшн увеличились в два раза, а за управление инфраструктурой теперь отвечает в два раза меньше сотрудников.
Но IT-отдел в lady & gentleman CITY по-прежнему один из самых крупных департаментов компании. В команде более двадцати пяти бизнес-аналитиков, бэкенд и фронтенд-разработчиков, тимлидов и других специалистов. Мы постоянно осваиваем новые актуальные технологии и инструменты, работаем с облачными сервисами, осваиваем сервисы по обработке big data и внедряем комплексные решения для повышения адаптивности сайта.
Теперь нам не приходится отвлекаться на работу с инфраструктурой, так как эти задачи берут на себя специалисты SberCloud. Многие процессы покрываются автотестами, а мы можем сконцентрироваться на доставке решений и настройке новых сервисов. В будущем мы планируем добавить элементы машинного обучения, а на их основе построить виртуальную примерочную и систему премодерации отзывов.
Пара свежих материалов из нашего блога:
