Google PCD: Desempenho, Escalabilidade e Engenharia de Resiliência — Guia de estudos

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Visão Geral

A engenharia de performance, escalabilidade e resiliência no Google Cloud foca em manter um serviço de baixa latência e com custo-benefício sob carga variável, ao mesmo tempo que tolera falhas sem violar os SLOs. O design deve alinhar os sinais de autoscaling com as características do workload, posicionar dados e computação para minimizar a latência de cauda, e implementar controles de sobrecarga, tentativas (retries) e failover para evitar falhas em cascata. Esta seção detalha os padrões, controles e trade-offs importantes para desenvolvedores de aplicações nas camadas de computação, rede e dados.

Escalabilidade e Distribuição de Carga

Escalabilidade horizontal vs. vertical

A escalabilidade horizontal adiciona instâncias ou pods para aumentar a capacidade e a resiliência. Prefira para serviços stateless e quando precisar de elasticidade rápida. Use Managed Instance Groups (MIGs), revisões do Cloud Run ou Deployments do GKE.
A escalabilidade vertical aumenta o tamanho da máquina. É útil para workloads single-threaded ou limitados por memória (memory-bound), ou para reduzir a coordenação entre nós, mas oferece uma margem de crescimento limitada e tempos de reinicialização mais longos.
Concorrência: Ajuste a concorrência de requisições para corresponder a perfis limitados por CPU (CPU-bound) vs. limitados por E/S (I/O-bound). O Cloud Run suporta concorrência por revisão; pods do GKE podem servir múltiplas requisições se seu runtime for não bloqueante (non-blocking); para isolamento estrito, defina a concorrência como 1.

Sinais de autoscaling e capacidade aquecida (warm capacity)

O autoscaling de MIGs suporta utilização de CPU, utilização de balanceamento de carga e métricas personalizadas via Cloud Monitoring. Para tráfego em rajadas (bursty), baseie o escalonamento em métricas de requisição (rps, profundidade da fila) em vez de CPU.
O Horizontal Pod Autoscaler (HPA) do GKE pode escalar com base em CPU, memória ou métricas personalizadas/externas (ex: tamanho da fila do Pub/Sub). Use o Vertical Pod Autoscaler (VPA) para o dimensionamento correto (right-sizing), mas evite atualizações ao vivo do VPA em frontends que escalam rapidamente para prevenir rotatividade (churn).
O Cloud Run escala com base na carga de requisições concorrentes e, opcionalmente, em métricas personalizadas. Evite partidas a frio (cold starts) mantendo uma capacidade aquecida (warm capacity): configure instâncias mínimas, mantenha a concorrência ociosa baixa e pré-aqueça via pings de saúde sintéticos, se necessário.
O autoscaling preditivo em MIGs e a configuração de réplicas mínimas (min replicas) em Deployments/Revisões ajudam a mascarar a latência de provisionamento durante os picos diurnos.

Balanceamento de carga, distribuição de tráfego global, verificações de saúde e failover

Use o Application Load Balancer externo global para ter um VIP anycast mundial, HTTP/2 e HTTP/3, e terminação na borda (edge) com o Cloud CDN. Os backends podem ser instance groups, NEGs zonais/regionais, NEGs serverless (Cloud Run/Functions) ou GKE Ingress.
As verificações de saúde (health checks) desviam o tráfego de backends não saudáveis. Garanta que seus endpoints de verificação de saúde validem as dependências de forma restrita (ex: processo e recursos locais críticos) para evitar falhas circulares em interrupções de serviços dependentes (downstream).
As listas de permissão (allowlists) do firewall devem permitir os verificadores de saúde. Se as verificações na porta 80 falharem, permita os intervalos do Google:

undefined

Failover: Configure serviços de backend primários/de backup ou políticas de tráfego que direcionam para regiões alternativas em caso de falha na verificação de saúde. Para failover em nível de DNS, use políticas do Cloud DNS com verificações de saúde para endpoints não-HTTP.

Latência e Eficiência

Orçamentos de latência

Aloque um orçamento de latência de ponta a ponta por camada (cliente, borda, aplicação, dados). Monitore p95/p99, não as médias. Use o Cloud Trace para encontrar contribuidores entre serviços e bloqueio de início de fila (head-of-line blocking). Aplique deadlines a RPCs para que o cancelamento no serviço chamador (upstream) libere capacidade.

Uso de cache e CDN

