Опыт разработки федерального edtech-проекта "Цифровой образовательный контент"
ЗаказчикАНО ВО «Университет Иннополис» — образовательная организация из Иннополиса — самого молодого города России, в которой занимаются образованием и исследовании в области информационных технологий.ЗадачаРазработать сервис для бесплатного доступа школьников и студентов к образовательному контенту.
С нами случился высоконагруженный и полезный проект. Технократия по заказу АНО ВО «Университет Иннополис» разработала сервис для бесплатного доступа школьников и студентов к образовательному контенту. Собрали под этот проект классную команду и сделали образование онлайн доступнее.
Мы запускали проект, когда вокруг все смирились с пандемией, а за ней и с повсеместной удаленкой. В таких обстоятельствах создание платформы для дистанционного доступа к образовательным курсам казалось естественным решением. Плюс, у сервиса есть социальная составляющая: доступ, который школьникам дает платформа, — бесплатный. А среди образовательных площадок, интегрированных в проект, 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 курсов. Ресурсом пользуются по всей стране.
Перейти на сайт
Полный текст статьи читайте на CMS Magazine
