Привет! Меня зовут Валентин Бритвич, я Unit Lead интеграций в СберМаркете. В статье я расскажу о сложностях роста Ruby-приложений, с которыми мы столкнулись по мере роста бизнеса, и о том, как с ними справиться. На заре СберМаркета мы начинали с одного Rails-монолита, но бизнес рос: за 5 лет tech-команда выросла в 19 раз, а потребление инфраструктуры — в 77 раз. А помимо монолита сейчас у нас 100+ микросервисов на Go, Ruby и Python.
С чего всё начиналось
Ещё на заре проекта мы в СберМаркете сразу хотели сделать наших клиентов счастливыми и довольными, а атрибутом счастья была возможность выбирать из широкого ассортимента продукции и многих акций.
Так появился первый Rails-монолит, в котором мы взаимодействуем с покупателями. По сути — это витрина, на которую мы выставляем товары, и где рассказываем об акциях.
Но одного Rails-монолита было мало: помимо витрины для клиентов, у нас есть бэк-офис для управления заказами. Мы сделали второй монолит, и разделили логику наших приложений на клиентское и партнёрское, для взаимодействия с нашими курьерами и сборщиками.
Тогда начались трудности: бизнес масштабируется, в монолите работает одновременно много команд разработчиков, и нужны огромные объёмы техподдержки. Я выделил четыре основных проблемы и расскажу вам, как мы с ними справились — возможно, это будет полезно и в вашем бизнесе.
Сотни разработчиков в монолите
Чтобы обслуживать большой монолит, нужна была команда из нескольких десятков разработчиков, которые начинали «толкаться» друг с другом, выполняя продуктовые задачи. В итоге скапливалась большая очередь на релизы, обновления выкатывались неделями, и это начинало мешать нашим клиентам.
Мы решили эту проблему, используя CODEOWNERS для каждой папки в репозитории, чтобы данными могла управлять только одна команда. Потом автоматизировали добавление CODEOWNERS с блокирующими пайплайнами, чтобы, кроме назначенных оунеров, никто не мог слить merge request в основную ветку.
Миграция террабайтной базы
Миграция терабайтной базы — это часто миллионы строк и недели согласований. Мы прошли этот путь и выделили 3 основных правила, как мигрировать базу легче:
Заранее продумать структуру данных. Прописать набор и типы полей при проектирований, понять, хватит ли нам этих полей при дальнейшем росте продукта. Мы поняли, как это важно, когда продукт вырос и потребовалось внести новое поле для работы с определенной сущностью, и ради этого пришлось мигрировать сто миллионов таблиц
Интересные статьи
Интересные статьи
