🌍 Migração Intercontinental com Snapshots Privados na Google Cloud: Aplicação Clínica em menos de 30 minutos

User Story

Neste projeto real, atuei como Especialista em Cloud em uma operação de migração de uma aplicação crítica de cadastros e um banco de dados MySQL de uma grande clínica localizada nos Estados Unidos. O desafio envolveu migrar as workloads entre continentes, saindo da região us-west1 (Oregon) para a região australia-southeast1 (Sydney), utilizando apenas recursos privados da infraestrutura da Google Cloud. Todo o processo foi realizado com foco em segurança, agilidade e disponibilidade, com tempo total de migração inferior a 30 minutos.

Arquitetura da Solução

🧱 Estrutura do Projeto

Parte 1 — Provisionamento de Infraestrutura em Oregon (EUA)

Inicialmente, configuramos duas instâncias de máquina virtual (VMs):

• usa-application-01 (Node.js)
• usa-database-01 (MySQL 8.0)

Ambas foram provisionadas na zona us-west1-b com o sistema operacional Debian 12 (Bookworm). Após a instalação dos serviços, a aplicação foi ajustada para se conectar ao banco via IP privado, reforçando o isolamento da rede.

Configurações principais:

• usa-database-01: instalação e configuração do MySQL com credenciais seguras.

• usa-application-01: instalação da aplicação Node.js, ajuste do arquivo index.js, instalação de dependências com NPM e liberação da porta 3000 para testes.

A aplicação foi testada com sucesso localmente, e os registros “Mike Mouse”, “Doug Dog” e “Cirrus Cloud” foram inseridos para validação pós-migração.

🔄 Parte 2 — Migração com Snapshots via Rede Privada

Após os testes, iniciamos a migração intercontinental com zero downtime perceptível e sem tráfego exposto à internet pública, seguindo estas etapas:

📸 Criação dos Snapshots

Com as VMs desligadas, criamos snapshots dos discos de ambas as instâncias originais:

gcloud compute disks snapshot usa-application-01 \
  --snapshot-names usa-application-snapshot --zone us-west1-b

gcloud compute disks snapshot usa-database-01 \
  --snapshot-names usa-database-snapshot --zone us-west1-b

🌐 Replicação na Austrália

Em seguida, criamos novos discos em australia-southeast1-a, utilizando como origem os snapshots acima:

gcloud compute disks create aus-app01 \
  --source-snapshot usa-application-snapshot --zone australia-southeast1-a

gcloud compute disks create aus-db01 \
  --source-snapshot usa-database-snapshot --zone australia-southeast1-a

🖥️ Provisionamento das Novas VMs

Criamos as novas instâncias usando os discos recém-criados:

gcloud compute instances create aus-app01 \
  --machine-type e2-micro --zone australia-southeast1-a \
  --disk name=aus-app01,boot=yes,mode=rw

gcloud compute instances create aus-db01 \
  --machine-type e2-micro --zone australia-southeast1-a \
  --disk name=aus-db01,boot=yes,mode=rw

Com as novas instâncias em funcionamento, atualizamos o index.js da aplicação para apontar para o novo IP privado do banco de dados e reiniciamos a aplicação com:

npm install
node src/index.js

✅ Validação e Conclusão

Acesse a aplicação através do IP público da aus-app01:3000 e confirme os cadastros realizados ainda nos EUA — dados e aplicação migrados com sucesso.

• 🔒 Toda a operação foi realizada em rede privada
• ⚡ Tempo total de replicação e boot: ~30 minutos
• 🌐 Latência reduzida na região final (Austrália)

📷 Evidências

• Screenshot das 4 instâncias: 2 nos EUA, 2 na Austrália

• Print da aplicação em aus-app01 com os dados migrados

🧹 Cleanup (Boas práticas)

• Deletar VMs antigas e snapshots para evitar custos.
• Manter registros de auditoria do Cloud Logging.

🧠 Conclusão

Este projeto demonstra a eficiência e o poder da Google Cloud Platform em processos de migração de aplicações críticas, sensíveis e geograficamente distribuídas. Utilizando práticas de DevOps e recursos nativos como snapshots e redes privadas, conseguimos alcançar uma migração rápida, segura e escalável.