Мы запускали проект, когда вокруг все смирились с пандемией, а за ней и с повсеместной удаленкой. В таких обстоятельствах создание платформы для дистанционного доступа к образовательным курсам казалось естественным решением. Плюс, у сервиса есть социальная составляющая: доступ, который школьникам дает платформа, — бесплатный. А среди образовательных площадок, интегрированных в проект, Skysmart, Uchi.ru, Сберкласс и другие. 

И так проект «Цифровой образовательный контент» начался в 2021. Мы занимались его разработкой полтора года. В этом материале рассказываем, как прошло и что получилось. 

«Создание платформы для онлайн-доступа к образовательным курсам». А расшифровать? Если широко, то мы разрабатывали механизм, открывающий учащимся бесплатный доступ к образовательному контенту от ведущих российских edtech-площадок. 

Фактически это витрина с бесплатным доступом к образовательным площадкам, их курсами и базой школьников. Площадки – их на данный момент 19 – подключаются к сервису через API и размещают на витрине курсы. 

Образовательные площадки делают это не просто так: за предоставленный контент им платит государство. Проект создан  в рамках национальной программы «Цифровая экономика Российской Федерации»

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

Идея и ТЗ проекта  — результат совместной работы АНО ВО «Университет Иннополис» и Министерства просвещения РФ. Нам повезло реализовывать.

К главному

У нас были необходимые свободные специалисты, поэтому мы быстро укомплектовали команду, провели онбординг. Приступить к работе получилось сразу, поэтому первый релиз случился через месяц. В периоды высокой нагрузки численность команды увеличивали до 17 человек.

Для упрощения коммуникации назначили лидов по каждому направлению: фронт, бэк, тест. Каждый отдельно собирал и доносил информацию до своей команды.

Несмотря на фиксированные сроки и бюджет, использовали методологию Scrum со спринтами. 

Давайте смотреть. Все началось с UI-кита

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

В процессе система эволюционировала. Мы заметили, что учителя не просто авторизуют своих учеников, но и используют эти курсы для преподавания.  

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

У проекта микросервисная архитектура. Каждый микросервис написан на java с использованием фреймворка spring boot. Также наши мастера бэкенда сообщили, что важно отдельно упомянуть 5 самых интересных, на их взгляд, технологий проекта: 

• SSO (Single Sign-On) — бесшовная авторизация, протокол oauth 2
• Spring Batch для пакетной обработки данных
• SSE (Server Sent Events) для отправки уведомлений от сервера к клиенту
• Docker Swarm для кластеризации сервисов по серверам(виртуальным машинам)
• EFK (elasticsearch + fluentd + kibana) для логирования системы

Теперь по порядку:

Про SSO

SSO — это бесшовная авторизация. Та самая технология, которая позволяет вам зарегистрировать, например, Google-аккаунт, а после использовать его для входа на сторонние сервисы. Так вот SSO изначально не планировалось. Был простой концепт платформы как хранилища ссылок на образовательные платформы. В таком случае всю информация о пользователе образовательные площадки получали через ссылки: мы вшивали в них смарт-коды. 

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

На своей стороне мы подняли авторизационный сервер. Далее через наш сервис происходила авторизация сразу на всех 19 образовательных площадках.  

Проблема этого этапа — синхронизация с площадками. Не все были знакомы с SSO: из 19 были готовы 6. Приходилось прорабатывать механизм подключения с каждым сервисом отдельно. Для кого-то мы организовывали песочницу, где можно было безопасно поэкспериментировать перед подключением. Подготовили документацию, в которой описали интеграцию с нами.

Spring Batch и тяжеловесная аналитика

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

Изначально мы просто копили эту информацию. К марту 2022 у нас уже было порядка 30 млн записей, в ноябре — 80 млн. Конечно, информация собиралась не просто так. Мы упоминали, что площадки получают оплату за предоставление контента. Так вот сбор статистики и помогает правильно рассчитывать выплаты. Например, одно из условий — пользователь 3 раза посетил курс. 

Теперь вернемся к тому, что число пользователей площадки — 10 млн, а число запросов в секунду доходило до 1000, поэтому нужно было найти решение для адекватной обработки такого количества данных, чтобы системе не стало плохо. 

Мы остановились на Spring Batch. Технология позволяет взаимодействовать не с каждой записью отдельно, а с пакетами. Например за месяц мы добавили 20 млн записей об активности пользователей. Берем по 500 штук и обрабатываем.

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

Расчет выплат и сбор статистики проводили по ночам. Это могло занимать до 12 часов.

Docker Swarm, серверы и работа с нагрузкой

Наша система развернута на 3 серверах, которые делятся на несколько виртуальных машин. Чтобы распределить нагрузку, мы запустили 5 экземпляров нашего сервиса. В этом случае условная тысяча запросов делится на 5 разных сервисов. Это не только про перераспределение ресурсов, но и про страховку. Если один упадет останется еще 4.

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

Для кластеризации сервисов по серверам использовали Docker Swarm. Было много споров об этом, и мы понимаем, что есть более современные технологи, вроде Kubernetes, но решили, что простота, которую дает swarm, — важнее.

Мы хостились на своих серверах. Еще и поэтому настроить docker swarm было проще, чем Kubernetes. Были проблемы с настройкой overlay сети поверх vlan, но разобрались. В итоге swarm помог нам выдерживать более высокие нагрузки. Плюс мы много работали над тюнингом самих баз и оптимизацией запросов.

SSE и постоянная связь с площадками

Привязали SSE. Это мало используемая технология для отправки уведомлений от сервера к веб-браузер. Дальше будет яснее.

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

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

Делали через SSE(Server Sent Events). Технология для отправки уведомлений от сервера к клиенту. Платформы установили долгое соединение с нами, а уже через это соединение мы эффективно можем менять любые статусы и оперативно оповещать об этом платформы. 

Когда происходят события: удаление, изменение статуса или добавления курса. Мы отправляем информацию через SSE. 

Логирование и EFK

Технические моменты. Мы подключили комплекс из нескольких инструментов, помогающих отслеживать работоспособность системы. С его помощью мы логировали все обращения пользователей, отправляли в Elasticsearch. У нас был один общий интерфейс — Kibana. В нем можно производить поиск по запросам пользователей, выяснять на каком этапе что-то рухнуло. Отдельно следили за нагрузкой каждой платформы. 

Проект был сложный, но в том числе поэтому он многое дал команде. Это был огромный опыт взаимодействия с государством и непростой системой приемо-сдаточных мероприятий. Несмотря на это, мы подключили 10 млн пользователей и обеспечили для них комфортное получение знаний. К платформе подключены 19 топовых образовательных площадок, которые предоставили 1300 курсов. Ресурсом пользуются по всей стране.