Escala e Balanceamento de Carga no Google Cloud

Este post parte de Máquinas Virtuais e de Compute Engine. A VM já sabemos criar; o que falta é fazer várias delas trabalharem como uma só.

O problema

Uma VM é um ponto único de falha

Uma VM sozinha tem dois limites. Quando o tráfego sobe, ela não dá conta, e quem precisa mexer nela é a equipe, à mão. Quando ela para, a loja para junto.

Criar mais VMs resolve a capacidade, mas abre outra pergunta: quem escolhe qual VM atende cada cliente, e quem percebe que uma delas está doente?

A solução

Um grupo de VMs iguais

Um grupo gerenciado de instâncias (managed instance group, ou MIG) é um conjunto de VMs criadas a partir do mesmo modelo de instância (instance template). O modelo guarda a receita: tipo de máquina, imagem, disco e script de inicialização. Quando o grupo precisa de mais uma VM, ela nasce idêntica às outras.

Com o grupo, você descreve o resultado, e não cada máquina. Por exemplo: "quero entre duas e dez VMs do site, e quero mais quando a CPU média passar de 70%". O Google Cloud acrescenta ou remove VMs para cumprir isso. Esse é o autoscaling.

Recuperação

O grupo troca a VM que adoeceu

O grupo pode verificar cada VM com um health check de aplicação: uma requisição periódica a uma página ou a uma porta da aplicação. Se a resposta não vier como esperado várias vezes seguidas, o grupo apaga a VM e cria outra a partir do modelo. Esse processo é o autohealing.

Existe um detalhe importante: a VM nova demora para subir, e uma verificação feita cedo demais daria um falso alarme. Por isso o autohealing tem um atraso inicial (initial delay), em que as falhas são ignoradas enquanto a máquina ainda inicializa.

Quanto à abrangência, o grupo pode ser zonal (todas as VMs numa única zona) ou regional (VMs distribuídas em várias zonas de uma região). Se a zona inteira cair, o grupo regional continua com as VMs das outras zonas.

Atualização

Trocar a versão sem derrubar a loja

Quando o site ganha uma nova versão, não faz sentido parar o grupo para trocar as VMs de uma vez. O grupo oferece duas formas de atualizar:

• Atualização gradual (rolling update): as VMs são trocadas em lotes. Você define quantas podem ficar fora ao mesmo tempo, e o grupo espera cada lote ficar saudável antes de seguir.
• Atualização canary: uma parte pequena das VMs recebe a versão nova, e o restante continua na antiga. Se o comportamento for bom, o grupo inteiro passa a usar a versão nova. Se não for, você só precisa reverter a parte que mudou.

Para pedir uma porcentagem de VMs no canary, o grupo precisa ter pelo menos dez instâncias. Com um grupo menor, a escolha é em número de VMs.

Quem recebe o pedido

O balanceador de carga

O grupo cuida das VMs, mas alguém precisa receber o pedido do cliente e entregá-lo a uma VM saudável. Esse papel é do balanceador de carga (load balancer). No Google Cloud, o balanceador global tem um único endereço IP (anycast), que atende pedidos do mundo inteiro e os encaminha para os backends com o melhor caminho.

Um backend service reúne os grupos de VMs que recebem o tráfego. Cada backend tem um health check próprio. Quando uma VM deixa de responder ao check, o balanceador para de mandar pedidos para ela. Ele não apaga a VM: quem faz isso é o grupo.

Não confunda

Health check do balanceador × autohealing do grupo

Na prática, os dois trabalham juntos: o balanceador protege o cliente enquanto o grupo resolve o problema.

Na prática

Qual escolher

Termos-chave

Cinco termos para fixar

Teste rápido

Três perguntas, estilo prova

Escala e balanceamento aparecem em qualquer nuvem: grupos de VMs com autoscaling e balanceadores existem na AWS, no Azure e na Oracle Cloud, com outros nomes. A ideia é a mesma: a máquina que falha sai da rota, e a capacidade acompanha a demanda.