Desbalanceamento do load balancer e health check enganoso LB imbalance, bad health checks
ID da causa dc-lb-imbalance · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
As conexões se concentram em um único servidor, ou jogadores continuam sendo mandados para um servidor que já caiu.
Por quê A regra de distribuição não serve para o caso, ou o health check não enxerga o estado real → Efeito Só um servidor fica sobrecarregado, ou há tentativas de conexão a um servidor que caiu → Na tela Só alguns canais ou alguns jogadores: câmera lenta, não conecta ou loading infinito
Logo após login ou manutenção, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Implementar um health check que responda às verificações do load balancer com base no estado real do jogo (avanço do tick, conexões com o BD), informar também a carga do servidor.
O que fazer (Equipe de infraestrutura)
Trocar o health check por um que confirme respostas reais do jogo, distribuir com base na carga dos servidores, monitorar a diferença de conexões entre servidores.
No gráfico
Alto só em alguns · Conexões e uso de CPU por servidor
Onde olhar
Sobrepor em um mesmo gráfico o número de conexões (ss -s) e o uso de CPU de cada servidor atrás do load balancer, e comparar o estado de saúde dos destinos no load balancer (na AWS, HealthyHostCount e UnHealthyHostCount no CloudWatch) com o estado real dos servidores do jogo
Confirma se
Só um ou dois servidores têm conexões e CPU muito acima dos outros, ou um servidor com o tick parado continua “saudável” e segue recebendo novas conexões
Descarta se
Conexões iguais entre os servidores, mas só um canal lento: carga dentro desse canal (“Sobrecarga de zona em thread única (hotspot)”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Load Balancing in the DatacenterGoogle Round robin simples deixa o uso de CPU variar em até 2 vezes entre tarefas; distribuição ponderada em que os backends informam sua carga nas respostas e nos health checks; estado lame duck, em que o backend pede para não receber mais requisições
Health checks for Network Load Balancer target groupsAWS Health check padrão a cada 30 segundos, com remoção após 2 falhas; serviços UDP são verificados com health checks TCP ou HTTP, então recomenda-se configurá-los para refletir o estado real do serviço