Criar uma plataforma de análise de jogo para dispositivos móveis: uma arquitetura de referência

Nos aplicativos de jogo para dispositivos móveis, um grande volume de dados de telemetria de jogadores e eventos é gerado. Esses dados são potencialmente úteis para fornecer insights do comportamento do jogador e do envolvimento dele com o jogo. A natureza desses jogos, que em grande parte são executados em dispositivos clientes instáveis, com conexões de Internet lentas e problemas relacionados a bateria e gerenciamento de energia, significa que a análise desses dados é um desafio único.

Nesta arquitetura de referência, você tem uma abordagem de alto nível para a coleta, armazenamento e análise de grandes volumes de dados de telemetria dos jogadores no Google Cloud Platform.

Para ser mais específico, você aprenderá a analisar eventos de jogos para dispositivos móveis usando dois padrões principais de arquitetura:

  • processamento em tempo real de eventos individuais com um padrão de streaming
  • processamento em massa de eventos agregados com um padrão de lote

Arquitetura de referência para telemetria de jogo

Figura 1: arquitetura de referência de telemetria de jogo

Na figura 1, os pipelines de processamento dos dois padrões são ilustrados, bem como alguns componentes opcionais para exploração, visualização e compartilhamento adicionais dos resultados. A arquitetura de referência tem alta disponibilidade e permite que você faça o escalonamento quando os volumes de dados aumentam. Observe também que essa arquitetura é composta somente de serviços gerenciados para os canais de análise de dados, ou seja, não é necessário executar máquinas virtuais ou gerenciar sistemas operacionais. Isso é especialmente evidente quando a autenticação do usuário no App Engine é processada no servidor de jogo. No artigo abaixo, você conhecerá essa arquitetura com detalhes.

Processamento de eventos em tempo real com padrão de streaming

Nesta seção, você conhecerá um padrão de arquitetura de exemplo em que um grande número de eventos de várias fontes diferentes são ingeridos, processados e analisados simultaneamente. O processamento ocorre à medida que os eventos acontecem durante o jogo, permitindo que você responda e tome decisões em tempo real.

Um grande número de mensagens de evento é gerado nos vários jogos para dispositivos móveis. Alguns são acionados pelo jogador, outros pelo horário do dia e assim por diante. Como resultado, os conjuntos de dados são desvinculados e você não tem como antecipar quantos eventos serão processados. Isso significa que a abordagem correta nesse caso é processar os dados usando um mecanismo de execução em streaming.

Imagine que o aplicativo para dispositivos móveis é um jogo de interpretação de papéis (RPG, na sigla em inglês) onde os jogadores lutam contra as forças do mal, cumprindo missões para derrotar monstros poderosos. Para rastrear o progresso do jogador, uma mensagem normal de evento inclui um identificador exclusivo para esse jogador, um carimbo de data/hora do evento, métricas indicando a missão, os pontos atuais de saúde e assim por diante. Ela será semelhante a este exemplo, uma mensagem de fim de batalha com o identificador playerkillednpc.

{
"eventTime":"2015-10-27T20:34:12.675362426+08:00",
"userId":"gamer@example.com",
"sessionId":"b6ff8881-0c30-9add-374c-c32052cee256",
"eventId":"playerkillednpc",
…
"attackRoll":17,
"damageRoll":13
}

Nesse exemplo, você viu um evento relacionado a batalha, mas essas mensagens podem incluir qualquer tipo de informação relevante para seu negócio, por exemplo, eventos de compra no jogo.

Como não é possível prever quais perguntas você precisará responder sobre os dados, uma boa estratégia é registrar o máximo de pontos de dados que puder. Com isso, você tem o contexto adicional necessário para as suas futuras consultas. Por exemplo, qual informação é mais útil: o fato de um jogador ter feito uma compra no jogo no valor de 50 centavos, ou aqueles que compraram um feitiço poderoso contra o chefe da missão 15, sendo que o jogador foi morto por esse chefe cinco vezes seguidas, nos 30 minutos anteriores a essa compra? A captura de dados completos do evento permite que você tenha um insight detalhado e preciso do que ocorre no seu jogo.

