Tradicionalmente, muitas empresas recorrem ao Mixpanel para fazer product analytics e entender a jornada de cada usuário. Mas, quando o produto deslancha e o volume de eventos dispara, o Mixpanel pode ficar caro. Neste post, mostramos um projeto com a Jelly Button no qual desenhamos uma solução própria de event analytics no Google Cloud Platform, de forma bem eficiente, que vai economizar cerca de um quarto de milhão de dólares por ano para a empresa.
A Jelly Button Games desenvolve e publica jogos interativos para mobile e web. Foi fundada em 2011, e seu carro-chefe é o Pirate Kings, em que os jogadores se enfrentam para conquistar ilhas exóticas, acumular ouro e virar o senhor dos sete mares no que a Jelly Button Games chama de experiência "mingle-player". Lançado em 2014, o jogo já passou de 70 milhões de downloads em iOS, Android e Facebook.
Aqui na DoiT International, ajudamos startups a arquitetar, construir e operar soluções de dados altamente robustas em Google Cloud Platform e Amazon Web Services. Junto com o time da Jelly Button, liderado por Meir Shitrit e Nir Shney-Dor, montamos um pipeline de dados global, robusto e seguro, que processa e armazena milhões de eventos por hora.
Usamos a Arquitetura de Referência do Google para Mobile Gaming Analytics como ponto de partida para nossa solução.
Arquitetura de Referência do Google para Mobile Gaming Analytics
Os requisitos
A Jelly Button cria jogos jogados por mais de 70 milhões de pessoas no smartphone. Cada jogador envia eventos relacionados ao jogo para o backend de analytics. Esses eventos precisam ser armazenados para processamento e análise posteriores. A Jelly Button usa esses dados para análise dos jogos, pesquisa e marketing.
Esse backend precisa manter latência muito baixa, para que o app mobile espere o mínimo possível ao enviar os eventos, processando o maior número possível de eventos por segundo. Dito isso, os dados de evento são críticos e nenhuma perda pode ser tolerada.
Por fim, os dados precisam ficar disponíveis para análise o quanto antes, e os milhões de eventos que chegam a cada hora não podem dificultar análises mais complexas.
A solução
Desde o começo, ficou claro que a melhor ferramenta para armazenar e analisar esse tipo de dado é o Google BigQuery: ele oferece armazenamento praticamente ilimitado, consultas extremamente rápidas e um mecanismo de ingestão nativo que permite inserir até 100 mil registros por segundo por tabela.
Por outro lado, precisávamos de uma infraestrutura de backend rápida, global e robusta, capaz de escalar automaticamente para garantir baixa latência a milhões de usuários ou reduzir para manter o custo no mínimo. Optamos pelo Google Container Engine (GKE), que é um cluster Kubernetes gerenciado.
Com o Kubernetes, montamos um backend bastante eficiente, implantado como cluster federado — um nos Estados Unidos e outro na Europa, ambos atendendo o tráfego que chega por um único Google HTTP/S Load Balancer global, com geo-awareness embutido, garantindo latência mínima para os clientes mobile.
Outro desafio era encaminhar os eventos recebidos pelo backend e armazená-los de forma confiável no Google BigQuery. Para preservar a baixa latência do backend, escolhemos o Google Cloud Pub/Sub. O Pub/Sub funciona como um canal de mensagens muito rápido, com taxa ilimitada, entrega global garantida e até 7 dias de persistência de mensagens.
Modelo publish/subscribe do Cloud Pub/Sub com armazenamento persistente
O último componente que faltava era um ETL capaz de lidar com o grande volume de mensagens vindas do Google PubSub e fazer filtragem, mapeamento e agregações sobre os dados brutos antes de armazená-los no Google BigQuery para análise. Por sorte, o Google Dataflow oferece um cluster totalmente gerenciado de workers, capaz de executar nosso ETL em modo streaming para fazer essas transformações e agregações em near realtime, deixando os dados disponíveis para análise quase que instantaneamente.
Visão geral da solução
Kubernetes
Na nossa configuração, cada pod tem dois containers: um nginx e um nodejs com o código do backend.
O código do backend é, basicamente, um servidor simples em nodejs
https://gist.github.com/spark2ignite/d9e927f589f2b3b998988b913ee27dc4
O backend só adiciona alguns metadados e envia o payload junto para o Google PubSub. Nada além disso é feito por aqui, justamente para manter a latência baixa.
O serviço implantado escala automaticamente com o Horizontal Pod Autoscaler do Kubernetes
https://gist.github.com/spark2ignite/26a9fbeeea279394730ac39b9c1b1df1
O próprio cluster também escala automaticamente pelo Google Container Engine Node Autoscaler, então os nós sobem e descem sozinhos.
Google Cloud Dataflow
A maior parte da lógica de transformação e agregação roda dentro do pipeline do Dataflow. Assim, ela é executada de forma assíncrona e não bloqueante, no cluster de computação distribuída do Dataflow.
O pipeline básico faz o parse das mensagens vindas do Google PubSub e grava alguns campos em colunas do BigQuery, mantendo o restante dos dados como um objeto json em uma coluna do tipo string.
https://gist.github.com/spark2ignite/a833f04c98d38c11a7398967835c9317
Para adicionar funcionalidades, geralmente basta editar a classe Mapping correspondente
https://gist.github.com/spark2ignite/35b78bb689060eb630468e0e8616b70f
Repare na linha:
options.setStreaming(true);É ela que faz o pipeline do Dataflow rodar em modo streaming. Ele não para até ser interrompido manualmente e segue processando as mensagens conforme elas chegam ao Google Pub/Sub, em near realtime.
Custos
A Jelly Button começou essa jornada de construir o próprio pipeline de dados para reduzir os custos com o Mixpanel e ganhar um pipeline de analytics mais flexível.
Em julho de 2017, o novo pipeline de analytics estava processando cerca de 500 eventos por segundo. Resumo dos nossos custos no Google Cloud Platform:
- Cerca de US$ 500 com Google Cloud Dataflow
- Cerca de US$ 500 com Google Container Engine
- Cerca de US$ 200 com Google Pub/Sub
- Cerca de US$ 100 com Google BigQuery
A Jelly Button acompanha e controla seus custos no Google Cloud Platform com o DoiT Cloud Intelligence™. Veja como fica o gasto médio diário da Jelly Button:
Resumo
O projeto inteiro levou cerca de 5 semanas. Passamos um bom tempo com a Jelly Button para arquitetar a solução, montar uma prova de conceito e, por fim, programar e testar com tráfego real. Já são alguns meses em produção e estamos confiantes de que a Jelly Button agora tem um pipeline de analytics robusto, pronto para suportar muitos milhões de novos jogadores em Pirate Kings e nos próximos jogos.