Testes de carga e de resistência prolongada antes do lançamento de uma plataforma de cassino

Uma data de lançamento é um plano de tráfego, não um fato de tráfego. Um título novo, um jackpot acumulado, um jogo eliminatório ou uma campanha mudam quantos jogadores chegam e em que velocidade; e se a plataforma absorve essa mudança é uma afirmação que alguém precisa testar em vez de presumir.

Um teste de carga responde com honestidade a uma pergunta estreita: este sistema, nesta configuração, consegue atender esta mistura de trabalho nesta taxa sem quebrar os próprios objetivos? Quase tudo o mais que se diz sobre testes de carga — que uma plataforma «escala», que vai «aguentar o dia do lançamento» — é uma previsão sobre um tráfego que ninguém mediu ainda.

O lançamento é o próprio pico

A lista de coordenação de lançamento do Google é um bom ponto de partida porque foi escrita para ser executada antes de uma data, não depois de um incidente. Ela pede à equipe de lançamento «estimativas de tráfego HTTP e largura de banda, o “pico” do lançamento e a mistura de tráfego», um «teste de carga, teste ponta a ponta, capacidade por data center na latência máxima», o «impacto sobre os outros serviços que mais nos importam» e a «degradação graciosa e como evitar sobrecarregar acidentalmente serviços de terceiros».

Essa lista é genérica para serviços web e anterior a boa parte do ferramental atual do setor. A forma dela continua servindo a uma plataforma de jogo, porque um lançamento é um degrau e não uma rampa. No momento em que um título entra no ar, os jogadores chegam juntos, e cada chegada não é uma única requisição. Início de sessão, leitura do lobby, consulta de saldo, aposta, resultado, a sequência de lançamentos na carteira e a leitura do histórico são trabalhos distintos que chegam multiplicados pela mesma multidão.

Escreva o modelo de carga antes de escrever o roteiro

Um teste comparativo contra um único endpoint mede um endpoint. Não diz nada sobre a plataforma. O primeiro artefato útil de um programa de capacidade é, portanto, um inventário do trabalho que a plataforma realmente faz, com o custo e os efeitos colaterais de cada item:

Trabalho	O que o teste precisa modelar	O que grava
Início de sessão e autenticação	Rajadas de acesso no momento do anúncio, incluindo as repetições que uma resposta lenta provoca	Registros de sessão e eventos de autenticação
Leituras de lobby, catálogo e detalhe do jogo	Quase só leituras, baratas individualmente, dominantes em volume	Nada
Ciclo da rodada	Aceitação da aposta, geração do resultado e os lançamentos na carteira que liquidam a rodada	Lançamentos no razão e histórico de rodadas
Contribuição e acumulação de jackpot	Um contador compartilhado que cada rodada contribuinte toca	Estado de acumulação e os registros que o justificam
Avaliação e concessão de bônus	Regras com muitas leituras e escritas ocasionais que criam passivo	Registros de bônus e passivo pendente
Pagamentos	Início do depósito, retornos do provedor e saques, cada um com a própria latência externa	Registros de pagamento e de carteira
Consultas de back office e relatórios	Longas, caras e muitas vezes executadas por pessoas em horário comercial	Nada, mas consomem os mesmos recursos
Fluxos de eventos e analytics	Contínuos, assíncronos e fáceis de esquecer no dimensionamento	Deslocamentos do fluxo e relatórios derivados

Duas decisões desse modelo determinam o que o teste pode concluir. A primeira é a mistura: uma execução composta sobretudo de leituras de lobby passa com folga sem dizer nada sobre o caminho da rodada. A segunda é se a carga é modelada como uma população fixa de usuários ou como uma taxa fixa de chegada. A distinção vale uma leitura na documentação do k6 sobre modelos abertos e fechados, porque os dois se comportam de forma diferente no instante em que o sistema desacelera: um aplica contrapressão esperando, o outro continua chegando.

Uma contagem de requisições não é um modelo de capacidade

É tentador expressar capacidade como requisições por segundo e comparar esse número com uma estimativa de lançamento. O capítulo do SRE sobre como lidar com sobrecarga explica por que essa comparação engana: «Requisições diferentes podem ter necessidades de recursos enormemente diferentes», e modelar a capacidade como «consultas por segundo» ou como características estáticas da requisição «muitas vezes resulta numa métrica ruim», porque as proporções entre requisições mudam conforme o produto muda. A recomendação do capítulo é medir a capacidade em recursos disponíveis — a CPU primeiro, na maioria dos casos — e definir limites por cliente para que o excesso de um não deixe os outros sem recursos.

Para uma plataforma de jogo, a versão prática é que uma rodada liquidada que toca o razão várias vezes não é intercambiável com uma leitura de lobby. Se o modelo de carga não carrega um custo por unidade de trabalho, o número de pico derivado dele é um número sem unidade.