Origem da mensagem: dispositivo móvel ou servidor de jogo?

Independentemente dos campos de conteúdo, decida se quer enviar as mensagens de eventos diretamente do dispositivo do usuário final que está executando o aplicativo para dispositivos móveis para a camada de ingestão do Cloud Pub/Sub ou passar pelo servidor do jogo. O principal benefício de passar pelo servidor é que a autenticação e validação são processados pelo seu aplicativo. Uma desvantagem é que será necessário usar capacidade adicional de processamento do servidor para tratar a carga de mensagens desses dispositivos.

Processar eventos de cliente e servidor de jogo em tempo real

Figura 2: processamento em tempo real dos eventos dos clientes e servidores do jogo

Independentemente da origem dos dados, a arquitetura de back-end ainda é, em grande parte, a mesma. Conforme mostrado na figura 2, há cinco partes principais:

  1. As mensagens de evento em tempo real são enviadas por um grande número de origens, por exemplo, milhões de aplicativos para dispositivos móveis.
  2. A autenticação é processada no servidor do jogo.
  3. No Cloud Pub/Sub, essas mensagens são ingeridas e temporariamente armazenadas.
  4. No Cloud Dataflow, o evento JSON é transformado em dados estruturados e baseados em esquemas.
  5. Os dados são carregados no mecanismo de análise do BigQuery.

Cloud Pub/Sub: ingestão de eventos escalável

Para processar essa carga, um serviço escalável capaz de receber e armazenar temporariamente essas mensagens de evento é necessário. Como o tamanho de cada evento individual é bem pequeno, você precisa se preocupar mais com o número total de mensagens do que com os requisitos gerais de armazenamento.

Outro requisito para esse serviço de ingestão é o suporte a vários métodos de saída. Isso significa que os eventos podem ser usados por vários destinos. Por fim, é preciso haver a opção entre o serviço atuar como uma fila, em que cada destino verifica alterações para alimentar novas mensagens, e um método push, que envia eventos antecipadamente, no momento em que eles são recebidos.

Felizmente, todas essas funcionalidades são fornecidas pelo Cloud Pub/Sub. Na figura 3, a camada de ingestão recomendada é ilustrada, com capacidade de processar milhões de mensagens por segundo e mantê-las por até sete dias no armazenamento permanente. O Cloud Pub/Sub opera no padrão publicar/assinar, em que você tem um ou mais editores enviando mensagens para um ou mais tópicos. Também é possível que haja vários assinantes para cada tópico.

Modelo publicar/assinar do Cloud Pub/Sub com armazenamento permanente

Figura 3: modelo publicar/assinar do Cloud Pub/Sub com armazenamento permanente

É possível escolher o número de tópicos e o agrupamento de cada um. Como há uma relação direta entre esse número e a quantidade de canais do Cloud Dataflow criados, é recomendável agrupá-los logicamente, de acordo com os eventos conectados. Por exemplo, pense no editor como um dispositivo móvel individual ou um servidor de jogo com vários editores para um único tópico. Tudo o que é necessário é a capacidade de autenticar e enviar uma mensagem formatada de maneira adequada pelo HTTPS.

Depois que uma mensagem, que nesse caso é um evento de telemetria do jogador, é recebida pelo serviço do Cloud Pub/Sub, ela é mantida de modo durável no armazenamento de mensagens até ser recebida por todas as assinaturas do tópico.

Canal de streaming do Cloud Dataflow

Com o Cloud Dataflow, você tem uma linguagem de alto nível para descrever com facilidade os canais de processamento de dados. Esses canais são executados por meio do serviço gerenciado do Cloud Dataflow no modo de streaming e recebem as mensagens do tópico do Cloud Pub/Sub quando elas chegam por meio de uma assinatura. Em seguida, o Cloud Dataflow executa o processamento necessário antes de elas serem adicionadas a uma tabela do BigQuery.

