Google ACE: Confiabilidade, Backup e Recuperação de Desastres — Guia de estudos

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Faz parte do Google Associate Cloud Engineer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Confiabilidade, backup e recuperação de desastres no Google Cloud exigem um projeto intencional que abranja domínios de falha, mecanismos de proteção de dados, gerenciamento de tráfego e prontidão operacional. Esta seção explica como estruturar serviços entre zonas e regiões, como proteger e restaurar dados com estado (stateful) e como validar os objetivos de recuperação com runbooks disciplinados e testes de resiliência contínuos. Ela também descreve os trade-offs da estratégia de DR e o planejamento de capacidade para garantir que a plataforma possa se recuperar dentro dos objetivos definidos de tempo de recuperação (RTO) e ponto de recuperação (RPO).

Domínios de Falha e Projeto Regional

• Zonas, regiões e serviços multirregionais

  • Zonas são os menores domínios de falha independentes. Uma única falha zonal não deve interromper um serviço regional.
  • Regiões agrupam zonas independentes com links de baixa latência. Projetos regionais sobrevivem a falhas zonais, mas não necessariamente a eventos regionais completos.
  • Serviços multirregionais replicam dados entre regiões, protegendo contra a perda de uma região a um custo mais alto e com latência de escrita potencialmente maior.
  • Princípio de projeto: evite pontos únicos de falha no menor domínio de falha que for importante para você. Se seu RTO/RPO exige sobreviver a uma falha zonal, implante em pelo menos duas zonas. Para capacidade de sobrevivência regional, implante componentes ativos em múltiplas regiões ou utilize serviços multirregionais.

• Managed instance groups (MIG) e autorrecuperação (self-healing)

  • Prefira MIGs regionais para distribuir instâncias entre as zonas de uma região. Isso mitiga interrupções zonais sem a necessidade de ferramentas separadas.
  • As verificações de integridade (health checks) do load balancer removem VMs não íntegras do tráfego. O autohealing do MIG substitui VMs não íntegras ou que não respondem. Use ambos.
  • Use health checks de nível de aplicação HTTP(S) que verificam endpoints de prontidão (readiness) e dependências. Uma verificação TCP apenas valida a alcançabilidade da porta.
  • Modo de falha por má configuração do autohealing: usar apenas o health check do load balancer impede o tráfego para uma instância com problema, mas não a recria. Configure o health check próprio do MIG para a substituição e um atraso inicial (initial delay) para evitar reinicializações prematuras durante o boot.

Exemplo:

• Crie um health check de aplicação com intervalos de 10 segundos e 3 limiares de falha (unhealthy thresholds) para acionar a autorrecuperação após ~30 segundos: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Anexe o health check a um MIG regional para autorrecuperação: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Considerações multirregionais

  • O Global external HTTP(S) Load Balancing suporta backends em múltiplas regiões com failover automático baseado em health checks.
  • A sincronização de estado entre regiões é o trade-off crítico. A taxa de transferência (throughput) do modo ativo-ativo é alta, mas a consistência e a resolução de conflitos devem ser projetadas. O modo ativo-passivo é mais simples, mas tem um failover mais lento e um RPO potencialmente maior.

Proteção de Dados: Bancos de Dados, Armazenamento e Computação

• Alta disponibilidade e réplicas do Cloud SQL
  • A configuração de alta disponibilidade posiciona uma instância de standby em uma zona diferente com replicação síncrona. O failover automático ocorre em caso de falha da instância primária. O RTO é tipicamente de minutos; o RPO é ≈ 0 dentro de uma região, mas considere as transações em andamento.
  • As réplicas de leitura descarregam as operações de leitura e podem ser entre regiões (cross-region) para DR. Elas são assíncronas; espere atraso na replicação (replication lag) e um RPO diferente de zero.
  • Backups e PITR
    • Habilite backups automatizados e recuperação point-in-time (PITR). Para o MySQL, habilite o logging binário; para o PostgreSQL, habilite a retenção para PITR.
    • Fluxos de restauração: em caso de corrupção ou erro do usuário, restaure para uma nova instância em um timestamp específico, aponte as aplicações ou réplicas para a instância restaurada e valide os dados.
  • Modos de falha e trade-offs
    • A alta disponibilidade (HA) não protege contra corrupção lógica de dados; backups e PITR, sim.
    • Réplicas entre regiões (cross-region) protegem contra a perda de uma região, mas podem ter atraso; teste seu RPO aceitável.