Caches em camadas: cache do cliente/navegador, borda da CDN (Cloud CDN) e caches regionais/em memória (Memorystore ou em processo). Escolha as chaves de cache e os cabeçalhos ‘vary’ com cuidado. Defina os TTLs com base na atualidade dos dados e no risco de obsolescência; considere o cache negativo para 404s quando for seguro.
Sirva ativos estáticos do Cloud Storage por trás do Cloud CDN para reduzir a carga na origem e a latência de cauda. Use URLs/cabeçalhos assinados para acesso controlado.

Reutilização de conexão

Prefira HTTP/2 ou gRPC para multiplexação e compressão de cabeçalho. Habilite keep-alives e pooling de conexões para reduzir a sobrecarga do handshake. Fique atento ao esgotamento de portas do NAT; ajuste os pools de conexão do cliente e os timeouts de ociosidade, e dimensione as portas do Cloud NAT por VM, se aplicável.

Eficiência do payload

Use codificações binárias (ex: protobuf) e comprima payloads de texto (gzip/brotli) acima de um certo limite de tamanho. Projete os campos de requisição/resposta com cuidado; pagine, filtre no lado do servidor e evite a busca excessiva de dados (over-fetching). Use ETags e requisições condicionais (If-None-Match) para evitar transferências redundantes. Para o Cloud Storage, use pré-condições de geração e leituras Range para conteúdo parcial.

Padrões de Sobrecarga e Resiliência

Limitação de taxa, contrapressão, enfileiramento e processamento em lote

Aplique limites de taxa na borda (Cloud Armor para limitação de taxa baseada em IP/geolocalização/serviço) e na camada de API (cotas do Apigee, tokens por cliente de API). Implemente algoritmos de token bucket ou leaky bucket no lado do servidor para um compartilhamento justo.
Contrapressão (Backpressure): não sobrecarregue os sistemas downstream. Use filas (Pub/Sub para entrega de eventos at-least-once; Cloud Tasks para limites por fila e por destino com agendamento e novas tentativas). Propague os erros 429 Too Many Requests ou 503 com o cabeçalho Retry-After para pressionar os clientes a recuarem.
O processamento em lote (batching) pode aumentar a vazão (throughput) e reduzir a sobrecarga por chamada (ex: mutações em lote para bancos de dados ou confirmações em lote no Pub/Sub), trocando o aumento da latência por mais eficiência. Ajuste o tamanho do lote e o tempo máximo de espera.

Proteção contra sobrecarga

Aplique timeouts e deadlines a cada chamada RPC. Use circuit breakers para parar de enviar trabalho para dependências com falha e habilitar fallbacks rápidos. Implemente o descarte de carga (load shedding) com base na profundidade da fila, no uso de CPU ou na violação do SLO de latência para proteger a funcionalidade principal.

Novas tentativas resilientes, backoff exponencial, jitter, idempotência e tratamento de duplicatas

Tente novamente apenas quando for seguro: timeouts de rede, erros 5xx ou códigos documentados como passíveis de nova tentativa (ex: Cloud Storage 429/5xx). Nunca tente novamente em erros 4xx como 400/401/403, a menos que especificado.
Use backoff exponencial truncado com jitter para evitar novas tentativas sincronizadas. Prefira o full jitter. Exemplo:

undefined

Garanta a idempotência. Use chaves de idempotência (ex: um ID de operação exclusivo) e operações de upsert/escritas condicionais para tolerar duplicatas. Para o Pub/Sub, remova duplicatas usando o messageId ou chaves da aplicação; projete os handlers para serem seguros para a entrega at-least-once. Para escritas no Cloud Storage, use pré-condições de generation-match para evitar sobrescritas.

Aquecimento de recursos inativos

Alguns serviços aplicam limites adaptativos. Para o Cloud Storage, aumente gradualmente as taxas de requisição em buckets anteriormente inativos para reduzir erros 429/5xx transitórios durante picos repentinos. Limite os produtores (producers) e aqueça os buckets com tráfego controlado antes de aplicar a carga total.

Alta Disponibilidade, Dados, DR e Testes

Multizona, regional, multirregional; ativo-ativo vs. ativo-passivo

Implante em múltiplos domínios de falha. Use MIGs regionais ou clusters GKE regionais para tolerância a falhas de zona. Para serviços globais, use múltiplas regiões com o balanceador de carga global.
O modelo ativo-ativo reduz o RTO e a latência, mas exige dados sem conflitos e um gerenciamento cuidadoso da consistência. O modelo ativo-passivo simplifica a semântica de escrita, mas acarreta um RTO mais alto e potencial capacidade ociosa (cold capacity).