Esse processamento pode envolver simples operações de elemento como converter todos os nomes de usuário para letras minúsculas ou fazer a junção dos elementos com outras fontes de dados, por exemplo, uma tabela de nomes de usuário com as estatísticas dos jogadores.

Transformar mensagens JSON no formato de tabela do BigQuery

Figura 4: transformar mensagens JSON no formato de tabela do BigQuery

Com o Cloud Dataflow, você consegue executar várias tarefas de processamento de dados, incluindo a validação em tempo real dos dados de entrada. Um caso de uso é a detecção de fraudes, por exemplo, destacar um jogador com pontos máximos de acerto fora do intervalo válido. Outro caso de uso é a limpeza dos dados, por exemplo, garantir que a mensagem de evento esteja corretamente formatada e corresponda ao esquema do BigQuery.

No exemplo da figura 4, a mensagem JSON original é decodificada do servidor de jogo e convertida em um esquema do BigQuery. O importante é que, para fazer isso, você não tem que gerenciar servidores ou máquinas virtuais. O trabalho de iniciar, executar e interromper os recursos de computação para processar o canal em paralelo é feito no Cloud Dataflow. Além disso, é possível reutilizar o mesmo código para os processamentos em streaming e em lote.

Com o SDK do Cloud Dataflow, você executa o canal separadamente do programa do Cloud Dataflow. No programa, o canal é criado, e o código que você escreveu gera uma série de etapas a serem executadas por um executor desse canal, que pode ser o serviço gerenciado do Cloud Dataflow no GCP, um serviço de terceiros como o Spark e o Flink ou um executor de canal local, que faz isso diretamente no ambiente local, o que é útil principalmente para fins de desenvolvimento e testes.

Com o Cloud Dataflow, você tem certeza de que os elementos são processados um a um e exatamente uma vez, além de poder usar a gestão de janelas de tempo e os acionadores para agregar eventos com base no horário do evento, o horário real em que eles ocorreram, em vez de usar o horário de processamento, aquele em que eles foram enviados para o Cloud Dataflow. Algumas mensagens podem ficar desatualizadas em relação à origem devido a problemas na conexão móvel da Internet ou de bateria descarregada, mas ainda assim é recomendável agrupar eventos por sessão de usuário. O recurso interno de janela de sessão do Cloud Dataflow oferece esse suporte. Consulte The world beyond batch: Streaming 101 para ler uma excelente introdução sobre as estratégias de janela de dados.

Como alternativa, caso os eventos tenham um campo exclusivo de sessão como um identificador exclusivo universal (UUID, na sigla em inglês), use essa chave para agrupar os eventos relacionados. A melhor escolha depende do cenário específico.

BigQuery: armazenamento de dados totalmente gerenciado para análise de dados em grande escala

O BigQuery consiste de duas partes principais: um sistema de armazenamento que fornece persistência de dados com redundância geográfica e alta disponibilidade, e um mecanismo de análise que permite executar consultas similares a SQL em grandes conjuntos de dados. No BigQuery, os dados são organizados em conjuntos de dados que contêm várias tabelas. É necessário definir um esquema para cada tabela. Com o job principal do Cloud Dataflow, na seção anterior, você estrutura os dados brutos de evento no formato JSON para um esquema do BigQuery usando o conector interno dele.

Depois que esses dados são carregados em uma tabela do BigQuery, as consultas SQL interativas podem ser executadas nessa tabela para que informações valiosas seja extraídas. Ele foi desenvolvido para escalas muito grandes e permite que você execute consultas de agregação em conjuntos de dados na escala de petabytes com tempos rápidos de resposta. Isso é ótimo quando aplicado em análises interativas.

Ferramentas de visualização de dados

Com o O Google Data Studio, é possível criar e compartilhar painéis interativos com acesso a uma ampla variedade de fontes de dados, incluindo o BigQuery.

