На конференции RubyRussia Кир Шатров расскажет об архитектуре Shopify. Как одного из самых больших и нагруженных в мире приложений на Rails поддерживает рост бизнеса на протяжении 10 лет, не переходя на микросервисы, Elixir и другие популярные альтернативы? В традиционном интервью перед конференцией вопросы Киру задал Анатолий Зайцев, разработчик компании Evrone.



Расскажи, как ты начал карьеру?

Как и многие, я занимался программированием еще в школе. Делал сайты на WordPress за 200$ каким-то знакомым. Узнал о Ruby on Rails и понял, что те задачи, которые на PHP занимают часы и дни, можно решать гораздо быстрее. Мне показалось, что стоит запрыгнуть на этот поезд: я купил книгу по Rails и начал изучать по шагам. Многие шаги не работали, и я забросил занятия. Вернулся через год, попробовал идти по онлайн-туториалам, и тогда все получилось. Только потом я понял, в чем была проблема: пока книгу писали, переводили, печатали и везли в магазины, прошел год, а то и полтора. Rails за это время сильно изменились. Естественно, что инструкции уже не работали. А когда я смог читать материалы онлайн и на английском, то легко вошел в Rails и сделал первые хобби-проекты.

Потом я познакомился с Олегом Балбековым, основателем конференции RailsClub, которая теперь называется RubyRussia. Так я попал в компанию Evrone, где проработал почти четыре года и благодаря классным и умным коллегам смог хорошо вырасти. Evrone здорово помог начать: была возможность делать опенсорс, расти. Потом я работал в Evil Martians, делал проекты уже другого масштаба — EBay, Groupon, Gett. У марсиан необычная культура опенсорса и экспериментов, которая бывает далеко не во всех командах. В перерывах между проектами или прямо на проектах у людей есть возможность заниматься опенсорсом. Именно так получается развивать Autoprefixer, AnyCable и не только. Как результат — есть о чем рассказать на конференциях. Я выступал на RailsClub в России, RailsConf в Штатах и на огромном количестве других крупных и не очень мероприятий. И из-за того, что я так много выступал, меня заметили и пригласили работать в Shopify.

Расскажи, как ты переехал в Канаду и как Shopify помогал в процессе?

Это получилось не сразу, были сложности с релокацией: в тот момент в Канаде правительство устроило забастовку и просто некому было апрувить или реджектить визы, но все разрешилось. Это был 2013-2014 год, Shopify очень не хватало разработчиков, и они начали перевозить инженеров со всего мира к себе. Этот процесс активно идет и сейчас. Сегодня масштаб такой, что совместно с правительством Канады Shopify разработал программу, которая позволяет получить рабочую визу за три недели. По такой схеме переезжает около ста человек в год. При этом, попасть на работу могут не только опенсорсеры и известные спикеры. Нам нужны разработчики, которые впишутся в команду и будут писать хороший код.

Получается, что попасть в Shopify возможно и без огромного послужного списка, если ты хорошо и профессионально делаешь свое дело?

Да, это так. А еще важно уметь рассказывать о своей работе. Кто-то скажет: «я пофиксил баг и обновил версию Ruby, добавил новую фичу». А можно рассказать о том же, но с точки зрения развития бизнеса, решения его проблем. Еще на собеседованиях в такие компании важно, какие нововведения ты внедрял на работе, как участвовал в жизни сообщества: не только писал код, но и, например, был волонтером, помогал организовать Ruby-конференцию.

Чем конкретно ты сейчас занимаешься в Shopify?

Задачи разные. Конечно, я пишу код. Но много моего времени уходит и на организацию процессов. Например, в конце ноября будет Black Friday. Для всех, кто работает в e-commerce, это самое большое событие в году. Мы начинаем готовиться еще в августе: нужно договориться с разными командами о выпуске новых фич, договориться с вендорами и провайдерами. А после того, как черная пятница пройдет, мы входим в фазу, когда начинаем делать что-то новое. Тогда мне приходится надевать шляпу архитектора.

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

Shopify — большая платформа. Сколько у вас клиентов?

Официальная цифра — 800 000 активных магазинов. Это не просто регистрации (их намного больше), это именно живые бизнесы.

Что Shopify как платформа дает клиентам?

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

Если ты живешь в стране, где у Shopify полная поддержка, значит, что тебе не нужно выбирать платежную систему, ведь есть Shopify Payments. Просто вводишь свои налоговые данные, и все будет работать. Та же ситуация с отправкой товаров: ты печатаешь стикер, клеишь его на посылку и отправляешь. Не нужно покупать марки, оплачивать доставку, Shopify автоматически интегрируется с почтами. Есть складские сервисы: ты можешь отправить свои товары на склад Shopify, а сложные алгоритмы вычисляют, на каком складе его хранить, как обеспечить доставку клиентам за один день. Это позволяет малому бизнесу конкурировать с Amazon и EBay.

Я некоторое время работал над переносом проекта на вашу платформу. У этого магазина были свои inventory, товары, клиентская база. Все работало достаточно удобно: есть экспорт\импорт, даже сторонние платежи подключаются в два клика. У вас огромная инфраструктура. Правильно ли я понимаю, что большинство библиотек (shopify api, shopify app, shopify co), написано на Ruby и Rails?

Да, это так.

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

