Guia de migração de servidor de jogos dedicado

Este artigo aborda considerações sobre como mover servidores de jogos de computador para o Google Cloud Platform (GCP). A maioria dos jogos on-line atuais apresentam processos de servidor de jogos dedicado que é executado em máquinas físicas ou virtuais. Este guia é destinado a desenvolvedores de jogos e equipes de operação familiarizadas com a execução de processos de servidor de jogos dedicado, seja no local ou na nuvem. Há diversos fatores a serem considerados em relação a migração de servidores de jogos para GCP. No entanto, a grande flexibilidade que a nuvem oferece pode trazer benefícios relevantes, como um modelo de faturamento vantajoso, infraestrutura global líder na indústria e as mais recentes tecnologias de nuvem. Este guia tem como objetivo ajudar você a começar sua migração. A indústria de jogos não tem uma terminologia padrão, então, para os fins deste artigo:

  • Máquina refere-se à máquina física ou virtual em que os processos de servidor de jogos são executados.
  • Servidor de jogos refere-se ao processo do servidor de jogos. Vários processos de servidor de jogos podem ser executados simultaneamente em uma máquina.
  • Instância refere-se a um único processo de servidor de jogos.

Motivos para executar servidores de jogos no GCP

Cada vez mais estúdios estão migrando os servidores de jogos dedicados para a nuvem. Assim, é superado o desafio de combinar compras de hardware com a imprevisível base de jogadores no tempo de lançamento. A possibilidade de lidar facilmente com fluxos inconstantes de atividade e pagar apenas pelo que for usado elimina um risco considerável no lançamento. Alguns benefícios incluem:

  • As máquinas virtuais (VMs, na sigla em inglês) do Google Compute Engine são faturadas por minuto, não por hora. Descontos por uso contínuo são aplicados automaticamente para as VMs que continuarem em execução. Não é necessário reservar capacidade e assumir os riscos financeiros relacionados.
  • Graças aos formatos personalizados das VMs, você paga apenas pela quantidade de CPU e memória que seu servidor de jogos dedicado de fato utiliza.
  • O tempo de inicialização das VMs do Compute Engine é muito rápido, sendo de segundos para o Linux e poucos minutos para o Windows.
  • Ampla disponibilidade regional para que os servidores de jogos possam ser colocados próximos aos clientes. Com o espaço de rede global padrão, esses servidores podem se comunicar facilmente com os servidores atuais, sem a necessidade de realizar mais trabalho.
  • É possível provisionar ambientes únicos para desenvolvimento, testes de qualidade ou eventos rapidamente e descartá-los assim que deixarem de ser necessários, sem compromissos e sem afetar outros ambientes.
  • É possível configurar facilmente versões hospedadas no Google Cloud Storage como versões distribuídas ou originadas na CDN diretamente dos buckets.
  • Com os instantâneos de artefatos de versão em discos separados, é possível fazer upgrades de sistemas operacionais facilmente, além de promover versões para produção por meio de symlinks.

Como usar projetos para segregar ambientes

Não é incomum que os ambientes público, de desenvolvimento, de testes e de preparação sejam separados em diferentes projetos. Os projetos ficam mais leves e podem ser facilmente criados e descartados. Outro padrão comum é criar um projeto para um ambiente de testes e implantar uma versão, que passa por testes rápidos de controle de qualidade. Quando essa versão está pronta para ser promovida ou rejeitada, o projeto que foi criado é descartado. Isso também garante separação de recursos e cotas. Por exemplo, uma versão com desempenho ruim no teste não pode impactar os serviços de produção consumindo recursos demais. Além disso, quando você descarta um projeto, todos os recursos dele são excluídos. Assim, você não se depara com ambientes de teste ou desenvolvimento esquecidos na sua fatura.

Como enviar versões para a nuvem

Fazer upload de versões para o Cloud Storage gera apenas custos de armazenamento por GB. Depois de carregado, é fácil usar este upload como uma origem de CDN ou distribuir versões para outros estúdios ou contratados. Você pode definir a vida útil de objetos carregados usando o Gerenciamento de ciclo de vida do objeto para manter a sobrecarga de administração gerenciável e limitar os custos.

Distribuição

