한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Анатомия игровых лагов › L13 Архитектура и эксплуатация серверов

Задержка автомасштабирования Autoscaling lag

ID причины in-autoscale · Основной ответственный Команда инфраструктуры · Серверная инфраструктура · Совместно Команда разработки · Разработка сервера

Открыть карточку в основной версии с иллюстрациями и экспериментами →

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

Почему Резкий рост подключений со стартом события → Следствие Несколько минут, пока новый сервер запустится и будет готов → На экране Первые несколько минут после старта события слоумо и ошибки входа

Симптомы
Слоумо, Ошибка входа / бесконечная загрузка
Факторы
Остановка
У кого
Весь сервер
Когда
При наплыве игроков, Сразу после входа или техработ
Ответственные
Основной ответственный Команда инфраструктуры · Серверная инфраструктура · Совместно Команда разработки · Разработка сервера
Команда разработки: задачи
Распределять игроков по каналам (тех, кто уже сидит в переполненном канале, на новый сервер не перенести), сократить время старта и загрузки данных на новом сервере.
Команда инфраструктуры: задачи
Масштабировать заранее до события, держать прогретые резервные серверы, при сокращении выключать сервер только после ухода оставшихся игроков.
Цифры для ориентира
На обнаружение нагрузки уходит от 1 до нескольких минут (метрики усредняются за несколько минут), ещё несколько минут на запуск нового сервера, чтение игровых данных и заполнение кэша.
На графике
Всплеск сразу после входа или техработ · число инстансов, загрузка CPU, очередь на вход
Где смотреть
Наложить журнал автомасштабирования (момент решения о масштабировании и момент ввода нового инстанса в работу) на графики загрузки CPU и числа подключений. В AWS смотреть метрики группы Auto Scaling (видны, только если их включить) GroupDesiredCapacity (целевое число), GroupPendingInstances (готовятся) и GroupInServiceInstances (в работе)
Подтверждает
Несколько минут после всплеска подключений растут только целевое число и число готовящихся инстансов, а CPU существующих серверов держится у лимита и отпускает с того момента, когда растёт число инстансов в работе
Опровергает
Если и после ввода новых инстансов всё тормозит, причина не связана с числом серверов (общий ресурс вроде БД, каскадный отказ)
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Подробнее
Автомасштабирование обычно применяют там, где новых игроков достаточно принять на новом сервере: авторизация, шлюзы, данжи. Проблемы бывают и при сокращении. Если ночью, когда игроков мало, выключать лишние серверы, не дожидаясь ухода оставшихся игроков, у этих игроков будет дисконнект.
Реальные инциденты
AWS 2021: Перегрузка внутренней сети AWS us-east-1
AWS 2025: Сбой DNS DynamoDB в AWS us-east-1 и долгое восстановление

Источники

  1. Target tracking scaling policies for Amazon EC2 Auto Scaling AWS
    Базовые метрики EC2 идут с интервалом 5 минут (с детальным мониторингом 1 минута), поэтому для быстрой реакции рекомендуются метрики с интервалом 1 минута и меньше
  2. Amazon CloudWatch metrics for Amazon EC2 Auto Scaling AWS
    Метрики группы публикуются с шагом 1 минута, только если их включить: GroupDesiredCapacity (сколько инстансов нужно поддерживать), GroupPendingInstances (число инстансов, ещё не введённых в работу), GroupInServiceInstances (число инстансов в работе)
  3. Scheduled scaling for Amazon EC2 Auto Scaling AWS
    Увеличивать и уменьшать мощность заранее в заданное время под предсказуемые изменения нагрузки
  4. Decrease latency for applications with long boot times using warm pools AWS
    Для приложений с долгой загрузкой задержку масштабирования сокращают пулом заранее инициализированных инстансов (warm pool)

Смотрите также

Тот же слой: L13 Архитектура и эксплуатация серверов

Причины с тем же симптомом (Слоумо) на других слоях

Карточка в основной версии с иллюстрациями и экспериментами