Teste num ambiente que possa falhar do mesmo jeito

Um teste de carga executado contra um ambiente subdimensionado produz um número confiante sobre o sistema errado. A paridade importa onde se decide se uma consulta é rápida: o volume do conjunto de dados e o tamanho dos índices, as estatísticas das tabelas, a configuração e o estado das flags de funcionalidade em teste, o aquecimento do cache e se os parceiros de integração estão acessíveis com latência realista. Um conjunto de dados restaurado e com a forma da produção encontra a consulta lenta que uma amostra de alguns milhares de linhas nunca encontra. O guia de requisitos de ambientes não produtivos cobre o que mais esse ambiente precisa separar antes de poder ser usado para isso.

Seis tipos de teste, seis modos de falha diferentes

A página do Grafana sobre tipos de teste de carga organiza o trabalho em testes de fumaça, de carga média, de estresse, de resistência prolongada, de pico e de ponto de ruptura, e traz duas ideias que valem para qualquer programa de capacidade: «nenhum tipo de teste elimina todos os riscos sozinho», e as categorias são relativas — «um teste de estresse para uma aplicação é um teste de carga média para outra».

Tipo	A pergunta que responde numa plataforma	O que guardar
Fumaça	O roteiro ainda percorre o caminho real depois da última entrega?	A versão do roteiro e um resultado de referência
Carga média	A plataforma mantém os objetivos na mistura esperada?	Latência e taxa de erro na taxa modelada
Estresse	O que acontece acima do pico esperado e o que degrada primeiro?	O ponto da primeira degradação e a forma dela
Resistência prolongada	A plataforma aguenta horas e não minutos?	A tendência dos recursos ao longo da execução, não só o fim
Pico	Uma chegada súbita e curta sobrevive sem cascata?	O tempo de recuperação e se algo ficou travado
Ponto de ruptura	Onde está o limite e a falha é ordenada?	O recurso limitante e o comportamento de recusa

A janela de resistência prolongada é onde a acumulação aparece

Um teste de uma hora com carga média exercita os caminhos; um teste de resistência prolongada exercita a aritmética da plataforma mantendo estado. As falhas que ele encontra são lentas: um pool de conexões que perde um descritor por ciclo, uma tabela de sessões que cresce sem uma rotina de retenção, um cache que nunca expulsa, uma fila que é drenada de dia e nunca de madrugada, uma acumulação que desvia porque uma rotina de conciliação não rodou, e um volume de logs que enche um disco depois de um limite que ninguém modelou. A própria descrição do Grafana para um teste de resistência prolongada é «a confiabilidade e o desempenho do seu sistema ao longo de períodos extensos», com duração medida em horas e não em minutos.

Duas regras práticas fazem um teste de resistência prolongada valer o tempo de agenda: rodá-lo por tempo suficiente para cruzar pelo menos uma janela programada de manutenção ou de processamento em lote, e observar os recursos ao longo do tempo em vez de ler o resumo do fim.

Carga sintética grava registros financeiros reais

Um teste de carga contra uma plataforma de jogo não reenvia uma página estática. Cada rodada simulada cria lançamentos no razão, cada bônus simulado cria passivo e cada depósito simulado cria um registro de pagamento. Esses registros caem nas mesmas tabelas a partir das quais o negócio reporta e, se o teste não for identificado, depois serão indistinguíveis da atividade real.

Decida antes da execução como o tráfego sintético é marcado, quais contas ou inquilinos ele usa, se fica excluído da conciliação e quando é removido; e guarde o registro dessa decisão junto com a execução. O guia de requisitos de conciliação da carteira descreve os controles que essas exclusões precisam respeitar, e o guia de registro de segurança e evidência de auditoria descreve onde o registro de um teste deliberado deve ficar.

O seu pico também é o pico dos seus fornecedores

Uma plataforma sob carga empurra essa carga para fora. Provedores de pagamento limitam taxa, fornecedores de identidade aplicam limites próprios e os endpoints de carteira dos provedores de jogos têm limites deles. A linha da lista sobre evitar sobrecarregar acidentalmente serviços de terceiros avisa exatamente disso: o seu pico vira o pico deles, e a degradação deles volta como o seu timeout.

Confirme com cada parceiro os limites publicados, modele no ambiente a latência realista e os erros deles, e teste como a sua plataforma se comporta quando estão lentos em vez de ausentes. Uma política de repetição agressiva, inofensiva em volume normal, é como uma dependência lenta vira uma fila que satura tudo o que está atrás dela.

Defina a condição de aprovação antes de apertar o botão

A lista pede «capacidade por data center na latência máxima», e a qualificação é o ponto: um número de capacidade sem um limite de latência descreve um sistema que atendeu requisições, não um que as atendeu de forma útil.

