ID причины in-gateway · Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Серверная инфраструктура, Команда разработки · Разработка клиента
Если поставить между клиентом и игровым сервером промежуточный сервер, каждый проход через него добавляет время обработки, а сам он становится единой точкой отказа.
Почему Схема клиент ↔ шлюз ↔ игровой сервер → Следствие Промежуточный сервер добавляет обработку и ожидание, при его перегрузке страдают все → На экране Пинг растёт у всех, при отказе шлюза дисконнект у всех игроков, которые через него подключены
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Серверная инфраструктура, Команда разработки · Разработка клиента
Команда разработки: задачи
Сервер: заложить возможность добавлять шлюзы и восстановление сессии, чтобы при падении шлюза персонаж продолжал игру после переподключения к другому шлюзу. Клиент: автоматически переподключаться при обрыве связи со шлюзом.
Команда инфраструктуры: задачи
Масштабировать шлюзы горизонтально (добавлять машины), мониторить CPU, число соединений и задержку обработки на каждом шлюзе.
Цифры для ориентира
Внутри одного ЦОД один проход обычно занимает меньше 1 ms. При перегрузке шлюза это время вырастает до десятков и сотен ms.
На графике
Растёт вслед за онлайном и нагрузкой · задержка обработки на шлюзе, CPU и число соединений шлюза
Где смотреть
Смотреть CPU и число соединений шлюза, Recv-Q его сокетов (ss, netstat) и разницу задержки до шлюза и после него. Для вызовов HTTP и gRPC через service mesh сравнить стандартную метрику Istio istio_request_duration_milliseconds на стороне отправителя (reporter=source) и получателя (reporter=destination)
Подтверждает
Время обработки на игровом сервере не меняется, растёт только задержка на участке шлюза, и в это же время CPU шлюза упирается в потолок или копится Recv-Q
Опровергает
Если маршрут в обход этого шлюза (прямое подключение, другой шлюз) тормозит так же, проблема в линии связи или на игровом сервере
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Подробнее
С service mesh (Istio и т. п.) добавляется ещё одно звено: sidecar-прокси (Envoy), который работает рядом с каждым сервером. Запрос между сервисами проходит сначала через sidecar отправителя, потом через sidecar получателя, и чем больше функций добавлено в прокси (например, сбор логов и метрик), тем больше время обработки и ожидания.
Performance and ScalabilityIstio В режиме sidecar запрос проходит по очереди через sidecar-прокси отправителя и получателя. Чем больше функций, тем длиннее путь обработки внутри прокси, а сбор телеметрии увеличивает ожидание следующего запроса
What is EnvoyEnvoy Envoy работает отдельным процессом рядом с каждым сервером приложений, и приложение обменивается данными через Envoy на localhost
Istio Standard MetricsIstio istio_request_duration_milliseconds (распределение времени обработки запросов HTTP и gRPC), метка reporter различает прокси отправителя (source) и получателя (destination)
netstat(8) — Linux manual pagenet-tools Recv-Q: число байтов в подключённом сокете, которые программа пользователя ещё не забрала
Смотрите также
Тот же слой: L13 Архитектура и эксплуатация серверов