As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

GAMEOPS03-BP04 Adote uma estratégia de implantação que minimize o impacto para os jogadores

Incorpore uma estratégia de implantação para o software e a infraestrutura do seu jogo que minimize a quantidade de tempo de inatividade que mantém os jogadores fora do seu jogo. Embora certos tipos de atualizações possam exigir a instalação de novas atualizações no cliente do jogo, desenvolva o jogo para minimizar ou evitar a necessidade de tempo de inatividade durante as implantações.

Nível de risco exposto se esta prática recomendada não for estabelecida: Alto

Orientação para implementação

Uma das etapas mais importantes a serem consideradas ao desenvolver uma estratégia de implantação de jogos é determinar como sua infraestrutura de jogos será gerenciada. Gerencie sua infraestrutura de jogos usando uma ferramenta de infraestrutura como código (IaC), como AWS CloudFormationo Terraform da Hashicorp, para reduzir os erros humanos durante a preparação do ambiente. Os modelos de infraestrutura podem ser implantados e testados em pipelines automatizados, o que cria consistência na configuração de diferentes ambientes de jogo.

Há várias estratégias de implantação que podem ser usadas em um jogo:

Substituição contínua

O objetivo principal de uma substituição contínua para implantação é realizar o lançamento sem encerrar o jogo e sem afetar os jogadores. É importante que a atualização ou as alterações a serem executadas sejam compatíveis com versões anteriores e funcionem de forma adjacente às versões anteriores do sistema.

Nessa implantação, as instâncias do servidor são substituídas incrementalmente (substituídas ou implantadas) por instâncias que executam a versão atualizada. Essa substituição contínua pode ser realizada de algumas maneiras diferentes. Por exemplo, para implementar atualizações contínuas em uma frota de servidores de jogos dedicados, uma abordagem típica envolve criar um novo grupo de EC2 instâncias do Auto Scaling que contém a nova versão de compilação do servidor de jogos implantada nelas e, em seguida, direcionar gradualmente os jogadores para as sessões de jogo hospedadas nessa nova frota de servidores. Se houver uma atualização do cliente de jogo associada que seja necessária como pré-requisito para usar a nova versão do servidor de jogo, você deverá incluir uma verificação de validação para verificar se somente os jogadores que têm essa nova atualização do cliente de jogo instalada são encaminhados para essas sessões de jogo.

As frotas de servidores (por exemplo, grupos de EC2 Auto Scaling) que contêm a versão antiga de compilação do servidor de jogos só são removidas do serviço depois de serem esgotadas das sessões ativas dos jogadores de maneira elegante, normalmente configurando métricas de servidor individualizadas que permitem que as equipes de operações do jogo automatizem esse processo. Como alternativa, para reduzir a quantidade de infraestrutura e o tempo para realizar uma implantação contínua, uma abordagem alternativa pode ser realizada em que as instâncias de produção existentes sejam removidas do serviço, atualizadas com a nova construção do servidor de jogos e depois colocadas de volta na frota de produção. Essa abordagem reduz a quantidade de infraestrutura necessária, mas também aumenta o risco, pois o número de servidores de jogos ao vivo disponíveis para os jogadores é reduzido à medida que os servidores são substituídos.

Esse modelo também pode ser usado para realizar implantações contínuas em serviços de back-end, como bancos de dados, caches e servidores de aplicativos que não hospedam jogos. Desde que esses serviços sejam implantados de maneira altamente disponível com várias instâncias em cluster, a complexidade das implantações nesses serviços deve ser menor do que as implantações em servidores de jogos dedicados.

Implantação azul/verde

O objetivo principal de uma blue/green implantação em um jogo é minimizar o tempo de inatividade e, ao mesmo tempo, permitir a reversão segura da implantação anterior, caso sejam identificados problemas. É adequado para implantações em que duas versões do back-end do jogo são compatíveis e podem atender aos jogadores simultaneamente.

Na estratégia blue/green de implantação, dois ambientes idênticos (azul e verde) são configurados. A versão existente do jogo é rotulada como azul, enquanto a nova versão do jogo que é o alvo de implantação é rotulada como verde. Quando o ambiente verde estiver pronto para a migração, você poderá configurar sua camada de roteamento para reverter o tráfego para o ambiente verde, mantendo o ambiente antigo (azul) disponível caso seja necessário um failback. Nesse cenário, as atualizações de roteamento podem exigir a atualização do serviço de matchmaking para configurá-lo para começar a enviar sessões de jogo para a nova frota ou, no caso de serviços de back-end de jogos, isso pode ser atualizar os registros DNS no Amazon Route 53 para seu serviço ou mudar os pesos do balanceador de carga do aplicativo para enviar tráfego para seu novo grupo-alvo.