Exemplo:

• Habilitar logging binário (MySQL) e backups automatizados:

undefined

• Snapshots de Persistent Disk (PD) e imagens de máquina
  • Os snapshots de PD são backups incrementais e com consistência de falha (crash-consistent) dos discos. O local de armazenamento deles é configurável e eles podem ser usados para criar novos discos em qualquer zona dentro do escopo de localização do snapshot.
  • Para obter backups com consistência de aplicação (application-consistent), coloque o sistema de arquivos e a aplicação em modo quiescente ou coordene os snapshots com mecanismos de backup específicos do banco de dados.
  • As imagens de máquina capturam os discos e os metadados da instância (discos de boot, discos anexados, propriedades da instância). Use imagens de máquina para uma recuperação mais rápida da frota ou para clonar uma configuração de servidor padrão (golden server).
  • As políticas de agendamento de snapshots automatizam os backups; impõem a retenção; e tagueiam os discos críticos adequadamente.
  • Fluxo de trabalho de restauração: crie um disco a partir de um snapshot, anexe-o a uma nova instância, atualize os scripts de inicialização e as contas de serviço e, em seguida, valide a integridade da aplicação antes de reintroduzir o tráfego.

Exemplo:

• Criar um snapshot e restaurar para um novo disco:

undefined

undefined

• Replicação, versionamento e retenção do Cloud Storage
  • Opções de classe de armazenamento: Standard para dados de acesso frequente (hot data); Nearline para acesso mensal infrequente; Coldline para acesso trimestral (recomendado para backups e DR); Archive para dados de longo prazo e raramente acessados.
  • Buckets Regionais, de Duas Regiões (Dual-Region) e de Múltiplas Regiões (Multi-Region) oferecem durabilidade por meio da replicação. O Dual-Region com replicação turbo pode restringir o RPO de replicação para objetos recém-escritos; o Multi-Region oferece ampla resiliência geográfica.
  • O versionamento de objetos protege contra exclusões e substituições acidentais, mantendo as versões não atuais. Combine-o com políticas de retenção e Bucket Lock para impor a retenção WORM.
  • Proteção contra exclusão acidental: habilite o Object Versioning, use uma política de retenção com um lock, implemente retenções baseadas em eventos (event-based holds) para bloqueios legais ou de processamento, restrinja exclusões por meio do IAM e do acesso uniforme no nível do bucket. Para acesso externo com prazo definido, use URLs assinadas (signed URLs) com expirações rigorosas.

Exemplo de ciclo de vida para mover para Coldline após 90 dias e excluir após 365 dias:

• lifecycle.json

undefined

• Aplicar:

undefined

Resiliência de Tráfego, Capacidade e Dependências

• DNS e failover de gerenciamento de tráfego

  • Prefira o Global External HTTP(S) Load Balancing para serviços voltados para a internet; ele usa IPs anycast e realiza failover entre regiões com base em verificações de integridade.
  • Para serviços privados, use balanceadores de carga internos HTTP(S) ou TCP/UDP. Projete para independência de zona com múltiplos backends.
  • Trade-offs do TTL do DNS: TTLs baixos permitem um failover mais rápido, mas aumentam a carga de consultas e podem ser ignorados por alguns resolvedores devido ao comportamento de cache. O failover de LB baseado em verificação de integridade é mais rápido e mais determinístico do que o failover apenas por DNS.
  • Políticas de DNS ponderadas ou de failover podem ser um plano de controle de último recurso para a evacuação de uma região, mas dependem da expiração do cache.

• Planejamento de capacidade e design de cotas

  • Identifique a capacidade mínima íntegra por zona e por região. Aplique buffers de folga (headroom) para failover (capacidade de “zona N+1”).
  • Use reservas regionais para tipos de máquina (shapes) críticos do Compute Engine para garantir capacidade durante eventos de escalonamento ou failover.
  • Pré-provisione endereços IP, regras de encaminhamento, capacidade do Cloud NAT, rastreamento de conexões e certificados SSL para evitar atrasos no plano de controle durante a recuperação.
  • Solicite aumentos de cota bem antes de precisar deles; valide as cotas em regiões secundárias e para todas as dependências (ex: instâncias do Cloud SQL por região, regras de encaminhamento por VPC, throughput do Pub/Sub, QPS do Cloud KMS).
  • Considerações sobre o Autoscaling: configure cooldowns, autoscaling preditivo se necessário, e defina limites mínimo e máximo para manter exatamente uma instância quando exigido por política.