Escreva os limites primeiro — o percentil que importa, a taxa de erro aceitável, a mistura que a execução deve usar e o teto de recursos — e deixe a execução produzir uma aprovação ou uma reprovação diante deles. Uma conclusão escolhida depois de ler os resultados é uma opinião com um gráfico anexado. Quando o objetivo é um objetivo de nível de serviço para os jogadores, vale a mesma disciplina de qualquer outro caso: o número é aquilo contra o que se reprova.

Recuse carga de propósito e comprove que consegue

Sob sobrecarga, o comportamento desejável não é aceitar tudo e colapsar. É continuar atendendo o tráfego que se consegue processar e recusar o resto com clareza. O RFC 6585 define a forma dessa recusa: o código de status 429 «indica que o usuário enviou requisições demais num determinado intervalo de tempo (“limitação de taxa”)», a resposta «DEVERIA incluir detalhes que expliquem a condição e PODE incluir um cabeçalho Retry-After», e uma resposta 429 «NÃO DEVE ser armazenada por um cache». O capítulo do SRE sobre como lidar com sobrecarga diz o mesmo do lado de quem serve: uma tarefa dimensionada para uma taxa deveria «continuar atendendo tráfego nessa taxa sem impacto significativo na latência, independentemente de quanto tráfego excedente lhe seja lançado», não pode cair, e isso deveria valer «em algum ponto acima de duas ou até dez vezes o que a tarefa está dimensionada para processar».

Assim, o teste de estresse tem um segundo entregável além do limite: a evidência de que a recusa é ordenada. Ultrapasse a capacidade de propósito e verifique se quem chama recebe uma resposta clara e passível de nova tentativa, ou se recebe timeouts enquanto as filas enchem.

Guarde um registro que sobreviva à entrega

Uma execução de capacidade que não deixa artefato nenhum é indistinguível de uma que foi omitida. O registro que vale guardar é curto: o roteiro e a versão do modelo de carga, o conjunto de dados e como foi produzido, a topologia e os tamanhos das instâncias, a configuração e o estado das flags de funcionalidade, o perfil de carga, os resultados brutos, os limites, cada exceção com um responsável, quem leu o resultado e o que foi decidido, e a data.

Mais duas condições pertencem a esse registro, não à memória de alguém. A primeira: um teste contra capacidade compartilhada ou de produção precisa de uma janela declarada, um responsável nomeado e uma condição de parada definida; um teste de carga que começa a afetar jogadores reais deixou de ser um teste e virou o incidente que deveria evitar. A segunda: se a execução deve produzir um pico, o guia do plano de resposta a incidentes é o documento que já deveria indicar quem observa e quem pode interromper.

Pare no que o teste comprova

Uma execução aprovada comprova que esta compilação, neste ambiente, atendeu aquele modelo de carga naquela data e naquela taxa. Não comprova que a plataforma esteja correta, que uma população real se comporte como o modelo, que um fornecedor vá respeitar os próprios limites, nem que o resultado sobreviva à próxima entrega. Capacidade é tendência, não medalha: uma mudança no caminho da rodada, no volume de dados ou na topologia invalida o último resultado, e o número útil é aquele que tem uma data e uma compilação ao lado.

É também por isso que um teste de carga pertence a um calendário e não apenas a uma lista de lançamento. O guia de observabilidade do RGS cobre o lado em tempo de execução da mesma pergunta — o que a plataforma registra sobre si enquanto atende — e os dois juntos são o que transforma uma data de lançamento de expectativa em evento monitorado. O trabalho de desenvolvimento de plataformas é onde fica o lado de capacidade desse processo de entrega.

Perguntas que os operadores fazem

Quanto tempo deve durar um teste de resistência prolongada?

Tempo suficiente para cruzar pelo menos uma janela programada de processamento em lote ou manutenção, o que na prática significa horas e não minutos. A duração não é resistência por si só: serve para deixar vazamentos, crescimento e desvios acumularem até um tamanho visível.

Um teste de carga pode rodar contra a produção?

Pode, mas é outro exercício com outras regras: janela declarada, responsável nomeado, condição de parada definida e uma decisão sobre os registros sintéticos que cria. Um teste de carga que degrada o serviço ao vivo é um incidente. Quando o objetivo é medir a plataforma e não a mudança, testar num ambiente com a forma da produção é a decisão mais barata.

Um teste de carga aprovado comprova que a plataforma sobreviverá ao dia do lançamento?

Não. Comprova que uma carga modelada foi atendida por uma compilação específica num ambiente específico numa data específica. Uma população real de jogadores decide a própria mistura, terceiros impõem os próprios limites e a próxima entrega pode mudar o custo do trabalho.