Uma das desvantagens da estratégia de blue/green implantação é o custo inerente do ambiente de espera devido à infraestrutura adicional necessária durante a execução da implantação. Uma opção para mitigar esse custo adicional de infraestrutura é considerar a adoção de uma variante de blue/green implantação em que o novo software de jogo é implantado nos mesmos servidores que já estão implantados na produção. Nesse cenário, um novo processo de servidor verde pode ser iniciado com o novo software junto com o processo de servidor azul existente, com a transição ocorrendo entre os processos do servidor e não entre uma infraestrutura física separada. Essa abordagem também pode acelerar as implantações de jogos em uma grande quantidade de infraestrutura, eliminando a necessidade de esperar que novos servidores sejam lançados na nuvem. Para obter as melhores práticas sobre essa abordagem de implantação, consulte Implantações azul/verde ativadas. AWS

Implantação do Canary

A implantação do Canary é útil para desenvolvedores de jogos, pois a estratégia pode ser aplicada para lançar uma versão alfa ou beta inicial de um jogo, ou um recurso do jogo, como um novo modo de jogo, mapa ou desafio, para um conjunto restrito ou pequeno de jogadores em produção. Essa implantação é chamada de canário. O lançamento pode ter rastreamento e relatórios adicionais, portanto, quando jogadores reais jogam esse jogo ou recurso, sua telemetria de jogo é coletada e analisada em busca de anomalias e problemas.

Para novos recursos, os jogadores não são notificados consistentemente sobre isso, e a telemetria do jogo é a principal fonte usada para determinar se os jogadores estão enfrentando problemas e se o lançamento deve ser revertido. Ao mesmo tempo, se nenhum problema significativo for identificado, o recurso poderá ser implementado para mais jogadores para obter dados adicionais. Se os jogadores forem notificados, eles poderão ser solicitados a fornecer feedback regular sobre sua experiência. Idealmente, essa atividade de teste seria coordenada por uma equipe de operações ao vivo.

Como estratégia, o canary deployment também pode ser usado em lançamentos padrão para disponibilizar gradualmente um novo recurso para os jogadores. Uma vantagem potencial em relação ao blue/green ambiente padrão é que não é necessário um segundo ambiente em grande escala. A capacidade do novo ambiente reduzido determina quantos jogadores devem ser integrados ao novo recurso. Antes de adicionar mais jogadores, a capacidade deve ser dimensionada adequadamente. Mesmo que se espere que essa blue/green técnica personalizada custe comparativamente menos do que o azul/verde padrão, estima-se que ela tenha um custo que pode ser maior do que a técnica de substituição contínua de implantações de canários.

Execute apenas um único canário em um ambiente de produção e concentre-se em seus dados e feedback. Se vários canários forem implantados, isso complica a solução de problemas e o isolamento de problemas na produção e prejudica a qualidade dos conjuntos de dados e do feedback que estão sendo coletados.

Uma variação do canário ocorre quando um ou mais experimentos (geralmente testes de interface do usuário) são executados por meio de implantações específicas, em que um conjunto de servidores de back-end do jogo serve uma versão de um recurso e outro conjunto do mesmo tamanho fornece outra versão do mesmo recurso. Nenhuma infraestrutura adicional ou especial é criada para isso, e somente os pacotes escolhidos de servidores de back-end recebem essas atualizações. O resultado dos experimentos é observar como os jogadores reagem a cada uma das versões do mesmo recurso, determinar se há um consenso geral de gostar ou não gostar e observar se há problemas identificados com sua usabilidade ou funcionalidade. Esses experimentos estratégicos também são chamados de A/B testes, e o processo geral é chamado de teste A/B. Após a conclusão desses experimentos, os dados de teste necessários são coletados antes de reverter para a versão atual do sistema de back-end do jogo nos servidores usados para os testes.

Implantações tradicionais antigas

No estilo tradicional de implantação, durante uma janela de manutenção programada, o jogo é encerrado e os jogadores conectados são eliminados ou esgotados antes que as instâncias do servidor no back-end do jogo sejam atualizadas com as versões de código mais recentes. Essa implantação afeta os jogadores toda vez que é realizada, e os jogadores devem ser notificados antes do cronograma. Como resultado, esse modelo causa o maior impacto ao jogador e deve ser evitado sempre que possível.

Depois que a atualização do jogo for implantada, o jogo poderá ser testado antes de abri-lo para os jogadores, que estariam esperando a reabertura do jogo. Isso pode causar um aumento no tráfego quando os jogadores tentam fazer login e jogar em um curto período de tempo. Portanto, se o jogo não foi projetado para lidar com esses picos de tráfego, você pode optar por permitir gradualmente que os jogadores voltem ao jogo em lotes.

Como alternativa, você pode optar por provisionar demais a infraestrutura para sustentar o pico inicial de tráfego e, depois que o tráfego do jogo diminuir, os recursos poderão ser reduzidos. Se necessário, realize esse tipo de implantação fora do horário de pico, quando o número de jogadores é menor. A manutenção programada com frequência, bem como a manutenção prolongada, inerentemente acarreta o risco de desgaste do jogador e de possível perda de receita. Os jogadores também esperam mudanças após um novo lançamento e podem perder a confiança no jogo ao retornar após um período de inatividade.

Etapas de implementação