É comum hospedar recursos e binários na nuvem usando um armazenamento de objeto como o Cloud Storage ou armazenamento em blocos, como discos permanentes. Qualquer processo que você tenha e use o S3 do Amazon Web Service pode ser facilmente modificado ou ampliado para usar o Cloud Storage, porque ele é compatível com APIs. Armazenar recursos no Cloud Storage é uma boa maneira de distribuir versões aos clientes, CDNs e até escritórios remotos. No entanto, copiar do Cloud Storage para suas máquinas virtuais de servidor de jogos pode gerar tempo de carregamento adicional, então essa abordagem não é recomendada. Muitos clientes com um grande número de servidores de jogos dedicados já estarão familiarizados com o padrão de "preparação" de imagens de disco que já têm todas as bibliotecas, os recursos e os binários necessários para iniciar uma nova VM de servidor de jogo dedicado. Essa estratégia é tão válida no GCP quanto no local ou em outras nuvens. No entanto, recomendamos parear instantâneos com discos somente leitura, conforme detalhado na seção a seguir, o que traz vantagens significativas.

Instantâneos com a estratégia de discos somente leitura

Em muitos jogos, o sistema operacional e a versão do servidor de jogos podem ser alterados de modo independente. Recomendamos que a versão do jogo não seja colocada no disco do SO, mas em um disco permanente separado, com artefatos de versão necessários que tenham ligação soft ou simbólica com o diretório esperado. Essa configuração cria um fluxo de trabalho organizado para distribuir várias versões para uma VM. Basta colocar cada versão no próprio disco, anexar todos os discos à VM e atualizar os links simbólicos quando estiver tudo pronto para alterar as versões do servidor de jogos. Versões anteriores em discos separados podem permanecer conectadas até que você tenha confiança de que a nova versão seja estável, permitindo rollbacks simples. É possível vincular discos permanentes a várias VMs, o que gera economia e elimina a necessidade de distribuir recursos a todas as máquinas virtuais.

Quando implementar essa abordagem como parte de um canal de desenvolvimento de jogos, recomendamos que você configure o sistema da sua versão para realizar as etapas necessárias para criar o disco com todos os arquivos do artefato na estrutura do diretório apropriado. Por exemplo, é possível usar um script simples que executa comandos gcloud ou um plug-in específico do GCP para o sistema de compilação de sua escolha. Também recomendamos que você crie várias cópias do disco e conecte as máquinas virtuais a essas cópias de modo equilibrado, tanto para considerações de capacidade quanto para gerenciar riscos de falhas. É possível criar vários discos permanentes a partir de um único instantâneo ao mesmo tempo. Essa é uma maneira eficaz de gerar rapidamente várias cópias do disco da mesma versão do servidor de jogos.

Rede

O GCP é executado na rede de fibra privada e personalizada do Google, fornecendo latência muito baixa entre os principais pontos de presença (PoPs, na sigla em inglês) metropolitanos e data centers do GCP. Com o modelo de rede do GCP, você pode manter o máximo possível do tráfego vital relacionado à jogabilidade na rede do Google entre a região que hospeda seus servidores e o PoP do Google mais próximo do ISP dos seus clientes. Compare isso às estratégias de roteamento mais comuns oferecidas por outros fornecedores, que tentam rotear seu tráfego para a Internet pública assim que deixam as VMs. A rede do Google oferece alta confiabilidade e latência mais previsível para seus jogadores.

Além disso, o GCP tem um espaço de rede global como padrão. Não é necessário "conectar" diferentes regiões ou zonas usando VPNs ou outros softwares de rede. Se você iniciar uma VM na zona us-central1-b e outra em eu-central1-a e, em seguida, configurá-las para usar a mesma rede, elas poderão se comunicar sem nenhuma configuração adicional. Todo o tráfego entre as zonas permanece na rede privada do Google, sem gerar latência por saltos extras causados pelo BGP na Internet pública.

Rede entre projetos

Por padrão, cada projeto do GCP que você cria representa uma rede própria global isolada. As máquinas virtuais não podem se comunicar entre si caso estejam em projetos separados sem que passem pela Internet pública. Há diversas maneiras de estabelecer uma rede entre projetos, mas recomendamos que você use um único projeto para executar servidores e serviços que você quer intercomunicar em um espaço de rede privada.

