Рассказываем на примере, как проходит разработка высоконагруженного продукта, и как к высоким нагрузкам готовиться, чтобы в момент Х ничего не сломалось.

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

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

Слона ели по кусочкам

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

Проще говоря, мы «вытаскивали» блоки функциональности из старой платформы The Open, наделяли их новым флоу, ставили на максимально новую архитектуру, а затем «вставляли» обратно. Делали это бесшовно, чтобы пользователи не сталкивались с трудностями, пользуясь как бы «старым» сайтом, но с «новыми» функциональными блоками.

Продажа билетов

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

Аутентификация с Amazon Cognito

Amazon Cognito – это платформа управления идентификацией для веб- и мобильных приложений. В ней собраны каталог пользователей, сервер аутентификации и служба авторизации. Мы интегрировались с платформой для реализации сервиса регистрации и аутентификации The Open.

Раньше у пользователей было несколько логинов для покупки билетов, мерча. Мы реализовали единый логин – single sign on (SSO). Поэтому, например, покупать билеты и мерч, вставать в лист ожидания за билетами и смотреть эксклюзивные видео турнира стало проще.

4 дня в году и 0 прав на ошибку

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

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

Выяснили, что при любых обстоятельствах во что бы то ни стало должны работать четыре блока: регистрация, таблица лидеров, tee-times и видеоплатформа The Open TV, на которой происходит стриминг турнира.

Дальше, чтобы обеспечить отказоустойчивость, мы смоделировали все возможные варианты отказов работы инфраструктуры: 

• падение серверов, 
• падение БД, 
• замедление работы и отказы отдельных внешних API, 
• деплой некорректных изменений в коде. 

На основе этого списка рисков спроектировали архитектуру, которая предусматривала 

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

Дополнительно мы заранее обговорили и зафиксировали план реагирования и коммуникации на любую из возможных ситуаций. 

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

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

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

Забавная терминология

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

Тут в какой-то момент обсуждения один из коллег из The Open спрашивает: «А что если происходит sudden death (внезапная смерть)?». Обсуждение продолжается, кто-то из наших ребят спрашивает, частое ли это явление – внезапная смерть? Ему отвечают, мол, бывает – нормальная практика. В голове – ужас – неужели гольф в списке настолько опасных видов спорта?

Оказалось, что sudden death – это форма плей-офф в соревнованиях по игре на счет ударов, когда один или несколько игроков имеют одинаковое количество очков. “Внезапно умирают” те, кто закатывает шар в одну лунку за большее количество ударов. 

Как портал выдерживает большие нагрузки

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

Другой инструмент – Application Performance Monitoring. Это система, которую мы использовали, чтобы в реальном времени выявить страницы или запросы, части кода, которые работают недостаточно быстро, чтобы устранить проблемы. 

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

Увеличивать скорость загрузки страниц также помогало обширное кэширование данных на нескольких уровнях: базы данных, приложения и CDN. О нем мы также рассказываем в нашей статье про масштабирование IT-продуктов. Для The Open кэширование делали очень гибким, с большим количеством правил, например, для часто обновляющихся разделов, новостей и видео. 

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

Итоги

Полноценная переработка платформы The Open была проведена примерно за год. Все это время мы постепенно вводили в эксплуатацию новые функциональные блоки так, что со временем портал полностью обновился.

С точки зрения архитектуры платформа The Open построена на нескольких интеграциях и элементах:

• сайт на CMS;
• сервис аутентификации Amazon Cognito;
• API с данными о ходе турнира;
• билетная платформа Securix;
• видеоплатформа Stream AMG;
• ecommerce платформа;
• мобильное приложение;
• CDN.

Платформа The Open работает уже не первый год. Турниры до сих пор освещаются с ее помощью. 

Успешное завершение проекта мы с командой разработки поехали отмечать в Pine Creek – гольф-курорт, где все изученные в ходе проекта правила гольфа удалось применить на практике и прочувствовать, что такое настоящая игра.