Top.Mail.Ru
 
Обсудить проект

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

DevOps
Stars Arena — децентрализованная социальная платформа (SocialFi) на блокчейне Avalanche. Мы отвечали за инфраструктуру и DevOps платформы, продукт разрабатывали команда клиента и дружественная компания-подрядчик. К началу подготовки продакшен уже работал с пользователями.

Задача:

Клиент готовил релиз токена и ждал наплыва пользователей. Нужно было подготовить продакшен: вместе с разработкой найти и устранить узкие места под нагрузкой, защитить сервис от ботов и DDoS-атак, не блокируя обычных пользователей, настроить мониторинг и сопровождать релиз. Ориентир для нагрузочных тестов — 2000 пользователей, одновременно заходящих на сайт.

На подготовку было около трёх недель, дату релиза по ходу сдвигали.

Итоги:

Вместе с разработкой мы устранили узкие места до релиза. Совместно с разработкой ускорили самый тяжёлый запрос ленты с 2000 до 30 мс. После этого тест на stage с 300 виртуальными пользователями прошёл без ошибок, а раньше не обрабатывалось и 10% запросов. Затем нагрузку довели до 2000 виртуальных пользователей — по нашей оценке, это более 200 запросов в секунду к API.

На релизе пик составил около 500 запросов в секунду, сервис отработал стабильно. Вместо единственного алерта появились дашборды и алерты на отказ сервиса, трафик пошёл через Cloudflare.

Период работы:

Октябрь 2024 года, около трёх недель

Команда:

2 DevOps-инженера, менеджер проекта; разработчики команды клиента и компании-подрядчика клиента

Инструменты:

  • Google Kubernetes Engine
  • Cloud SQL для PostgreSQL
  • Cloud Armor
  • облачный балансировщик нагрузки Google Cloud
  • Cloud Monitoring
  • Cloud Logging
  • Cloudflare
  • k6 Cloud

Решение:

Подготовку начали с общего планирования с разработкой: завели пакет задач по рискам релиза, к проекту подключили второго DevOps-инженера. Затем собрали факты о системе: обновления выкатываются без остановки сервиса (rolling-деплой), настройки приложения применяются только с перезапуском, stage по объёму данных подходит для нагрузочных тестов.

Код оптимизировала разработка, инфраструктуру и нагрузочные тесты вели мы. Узким местом был тяжёлый запрос к базе данных при открытии главной страницы и ленты. Совместно с разработкой мы нашли его и проверили исправление тестами: самый тяжёлый запрос ленты ускорился с 2000 до 30 мс. На время подготовки договорились о заморозке функциональности (feature freeze): в продакшен шли только исправления ошибок.

Что изменили в инфраструктуре

  1. Ресурсы. Увеличили ресурсы базы данных и кластера. К релизу работало автомасштабирование подов (HPA): Kubernetes добавляет копии приложения при росте нагрузки. Минимальное число нод и размер инстанса базы данных заранее подняли вручную.
  2. Защита без блокировки пользователей. Проверили правила Cloud Armor (WAF — фильтр веб-запросов) по логам за три месяца: ложных срабатываний не было, блокировались только боты. Нашли и исправили ошибку в настройке ограничения частоты запросов (rate-limit), из-за которой на пике могли пострадать обычные пользователи.
  3. Cloudflare. Нашли, почему при проксировании через Cloudflare сайт не открывался, исправили настройку и включили Cloudflare для продакшена: он кэширует ответы, а при атаке позволяет закрыть сайт проверкой браузера. Перед релизом под управление Cloudflare перевели основной домен. Режим проверки браузера (Under Attack) заранее включили на stage и ненадолго в продакшене: тестировщик разработки проверил вход и авторизацию на разных устройствах и в браузерах, после чего режим оставили в резерве на случай DDoS-атаки.
  4. База данных. Проверили, что реплика доступна только для чтения. По замечанию разработки ограничили время жизни зависших транзакций — сначала на stage, затем в продакшене. Облачный сервис не распределяет чтение между репликами, поэтому мы собрали свой балансировщик и проверили его на stage.
  5. Мониторинг. Вместо единственного алерта на число строк в логах собрали дашборды (запросы в секунду, время ответа бэкенда на балансировщике, ресурсы) и алерты на отказ сервиса. Ошибки приложения смотрели через представление (view) в Cloud Logging.

Как проверили

Тесты запускали в k6 Cloud — облачном сервисе, который генерирует нагрузку по сценариям. Сценарии повторяли путь пользователя: главная страница и лента, авторизация, открытие публикаций, запрос баланса токена. Stage по ресурсам примерно в десять раз меньше продакшена, для тестов его ресурсы подняли. Тесты проверяли исправления разработки и искали новые узкие места:
  • после оптимизации запроса ленты тест на 300 виртуальных пользователей прошёл без ошибок;
  • тест фронтенда показал, что под нагрузкой его поды перезапускаются и отдают ошибку 502: проверка работоспособности (health check) отвечала дольше допустимого. Мы увеличили время ожидания проверки, и перезапуски прекратились;
  • в финальных тестах нагрузку довели до 2000 виртуальных пользователей, по результатам подготовили отчёт о тестировании.

Релиз

Релиз сопровождали вместе с разработкой. Пик нагрузки составил около 500 запросов в секунду, фронтенд под нагрузкой больше не перезапускался, сервис отработал стабильно. После пика ресурсы кластера уменьшили.
Обсудить проект _
Если у вас есть ИТ-проблема, оставьте свои контакты, и мы поможем спланировать ее решение. Обещаем не рассылать спам.
Нажимая, я говорю «Да» конфиденциальности и соглашаюсь с обработкой персональных данных
hello@softwarecats.dev
Новосибирск, ул. Демакова
23/5, оф.308
Контакты _

Еще про наши проекты:

    • Главная
      →
    • Кейсы
      →
    • DevOps
      →
    • Подготовка инфраструктуры Stars Arena к релизу токена и наплыву пользователей