Привет! Меня зовут Валентин Бритвич, я Unit Lead интеграций в СберМаркете. В статье я расскажу о сложностях роста Ruby-приложений, с которыми мы столкнулись по мере роста бизнеса, и о том, как с ними справиться. На заре СберМаркета мы начинали с одного Rails-монолита, но бизнес рос: за 5 лет tech-команда выросла в 19 раз, а потребление инфраструктуры — в 77 раз. А помимо монолита сейчас у нас 100+ микросервисов на Go, Ruby и Python.
С чего всё начиналось
Ещё на заре проекта мы в СберМаркете сразу хотели сделать наших клиентов счастливыми и довольными, а атрибутом счастья была возможность выбирать из широкого ассортимента продукции и многих акций.
Так появился первый Rails-монолит, в котором мы взаимодействуем с покупателями. По сути — это витрина, на которую мы выставляем товары, и где рассказываем об акциях.
Но одного Rails-монолита было мало: помимо витрины для клиентов, у нас есть бэк-офис для управления заказами. Мы сделали второй монолит, и разделили логику наших приложений на клиентское и партнёрское, для взаимодействия с нашими курьерами и сборщиками.
Тогда начались трудности: бизнес масштабируется, в монолите работает одновременно много команд разработчиков, и нужны огромные объёмы техподдержки. Я выделил четыре основных проблемы и расскажу вам, как мы с ними справились — возможно, это будет полезно и в вашем бизнесе.
Сложность #1: сотни разработчиков в монолите
Чтобы обслуживать большой монолит, нужна была команда из нескольких десятков разработчиков, которые начинали «толкаться» друг с другом, выполняя продуктовые задачи. В итоге скапливалась большая очередь на релизы, обновления выкатывались неделями, и это начинало мешать нашим клиентам.
Мы решили эту проблему, используя CODEOWNERS для каждой папки в репозитории, чтобы данными могла управлять только одна команда. Потом автоматизировали добавление CODEOWNERS с блокирующими пайплайнами, чтобы, кроме назначенных оунеров, никто не мог слить merge request в основную ветку.
Сложность #2: миграция террабайтной базы
Миграция терабайтной базы — это часто миллионы строк и недели согласований. Мы прошли этот путь и выделили 3 основных правила, как мигрировать базу легче:
Заранее продумать структуру данных. Прописать набор и типы полей при проектирований, понять, хватит ли нам этих полей при дальнейшем росте продукта. Мы поняли, как это важно, когда продукт вырос и потребовалось внести новое поле для работы с определенной сущностью, и ради этого пришлось мигрировать сто миллионов таблиц ? В итоге больше месяца мы получали все апрувы и почти сутки потратили на саму миграцию базы.
Сначала катим миграцию → потом код, который начнёт использовать новые или измененные поля из миграции.
Миграции на таблицы до миллиона строк мы прогоняем самостоятельно, используя LHM от Shopify, или механизма Concurrently PostgreSQL. Если в таблице больше миллиона строк — подключаем DBA, которые проведут миграцию с помощью специальных инструментов, например, Ghost.
Сложность #3: настройка интеграции партнёров в приложение
Чтобы настроить удобный для всех процесс попадания партнёров в продакшн, нужно валидировать все исходящие и входящие данные, и разработать документацию, в которой будут описаны все корнер-кейсы, с которыми можно столкнуться, и подготовить ответы на вопросы, которые могут возникнуть. Из документации должно быть понятно, как начать работу с вашим API, и как провести интеграцию от момента получения токена и первичной аутентификации до момента запуска в продакшене.
Одним из наших решений было разработать плэйграунд для selfcheck & prepare — это специальная песочница, в которой партнеры прогоняют тест-кейсы интеграции, в том числе различные корнер-кейсы. Таким образом мы понимаем, готов ли мерчант к интеграции, и только пройдя синтетические тесты, партнёр может отправиться в продакшн.
95% наших партнёров проходит плейграунд самостоятельно практически без участия команды разработки. Но всегда остаются ключевые игроки рынка, у которых есть собственные программные продукты для интегрирования и они не могут или не хотят разрабатывать решение под наш контракт. Нашим ответом стала разработка систем адаптеров, которые умеют общаться на языке нашего контракта, и языке контракта партнёра. У адаптеров минимум бизнес-логики, но они отлично понимают, о чём говорят обе системы, благодаря чему обеспечивается бесперебойное взаимодействие между системами СберМаркета и системами партнеров.
Сложность #4: как обеспечить надёжность интеграций в high season
В СберМаркете высокий сезон обычно зимой, и мы стараемся заранее к нему готовиться. Регулярно проводим нагрузочное тестирование, чтобы найти слабые места, и оптимизируем кодовую базу и работу с базой данных. Мы используем подход Fail Fast — лучше превентивно отключить часть функционала, чем обвалить всё полностью.
Подробнее о феномене высокого сезона в e-com мои коллеги рассказывали в подкасте «Для tech и этих»
Для надёжной работы приложения очень важен настроенный инцидент-менеджмент. У нас есть комитет надёжности, туда выводятся самые приоритетные инциденты, и обсуждаются большим количеством участников, не только чтобы митигировать текущий, но и чтобы свести к минимуму риски возникновения похожих инцидентов в будущем.
Важно расширять и настраивать наблюдаемость ваших систем. Мы, например, используем Grafana и VictoriaMetrics для сбора и отображения технических и бизнесовых показателей в моменте времени, grafana on-call для своеременного уведомления об отклонениях от нормы поведения систем. Дополнительно у нас есть целый набор технических и инфраструктурных решений по хранению и обработке логов приложений.
На основе выстраиваемых метрик нужно строить систему алертов, которая будет в автоматическом режиме уведомлять о внештатных ситуациях. Grafana On-call, как один из инструментов, может помочь в этом.
А ещё логи — наше всё. Логирование помогает в любой момент понять, что и когда пошло не так, и починить. Для работы с логами мы используем Kibana.
Ещё важна управляемость изменений. Нужно понимать, что происходит с системой в каждый момент времени и видеть, какие изменения были применены. Для этого отлично подходит инструмент «фича-флаги», которые позволяют точечно контролировать новый функционал, и не аффектить большое количество пользователей. Здесь главное не переусердствовать, поэтому мы взяли за правило «фича-флаг = релиз».
Выводы и советы
Я считаю, что самое главное — адаптироваться под задачи бизнеса. А бизнес очень гибкий: то, что было актуально вчера, может потерять значение сегодня по множеству причин. Важно готовить системы к высокому сезону, проводить нагрузочное тестирование. Делайте изменения в вашей кодовой базе, в ваших базах данных для того, чтобы всё это жило, дышало и могло работать. По необходимости расширяйте базу, шардируйте её, выносите часть логики в микросервисы, отделяйте еще каким-то образом, но готовьте ваши системы.
И будьте наблюдательными. Не стоит забывать про алерты. Алерты — очень важная вещь, которая даст вам понять, что с вашей системой что-то не так до того, как это заметят ваши клиенты.
Tech-команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.