В этом году Учи.ру исполняется 10 лет. За это время компания пережила технологические и архитектурные трансформации. Она выросла из простого сайта, где можно было решать примеры на счёт столбиком, до группы компаний с курсами по школьным и внешкольным предметам, олимпиадами и многим другим. Команда научилась справляться с внезапным усилением трафика, одновременно запускать несколько задач и «распиливать» огромный монолит на кусочки. Сейчас может показаться, что все используемые нами решения стандартны, но в далеком 2012 году мы внедряли их одними из первых. Я, Алексей Вахов, директор по инновациям Учи.ру, расскажу о ключевых технологиях и архитектурных принципах, которые лежат в основе платформы.

Облачные решения

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

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

Использование облачных решений помогало нам спокойно проходить все пики трафика, включая первый самый сильный, который случился в 2020 году из-за массового перехода школьников на дистанционное обучение. Если бы мы сидели на физических серверах, условно, при увеличении трафика в 7 раз нам бы пришлось добавить 7 новых серверов. За день-два это не сделать, и расходы очень большие. Поэтому или облако, или ваш сайт лежит, и вы теряете пользователей.

Другой важный момент — облачные решения оказались удобной средой для большого количества тестовых окружений, которые разработчик поднимает под каждую задачу. Такой подход делает разработку проще, потому что можно много задач запускать параллельно. Это помогает проверять несколько гипотез одновременно, быстро доводить идеи до рынка — короткими и прицельными выстрелами. Поэтому применительно к легким тестовым окружениям у нас появился термин «shot». Он идеально описывает их работу.

Сначала у нас этих тестовых окружений были десятки, сейчас — сотни. Например, через них мы реализуем A/B-тесты, которых за год у нас проходит около 350 за год. Без тестовых окружений такой цифры добиться бы не удалось.

Мы начинали Учи.ру на сервисе Heroku: это PaaS-продукт, облачная платформа, позволяющая работать по технологии NoOps. То есть продукт обслуживается без операторов, через полную автоматизацию. В результате снижаются затраты на поддержку IT-инфраструктуры. Благодаря Heroku мы целый год работали без администраторов.

Нам очень понравился опыт работы с PaaS, но со временем мы уткнулись в лимиты Например, в Heroku с какого-то момента мы не могли вытащить перфоманс кода, потому что платформа закрытая. Мы добавляли ресурсы, это сильно увеличивало стоимость, при этом выполнение запросов все равно было медленным. Кроме того, у нас не было доступа к настройке базы, поэтому она не справлялась с нагрузкой. А потом появился закон о локализации персональных данных. Возможно, привлекая специалистов Heroku и добавляя ресурсов, можно было улучшить продакшен, но стоимость в любом случае получалась катастрофической, поэтому мы переехали на IaaS — на огромную облачную инфраструктуру, публичное облако. И позже на базе этого IaaS мы построили собственный PaaS-продукт.

Сервисный подход и приложения

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

Монолитное решение, которое было очень простым и понятным, стало усложнять жизнь разработчикам. С него удобно начинать, его легко выкатывать и тестировать, поэтому на стартовом этапе лучше действительно все делать монолитом. Но по мере роста задач монолит с его громоздкостью становится неудобным и неэффективным. Разные функциональные элементы практически невозможно дифференцировать, они слишком крепко связываются друг с другом. Поэтому мы были вынуждены менять принцип работы

Мы обратились к сервисному подходу: он предполагает, что мы используем контейнеры и весь продукт разбит на приложения. Кабинет учителя — отдельно, кабинет ученика — отдельно.  Благодаря этому условные 50 IT-специалистов работают спокойно и обособленно, не мешая друг другу. Сейчас у нас больше 500 приложений, и если бы это все продолжало разворачиваться на монолите, мы бы не смогли сделать столько и реализовать их качественно.

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

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

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

Поэтому мы пробовали сегментировать входящий трафик на разные инстансы одного приложения. То есть, когда у нас было слишком много трафика, оно падало из-за активности пользователей, и мы порой не могли его поднять. Мы пробовали разносить нагрузку по разным контейнерам — например, главная страница отдается с одной группы, кабинет ученика с другой и так далее. Но это не решало проблему. В результате мы пришли к Circuit Breaker, который при достижении определенного уровня ошибок закрывает работу с сервисом, дает сервису прийти в себя и обратно запускает. Благодаря этому мы стабилизировали работу системы и увидели, как можно поддерживать высоконагруженный продакшн. А также поняли, насколько для крупной платформы с множеством задач сервисный подход и асинхронная архитектура удобнее монолита.

Переход на докер

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

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

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

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

К докеру добавился оркестратор — софт, который помогает управлять этим множеством мелких виртуальных машин. Он делает разработчика независимым от железа. Например, если сервер сгорит, оркестратор перекинет контейнеры на другие машины, развернет, проследит за совпадением версий ПО, все соединит и так далее.

Инфраструктурная платформа

Чтобы эффективно работать со всеми слоями архитектуры — физическими серверами, облаком, контейнерами — нужен дополнительный прикладной софт. Мы об этом задумались в 2017 году, когда столкнулись с «болезнью роста»: компания Учи.ру стала крупнейшим EdTech-проектом в России, стала активно осваивать международные рынки. У нас было очень много приложений и проектов, эффективно работать с ними становилось все труднее. 

Платформа становилась инфраструктурной, и мы начали искать решение проблемы масштабирования. Вместо подбора готовых решений мы разработали собственную программу — она называется «Шаман». Это UI-софт для управления облаком, надстройка над оркестратором, с помощью которого разработчики могут выполнять свои бизнес-задачи: поднимать тестовое окружение и микросервисные связки, выкатывать продакшены, поднимать контейнеры с заданными аргументами и многое другое.

Разработчикам не нужно углубляться в конфигурацию оркестратора: они просто указывают в «Шамане», какие контейнеры нужно запустить, с какими аргументами, и так далее. Это очень упростило все задачи и помогло их систематизировать и выполнять единообразно. Ядро «Шамана» писал я, на Ruby, позже его ребята почти полностью переписали на Go.

В итоге получилась простая цепочка: все приложения Учи.ру крутятся в контейнерах, ими управляет оркестратор — у нас это nomad. А над этим всем стоит «Шаман», который облегчает контроль над оркестратором и конфигурацию приложений для разработчиков. Название мы придумали шуточное в ответ на разные мемы о том, что IT-специалисты занимаются каким-то волшебством, шаманят. Мы думали, название будет временным, но оно закрепилось и стало постоянным.

Что будет дальше

За 10 лет IT как отрасль сильно изменилась: когда компания Учи.ру появилась на рынке, большинство продуктов были серверными, а из специалистов существовали только веб-программист и верстальщик. И в том далеком 2012 году мы оказались в числе первых, кто использовал инновационные идеи — облачные решения, докер, сервисный подход. Каждый раз на шаг мы опережали массовое применение этих технологий и играли на опережение.

Сейчас, на наш взгляд, индустрия IT достигла определенного плато. Новые технологии появляются и будут развиваться — искусственный интеллект, zero coding, блокчейн и метавселенные готовятся стать распространенным явлением, в том числе и в образовательных проектах. Но бизнес прагматичен, поэтому маловероятно, что в ближайшие 5 лет все инновации резко войдут в массовые продукты. 

Поэтому сейчас мы видим будущее нашей платформы в увеличении количества и качества контента. В росте числа пользователей и повышении отказоустойчивости, чтобы выдерживать этот трафик и сохранять платформу удобной для всех.

Приглашаем отпраздновать десятилетие вместе с нами и принять участие в викторине.

Вопросы посвящены истории онлайн-платформы и курсам. Присоединяйтесь к соревнованию и узнайте, почему нас выбирают более 10 млн российских школьников.