RTO, RPO, backup, restauração e testes de recuperação de desastres

Defina o RTO (tempo para recuperar o serviço) e o RPO (perda de dados tolerável) por carga de trabalho. Mapeie para as capacidades da plataforma:
- Cloud Spanner: multirregional com disponibilidade de cinco noves e replicação síncrona para um RPO próximo de zero.
- Cloud SQL: Alta Disponibilidade (High Availability) dentro da região; use réplicas entre regiões para DR, habilite o PITR e valide os runbooks de failover/failback.
- Firestore e Bigtable oferecem opções regionais e multirregionais; escolha para atender ao RTO/RPO.
- Buckets do Cloud Storage com dupla ou múltiplas regiões fornecem georredundância; verifique os procedimentos de restauração e a reemissão de URLs assinadas.
Teste o DR: Realize simulações de failover regularmente. Valide os backups restaurando-os em um ambiente isolado, ensaie o failover de DNS/tráfego e meça o RTO/RPO real.

Desempenho de banco de dados e armazenamento, design de índices, chaves quentes (hot keys) e contenção

Cloud Spanner: Evite chaves primárias que aumentam monotonicamente, pois causam hotspots. Use tabelas intercaladas (interleaved tables) para localidade, índices secundários para padrões de leitura e transações limitadas (bounded transactions) para reduzir conflitos de bloqueio. Dimensione os nós para QPS e armazenamento; mantenha pelo menos três nós para quórum de produção e margem de crescimento (headroom).
Cloud SQL: Analise as consultas, adicione índices de cobertura (covering indexes), evite transações longas e use pools de conexão. Ajuste as configurações do InnoDB ou Postgres criteriosamente; escale réplicas de leitura para cargas de trabalho com muita leitura.
Bigtable: Projete as chaves de linha (row keys) para distribuir a carga uniformemente (usando salting ou inversão de campos). Use roteamento multicluster para alta disponibilidade entre regiões, se disponível.
Firestore: Use índices compostos para consultas com múltiplos campos; esteja ciente de hotspots quando muitas escritas visam o mesmo caminho de documento.
Cloud Storage: Consistência forte de leitura após escrita para novos objetos; use uploads paralelos e fragmentação (chunking) para maior throughput. Aumente o tráfego gradualmente em buckets ociosos; prefira a borda da CDN para leituras quentes (hot reads). Para muitas VMs que precisam do mesmo grande conjunto de dados somente leitura, anexe um disco persistente no modo somente leitura a múltiplas instâncias para acesso local rápido a baixo custo.

Testes de carga, experimentos de caos, injeção de falhas e planejamento de capacidade

Testes de carga: Simule formatos de tráfego e distribuições de dados realistas. Aqueça caches e autoscalers; teste a latência p95/p99 sob carga e durante eventos de escalonamento. Espelhe uma pequena fração do tráfego real para stacks de sombra (shadow stacks) para validar o comportamento com a complexidade de produção.
Caos e injeção de falhas: Mate pods/VMs, isole uma zona (cordon), injete latência/erros na malha de serviços (service mesh) (ex: Envoy/Istio) para observar o raio de impacto (blast radius) e a resiliência. Verifique se os circuit breakers e as retentativas se comportam como esperado.
Planejamento de capacidade: Faça previsões usando a demanda histórica e eventos planejados. Mantenha uma margem de crescimento (headroom) para falhas N+1 e rebalanceamento. Alinhe os cooldowns e as taxas máximas do autoscaler com os picos esperados; pré-provisione durante picos previsíveis.

Trade-offs de disponibilidade entre serviços gerenciados e arquiteturas personalizadas

Computação: O Cloud Run oferece escalonamento rápido para zero e baixo custo operacional, mas tem partidas a frio (cold starts) e restrições de simultaneidade de requisições. O GKE fornece controle granular e portabilidade a um custo operacional mais alto. As VMs do Compute Engine fornecem controle máximo com a maior carga operacional.
Dados: O Cloud Spanner fornece consistência global e alta disponibilidade a um custo mais alto e com maior rigor de esquema. O Cloud SQL se encaixa em RDBMS tradicionais com operações mais simples, mas com HA/escalabilidade limitadas. O Bigtable se destaca em chave-valor/séries temporais de baixa latência e escala massiva. O Firestore oferece esquemas flexíveis com consistência forte e opções globais.
Rede: Balanceadores de carga globais e o Cloud CDN são altamente disponíveis e operam na borda do Google; proxies “faça você mesmo” (DIY) oferecem personalização, mas criam risco operacional e de falha.
Prefira serviços gerenciados para uma maior disponibilidade base e resistência a DDoS, mas leve em conta as cotas, partidas a frio e a semântica específica do serviço em seu design.