Também é possível integrar o BigQuery a várias ferramentas de visualização e BI de terceiros conhecidas, como o Tableau e o QlikView. Caso você esteja familiarizado com os blocos de notas do Jupyter (antigo IPython), o serviço Cloud Datalab tem conectividade integrada ao BigQuery. Por fim, é possível executar consultas do BigQuery diretamente do Planilhas Google e do Microsoft Excel.

Processamento em massa usando padrão de lote

O outro padrão principal é o processamento normal de grandes conjuntos de dados vinculados que não precisam ser processados em tempo real. Os pipelines de lote geralmente são usados para criar relatórios ou são combinados com origens em tempo real para oferecer a situação ideal: dados históricos confiáveis que incluam as informações mais recentes, provenientes dos pipelines de stream em tempo real.

Processamento em lote de eventos e registros dos servidores de jogo

Figura 5: processamento em lote de eventos e registros dos servidores de jogo

O Cloud Storage é o local recomendado para armazenar grandes arquivos. Ele é um serviço de armazenamento de objetos durável, de alta disponibilidade e custo acessível. Mas então surge a primeira dúvida: como colocar os dados no Cloud Storage? A resposta depende das suas fontes de dados, e este é o assunto das próximas seções. Você conhecerá três diferentes cenários de fontes de dados: locais, outros provedores de nuvem e o GCP.

Cenário 1: transferir arquivos de servidores locais

Há vários métodos para transferir arquivos de registro do seu data center local com segurança. A maneira mais comum é usar o utilitário de linha de comando de código aberto gsutil para configurar as transferências recorrentes de arquivos. Entre os recursos disponíveis no comando gsutil, estão incluídos os uploads de vários threads em paralelo, quando há muitos arquivos, a sincronização automática de um diretório local, os uploads que podem ser retomados, para arquivos grandes e, para arquivos muito grandes, a divisão deles em partes menores, além do upload em paralelo. Esses recursos reduzem o tempo de upload e maximizam o uso da conexão de rede.

Se você não tem largura de banda de Internet suficiente para fazer os uploads em tempo razoável, conecte-se diretamente ao GCP por Peering direto ou por meio do Carrier Interconnect. Como alternativa, caso você prefira enviar mídias físicas, há um serviço de terceiros chamado Offline Media Import/Export que recebe essa mídia e faz o upload em seu nome.

Cenário 2: transferir arquivos de outros provedores de nuvem

Alguns arquivos de registro podem estar armazenados em outros provedores de nuvem. Talvez você execute um servidor de jogo e a saída dos registros seja enviada para o serviço de armazenamento desse provedor. Ou o serviço que você usa tem um destino de armazenamento padrão. Por exemplo, o Amazon Cloudfront, um serviço de rede de entrega de conteúdo (CDN, na sigla em inglês), armazena os registros em um intervalo do Amazon S3. Felizmente, transferir os dados do Amazon S3 para o Cloud Storage é bem simples.

Se você está transferindo grandes quantidades de arquivos diariamente do Amazon S3 para o Cloud Storage, você pode usar o Serviço de transferência de armazenamento para transferir arquivos de fontes, incluindo os serviços Amazon S3 e HTTP/HTTPS. As transferências recorrentes podem ser configuradas de maneira regular e várias opções avançadas estão disponíveis nesse serviço de transferência. Ele usa a grande capacidade de largura de banda entre os provedores de nuvem e técnicas avançadas de otimização de largura de banda para proporcionar altas velocidades de transferência.

A orientação é usar esse serviço para transferências de 1 TB a 10 TB ou mais, porque isso evita a sobrecarga operacional de executar a ferramenta gsutil, mencionada no cenário 1, em vários servidores. Para transferências menores, ou quando você precisa mover dados várias vezes por dia, usar a ferramenta gsutil mencionada no cenário 1 é uma boa escolha.