Компания началась с парня по имени Тоби, который увлекался сноубордами. Двенадцать лет назад он решил написать свой магазин для продажи этих сноубордов. Делать это на PHP, Java и XML ему было не интересно. Тогда друг Дэвид показал ему свой новый классный фреймворк, который позволял быстро создавать веб-приложения. Фреймворк назывался Ruby on Rails, и на нем Тоби построил свой магазин для сноубордов. Ему понравился язык и идеи фреймворка, Тоби стал одним из первых контрибьюторов в Rails. На тот момент у Rails еще не было даже централизованного git репозитория! Люди просто обменивались новыми версиями. Так Тобиас Лютке и Давид Хейнемейер Ханссон начали работать над Rails. И скоро Тоби понял, что гораздо круче запустить не свой магазин сноубордов, а целую платформу для других магазинов.

Тобиас Лютке — наш фаундер, он все еще является СЕО. Его можно встретить в офисе, все эти пятнадцать лет он работает над Shopify. Компания началась с Rails, и в ней работают люди, которые искренне любят этот фреймворк. Они видят, как быстро смогли построить на Rails то, что они хотели. Видят, как быстро разработчики могут что-то делать, экспериментировать и доставлять в продакшен.

Я не думаю, что в компании когда-то серьезно рассматривали варианты перехода на что-то другое. На мой взгляд, веб-приложения все равно будут упираться в базу. Сходить куда-то, взять что-то, переформатировать это, склеить шаблон, положить в кэш и потом отдать результат. На это уходит большая часть времени. Rails прекрасно подходит для рендеринга страниц за 100-300 миллисекунд. Конечно, если нужно рендерить за 8-10, то придется выбрать что-то более быстрое, например, Go. В компании есть отдел, который занимается инфраструктурой, масштабированием и исследованием направлений роста с нашими текущими технологиями.

Как решаете проблемы с масштабированием и высокими нагрузками?

У нас очень типичный стек: Rails, MySQL, Memcache, Redis. Наверняка, ты работал с таким на многих проектах. Где-то в 2014 году, когда компании было 10 лет, мы поняли, что все необходимое уже не лезет в одну базу данных. Можно покупать более мощное железо для сервера MySQL и расти вертикально, но всему есть предел.

Тогда мы решили, что шардинг поможет расти горизонтально. Как SaaS, где данные одного магазина не пересекаются с данными другого, мы можем организовать шардинг довольно просто. Никогда не придется делать join между двумя разными магазинами. С нашей моделью шардинга, на одном шарде живут тысячи магазинов разного размера и разной нагрузки. Шард включает в себя не только сущность базы данных, а также свой Redis, свой Memcache и так далее. За счет полной изоляции между шардами мы разбиваем весь Shopify на сотни маленьких Shopify. Каждый может хостится в отдельном регионе, датацентре, провайдере, в отдельной юрисдикции. Если у тебя 100 шардов, и на одном из них что-то упало, это затронет всего 1% клиентов. Это очень немного, если сравнить с ситуацией, когда при падении одного ресурса на всех падает все.

Это и есть горизонтальное масштабирование с помощью шардинга. И шардинга не только одного, самого главного ресурса (базы данных), а изоляции всех компонентов, которые используют магазины. Дальше появляются интересные проблемы. Например, на каком-то шарде больше магазинов, где много трафика, а на каких-то меньше. На каких-то больше нагрузки, а на каких-то меньше. Приходится решать проблемы балансировки магазинов внутри шарда.

Вы мигрируете магазин из одного шарда в другой?

Когда нужно решить такие проблемы — да. У нас есть тулинг, который я подробно опишу в докладе. Будет рассказ о том, как мы пришли к этой схеме, как работает шардинг, как такой подход может применяться не только к нашему бизнесу, но и к другим. Нам пришлось самим разработать тул для миграции магазинов между шардами и датацентрами. В основном, миграция нужна для ребалансировки.

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

На конференцию приезжает Yukihiro Matsumoto. Что бы ты хотел у него спросить?

Сначала опишу контекст, чтобы мой вопрос был более понятен. Насколько я знаю, разработка Ruby — это несколько индивидуальных личностей, меньше десяти человек, среди них не более пяти ключевых. Большинство — японцы, которые очень давно этим занимаются. Кто-то из них может в одиночку реализовать такую мажорную фичу, как, например, guild или аннотации типов. Все завязано на этих людей. И если один человек, которого спонсирует Cookpad или Heroku, реализует ключевую фичу определенным образом, то именно такой она и будет. Но есть bus factor.

На мой взгляд, самые большие продвижения в Ruby, которые происходили за последние пару лет, были инициированы большими компаниями, так как большие проблемы невозможно решить в одиночку. Например, Stripe нанимает людей, которые занимаются разработкой типизированных языков программирования, и дает им год на исследование. Так получается Sorbet, который является не просто способом тайп-чекинга, а целой парадигмой, его можно масштабировать, его документация построена на опыте сотен человек внутри Stripe. И таких примеров масса. Oracle спонсирует Truffle, и несколько людей работают над созданием виртуальной машины следующего поколения, переиспользуя часть виртуальных машин, которые уже были разработаны на протяжение десятков лет, десятками умных людей внутри Oracle.

Я бы спросил Маца о том, насколько он верит в реалистичность решения больших проблем Ruby силами небольшой группой индивидуальных контрибьюторов. Насколько такая модель может конкурировать с примерами, когда проблемы решались при помощи крупного спонсора.

Обсудим на конференции!

Напомним, что она состоится 28 сентября в Москве, все подробности и регистрация на сайте.

Нас поддерживают:

Организатор — Evrone
Генеральный партнер — Toptal
Золотой партнер — Gett
Серебряные партнеры — Валарм, JetBrains, Bookmate и Cashwagon
Бронзовый партнер — InSales