Rede do GCP para servidores de jogos

O padrão de rede mais comum para servidores de jogos dedicados no GCP é criar uma rede de "jogos" dedicada usando o Console do Google Cloud Platform. Configure essa rede com as portas de jogos adequadas abertas para tráfego de Internet, além de todas as portas internas necessárias para verificações de integridade, monitoramento ou comunicação de serviços de plataforma. Em seguida, especifique essa rede ao criar máquinas virtuais que hospedam servidores de jogos dedicados.

Práticas recomendadas

Depois que os servidores de jogos forem migrados para o GCP, você poderá ter benefícios em otimizar as versões do servidor para usar a infraestrutura do GCP.

Otimizações de vCPU

Velocidades de clock são bastante constantes por vCPU, mas o Google conta com regiões de nuvem que contêm as mais recentes arquiteturas de CPU Intel. Alguns clientes de jogos notaram melhorias na velocidade de até 20% no Linux quando compilaram com sinalizações específicas da arquitetura e executaram os servidores em regiões que oferecem CPUs dessas famílias. Essa consistência da velocidade do vCPU também ocorre em uma abordagem de escalonamento horizontal, e não vertical, para tarefas com uso intenso de CPU. Quando possível, use threads de trabalhador e carregue em paralelo seu código para permitir que ele use várias CPUs, em vez de precisar de mais ciclos de poucas CPUs.

Otimizações de rede

Ainda que haja custo para saída de tráfego, não há custos para entrada. Considere os padrões de comunicação assimétricos para usar uma taxa de atualização maior para pacotes originados pelo cliente do que dos originados pelo servidor. Muitas vezes, o efeito de uma taxa de atualização de servidor mais baixa pode ser reduzido com interpolação ou extrapolação. Além disso, se o código de ordenação/serialização do servidor puder ser suficientemente eficaz, avalie o uso da compressão de pacotes para que eles fiquem pequenos.

Eventos de análise e otimização de registros

Pense na possibilidade de estabelecer um caminho de geração de registros e evento de análise de alto volume no Google BigQuery ou Cloud Storage e permitir a ativação ou desativação desse recurso para cada processo de servidor de jogos individual. Essa abordagem permite que você investigue rapidamente explorações reportadas, analise o equilíbrio da jogabilidade ou gere dados de treinamento de ML. Os dados armazenados em cada serviço têm preço baixo, US$ 102,40/mês por 5 TB de armazenamento atualmente, e apresentam um histórico significativo de reduções no preço. O armazenamento pode ser configurado para expirar automaticamente após determinada data, o que permite um controle fácil sobre volumes de dados e custos.

Externalização do estado de jogos

Nossa visão geral da infraestrutura de jogos em nuvem faz uma abordagem rápida sobre as possíveis vantagens da externalização de estado. Pense em quais porções do seu estado de jogo podem ser externalizadas. Algumas quantidades de estado de externalização podem ser realizadas hoje, e mais tecnologias de nuvem surgem todos os dias que melhoram essa capacidade. O estado de externalização pode ativar vários recursos interessantes, como:

  • Permitir a migração de processos de servidor de jogos entre VMs, durante jogos, com mínima interrupção. Isso pode ser usado em vários cenários, incluindo:

    • Localizar paralelamente serviços ou servidores de jogos que estabelecem comunicação de altos volumes de intrasservidores na mesma região ou na mesma VM, sem tentar predizer os padrões de tráfego do usuário de antemão.
    • Segregar processos que têm alto uso de recursos.
    • Remover em tempo real processos das VMs que precisam ser desligados para atualizações ou removidos para redução de uso após passar um estado de alta demanda.
  • Permitir que vários processos funcionem em diferentes partes da simulação e compartilhar as atualizações entre cada um deles de modo semelhante ao compartilhamento de memória, mas em escala muito maior.

  • Permitir que a serialização do estado seja salva em disco ou compartilhada em um outro servidor de jogos, o que pode abrir novas possibilidades para esportes eletrônicos, como:

    • Replays autoritários capturados por servidor com uma corrente de custódia.
    • Servidores de jogos dedicados "espelhados", permitindo grandes números de espectadores ao vivo nos clientes de jogos.

A seguir