Сложная архитектура простых приложений
По мотивам Adidas Running (ex. Runtastic)
Runtastic
Опыт Адидас по развитию e-commerce и систем электронных соревнований. В 2012–2020 годах Адидас смог развить e-commerce с нуля до 20% от суммарных продаж. Из них 20% благодаря таким системам продвижения.
Как я бы создавал архитектуру этого приложения.
Обоснование и количественные оценки влияния таких архитектурных решений как: microservices, data lake, data mesh, CQRS, Saga.
Предыстория
Рынка систем электронных соревнований (в 2012 г) нет, но есть огромный интерес к спортивному образу жизни и к соревнованиям. В США не менее 50 миллионов (!) человек (это примерно 15% всего населения) хотя бы раз в неделю выходят на пробежку.
Адидас имеет объем продаж 20–30 млрд долл. в год.
Основной рынок — США, остальные страны — второстепенные рынки.
Цели приложения
1. Стимулирование людей соревноваться с собой и другими.
Показатели:
Количество участников 50 млн человек
Активность соревнований: 200 млн групповых соревнований в год,10 млн активных трекеров, 100 млн индивидуальных планов тренировок в год
Активность соцсетей: 10 млн активных пользователей (от 1 сообщения в месяц)
2. Стимулирование продаж: через формирование образа бренда — фаворита при выборе товаров, через прямые предложения продаж и рекламу товаров в приложении
Показатели: объем продаж через интернет канал до 20% от общих продаж бренда
Соревновательный компонент в интернет-канале стимулирует продажи e- commerce на 20% (остальное — сила материнского бизнеса) = потенциальный эффект до 1 млрд. долл. продажи и принесет до $200 млн прибыли в год.
Целевой срок 5–8 лет.
Требования пользователей
Перечень возможностей для пользователя:
Участвовать в забеге, имея
Трекинг
Голосовой помощник
Информацию о месте в забеге и о лидере забега
Статистику забегов (в т. ч. улучшение своих результатов)
Вызовы
Планы тренировок (включая рекомендации по экипировке)
Возможность создания и присоединения к забегам
Возможность создания и присоединения к социальным группам по интересам.
Возможность поделиться в группе или всем информацией о своих достижениях, историях, экипировке.
В ходе эксплуатации будут выявляться новые требования. Требования могут быть короткоживущими — на рекламную акцию и даже на мероприятие. Поэтому у нас предполагается огромный поток требований и изменений.
Нужны средства разработки плагинов средствами комьюнити. Например, озвучка различными голосами на разным языках. Довольно большая ставка на внешние разработки плагинов и микросервисов на основе обработки данных пользователей.
Функциональные требования
Система должна
собирать требования и метрики от активных участников, показатели, получаемые при проверке гипотез, сообщений на форумах и обратной связи на фокус-группах
обеспечивать гибкое и дешевое создание нового функционала для проведения десятков проверок A/B гипотез в день (короткоживущий или локальный гибкий функционал)
интегрироваться с фитнес-функциями телефона, а также с устройствами типа фитнес трекеров / браслетов (легко расширяемый список типов устройств)
возможность хранения необработанных данных различного формата (data lake) с фитнес трекеров и датчиков для гибкого развития алгоритмов их обработки (ETL — Extract, Transform, Load) и доступа к данным из различных компонентов (data mesh)
поддерживать использование по всему миру, включая регионы, где нет нативных пользователей, но могут приезжать группы для тренировок в «диких» местах. В частности:
сохранение и публикацию маршрутов и достижений, ранее пройденных участниками
импорт маршрутов и достижений не участников из внешних источников данных
обеспечивать выплаты и иные поощрения за формирование требуемых карт маршрутов, контента, иных услуг по развитию и продвижению системы
Нефункциональные требования
Система должна
развиваться быстрее конкурентов, быть лучшим решением на высококонкурентном рынке
быть масштабируемой до десятков миллионов пользователей
поддерживать возможность и обеспечивать высокую производительность при проведении соревнований с большим количеством участников.
обеспечивать высокий уровень безопасности и защиты пользовательских данных.
Ограничения
Основной тип соревнований ограничен возможностью фиксации результатов, а именно трекеров и датчиков телефонов (место и высота, скорость, шаги, пульс). Поэтому соревнования ограничены такими типами
Бег, ходьба
Туризм, посещение труднодоступных либо популярных мест
Велосипед
Моторизованные виды спорта: автомобиль, мотоцикл
Ubiquitous Language
Достижение
Соревнование (событие, участники, результат)
Экипировка
Маршрут
Организованное мероприятие
Координаты
Трекинг прохождения
Группа
Тренировка
Программа тренировок (план, подсказки, аудио ментор / ИИ тренер)
Пользователь
Промо
Устройство (телефон, фитнес браслет, наушники и т. п.)
Биологический показатель (пульс и т. п.)
Выплаты (призовой фонд, поощрения за новый маршрут, донаты и т. п.)
Мультимедиа (фото и видео, которые можно привязать к достижению, маршруту, группе, пользователю или просто хранить и обмениваться между участниками)
Stakeholders
Интересы и выгоды. Что ожидают получить разные группы стейкхолдеров? Поскольку это не заказной продукт, а тиражируемый, то основной стейкхолдер — пользователь различного типа: индивидуальные тренировки, групповые, профессиональные, блогер. Для каждого типа пользователей свой интерес.
Владельцы компании — выгоду от инвестиций
Пользователи
увидеть свои достижения, индивидуальные и групповые, похвастаться
индивидуальные тренировки: достигнуть цели, соревноваться с собой
групповые тренировки: выиграть забег
туризм: пройти маршрут, достигнуть целевой точки
профи/рекордсмен: записать рекорд, получить ачивку (achievement) как в игре
блогер: рассказать о соревнованиях широкой аудитории
Продажи — рост продаж в e‑commerce сегменте
Маркетинг — средство повышения лояльности к бренду, развитая аналитика
Бизнес‑партнеры — рост продаж в коллаборации с основным брендом
Внешние разработчики — монетизация
Атрибуты качества (компания концентрируется на…)
Расширяемость функционала
Удобство
Безопасность
Масштабируемость
Интегрируемость с другими системами
Концептуальная архитектура
30,000 Foot View
Основные домены (на 1-й год развития продукта)
© draw.io
Базовая архитектура
10,000 Foot View
Домены:
Соревновательные
Соревнование
Маршрут, ИИ тренер, Достижения личные / групповые (ачивки)
Трекинг
Трекинг — данные приборов (пульс, шаги, геометки)
Социальные
Личный кабинет (учетные данные), Новости и промо, Организатор, Сообщество
Экипировка
Покупки, Экипировка (виртуальный шкаф),
Финансовые
Подписки, Платежи
Внутренние процессы
Маркетинг
Администрирование
Аналитика
Основной кейс: выбрано соревнование, выбраны участники, время проведения и маршрут. Участнику помогает ИИ тренер (голосовые подсказки). Организатор (опциональный) следит за выполнение правил, за безопасностью и общим процессом организации. Участник в ходе соревнования может видеть и слышать свои успехи и сравнивать их с результатами других участников, а также рекордами аналогичных соревнований.
Домен маршрут включает как плановые, так и фактические метки (координаты и время). Достижение — это посещение места, финальной точки. Достижение может быть реализовано несколькими маршрутами.
Домен достижение это целевая точка (и) маршрута и история ее достижений. При выборе маршрута (перед соревнованием и при туризме) можно смотреть и выбирать на карте похожие пути достижения целевой точки.
В случае если это не бег, а силовые тренировки, достижение это количественные показатели (вес штанги и т. п.). Но это не основной сценарий использования.
Схема взаимодействия всех доменов слишком сложна, поэтому приводятся только фрагменты, реализующие основные варианты взаимодействия.
Потенциальные проблемы: распределенные транзакции. Например, при оплате подписок потребуется обработка платежными системами. Для борьбы с недостатками распределенных транзакций используем оркестратор либо sidecar с логикой повторов, обработки ошибок и отмены распределенной транзакции.
Для синхронизации возможные варианты решения:
2-х фазный commit
CQRS
SAGA
и др.
Ввиду требований к скорости обработки и надежности — рекомендуется шаблон SAGA [1] [2]
Диаграмма компонент
Основные домены (на 1й этап)
Полная схема (все домены)
Архитектурные опции и основание выбора
ADR (на 1-м этапе проекта, в 1-й год)
Бизнес решения
Название ADR: целесообразность реализации собственной соц. сети.
Статус: принято.
Контекст: на 1й стадии проекта нет определенности нужно ли создавать свою социальную сеть и какие функции в нее вносить.
Решение: реализовать минимальный функционал (поиск людей по id, просмотр их достижений) и использовать другие соцсети, перетаскивая функционал к себе по мере уточнения что затребовано. Возможно, сразу потребуется общий голосовой чат через гарнитуру, т. к. общение текстом при соревновании затруднительно).
Последствия: риск, что отсутствие важных функций соцсети замедлит распространение программы. Но на 1-м этапе это не важно. На основе опыта эксплуатации определить, какие функции нужны ко 2-му этапу.
Технические решения
Название ADR: Выбор архитектурного шаблона
Статус: Adidas принял решение 2 — с его то ресурсами…
Контекст: Огромное количество изменений (десятки в день) продукта, краткосрочные изменения с актуальностью в дни и недели. Требуется быстрый CI / CD (до 10 минут на экземпляр / инстанс, до 30 минут на все экземпляры).
Микросервисы тут необходимы и безальтернативны, но дорогостоящи.
Решение1: монолит + микросервисы в минимально достаточном количестве. Не решайте проблемы, которых у вас нет.
Решение 2: монолит как MVP и сразу разрезаем на микросервисы в большом количестве. Для роста скорости изменений продукта сразу вкладываемся в инструментарий микросервисов и раздуваем команды.
Первые кандидаты в микросервисы (после подтверждения критериев):
Сбор и обработка данных с датчиков (как самый нагруженный). Критерий выделения: необходимость распределенной архитектуры (более 50vCPU в пике без учета СУБД — этого хватит для обработки 100К датчиков на сервере одновременно) и подтвержденные экспериментально низкие риски от микросервисов, например, низкие задержки из-за асинхронности, сети и т. п. — критичное время обработки геометок не более секунды, в монолите с этим проще. Поэтому сначала переносим только некритичную к задержкам часть — обработку исторических данных, затем сервис онлайн обработки потоков данных датчиков. А там по ходу дела посмотрим, стоит ли переносить остальное.
Для обработки данных с датчиков предполагается использовать CQRS: Пусть данные ранее обрабатывались и хранятся в одном кластере, но кластер перегружен и далее данные этого трекера будет обрабатывать новый кластер. Тогда для исторических данных (редко используемых) имеет смысл использовать общее хранилище (Query), а для текущих данных локальное хранилище (Command).
CQRS + кластеры
Из-за трудности прогноза нагрузки на систему (число пользователей, пиковые часы) сервис имеет смысл вывести в облако (AWS или аналог). Дальнейшее развитие в зависимости от размера (на 1-й год прогнозируются пиковые потребности в 1000 vCPU) и равномерности нагрузки. Нагрузка скорее всего будет крайне неравномерной, так что в облаке и останется.
Организации соревнования (как самый быстро развивающийся, функционал) с целью облегчения CI / CD). Критерий выделения: неудобство обновления монолита — например, длительный разогрев кешей в других частях приложения, которые не нужно было обновлять и падение их производительности после обновления, либо длительный процесс самого обновления (большой размер или кривая процедура обновления).
Микросервисы имеют много недостатков. По исследованиям, переход на них на простых проектах (до 10 человеко-лет) увеличивает трудоемкость разработки в 1.5–2 раза. Однако, микросервисы позволили бы масштабировать команду разработки.
Trade-off
Увеличение скорости разработки в 2 раза ценой увеличения команды и затрат в 5 раз. Бизнес, подумай хорошенько!
Международные компании с огромным бюджетом на конкурентном рынке могут себе это позволить.
Если не учитывать требования к скорости разработки, то по ощущениям точка пересечения графиков на уровне 100 человеко-лет (для PHP и мультиязычных команд раньше из-за трудностей обновления фреймворков и библиотек, для C# / Java позже). Чем выше требования к скорости (на конкурентном рынке) тем раньше наступает точка пересечения графиков.
Стоимость изменений кода в зависимости от роста сложности проекта
Название ADR: хранить только обработанные данные или сырые?
Целесообразность Data lake
Статус: принято.
Контекст: различный формат данных с разных источников, развитие алгоритмов обработки данных (фильтрации ошибок, агрегации). Для корректного (одним алгоритмом) сравнения старых и новых маршрутов и соревнований потребуется повторная обработка старых данных новыми алгоритмами. Также не хорошо терять данные личных забегов при смене пользовательского устройства, нужно хранит их на сервере с привязкой к id пользователя.
Решение: для хранения сырых данных разного формата, без валидации и агрегации потребуется Data Lake. Дальнейшая обработка данных в ETL и хранение в Data warehouse. Кроме доменных потребуются корпоративные данные = дата продукты. Способ реализации — через data mart (витрины данных).
Последствия: большое количество передаваемой и хранимой информации, потенциальные угрозы безопасности ввиду конфиденциальности данных трекинга тренировок. Поэтому должна быть возможность удаления всей или части информации трекинга с сервера — по требованию или по расписанию. Информация на сервере должна быть деперсонализирована (нельзя сопоставить ФИО и трекинг).
Название ADR: целесообразность data mesh (нескольких команд для работы с data warehouse и data mart).
Статус: принято.
Контекст: сложность проектирования data warehouse и проблемы ответственности за данные.
Решение: вместо централизованного data warehouse мы будем создавать независимые и автономные наборы данных, имеющие собственную ценность и стоимость.
Спортивные организации: анализ результатов, оценка производительности, определение трендов.
Тренеры и спортсмены: анализ производительности, выявление сильных и слабых сторон, индивидуальные тренировочные программы.
Путешественники и туристические компании: планирование маршрутов, оценка популярных мест, персонализация предложений.
Сервисы для здоровья и фитнеса: рекомендации тренировок и диет, отслеживание физической активности, мотивация пользователей.
Последствия:
Гибкость и масштабируемость обработки данных.
Большая автономия и производительность команд.
Улучшенное качество данных и аналитические выводы.
Изменения в организационной структуре и процессах.
Дополнительные затраты на обучение и инфраструктуру для управления данными.
План разработки
Первый удобный продукт (полгода разработка, год эксплуатация) — простые сервисы, отработка концепции, удобство, интерес
Захват рынка виртуальных спорт соревнований (2–3 года) — конкурентная борьба, персонализированное взаимодействие с пользователем (и значит множество A/B гипотез), расширение до десятков миллионов пользователей, сложные сервисы, много разных данных
Коммерциализация (5 лет) — эксперименты по коммерциализации нашли путь от сердца к кошельку
Выделение критических бизнес-сценариев для 1-го этапа.
Как бегун я хочу
Отслеживать свои пробежки и получать точную информацию о расстоянии, времени, скорости и пути, чтобы анализировать свой прогресс и достигать своих целей.
Иметь возможность установить себе цели по пробежкам (например, определенное расстояние, время или количество калорий), чтобы мотивировать себя на достижение новых результатов.
Иметь доступ к персонализированным тренировкам и планам, чтобы улучшить свою физическую подготовку и достичь определенных беговых марафонов или соревнований.
Получать уведомления и мотивационные сообщения во время пробежек, чтобы поддерживать мотивацию и настроение.
Иметь возможность просматривать свою историю тренировок, чтобы отслеживать свой прогресс на протяжении времени и сравнивать результаты.
Иметь доступ к сообществу и возможность делиться своими достижениями, фотографиями и тренировками с друзьями или другими участниками, чтобы получить поддержку и вдохновение.
Иметь возможность интегрировать приложение с моими устройствами для измерения сердечного ритма, шагов или других физических показателей, чтобы получать более полную информацию о своих тренировках.
Иметь возможность создавать собственные тренировки или маршруты, чтобы адаптировать тренировки под свои индивидуальные потребности и предпочтения.
Получать рекомендации и советы по улучшению техники бега, чтобы избежать травм и повысить эффективность тренировок.
Иметь доступ к погодным условиям и прогнозам, чтобы выбрать наилучшее время и место для пробежки.
Как член команды соревнования я хочу
Иметь возможность зарегистрироваться онлайн для участия в соревновании, чтобы упростить и ускорить процесс регистрации.
Получить информацию о маршруте, времени начала и правилах соревнования, чтобы быть готовым и планировать свою участие.
Иметь доступ к результатам и рейтингам соревнования, чтобы отслеживать свои достижения и сравнивать их с другими участниками.
Как организатор соревнований я хочу
Распространять новости / анонсы соревнований
Создать онлайн-регистрацию для участников, автоматизировать процесс регистрации.
Предоставить участникам информацию о маршруте, времени начала и правилах соревнования, чтобы обеспечить их готовность и безопасность.
Иметь систему для учета результатов и составления рейтингов, чтобы предоставить участникам обновленную информацию о их достижениях.
Как разработчик / аналитик я хочу
Собирать обратную связь: предоставьте пользователям возможность отправлять обратную связь непосредственно через приложение или веб-сайт.
Организовать опросы и исследования: проводите опросы или исследования среди пользователей, чтобы получить более конкретные данные о их требованиях и предпочтениях. Через приложение и соц. сети.
Создать механизм отслеживания ошибок и запросов на функции.
Отдельные вопросы
Синхронизация данных
Синхронизация данных от разных бегунов или одного бегуна в разных забегах. Чтобы показывать взаимное расположение бегунов в забеге нужно сравнивать геометки с разными координатами и на разные моменты времени. Таким образом, голосовые подсказки («вас догоняет бегун №12» или «вы бежите лучше, чем вчера на 5 метров») должны адаптироваться под точность геометок, их частоту, время обработки их на сервере и время доставки от и до клиентского устройства.
Инфраструктура.
Несколько кластеров регионально приближенных к скоплениям потребителей. Возможность переключения устройств от одного кластера на другой.
Безопасность
Защита приватных данных
Пример: скандалы с утечкой данных о фитнес трекерах военных.
Принципы: хранение и передача данных по белому списку, предельные сроки хранения, сброс данных по желтому коду опасности — по требованию пользователя или подозрению о компрометации пароля и т п.
Сервисы по сканированию уязвимостей: Nessus, NMap
Сервисы по анализу сетевого трафика и обнаружению сетевых вторжений: Metasploit
Диаграммы потоков данных
© Visual Paradigm
Минимальный вариант
Диаграмма потоков данных
Время обработки: датчики → маршрут <= 1 сек, маршрут – озвучивание <= 1 сек
Риски проекта в целом
1. Невозможность переноса спортивного опыта и ощущений в виртуал (любят бегать, но с приложением не интересно и т. п.):
Идентификация риска: Аналитика, опросы.
Стратегия работы с риском:
Обеспечение обучения и поддержки: Предоставление пользователю необходимых ресурсов, инструкций и обучения по использованию виртуальной среды для максимального использования спортивного опыта.
Регулярный обратный отзыв: Сбор обратной связи от пользователей, выявление проблем и недостатков, а также внесение улучшений в виртуальную среду на основе этой информации.
2. Конкуренты будут быстрее:
Идентификация риска: Скорость изменений, распространённость приложения
Стратегия работы с риском:
Непрерывное исследование рынка: следить за изменениями в индустрии, изучать действия конкурентов и определять, какие инновации и улучшения могут быть применены в проекте.
Сосредоточение на уникальных преимуществах: Создание уникального предложения, которое отличается от конкурентов и предоставляет дополнительную ценность для пользователей.
3. Скандалы с приватностью данных:
Идентификация риска: оценка устойчивости к взлому и утечкам приватных данных, разделение данных на группы по критичности утечки.
Стратегия работы с риском:
Разработка политик и процедур безопасности: Установление строгих правил и мер безопасности для защиты данных пользователей.
Регулярные аудиты и тестирования: Проведение регулярных проверок системы безопасности, а также тестирование на уязвимости, чтобы выявить и устранить потенциальные уязвимости.
Стоимость владения
1й этап
Прогнозная нагрузка до 1 млн активных трекеров (10% от конечной цели)
Как бы там ни было, но грубые оценки показывают, что понадобится хранилище по 1–10 мегабайт на соревнование (принято решение информацию от трекеров не удалять и не огрублять), понадобится примерно 1 vCPU в облаке на 1000 активных трекеров — серверы приложений и СУБД (при масштабировании до 1 млн трекеров = 1000 vCPU = ~50 серверов) на 1-й этап. Пиковая нагрузка 3–4 часа в день. Оценка стоимости облака $200.000 в год.
Если не готовы сразу к таким тратам, то ограничение числа пользователей, распространение через закрытые группы.
Длительность первого этапа эксплуатации — 1 год.
Затраты за 1й год 1 млн $, Коммерческий эффект нулевой
2й этап — усложнение сервисов, частичное масштабирование
Затраты за 2–4 годы от 5 до 15 млн $ в год, Коммерческий эффект минимальный
Конечный этап — с 5 по 10 годы после старта проекта
50 млн пользователей, до 10 млн трекеров одновременно, 10 млн трекер-часов в сутки.
Затраты на железо 5 млн $ ежегодно на облако.
Затраты на софт 20 млн $ в год. 60% из них это оплата труда гросс, 40% накладные расходы — офис, лицензии на ПО и т. п.
Основной поток разработки — A/b тестирование гипотез, таргетированный подход к сотням групп пользователей, поддержка маркетинга
Команда 50 человек. 15 разработчиков, 10 тестировщика, 10 аналитика, 15 остальных (CI/CD, админы БД, менеджмент, маркетинг, администраторы соцсетей…). 30% команды в США с высокими расходами на оплату труда. Большой поток доработок по кратковременному функционалу — даже на отдельные крупные мероприятия, ~10 доработок в день.
Затраты на продвижение и рекламу 10 млн $ в год. Я бы тут не экономил: риски что конкурент обойдет высокие и не полностью связаны с качеством продукта.
Оплата внешним подрядчикам (платная организация мероприятий, оцифровка трекинга и медиаконтент соревнований и туристических маршрутов) 7 млн $ в год.
Итого в год 5 + 20 +10 + 7= 25 млн $.
Прогнозный коммерческий эффект 200 млн $ в год (см цели). 5 лет вкладываем без прибыли, но потом получаем хороший эффект на фоне высоких рисков. Если не получили 5 млн пользователей, то проект не взлетел и его можно закрывать.
