Pokémon GO 2016: 50x o tráfego previsto no lançamento

01 · CONTEXTO

Um lançamento que ninguém dimensionou

Pokémon GO era um aplicativo móvel que usou mais de uma dúzia de serviços do Google Cloud.

O lançamento foi também a estreia de uma equipe nova do Google, a Customer Reliability Engineering (CRE). Seu primeiro cliente foi a Niantic, e a primeira missão foi justamente esse lançamento. A CRE é um modelo em que técnicos do Google se integram às equipes do cliente, criando responsabilidade compartilhada pela confiabilidade de aplicações críticas.

02 · A ESTIMATIVA E A REALIDADE

Alvo, pior caso e o que de fato chegou

A equipe mirou um tráfego de referência, chamado de 1X, e estimou um pior caso de cerca de 5X esse alvo. O tráfego real chegou a 50X o alvo inicial, dez vezes o pior caso. Uma segunda fonte resume o mesmo ponto como tráfego 50 vezes além do esperado.

O Cloud Datastore era o banco principal do jogo para registrar o mundo de Pokémon e virou um indicador direto da popularidade do jogo.

Em até 15 minutos do lançamento na Austrália e na Nova Zelândia, o tráfego passou bem da expectativa da Niantic. A empresa pediu reforço à CRE por causa do lançamento nos EUA, planejado para o dia seguinte.

03 · A ARQUITETURA

Jogadores, balanceador, contêineres e banco

A lógica da aplicação roda no Google Container Engine (GKE), baseado no Kubernetes. A Niantic o escolheu por orquestrar o cluster de contêineres em escala planetária, e o jogo foi o maior deployment de Kubernetes no Container Engine até então.

1. O aplicativo no celular dos jogadores gera o tráfego que chega ao jogo.

2. Antes da troca, o tráfego passava pelo Network Load Balancer, que depois foi substituído.

3. A lógica do jogo roda num cluster de contêineres no GKE, orquestrado pelo Kubernetes.

4. O Cloud Datastore guarda o mundo do jogo e serve de termômetro da demanda.

Em português simples: balanceador de carga na frente, uma camada de aplicação que se amplia adicionando nós e um banco gerenciado atrás. O caso mostra o que fazer quando essa estrutura precisa crescer muito além do previsto.

04 · ESCALAR EM PLENO VOO

Trocar o motor com o avião voando

Em preparação para o lançamento no Japão, a Niantic e a CRE fizeram o upgrade para uma versão nova do GKE, que permitia adicionar mais de mil nós ao cluster. A troca de versão foi feita com cuidado para não interromper jogadores existentes, enquanto milhões de novos jogadores entravam.

Na mesma linha, as equipes trocaram o Network Load Balancer pelo HTTP/S Load Balancer, um sistema global para tráfego HTTPS, com mais controle, conexões mais rápidas e maior vazão.

Do lado da capacidade, a CRE provisionou capacidade extra em nome da Niantic para ficar à frente do crescimento, e o Google provisionou muitas dezenas de milhares de núcleos para o cluster do jogo.

1. O cluster do GKE foi atualizado para comportar mais de mil nós adicionais, sem tirar o jogo do ar.

2. O balanceador de rede deu lugar ao HTTP/S Load Balancer, global e com mais vazão.

3. A CRE provisionou capacidade extra para a Niantic, mantendo o banco à frente do crescimento.

4. Com os ajustes, o lançamento no Japão ocorreu sem incidentes.

05 · RESULTADO E LIÇÕES

O que compensou e o que sobrou

As lições do lançamento nos EUA (capacidade generosa, versão nova do Container Engine e HTTP/S Load Balancer) compensaram quando o jogo foi lançado no Japão sem incidentes. Lá, o número de novos usuários foi o triplo do lançamento nos EUA duas semanas antes.

Nem tudo correu bem no lançamento. Engenheiros da Niantic e do Google trataram cada problema em sequência, criando e implantando soluções. Pela escala do cluster, muitos bugs foram identificados, corrigidos e incorporados ao projeto open source do Kubernetes.