Подготовка инфраструктуры Stars Arena к большому наплыву пользователей

Наш клиент компания Stars Arena - это децентрализованная социальная платформа (SocialFi), построенная на блокчейне Avalanche, которая позволяет пользователям монетизировать своё влияние и взаимодействовать с аудиторией через покупку и продажу «билетов» (Tickets), представляющих собой токенизированные доли профилей пользователей. Эти билеты предоставляют доступ к эксклюзивному контенту, таким как закрытые чаты и приватные публикации.

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

4-й квартал 2024 года

Разработчики фронт/бэк, 2 DevOps-инженера

Как только мы получили информацию о том, что ивент состоится, мы начали подготовку.

Мы знали, что текущее узкое горлышко - это запросы к БД со стороны фронтенда, при подгрузке ленты.

Работы решили проводить следующим образом:

1. Проанализировать текущие запросы к БД, найти наиболее тяжелые.
2. Поправить эти запросы силами разработки.
3. Провести нагрузочное тестирование.
4. Проанализировать полученные данные, зафиксировать и поправить узкие места и точки, не поддающихся масштабированию.
5. Так как у нас было достаточно жесткое ограничение по времени - исправление только критичных мест.

Анализ текущих запросов к БД показал, что при переходе на главную страницу генерируется очень долгий и тяжелый запрос к БД. Даже при заходе 100 одновременных пользователей этот запрос мог привести к отказу сервиса.

Этот запрос с высоким приоритетом был передан разработчикам для рефакторинга и ускорения.

Команда же DevOps инженеров начала готовить инфраструктуру.

Мы обновили пул нод у прод кластера, заменив тип нод на более мощные, что позволило нам выделить больше ресурсов на каждый из подов. На тот момент у нас уже был реализован и работал авто скейлинг (HPA + Node autoscaling), что в итоге позволяло нам поддерживать приложение в рабочем состоянии даже в момент пиковых нагрузок без участия инженеров. Помимо прочего, нами было принято решение подключить проксирование через Cloudflare, которое помогло бы нам быстро отреагировать на DDoS.

Последнее что мы сделали - мы определили  предполагаемый пользовательский путь и с помощью сервиса K6 сгенерировали необходимую нагрузку. По результатам повысили доступные ресурсы для k8s кластера и БД.

Мы убедились что:

1. Оптимизация, сделанная разработчиками работает корректно.
2. Мы можем выдерживать планируемую нагрузку, и есть запас.
3. Авто скейлинг отрабатывает корректно.

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