• Resiliência de dependências

  • Faça um inventário dos serviços upstream e downstream. Para cada um, defina o comportamento em caso de falha e os mecanismos de fallback: configuração em cache, modos degradados, circuit breakers, filas com tópicos de dead-letter e backpressure.
  • Valide o escopo do IAM e das contas de serviço nas regiões de recuperação. A falta de papéis (roles) comumente causa falhas silenciosas durante eventos de DR.
  • Chaves de criptografia: garanta que as réplicas de chaves do Cloud KMS ou as chaves multirregionais estejam alinhadas com a localização dos dados. Planeje a localidade do key ring e o IAM nas regiões secundárias.

Operações de Resiliência e Melhoria Contínua

• RTO, RPO, planos de recuperação e runbooks

  • O RTO define a rapidez com que o serviço deve ser retomado; o RPO define a perda de dados aceitável. Derive-os da análise de impacto nos negócios (business impact analysis).
  • Mapeie cada componente do sistema para mecanismos específicos que satisfaçam o RTO/RPO: alta disponibilidade (HA) para falhas de zona, replicação entre regiões para falhas regionais, backups para corrupção de dados e classe de armazenamento/replicação para durabilidade.
  • Mantenha runbooks: etapas precisas, comandos, acesso a credenciais, verificações de validação de integridade (health checks) e árvores de decisão. Armazene em um repositório versionado e com controle de acesso, e pratique regularmente.
  • Validação da recuperação: agende simulações para medir o RTO/RPO real, validar a integridade dos dados e coletar ações de melhoria. Teste tanto restaurações de escopo pequeno (tabela, disco) quanto a recuperação completa do site.

• Estratégias de DR e trade-offs

  • Ativo-ativo: todas as regiões atendem ao tráfego; RTO mínimo e RPO baixo se a sincronização de dados for projetada corretamente. Maior complexidade e custo; requer resolução de conflitos e balanceamento de carga global.
  • Ativo-passivo: a região primária está ativa; a secundária está em modo warm (pré-aquecida) e recebe dados replicados. Custo moderado; RTO de minutos a dezenas de minutos; RPO diferente de zero, dependendo da replicação.
  • Pilot-light: serviços críticos mínimos são executados na região secundária (replicação de banco de dados, footprint mínimo da aplicação). RTO de horas; custo-benefício eficiente; orquestração cuidadosa é necessária para escalar a computação durante o failover.
  • Cold-standby: infraestrutura definida como código, mas não provisionada. RTO de dias; custo mais baixo; risco de surpresas devido a desvios de configuração (drift), cotas e escassez de capacidade.

• Testes de caos e simulações de falha

  • Simule regularmente falhas de instâncias, travamentos de processos, falhas de health check, condições de disco cheio e interrupções de dependências. Use ferramentas ou scripts para encerrar instâncias, bloquear o tráfego de saída (egress) para backends ou injetar latência na camada de proxy.
  • Valide o autohealing do MIG e a remoção pelo LB falhando intencionalmente no endpoint de health check. Confirme o comportamento de substituição e os cronogramas de recuperação.
  • Pratique a evacuação regional: drene os backends em uma região, observe o failover do balanceador de carga global e verifique as dependências com estado (stateful) na região secundária.
  • Melhoria contínua: registre métricas de tempo médio para detectar (mean time to detect), tempo de failover e perda de dados durante os testes. Priorize correções que reduzam o RTO/RPO e eliminem etapas manuais.

Cenário de Problema Prático

A Brightlane Retail opera uma plataforma de e-commerce na região us-central1 com requisitos rígidos de disponibilidade e um RPO de quatro horas para os dados de pedidos. A liderança exige que a plataforma sobreviva a uma interrupção de zona sem tempo de inatividade (downtime) e a uma interrupção regional com impacto mínimo para o cliente.

Abordagem:

1. Implementar um MIG regional com autohealing por HTTP e um Global HTTP(S) Load Balancer

   • Justificativa: Um MIG regional distribui as instâncias entre zonas, e os health checks HTTP no nível da aplicação permitem a autorrecuperação (self-healing) após três verificações falhas de 10 segundos cada. O balanceador de carga global remove automaticamente as VMs não íntegras e direciona o tráfego por failover para as zonas íntegras.
   • Comandos: gcloud compute health-checks create http app-hc –check-interval=10s –timeout=5s –unhealthy-threshold=3 –request-path=/healthz gcloud compute instance-groups managed update web-rmig –region=us-central1 –health-check=app-hc –initial-delay=60

2. Habilitar a alta disponibilidade (HA) do Cloud SQL com uma réplica de leitura entre regiões e PITR

   • Justificativa: A alta disponibilidade regional oferece sobrevivência a falhas de zona com failover automático. Uma réplica de leitura (read replica) em us-east1 fornece DR regional com um RPO diferente de zero, mas limitado. Habilitar o PITR (point-in-time recovery, que usa o log binário para o MySQL) resolve a corrupção lógica, permitindo a restauração para um ponto específico no tempo.
   • Comandos: gcloud sql instances patch orders-mysql –enable-bin-log –backup-start-time=03:00 gcloud sql instances create orders-replica –master-instance-name=orders-mysql –region=us-east1

3. Proteger ativos de objetos com o Cloud Storage Dual-Region e políticas de ciclo de vida

   • Justificativa: Imagens de produtos e ativos estáticos são armazenados em um bucket dual-region para resiliência regional. As transições de ciclo de vida (lifecycle) movem artefatos mais antigos para o Coldline para otimizar custos, e o versionamento somado a políticas de retenção previnem a exclusão acidental de ativos críticos.
   • Etapas: Habilite o Versionamento de Objetos (Object Versioning), defina uma política de retenção de 30 dias para buckets críticos e aplique regras de ciclo de vida para mover para o Coldline após 90 dias e excluir após um ano para artefatos de build não críticos.

4. Agendar snapshots de Persistent Disk (PD) e criar imagens de máquina para serviços com estado (stateful)

   • Justificativa: Snapshots incrementais dos discos de VM fornecem opções de restauração rápidas e consistentes com o estado no momento da falha (crash-consistent). Imagens de máquina capturam a inicialização e a configuração para acelerar a reidratação dos servidores de aplicação durante um failover de região. Agendamentos de snapshot garantem backups consistentes e orientados por políticas.
   • Comandos: gcloud compute resource-policies create snapshot-schedule daily-2am –max-retention-days=14 –on-source-disk-delete=apply-retention-policy –start-time=02:00 gcloud compute disks add-resource-policies app-disk-1 –resource-policies=daily-2am gcloud compute machine-images create app-mi-2024-09-01 –source-instance=app-vm-template

5. Definir RTO/RPO e codificar runbooks de DR e IaC (Infrastructure as Code)

   • Justificativa: Defina um RTO no nível de serviço de 15 minutos para web/API e um RPO de quatro horas para pedidos. Os runbooks especificam procedimentos de failover de tráfego, promoção da réplica de leitura do Cloud SQL, contingências de DNS e etapas de verificação. A infraestrutura como código (Terraform/Deployment Manager) garante reconstruções determinísticas e reduz erros manuais.

6. Provisionar capacidade e cotas na região secundária

   • Justificativa: Crie reservas para tipos de VM críticos, provisione antecipadamente um backend de balanceador de carga em standby, certificados SSL, capacidade de NAT e verifique as cotas para Compute, SQL, regras de encaminhamento e KMS em us-east1. Isso evita a falta de capacidade durante um failover.

7. Validar a recuperação por meio de simulações de caos (chaos drills) e documentar melhorias

   • Justificativa: Simulações trimestrais de falha de zona validam o comportamento do MIG e do LB; a evacuação regional semestral promove a réplica de leitura em us-east1, aponta o LB global para os backends de us-east1 e mede o RTO/RPO. Os resultados impulsionam melhorias, como a redução de etapas manuais ou o aumento da capacidade da réplica.

Seguindo essas etapas, a Brightlane Retail alcança alta disponibilidade zonal com autorrecuperação automatizada e uma postura de DR regional com runbooks definidos e testados, garantindo que os dados de pedidos atendam a um RPO de quatro horas e que os serviços da aplicação se recuperem dentro dos limites de RTO estabelecidos.

← Segurança · Todos os domínios · Gerenciamento de Custos →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Google →