Google PCA: Migração, Modernização e Estratégia de Nuvem Híbrida — Guia de estudos
Faz parte do Google Professional Cloud Architect — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.
Visão Geral
Uma estratégia bem-sucedida de migração, modernização e nuvem híbrida alinha as escolhas de plataforma com os resultados de negócio, ao mesmo tempo que gerencia riscos de disponibilidade, integridade de dados, latência, segurança e custo. O caminho equilibra um rehost rápido para reduzir o risco do data center com uma refatoração direcionada para capturar os benefícios da nuvem. O modelo operacional deve evoluir junto com a tecnologia para sustentar as melhorias. Esta seção fornece um plano pragmático para avaliação e planejamento de ondas (waves), frameworks de decisão, mecânica da migração, integração híbrida, padrões de modernização, considerações sobre políticas e multinuvem, e otimização pós-migração, com ênfase em modos de falha e trade-offs.
Avaliação, Prontidão e Planejamento de Ondas (Waves)
Descoberta e análise de dependências
- Inventariar workloads, versões, kernels de SO, armazenamento, IAM e classificações de dados. Mapear dependências entre fluxos web→API→DB, serviços compartilhados (LDAP/AD, DNS, NTP), pipelines de batch e APIs externas.
- Usar profiling de aplicações e tracing distribuído em ambientes de pré-migração para revelar dependências ocultas e latência de cauda longa (long-tail). Ativar os VPC Flow Logs e a instrumentação no nível da aplicação (Cloud Logging, Cloud Monitoring, Cloud Trace).
- Identificar os limites de estado (state) e a gravidade dos dados (data gravity): tamanho, padrões de acesso (mix de R/W), expectativas de consistência e topologia de replicação.
Prontidão e competências
- Avaliar as competências em fundamentos de nuvem, IaC, CI/CD, SRE, segurança, redes e banco de dados. Definir um roteiro (roadmap) de treinamento e certificação baseado em funções e reservar tempo no orçamento para capacitação (upskilling) e acompanhamento em plantões (shadow on-calls).
- Estabelecer uma landing zone (projetos, pastas, Shared VPC, políticas da organização, coletores de auditoria, estratégia de CMEK) antes da primeira onda (wave).
Planejamento de ondas (waves) de migração
- Agrupar aplicações em ondas (waves) por afinidade e raio de impacto (blast radius): dados compartilhados, dependências síncronas e janelas de mudança. Trazer dependências de alto risco para a mesma onda (wave) ou usar stubs para elas com contratos de API bem definidos.
- Definir SLOs, RTO/RPO, critérios de rollback e portões de validação (validation gates) por onda (wave): verificações de schema, jornadas de usuário sintéticas, limites de performance.
- Preparar runbooks e gerenciamento de mudanças: passos de cutover, checkpoints, rollback e coleta de evidências para aprovação (sign-off).
Compatibilidade, licenciamento e baselining de performance
- Validar o suporte de SO e middleware no Compute Engine e em serviços gerenciados. Verificar os termos de licenciamento comercial, restrições de BYOL, requisitos de módulos de kernel e afinidades de hardware.
- Capturar baselines de CPU, memória, IOPS, throughput e latência com valores de pico e percentil 95 para dimensionar os recursos de destino e validar os benefícios.
Governança de dados
- Classificar dados PII/PCI. Planejar a desidentificação ou tokenização na ingestão usando o Cloud DLP. Definir políticas de auditoria, retenção e exportação antes que o primeiro log de produção seja armazenado.
Modos de falha comuns: dependências síncronas desconhecidas causando timeouts em cascata após o cutover; intervalos de IP sobrepostos bloqueando a conectividade; lacunas de conformidade de licença; falta de paridade no rollback onde mutações de dados não podem ser desfeitas.
Padrões de Migração, Movimentação de Dados e Cutover
Estrutura de decisão (os 6 Rs)
- Rehost: mover como está (as-is) para o Compute Engine. Tempo mais rápido para a nuvem, mudança mínima. Risco: carrega dívida técnica e dimensionamento ineficiente.
- Replatform: pequenas alterações para adotar serviços gerenciados (ex: Cloud SQL, Cloud Load Balancing). Benefícios operacionais mais rápidos com pouca alteração de código.
- Refactor: decompor ou conteinerizar para GKE/Cloud Run; adotar padrões orientados a eventos. Maior benefício a longo prazo com risco na entrega.
- Retire (Aposentar): remover sistemas não utilizados após o uso e as dependências serem comprovadamente ausentes.
- Retain (Manter): manter on-premises por motivos regulatórios ou de latência; integrar via nuvem híbrida.
- Relocate (Realocar): mover cargas de trabalho vSphere para o Google Cloud VMware Engine; preserva o ferramental e minimiza as mudanças.
Ferramentas de migração de computação e banco de dados
- O Migrate to Virtual Machines acelera o rehost para o Compute Engine, preservando discos e configuração de rede. Valide o suporte ao sistema operacional convidado (guest OS) e os drivers de kernel.
- O Database Migration Service fornece replicação online homogênea (ex: MySQL, PostgreSQL) para o Cloud SQL com baixo tempo de inatividade. Garanta que as configurações de binlog/replicação estejam corretas e que a latência suporte a sincronização quase em tempo real.
- Escolha bancos de dados que correspondam à carga de trabalho:
- Cloud SQL para necessidades relacionais gerenciadas; habilite o aumento automático de armazenamento e monitore a CPU perto de 75% por núcleo; acompanhe o atraso na replicação (replication lag) e faça sharding ou escale verticalmente se estiver se aproximando dos limiares.
- Bigtable para ingestão de séries temporais de baixa latência e alta taxa de transferência (ex: dados de sensores).
- Spanner para escala global e consistência forte; entenda a dependência tecnológica (lock-in) vs. a portabilidade.
- Movimentação de dados
- Storage Transfer Service para transferências contínuas ou agendadas; paraleliza e é ciente de novas tentativas (retry-aware).
- Transfer Appliance para cargas em massa únicas (de dezenas a centenas de TB) para reduzir o tempo e o risco de rede.
- gsutil e uploads compostos paralelos para conjuntos de dados de pequeno a médio porte.
Migração online vs. offline
- Online: replicação contínua com um cutover curto. Prós: tempo de inatividade mínimo; Contras: requer latência e largura de banda estáveis; cuidado para evitar a escrita dupla (dual-write).
- Offline: snapshot e importação em massa. Prós: simples e previsível; Contras: o tempo de inatividade é igual à duração da cópia.
Planejamento de cutover, rollback e controle de tempo de inatividade
- Diminua os TTLs do DNS dias antes do cutover, congele alterações não essenciais e agende uma janela de manutenção.
- Execute portões de validação: paridade de esquema, checksums ou contagem de linhas, testes de fumaça (smoke tests) da aplicação, tráfego canário (canary) e sondas de desempenho.
- Rollback: garanta alterações de esquema retrocompatíveis, feature flags e dados da fonte da verdade (source-of-truth) preservados. Evite escritas irreversíveis até que a estabilidade seja comprovada.
- Exemplo de expansão de disco de VM com tempo de inatividade mínimo:
- Redimensione o disco no Console ou na CLI:
undefined
- No Linux ext4:
undefined
Atualizações contínuas (rolling updates) de aplicativos com impacto mínimo no GKE:
undefined
Modos de falha comuns: perda de pacotes sobre o Cloud VPN interrompendo a replicação do banco de dados (use Dedicated Interconnect ou Partner Interconnect), divergência na escrita dupla durante o cutover, falta de verificações de saúde (health checks) interrompendo as atualizações contínuas.
Identidade Híbrida, Conectividade e Integração On-Premises
Identidade
- Mantenha o Active Directory como a fonte da verdade. Use o Google Cloud Directory Sync para sincronização de contas e grupos, e configure o SAML SSO para o acesso de usuários ao Google Cloud.
- Conceda o menor privilégio no IAM por meio de papéis, use contas de serviço (service accounts) para cargas de trabalho e prefira o Workload Identity Federation em vez de chaves de longa duração.
Conectividade e roteamento híbridos
- Use o Cloud VPN para necessidades iniciais de baixa taxa de transferência e testes; mude para o Dedicated Interconnect para largura de banda sustentada, menor latência e desempenho de replicação previsível. Implante anexos de VLAN (VLAN attachments) redundantes e HA VPN ou interconexões duplas para resiliência.
- Garanta que os intervalos de IP do Google Cloud não se sobreponham aos CIDRs on-premises para preservar a alcançabilidade de ponta a ponta.
Imponha o acesso em camadas com regras de firewall e tags. Exemplo para permitir apenas web→API:
undefined
Use o Private Service Connect e o acesso privado do Google para comunicação entre serviços sem saída para a internet (egress público); segmente com o VPC Service Controls quando apropriado.
DNS Híbrido: use o Cloud DNS com políticas de encaminhamento e de entrada/saída (inbound/outbound) para resolver nomes tanto on-premises quanto na nuvem.
Integração on-premises e latência
- Mantenha o estado próximo da computação ou vice-versa; se o banco de dados on-premises precisar permanecer como autoritativo, considere o App Engine flexible ou o Compute Engine com Cloud VPN/Interconnect para acesso privado.
- Introduza caches e filas para desacoplar caminhos síncronos e para absorver a variação de latência (jitter); meça a latência p95/p99, não apenas as médias.
Modos de falha comuns: CIDRs sobrepostos bloqueando rotas, redundância insuficiente da sessão BGP, vazamentos de DNS público ou de saída (egress) expondo serviços privados e protocolos “faladores” (chatty) não antecipados sofrendo em links de alta latência.
Modernização, Modelo Operacional e Otimização
Padrões de modernização de legado
- Padrão Strangler Fig: posicionar uma fachada de API na frente do monólito e rotear domínios incrementalmente para novos serviços.
- Conteinerização: padronizar imagens de base (preferir imagens slim como Alpine, quando compatível), ordenar as camadas do Dockerfile para armazenar em cache a instalação de dependências antes de copiar o código-fonte para reduzir o tempo de build e adotar um pipeline de CI/CD com testes automatizados em staging.
- Dados gerenciados: mover armazenamentos operacionais para bancos de dados gerenciados; escolher por domínio: Cloud SQL para transacional, Bigtable para séries temporais, Spanner para cargas de trabalho globalmente consistentes.
Validação de compatibilidade, consistência e desempenho de aplicações
- Confirmar o suporte a SO e middleware, limites de threads e conexões e semântica do sistema de arquivos. Validar a portabilidade de licenciamento e a medição de uso.
- Definir requisitos de consistência de dados (read-your-write, leituras monotônicas, eventual vs. forte). Alinhá-los aos bancos de dados de destino e padrões de acesso.
- Validar o desempenho com testes de carga e jornadas de usuário sintéticas; garantir que os orçamentos de SLO sejam alcançáveis após a migração.
Observabilidade e conformidade
- Instrumentar aplicações com Cloud Logging, Monitoring e Trace para localizar a latência entre microsserviços.
- Exportar logs de auditoria e alterações de política do IAM para o BigQuery e compartilhar com auditores por meio de views e IAM em datasets. Exportar métricas de longo prazo para o Cloud Storage para atender a requisitos de retenção de vários anos.
Modelo operacional e responsabilidade
- Adotar práticas de SRE: SLOs, orçamentos de erro, resposta a incidentes e postmortems sem atribuição de culpa. Definir a responsabilidade pelo serviço, runbooks e rotações de plantão (on-call).
- Usar IaC (ex: Terraform) para provisionar a infraestrutura de forma consistente. Esteja ciente de que o Deployment Manager é específico do Google, pode limitar a automação de recursos multinuvem e não é familiar para muitos engenheiros.
- Automatizar a consistência de políticas com Organization Policy, IAM Conditions, Config Sync e Policy Controller (OPA Gatekeeper) entre projetos e ambientes.
Estratégia multinuvem e trade-offs de lock-in
- Aumentar a portabilidade com Kubernetes, práticas de 12-factor app, contratos definidos por OpenAPI e abstrações de egresso de dados. Equilibrar a portabilidade com a carga operacional e o desempenho; serviços gerenciados reduzem o trabalho repetitivo (toil), mas podem aumentar o custo de troca.
Otimização de custo e desempenho; descomissionamento
- Escalar o Compute Engine stateless com grupos de instâncias gerenciadas e autoscaling; escolher serverless (Cloud Functions ou Cloud Run) para cargas de trabalho com picos (bursty) ou de MVP que se beneficiam da escalabilidade para zero.
- Redimensionar (rightsize) VMs, habilitar o autoscaling no GKE, aplicar descontos por uso contínuo e descomissionar artefatos não utilizados. Acompanhar a realização dos benefícios por meio de KPIs (disponibilidade, latência, custo por serviço).
- Descomissionar sistemas on-premise após um período de observação (cooling period) e confirmação de dependências. Arquivar ou excluir dados conforme a política de retenção e atualizar o CMDB.
Cenário de Problema Prático
A Acme Weather Networks precisa migrar sua plataforma de sensores em tempo real e uma UI de administração legada em J2EE de um data center on-premise para o Google Cloud. O sistema ingere dados de 50.000 sensores que enviam 10 leituras por segundo e armazena cinco anos de dados históricos (75 TB). Ele deve manter o acesso privado ao ERP e ao Active Directory on-premise durante a transição, minimizar o tempo de inatividade (downtime) de um banco de dados MySQL on-premise e eliminar falhas de replicação intermitentes observadas pela VPN.
Estabelecer uma landing zone segura
- Criar organização, pastas e projetos de prod/nonprod. Configurar uma Shared VPC com intervalos de IP não sobrepostos para garantir a alcançabilidade on-premise por meio de conectividade híbrida. Aplicar políticas da organização e exportações centralizadas de logs de auditoria para o BigQuery com acesso de privilégio mínimo.
- Justificativa: Evitar conflitos de roteamento e aplicar uma governança de base antes da chegada das cargas de trabalho.
Implementar identidade híbrida
- Configurar o Google Cloud Directory Sync para espelhar identidades e grupos do AD e configurar o SSO SAML. Usar contas de serviço e papéis personalizados do IAM para a plataforma e as cargas de trabalho.
- Justificativa: Mantém a identidade corporativa como a fonte da verdade e habilita o controle de acesso de privilégio mínimo.
Provisionar conectividade e planejar o desempenho
- Começar com HA Cloud VPN para dev/test. Para a replicação do banco de dados de produção e a ingestão constante de sensores, provisionar Dedicated Interconnect com anexos de VLAN duplos e sessões BGP.
- Justificativa: O Interconnect oferece menor latência e menos quedas de pacotes do que a VPN, estabilizando a replicação do MySQL e a ingestão de streaming.
Mover dados históricos de forma eficiente
- Solicitar Transfer Appliances, carregar o conjunto de dados de 75 TB on-premise, enviar e reidratar no Cloud Storage. Usar o Storage Transfer Service para atualizações incrementais contínuas, se necessário. Executar o Cloud DLP em logs de suporte para desidentificar PII antes do armazenamento no Bigtable ou BigQuery.
- Justificativa: A transferência em massa offline reduz o risco da janela de transição (cutover) e evita a saturação dos circuitos.
Realocar (rehost) a UI de administração J2EE
Usar o Migrate to Virtual Machines para fazer o lift-and-shift da VM J2EE para o Compute Engine. Colocar as instâncias em um grupo de instâncias gerenciadas atrás de um balanceador de carga HTTP(S). Aplicar regras de firewall por tags para forçar apenas os fluxos web→API→DB. Exemplo:
undefined
- Justificativa: Redução rápida de risco com um ambiente de execução familiar, ao mesmo tempo em que se impõem caminhos de rede de privilégio mínimo.
Migrar o MySQL para o Cloud SQL com tempo de inatividade mínimo
- Fazer o baseline do desempenho e habilitar o logging binário na origem. Usar o Database Migration Service para configurar a replicação contínua para o Cloud SQL. Habilitar o aumento automático de armazenamento e criar alertas para CPU próxima de 75% e atraso de replicação (replication lag) abaixo de 60 segundos.
- Justificativa: A migração online alcança baixo tempo de inatividade; o SQL gerenciado reduz o trabalho repetitivo (toil) e impõe SLOs operacionais.
Executar a transição (cutover) controlada
- Reduzir os TTLs do DNS 48 horas antes, congelar alterações de esquema e agendar uma janela de manutenção. Parar as escritas on-premise, garantir que o lag do DMS seja zero, executar checksums e testes de fumaça (smoke tests) da aplicação e, em seguida, apontar os clientes para o Cloud SQL. Manter um plano de rollback onde as escritas possam ser redirecionadas de volta para o ambiente on-premise se a validação falhar.
- Justificativa: Passos determinísticos limitam o RTO e mantêm a consistência dos dados.
Construir a ingestão para telemetria em tempo real
- Ingerir via Pub/Sub, processar com o Dataflow e armazenar as séries temporais no Bigtable para escritas e leituras de baixa latência. Manter a integração com o ERP privada sobre o Interconnect.
- Justificativa: O Bigtable corresponde ao perfil de séries temporais de alta vazão (throughput), e o Pub/Sub desacopla produtores com picos de dados (bursty) dos consumidores.
Conteinerizar serviços e introduzir CI/CD
Conteinerizar serviços stateless para o GKE. Otimizar Dockerfiles usando imagens de base slim e ordenando as camadas para que a instalação de dependências preceda a cópia do código-fonte. Implementar um pipeline de CI/CD com testes automatizados em staging e lançamentos canário (canary rollouts). Atualizar com tempo de inatividade mínimo:
undefined
- Justificativa: Melhora a velocidade de implantação, a confiabilidade e a escalabilidade sem uma reescrita completa (big-bang).
Aprimorar a observabilidade e a auditoria
- Instrumentar com Cloud Logging, Monitoring e Trace para identificar a latência entre microsserviços. Exportar logs de auditoria para o BigQuery e compartilhar views com escopo para auditores. Exportar métricas de longo prazo para o Cloud Storage para atender à retenção de cinco anos.
- Justificativa: A telemetria de alta fidelidade dá suporte aos SLOs e à conformidade.
Otimizar e descomissionar
- Habilitar o autoscaling em MIGs e GKE, redimensionar (rightsize) instâncias, aplicar descontos por uso contínuo e agendar cargas de trabalho que não são 24x7 em serverless (ex: Cloud Functions para tarefas auxiliares) para escalar para zero. Após a estabilidade e um período de observação (cooling period), descomissionar os sistemas on-premise, atualizar o CMDB e publicar os benefícios realizados.
- Justificativa: Capturar eficiências de custo e operacionais enquanto elimina despesas de execução dupla.
Operacionalizar e treinar
- Finalizar runbooks, matriz RACI, rotações de plantão (on-call) e orçamentos de SLO/erro. Entregar treinamentos direcionados e planos de certificação para fechar as lacunas de habilidades. Preferir o Terraform para IaC; observe que o Deployment Manager é específico do Google e pode não abranger recursos que não são do Google.
- Justificativa: Um modelo operacional maduro sustenta a confiabilidade e a velocidade para além do evento de migração.
← Confiabilidade · Todos os domínios · Operações →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →