Google PCNE: Balanceamento de Carga, Cloud CDN e Gerenciamento de Tráfego Global — Guia de estudos

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Network 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

Esta seção explica como o Google Cloud Load Balancing, o Cloud CDN e o gerenciamento de tráfego global trabalham juntos para fornecer serviços resilientes, de alto desempenho e seguros. Ela aborda as famílias e a seleção de balanceadores de carga, o comportamento de proxy versus passthrough, componentes de backend e roteamento, failover e gerenciamento de capacidade, cache do Cloud CDN e proteções de origem, designs anycast e entre regiões, direcionamento de DNS e verificações de integridade, observabilidade e padrões de design para pontos de entrada globais robustos.

Famílias de balanceadores de carga, seleção e comportamento do plano de dados

O Google Cloud oferece balanceadores de carga externos e internos com escopo, protocolo e características de plano de dados distintos. A escolha do balanceador correto alinha as necessidades de protocolo, a geografia e os controles operacionais.

Proxy externo L7 (global): External Application Load Balancer para HTTP(S) e gRPC. Termina o TLS, impõe políticas L7, suporta mapas de URL, Cloud CDN, Cloud Armor, recursos de solicitação/resposta e anycast IPv4/IPv6. Ideal para APIs/sites web voltados para a internet que exigem roteamento avançado, segurança e cache.
Proxy externo L4.5: External TCP Proxy Load Balancer (global) e External UDP Proxy Load Balancer (regional) terminam as conexões do cliente e as encaminham via proxy para os backends. Use quando precisar de um VIP global e recursos L4 (política de TLS, preservação do IP do cliente via cabeçalhos para TCP) sem roteamento L7.
Passthrough externo L3/L4 (regional): External Network Load Balancer encaminha pacotes sem terminar a conexão. Latência mais baixa e mais simples; suporta TCP/UDP/ESP/ICMP. Apropriado para lift-and-shift, backends heterogêneos ou protocolos que não toleram a terminação de proxy. O NLB clássico usa pools de destino (target pools); o NLB de passthrough regional mais recente usa serviços de backend (backend services).
Proxy interno (regional): Internal HTTP(S) Load Balancer (L7) e Internal TCP Proxy Load Balancer (L4.5) terminam e encaminham via proxy dentro de uma VPC para uso norte-sul de microsserviços e de serviço a serviço. Suportam roteamento por host/caminho (HTTP), mTLS para clientes via aplicação e políticas de segurança por serviço.
Passthrough interno (regional): Internal TCP/UDP Load Balancer distribui conexões para backends em endereços privados RFC1918, preservando o IP do cliente e usando o hashing MAGLEV. Ideal para serviços leste-oeste (bancos de dados, protocolos personalizados) que exigem distribuição com reconhecimento de zona e baixa sobrecarga.

Trade-offs de camada e terminação:

O Proxy L7/4.5 oferece roteamento avançado, descarregamento de TLS (TLS offload), observabilidade, Cloud Armor/CDN e failover entre regiões ao custo de saltos (hops) adicionais e possíveis alterações de cabeçalho/NAT. É adequado para pontos de entrada públicos e malhas de serviço (service meshes).
O Passthrough L3/L4 preserva o IP do cliente de ponta a ponta e minimiza a latência, mas não possui recursos L7 e tem menos ganchos (hooks) de observabilidade. O comportamento da sessão é baseado em hash; as verificações de integridade são mais simples.

Escopo e famílias de IP:

VIPs anycast globais estão disponíveis para o External Application LB e o External TCP Proxy LB, fornecendo endereços IPv4/IPv6 únicos alcançáveis de qualquer lugar. LBs regionais usam VIPs unicast regionais. A exposição de serviços públicos em IPv6 é alcançada configurando um balanceador de carga global externo com um endereço IPv6.

Destaques dos critérios de seleção:

Necessidade de roteamento por host/caminho, redirecionamentos, Cloud CDN, Cloud Armor ou gRPC: External Application LB.
Necessidade de TCP global sem L7: External TCP Proxy LB.
Protocolos que não funcionam bem com proxies (ex: alguns legados UDP/TFTP): Passthrough Externo ou Interno.
Serviço a serviço privado com roteamento HTTP: Internal HTTP(S) LB.
Minimizar custo/saltos (hops) para tráfego intra-VPC: Passthrough Interno.

Backend services, objetos de roteamento, integridade e aderência de tráfego

Objetos principais do plano de dados:

Backend services: Definem backends (grupos de instâncias, NEGs zonais, NEGs híbridos, NEGs sem servidor), verificações de integridade, modo de balanceamento, capacidade, afinidade de sessão, tempo limite e política de failover. Necessários para LBs de proxy e LBs de passagem mais recentes.
Target pools: Construção legada para o NLB externo clássico. Adequado para distribuições TCP/UDP simples e VMs heterogêneas durante o lift-and-shift.
Named ports: Chaves em grupos de instâncias que mapeiam nomes lógicos (por exemplo, http) para números de porta, referenciadas por backend services e URL maps. Garanta a consistência entre os membros do grupo.

Verificações de integridade e failover:

Tipos: HTTP(S), HTTP/2, gRPC, TCP, SSL. Escolha uma verificação que valide a prontidão real do serviço, não apenas a alcançabilidade do SO.
Escopo: As verificações de integridade são regionais; cada backend deve ter uma verificação de integridade com escopo para sua região de serviço.
Política de failover: O backend service pode designar backends primários e de failover. O tráfego faz failover quando o primário não está íntegro ou está sem capacidade (se o failover por capacidade estiver ativado e o limite for atingido). Considere o draining e a reserva de capacidade para evitar o efeito manada (thundering herd).

URL maps e roteamento:

O URL map se anexa ao LB HTTP(S) externo ou interno e define regras de host e seletores de caminho (path matchers).
Serviço padrão: Backend genérico (catch-all) para solicitações que não correspondem a nenhuma regra; se não for definido, um 404 é retornado.
Redirecionamentos e reescritas: Use as ações do URL map para realizar redirecionamentos HTTPS, redirecionamentos de host canônico ou reescritas de caminho antes do roteamento.

Exemplo: URL map mínimo com redirecionamento HTTPS e backend padrão

Crie uma regra de host para example.com, redirecione HTTP para HTTPS, roteie /static para um bucket de backend habilitado para CDN e, por padrão, para um backend service regional.

Afinidade de sessão e draining:

As opções de afinidade dependem do tipo de LB. Opções comuns:
- Nenhuma: Melhor para stateless; maximiza a distribuição de carga.
- IP do cliente: Aderência (sticky) pelo IP de origem em L4/L7; use quando múltiplos protocolos (por exemplo, HTTP e TFTP) devem ter aderência conjunta ao mesmo backend.
- Cookie gerado (somente L7): O LB define um cookie para manter a persistência em um backend; melhor distribuição do que o IP do cliente para clientes com NAT.
Compromissos: A afinidade pode causar concentração de tráfego (hotspotting) e complicar o autoescalonamento. Prefira a ausência de estado (statelessness) sempre que possível.
Connection draining: Em uma redução de escala (scale-in) ou remoção de backend, o LB respeita o tempo limite de draining para permitir que as conexões existentes sejam fechadas de forma gradual. Ajuste o tempo de drain para a sua solicitação mais longa esperada para evitar resets.

Capacidade e autoescalonamento:

Modos de balanceamento: Baseado em utilização (por exemplo, CPU), RPS ou conexões. Cada backend anuncia sua capacidade; o LB descarta a carga ou faz failover quando ocorre saturação.
Autoescalonamento: Managed instance groups escalam com base em sinais (CPU, métricas personalizadas). O atraso no aumento de escala (scale-out lag) pode causar 503 se o LB ficar sem capacidade; pré-aqueça com um número mínimo de réplicas ou autoescalonamento preditivo para tráfego diurno.
Failover e transbordamento: Habilitar o failover por capacidade com um limite apropriado permite um transbordamento (overflow) suave entre regiões.

Segurança nos backends:

Restrinja o acesso ao backend usando regras de firewall direcionadas a tags de instância ou contas de serviço. Permita apenas o tráfego das faixas de origem do balanceador de carga e da verificação de integridade do Google e as faixas de cliente aprovadas se o acesso direto for necessário para clientes internos.

Exemplo: restringir clientes e verificações de integridade a um grupo com tag de backend

Marque as instâncias com a tag application.
Crie uma regra de permissão de entrada (ingress allow) para tcp:80 a partir dos seus CIDRs de cliente e das faixas de verificação de integridade do Google, direcionando para a tag application.
A negação por padrão (deny-by-default) é recomendada para expor o tráfego descartado nos logs.

Cloud CDN, política de cache e proteção da origem

O Cloud CDN se integra com o Application Load Balancer externo para armazenar respostas em cache nos POPs de borda, reduzindo a latência e aliviando a capacidade da origem.

Modos de cache e TTLs:

Usar cabeçalhos da origem: Respeita os cabeçalhos Cache-Control e Expires da sua origem. Preferido para garantir a corretude.
Forçar cache: Armazena em cache todas as respostas com um TTL padrão configurado, opcionalmente substituindo ou ignorando os cabeçalhos da origem para conteúdo estático. Use com cuidado para evitar o cache de dados dinâmicos.
Ignorar cache (Bypass): Útil para caminhos que nunca devem ser armazenados em cache.

Chaves de cache:

Os campos da chave incluem protocolo, host, caminho, parâmetros de consulta, cabeçalhos e cookies. Configure a política de query-string (incluir tudo, incluir selecionados ou ignorar), a inclusão seletiva de cabeçalhos e cookies e a segmentação por dispositivo, conforme necessário.
Mantenha as chaves mínimas para maximizar a taxa de acerto (hit ratio); varie apenas nos campos que alteram a representação.

Solicitações assinadas:

URLs assinadas: Anexe uma assinatura HMAC ou RSA com expiração e escopo de caminho para conceder acesso por tempo limitado a recursos específicos. Bom para usar o CDN como acelerador com autorização por objeto.
Cookies assinados: Autorize um conjunto de caminhos com um cookie; útil para conteúdo restrito em todo o site.
Rotacione as chaves e imponha expirações curtas para reduzir o risco de replay.

Compressão e corretude:

As origens devem comprimir mesmo quando as solicitações incluem um cabeçalho Via. Se o CDN servir objetos não comprimidos enquanto a origem “suporta compressão”, verifique se a origem está configurada para comprimir quando o cabeçalho Via está presente.

Segurança da origem:

Use HTTPS dos proxies de borda para as origens com políticas de TLS modernas.
Limite a alcançabilidade da origem: regras de firewall no backend que permitem apenas tráfego dos intervalos de origem do load balancer e dos health checks do Google e de produtores privados conhecidos. As instâncias de backend não devem aceitar entrada (ingress) pública arbitrária.
Combine com o Cloud Armor para DDoS/WAF de camada 7 (L7), limitação de taxa (rate limiting) e detecção de ameaças. Use o modo de visualização (preview) para novas regras para mitigar falsos positivos.
Invalide o conteúdo intencionalmente usando as APIs de invalidação de cache quando precisar purgar antes da expiração do TTL. Para conteúdo dinâmico, prefira TTLs curtos e revalidação (ETag/If-None-Match).

Modos de falha e trade-offs:

Chaves de cache muito amplas desperdiçam cache e diminuem a taxa de acerto; chaves muito restritas arriscam servir variantes incorretas.
Forçar o cache de dados dinâmicos pode vazar conteúdo personalizado.
URLs/cookies assinados protegem o acesso na borda, mas o acesso direto à origem (bypass) ainda deve ser negado por meio de política de rede.

Gerenciamento de tráfego global, direcionamento de DNS, observabilidade e pontos de entrada resilientes

Front doors Anycast e failover entre regiões:

O Application LB externo e o TCP Proxy LB externo usam VIPs anycast globais para atrair clientes para a borda do Google mais próxima. O tráfego é então enviado por proxy para o backend mais saudável e próximo com capacidade. Configure várias regiões de backend com verificações de integridade (health checks) e configurações de capacidade consistentes para failover e overflow contínuos.
Pré-provisione capacidade em regiões secundárias para evitar penalidades de cold-start; coordene os valores min/max do autoscaler com os limites de capacidade do LB.

Gerenciamento de tráfego interno regional:

O Internal HTTP(S) LB e o Internal Passthrough LB são regionais; projete para diversidade de zonas dentro de uma região e, quando necessário, para múltiplas regiões usando LBs separados com Private Service Connect ou clientes cientes do serviço (service-aware) para selecionar endpoints regionais.
Mantenha a latência leste-oeste (east-west) baixa, colocando os serviços que se comunicam na mesma região e VPC. Use endereçamento RFC1918 com uma única VPC ou VPCs em peering para custo mínimo e simplicidade operacional.

Políticas de roteamento e verificações de integridade do Cloud DNS:

Políticas: Weighted round robin (divisão de tráfego), geolocalização (enviar usuários para o VIP regional mais próximo) e failover (primário/backup). Combine políticas para atender às regras de negócio.
Verificações de integridade (Health checks): Anexe health checks de DNS (HTTP/HTTPS/TCP) aos registros A/AAAA usados no direcionamento para que endpoints não íntegros sejam removidos. Leve em conta o cache do resolvedor (TTL), que atrasa a reação; mantenha os TTLs baixos nos registros direcionados para melhorar a responsividade do failover, ao custo de mais consultas DNS.
Direcionamento de tráfego: Use políticas ponderadas (weighted) para realizar migrações em fases ou deslocar a carga entre regiões. Evite direcionar para endereços privados a partir da internet, a menos que esteja usando DNS split-horizon.

Observabilidade e diagnóstico:

Logs do balanceador de carga: Habilite os logs para todos os LBs. Os logs de HTTP(S) incluem método/URI da requisição, latência, acerto/erro de cache (hit/miss), serviço de backend, regra do mapa de URL, detalhes de TLS e códigos de resposta. Os logs de TCP/UDP fornecem metadados de conexão e o status da sonda de verificação de integridade (health probe).
Métricas: Monitore a saúde do backend, utilização, RPS, conexões, latência, taxa de acerto de cache (cache hit ratio), taxas de erros 4xx/5xx e saturação de capacidade. Crie alertas para mudanças repentinas e limites sustentados.
Padrões de erro comuns de HTTP(S):
- 404: Nenhuma correspondência no mapa de URL; confirme as regras de host/caminho e o serviço padrão.
- 301/302: Redirecionamentos intencionais; verifique loops de redirecionamento.
- 502: Falha na conexão com o backend ou incompatibilidade de protocolo (ex: HTTP/1.1 vs gRPC); verifique a integridade e a configuração do protocolo do backend.
- 503: Backends sem integridade ou sem capacidade; verifique os health checks, cotas e o comportamento do autoscaler.
Rastreamento de requisições: Use X-Forwarded-For, X-Forwarded-Proto e IDs de rastreamento (trace IDs) propagados pela sua aplicação. Correlacione os logs do LB com os logs do backend usando os IDs de requisição.
Firewall insights: Habilite os logs de firewall da VPC nas regras de permissão (allow) e negação (deny). Para registrar explicitamente os pacotes descartados (drops), adicione uma regra deny-all de baixa prioridade com os logs habilitados.

Design de ponto de entrada global resiliente:

Use um único VIP anycast global em um Application LB externo que atende a múltiplos backends regionais. Posicione os backends serverless/VM/container em pelo menos duas regiões. Habilite o failover e o overflow entre regiões, configure health checks conservadores e ajuste o esvaziamento de conexões (draining) e os timeouts para suas cargas de trabalho.
Proteja o ponto de entrada com o Cloud Armor e políticas de limitação de cota. Use o Cloud CDN para conteúdo estático e dinâmico cacheável para absorver picos de tráfego na borda.
Exponha dual-stack IPv4/IPv6 no LB global para atender a todas as redes. Para um acesso restrito de clientes, aplique regras de firewall no backend com intervalos de origem (source ranges) precisos e tags de instância ou contas de serviço.

Exemplo: regra de firewall restringindo os intervalos de IP de clientes e de health checks para backends com tags

Marque as instâncias com a tag application.
Crie uma regra de permissão de entrada (ingress allow) para tcp:443 com source-ranges=203.0.113.0/24,198.51.100.0/24 e os intervalos de IP dos health checks do Google, direcionada à tag application.
Garanta que exista uma regra deny-all de prioridade mais baixa com logs habilitados para capturar origens inesperadas.

Cenário de Problema Prático

A Acme Retail lança uma plataforma global de e-commerce que precisa de baixa latência, segurança robusta e failover transparente entre us-east1 e europe-west1, ao mesmo tempo que serve mídia estática de forma eficiente. Apenas os escritórios corporativos e uma rede de staging de um CDN parceiro devem poder acessar a interface de administração privada.

Front door e backends

