O caso
O projeto estava pronto. Faltava escolher o servidor.
Com os projetos organizados, o Isaac abriu a tela para criar a primeira VM da loja e encontrou dezenas de tipos de máquina, vários tipos de disco e uma lista de sistemas operacionais.
Escolher grande demais era desperdício. Escolher pequeno demais derrubaria a loja na Black Friday.
Este post parte de Máquinas Virtuais, de Modelos de Serviço na Nuvem e de Google Cloud: o ponto de partida.
O problema
Uma VM sob medida
Cada carga de trabalho pede uma combinação diferente de processador, memória, disco e rede. Uma VM com recursos demais desperdiça dinheiro, e uma com recursos de menos trava no pico.
E uma VM sozinha é um ponto de falha: se ela cair, a loja cai junto.
A solução
O Compute Engine
O Compute Engine é o serviço de VMs do Google Cloud. É IaaS, como vimos em Modelos de Serviço: o Google cuida do hardware e da virtualização, e você cuida do sistema operacional para cima. As VMs ficam num projeto, numa zona de uma região, ligadas a uma rede VPC.
Ao criar uma VM, você escolhe quatro coisas:
Zona (zone)
Onde a VM roda, dentro de uma região. Perto dos clientes, para reduzir a latência.
Na loja: São Paulo, southamerica-east1.
Tipo de máquina (machine type)
Quantos processadores (vCPUs) e quanta memória a VM tem.
Na loja: o suficiente para o pico, sem sobrar muito.
Imagem (image)
O sistema operacional e o software de partida da VM, como uma versão do Linux ou do Windows.
Na loja: uma imagem de Linux com o sistema de pedidos instalado.
Disco (disk)
Onde ficam o sistema operacional e os dados. Há vários tipos, que veremos a seguir.
Na loja: um disco que sobrevive se a VM for apagada.
A cobrança é por segundo, com mínimo de um minuto. Se a VM for desligada, você deixa de pagar pelo processador e pela memória, mas o disco continua cobrando.
Um recurso próprio do Google é a migração ao vivo (live migration): quando o Google faz manutenção no servidor físico, a VM em execução é movida para outro sem ser reiniciada.
Tipos de máquina
Famílias de máquina
Os tipos de máquina se agrupam em famílias, cada uma pensada para um perfil de carga:
| Família | Para que serve | Na loja |
|---|---|---|
| Uso geral (general-purpose) | Equilíbrio entre processador e memória, o ponto de partida para a maioria das cargas | O site e o sistema de pedidos |
| Otimizada para computação (compute-optimized) | O maior desempenho por núcleo, para cálculo pesado | O cálculo de frete em lote |
| Otimizada para memória (memory-optimized) | Muita memória por núcleo, para dados que cabem na RAM | Um banco de dados em memória |
| Otimizada para armazenamento (storage-optimized) | Muito disco local, com leitura e escrita rápidas | Um banco com muita escrita |
| Otimizada para aceleradores (accelerator-optimized) | GPUs e outros aceleradores, para aprendizado de máquina | Recomendação de produtos |
Em algumas séries, em vez de um tamanho pronto, você monta um tipo de máquina personalizado: escolhe a quantidade de vCPUs e de memória que a carga precisa, e paga só por isso.
Dados
Discos e imagens
A VM parte de uma imagem: um modelo com o sistema operacional. O Google oferece imagens públicas, e você pode criar imagens personalizadas com o seu software já instalado, para criar VMs iguais em minutos.
Os dados ficam em discos, como o armazenamento em bloco que vimos antes. O Compute Engine tem três opções:
- Persistent Disk: disco em rede, replicado e durável. É o disco clássico das VMs, muito usado como disco de boot.
- Hyperdisk: disco em rede, também durável, com mais desempenho e tamanho e velocidade ajustáveis.
- Local SSD: disco ligado fisicamente ao servidor, o mais rápido, mas os dados se perdem se a VM for parada.
Uma cópia do disco em um momento no tempo é um snapshot, o jeito de fazer backup.
Não confunda
Disco persistente × Local SSD
Persistent Disk e Hyperdisk
“Os dados precisam sobreviver à VM?”
- Exemplo
- O banco de dados de pedidos da loja.
- Foco
- Durável: os dados continuam se a VM for parada ou apagada.
Local SSD
“Preciso da leitura e escrita mais rápidas, e os dados são descartáveis?”
- Exemplo
- Um cache temporário, que a loja recria quando precisa.
- Foco
- Muito rápido, mas perde os dados quando a VM é parada.
Escala
Escala e disponibilidade
Para não depender de uma VM só, você cria um modelo de instância (instance template), que guarda a receita da VM: tipo de máquina, imagem e disco. Com ele, forma um grupo gerenciado de instâncias (MIG, de managed instance group), que cuida de várias VMs iguais como se fossem uma só.
O grupo oferece:
- Autoscaling: acrescenta VMs quando a demanda sobe e as remove quando ela cai. É a elasticidade na prática.
- Autohealing: um teste de saúde verifica cada VM, e a que falhar é recriada automaticamente.
- Distribuição por zonas: um grupo regional espalha as VMs por várias zonas, e a falha de uma zona não derruba tudo.
- Atualização automática (rolling update): troca as VMs por uma versão nova do modelo, aos poucos.
Preço
Como pagar pela VM
Os modelos de preço de Custos na Nuvem têm nomes próprios no Compute Engine:
| Modelo | No Compute Engine | Quando usar |
|---|---|---|
| Sob demanda (on-demand) | Preço padrão, cobrado por segundo | Carga imprevisível |
| Uso contínuo (sustained use) | Desconto automático para VMs que ficam ligadas boa parte do mês, em alguns tipos de máquina | Carga que roda muito, sem planejar |
| Compromisso (committed use) | Committed Use Discounts, por 1 ou 3 anos | Carga constante e previsível |
| Capacidade ociosa (spot) | Spot VMs, com desconto de até cerca de 90%, que o Google pode interromper | Carga que tolera interrupção |
O desconto por uso contínuo é uma característica marcante do Google Cloud: ele é automático, sem compromisso nem contrato.
Termos-chave
Seis termos para fixar
Toque no cartão para ver a definição.
Teste rápido
Três perguntas, estilo prova
01
Uma carga de trabalho precisa de muita memória por núcleo, como um banco de dados que mantém os dados na RAM. Qual família de máquina escolher?
02
Uma VM de um grupo gerenciado falha no teste de saúde. O que o grupo faz?
03
Os dados de uma VM precisam sobreviver se ela for parada ou apagada. Onde guardá-los?
Em prova, o Compute Engine é a resposta quando a carga precisa de uma VM com controle sobre o sistema operacional. O que muda de uma questão para outra é o detalhe: a família pelo perfil de carga, o disco pela durabilidade, o grupo gerenciado para crescer e se recuperar, e o modelo de preço pela previsibilidade. Para o Isaac, o próximo passo é rodar a loja sem administrar VMs.