Cenário de Problema Prático

A NimbusMart, uma empresa global de e-commerce, precisa de uma API de catálogo de produtos de baixa latência com disponibilidade de cinco noves e latência de leitura minimizada para usuários na América do Norte, Europa e Ásia-Pacífico. As escritas devem ser globalmente consistentes. O tráfego tem picos durante as vendas relâmpago (flash sales), e incidentes históricos incluem retentativas em cascata e sobrecarga na origem.

Abordagem:

Provisione uma instância multirregional do Cloud Spanner usando nam-asia-eur1 com pelo menos três nós.

Justificativa: Fornece leituras/escritas globalmente consistentes com disponibilidade de cinco noves e posiciona réplicas perto dos usuários para reduzir a latência de leitura. Um mínimo de três nós oferece robustez de quórum e margem de crescimento (headroom) para rebalanceamento.

Implemente uma camada de API sem estado (stateless) em múltiplas regiões atrás do Application Load Balancer externo global.

Justificativa: O VIP Anycast e o roteamento global reduzem o tempo de estabelecimento da conexão e direcionam os usuários para a região íntegra mais próxima. Serviços sem estado facilitam o escalonamento horizontal e o failover.

Configure verificações de saúde (health checks) e regras de firewall para a acessibilidade do balanceador de carga.

Justificativa: As verificações de saúde impedem o roteamento para back-ends não íntegros. Permita os intervalos de IP de verificação de saúde do Google para que as verificações tenham sucesso: gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS

Implemente o autoscaling com base em métricas de requisição com capacidade pré-aquecida (warm capacity).

Justificativa: Escale os MIGs ou o HPA do GKE com base em QPS/latência em vez de CPU para reagir ao tráfego de vendas relâmpago. Mantenha um número mínimo de réplicas por região para evitar partidas a frio e habilite o autoscaling preditivo antes de eventos conhecidos.

Adicione o Cloud CDN para a mídia estática de produtos armazenada no Cloud Storage.

Justificativa: O cache na borda (edge caching) alivia a carga da origem, reduz a latência de cauda (tail latency) e mitiga a amplificação de picos nas camadas de aplicação e armazenamento. Use URLs assinadas e chaves de cache/TTLs apropriados.

Imponha proteção contra sobrecarga e limitação de taxa (rate limiting) na borda e no serviço.

Justificativa: Configure limites de taxa do Cloud Armor para absorver picos abusivos. No serviço, use limites do tipo token-bucket por cliente e descarte requisições de baixa prioridade quando os SLOs de latência estiverem ameaçados. Aplique deadlines a cada chamada downstream.

Use retentativas resilientes com backoff exponencial truncado e jitter total; garanta a idempotência com IDs de operação.

Justificativa: Evite o efeito manada (thundering herds) e escritas duplicadas durante falhas parciais. Chaves de idempotência garantem repetições seguras; para operações de armazenamento, use pré-condições condicionais.

Introduza uma fila de escrita para suavizar picos (burst smoothing) e para assincronia onde for aceitável.

Justificativa: O Pub/Sub amortece picos repentinos de escritas não críticas (ex: eventos de analytics), desacoplando os produtores do Spanner e protegendo os caminhos de escrita primários contra sobrecarga.

Defina SLOs e orçamentos de latência; instrumente o rastreamento e os dashboards.

Justificativa: Orçamentos por camada (per-tier) guiam a otimização. Os SLOs do Cloud Monitoring com orçamentos de erro e o Cloud Trace revelam os contribuidores de latência p99 entre regiões e na camada de dados.

Estabeleça runbooks de DR e teste o failover.

Justificativa: Com o Cloud Spanner multirregional e computação multirregional, pratique simulações de evacuação de região. Verifique o RTO com cronogramas de drenagem e aumento de tráfego, e valide se os autoscalers e o CDN se comportam corretamente durante o failover.

Este design satisfaz as metas de disponibilidade global e baixa latência alinhando a topologia de computação e dados, impondo controles de sobrecarga e usando serviços gerenciados que fornecem escalabilidade e resiliência comprovadas.

← Observabilidade · Todos os domínios · Testes →

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