Crie um Application Load Balancer externo com um VIP anycast dual-stack e certificados TLS para o hostname público da loja.
Defina dois serviços de backend, cada um apontando para um grupo de instâncias gerenciadas (managed instance group) regional em us-east1 e europe-west1. Habilite os health checks (HTTPS) e defina o modo de balanceamento para utilização com um limite de capacidade de 80%.
Justificativa: O Anycast combinado com backends multirregionais garante que os usuários acessem a borda mais próxima e que o failover ocorra de forma transparente se uma região ficar indisponível ou saturada.

Mapa de URL, roteamento e redirecionamentos

Configure um mapa de URL com regras de host para os hostnames da loja pública e do administrador privado. Roteie /static para um backend bucket com o Cloud CDN habilitado; roteie /api e / para os backends de VM. Adicione um redirecionamento de HTTP para HTTPS.
Justificativa: O roteamento por host/caminho separa o tráfego estático do dinâmico e impõe o acesso seguro.

Política do Cloud CDN

Para o backend bucket /static, defina o modo de cache para usar os cabeçalhos da origem e defina uma chave de cache que ignore parâmetros de consulta não funcionais e inclua apenas o cabeçalho Accept-Encoding. Habilite o cache negativo para erros 404 comuns com um TTL curto.
Justificativa: Respeita a semântica do conteúdo, maximiza a taxa de acertos (hit ratio) e evita o cache de variantes incorretas.

Afinidade de sessão e esvaziamento de conexões

Defina a afinidade de sessão como generated-cookie para a loja pública e none para os ativos estáticos; defina o esvaziamento de conexão (connection draining) para 60 segundos.
Justificativa: Os cookies mantêm as sessões de carrinho de compras estáveis, permitindo uma ampla distribuição; o esvaziamento de conexões evita erros visíveis ao usuário durante eventos de scale-in ou failover.

Failover entre regiões e autoscaling

Habilite o failover por capacidade (failover-on-capacity) com um limite de overflow de 90% para deslocar o excesso para a outra região. Configure o autoscaling do MIG com um mínimo de 4 réplicas por região e metas de CPU correspondentes à utilização do LB.
Justificativa: Evita “penhascos” de capacidade e coordena as decisões do LB e do autoscaler para um escalonamento suave.

Restrição da interface de administração

Crie um Internal HTTP(S) Load Balancer para o hostname do administrador privado, acessível apenas de dentro da VPC. Publique um DNS split-horizon no Cloud DNS para que clientes internos resolvam para o VIP do ILB e clientes externos recebam NXDOMAIN.
Justificativa: Mantém o tráfego de administração privado e controlado sem expor endpoints públicos.

Firewall de backend e segurança da origem

Marque os backends de administração e web com a tag application e adicione uma regra de permissão (allow) para tcp:443 a partir dos CIDRs corporativos e de staging, mais os intervalos de origem do balanceador de carga e dos health checks do Google; adicione uma regra deny-all com logs em uma prioridade mais baixa.
Justificativa: Garante que apenas os clientes pretendidos e a infraestrutura do Google possam alcançar os backends e fornece visibilidade sobre os pacotes descartados (drops).

Cloud Armor

Aplique uma política de segurança com regras de WAF gerenciadas e um limite de taxa (rate limit) em modo de pré-visualização (preview) para picos de tráfego em /api.
Justificativa: A proteção na camada 7 (L7) e a aplicação em fases reduzem o risco durante o ajuste fino.

Direcionamento de Cloud DNS e health checks

Publique registros A e AAAA para o hostname da loja pública apontando para o VIP anycast do ALB. Para um canary blue/green, crie uma política ponderada (weighted) em um hostname canary designado, dividindo 5% para o ALB exclusivo de europe-west1 e 95% para a implantação global. Anexe health checks HTTPS para remover o canary se ele não estiver íntegro e defina o TTL para 20 segundos.
Justificativa: O canary baseado em DNS permite uma exposição gradual com remoção baseada na integridade e convergência rápida.

Observabilidade

Habilite os logs do LB e do CDN; exporte para o BigQuery para análise. Configure alertas para a taxa de erros 5xx, capacidade do backend, falhas de health check e taxa de acerto do CDN (hit ratio). Use testes de mapa de URL e logs de requisição para diagnosticar erros de roteamento; inspecione picos de erros 502/503 para verificar saturação do backend ou incompatibilidades de protocolo.
Justificativa: O monitoramento proativo e o diagnóstico rápido minimizam o MTTR (Tempo Médio para Reparo) e preservam a experiência do usuário.

← Conectividade Híbrida · Todos os domínios · Cloud DNS →

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