Cenário 3: os dados já estão no GCP

Em alguns casos, os dados já são armazenados automaticamente no Cloud Storage, por padrão. Por exemplo, os dados da Google Play Store, incluindo revisões, relatórios financeiros, instalações, falhas e relatórios de ANR, estão disponíveis em um intervalo do Cloud Storage, na conta de desenvolvedor do Google Play. Quando isso acontece, mantenha os dados no intervalo original para onde foram exportados, a menos que haja razões para movê-los para outro intervalo.

Padrão de serviço de transferência assíncrona

Uma abordagem escalável e de longa duração é a implementação de um padrão de serviço de transferência assíncrona, em que você usa uma ou mais filas e mensagens para iniciar as transferências com base em eventos ou acionadores. Por exemplo, quando um novo arquivo de registro é gravado no disco ou no armazenamento de arquivos de origem, uma mensagem é enviada para a fila. Os trabalhadores executam o job de transferência desse objeto para o Cloud Storage, removendo a mensagem da fila somente após a conclusão dele.

Padrão alternativo de lote: carregamento direto do Cloud Storage para o BigQuery

Talvez você esteja se perguntando se é realmente necessário usar o Cloud Dataflow entre o Cloud Storage e o BigQuery. Para carregar os arquivos JSON diretamente no Cloud Storage, forneça um esquema e inicie um job de carregamento ou consulte diretamente os arquivos de backup CSV, JSON ou Cloud Datastore em um intervalo do Cloud Storage. Essa solução é aceitável para os primeiros passos, mas lembre-se das vantagens de usar o Cloud Dataflow:

  • Transformar os dados antes de fazer o commit para o armazenamento. Por exemplo, é possível agregar os dados antes de carregá-los para o BigQuery, agrupando tipos diferentes de dados em tabelas separadas. Isso ajuda a reduzir os custos do BigQuery, porque minimiza o número de linhas a serem consultadas. Em um cenário real, use o Cloud Dataflow para calcular os placares das sessões individuais ou coortes como clãs e equipes.

  • Uso intercambiável de canais de dados em lote e em streaming desenvolvidos no Cloud Dataflow. Quando você altera a fonte e o coletor de dados, por exemplo, do Cloud Pub/Sub para o Cloud Storage, o mesmo código funciona para os dois cenários.

  • Maior flexibilidade em termos de esquema de banco de dados. Por exemplo, quando campos são adicionados aos eventos ao longo do tempo, talvez seja necessário adicionar os dados brutos JSON a um campo "pega-tudo" no esquema e usar a funcionalidade de consulta de JSON do BigQuery para consultar esse campo. Desse modo, você consegue consultar várias tabelas do BigQuery, mesmo que o evento de origem requeira esquemas diferentes. Isso é mostrado na figura 6.

Coluna adicional para capturar novos campos de evento no JSON bruto

Figura 6: coluna adicional para capturar novos campos de evento no JSON bruto

Considerações operacionais das arquiteturas de referência

Depois de estabelecer e criar os pipelines, é importante monitorar o desempenho e as exceções. A interface do usuário de monitoramento do Cloud Dataflow tem uma visualização gráfica dos jobs do pipeline de dados, bem como as métricas importantes. Veja uma amostra disso na captura de tela da figura 7.

Console interno de monitoramento do Cloud Dataflow

Figura 7: console interno de monitoramento do Cloud Dataflow

Com o console do Cloud Dataflow, você tem as informações sobre o gráfico de execução do canal, e também as estatísticas de desempenho atuais como o número de mensagens processadas em cada etapa, atraso estimado do sistema e marca d'água dos dados. Para mais informações detalhadas de como o Cloud Dataflow está integrado com o serviço Stackdriver Logging, veja o exemplo na captura de tela da figura 8.

Stackdriver Logging integrado com o Cloud Dataflow

Figura 8: Stackdriver Logging integrado com o Cloud Dataflow

Documentos e recursos adicionais

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…