Google PCA: Custo, Desempenho e Design de Nuvem Sustentável — Guia de estudos

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Custo, desempenho e design de nuvem sustentável são disciplinas co-otimizadas. Construir arquiteturas eficientes no Google Cloud exige observabilidade financeira, capacidade elástica que acompanha a demanda, rigor no ciclo de vida dos dados, posicionamento e cacheamento informados para redes e medição contínua. Esta seção explica padrões de design e operacionais que reduzem o desperdício sem sacrificar a confiabilidade, a segurança ou o desempenho, e destaca modos de falha e trade-offs para evitar surpresas custosas.

Arquitetura de Custos e Responsabilidade Financeira

Estabeleça controles financeiros como parte da linha de base da sua plataforma.

Análise e alocação de faturamento
- Exporte os dados de faturamento para o BigQuery para uma análise de gastos consultável e quase em tempo real por projeto, serviço, SKU e rótulo. Particione por dia para consultas escaláveis e defina controles de acesso ao dataset para as partes interessadas de finanças e engenharia.
- Use orçamentos com limites de alerta para evitar desvios de gastos. Roteie os alertas de orçamento para o Pub/Sub e automatize respostas (por exemplo, pausando workloads não críticos). Esteja ciente de que os alertas não são transacionais e podem ter atrasos nos relatórios; não confie neles como o único controle para jobs descontrolados.
Rótulos, tags e atribuição de custos
- Padronize os rótulos em toda a organização (cost_center, env, owner, app) e imponha-os no momento do provisionamento com templates de implantação ou policy-as-code.
- Prefira tags hierárquicas e uma estrutura de pastas/projetos para refletir os modelos de chargeback/showback. Use tanto rótulos (nível de recurso) quanto tags (escopo de política e faturamento) para alcançar uma alocação precisa.
Mecanismos de proteção de orçamento e detecção de anomalias
- Configure orçamentos por projeto e por portfólio; defina múltiplos limites (por exemplo, 50, 80, 100 por cento) e alertas de “previsão” (forecasted) para ação proativa.
- Use os insights do Recommender (VM ociosa, disco não anexado, IPs, compromissos não utilizados) para eliminar o desperdício continuamente.
Exemplos práticos
- Aplique rótulos na criação:

undefined

Consulte a exportação de faturamento em busca de gastos não rotulados para garantir a conformidade por meio de verificações de CI/CD.

Modos de falha e trade-offs comuns:

Rótulos inconsistentes quebram a alocação de custos; imponha a conformidade com políticas da organização e validação nos pipelines.
O faturamento centralizado sem orçamentos por equipe dificulta a responsabilização; crie orçamentos no nível da equipe ou do produto.
Atrasos nos alertas de orçamento significam que picos rápidos podem ultrapassar o limite; adicione limites (caps) e cotas em camadas sempre que possível.

Eficiência e Desempenho da Computação

Combine os recursos com os perfis de workload; automatize a elasticidade; reserve ou obtenha descontos para a carga de base estável.

Rightsizing e tipos de máquina personalizados
- Analise continuamente a utilização de CPU, memória, IOPS de disco e rede para fazer o rightsizing. Use tipos de máquina personalizados para ajustar a vCPU e a memória às necessidades reais da aplicação e evitar pagar por memória ociosa.
- Fique atento à margem de segurança (headroom): mire em 60–75% de CPU sustentada e garanta uma margem de memória suficiente para GC ou picos. Um rightsizing muito agressivo aumenta o risco de throttling ou OOMs.
Autoscaling e agendamento do ciclo de vida
- Use o autoscaling de grupos de instâncias gerenciados com base em sinais relevantes (CPU, capacidade do balanceador de carga ou profundidade de fila personalizada). Configure períodos de aquecimento (warmup) e controles de scale-in para evitar oscilação excessiva (thrashing).
- Para ambientes que não operam 24/7, agende o início/parada de VMs, node pools do GKE ou instâncias mínimas do Cloud Run para evitar gastos com ociosidade. Um primeiro passo simples é usar o Cloud Scheduler para acionar um job do Cloud Run que pare as instâncias de desenvolvimento todas as noites.
Instrumentos de desconto
- Descontos por uso contínuo (CUDs): comprometa-se por 1 a 3 anos para o uso em estado estável elegível para compromissos. Equilibre o tamanho do compromisso com o uso histórico e as previsões de negócio; comprometer-se em excesso desperdiça dinheiro.
- Spot VMs: ideais para workloads tolerantes a falhas, em lote (batch) ou distribuídos. Elas podem ser retomadas a qualquer momento; implemente checkpointing e grupos de múltiplas instâncias com fallbacks on-demand.
  - Exemplo:

undefined

Reservas de capacidade: reserve capacidade zonal ou regional para frotas críticas a fim de mitigar falhas de scale-up durante períodos de escassez regional.
- Exemplo:

undefined

Métricas de utilização e ajuste de desempenho
- Instrumente com o Cloud Monitoring, Profiler e Trace. Meça a latência p50/p95, o CPU steal, o tempo de GC e os backlogs de fila. Otimize os caminhos de código críticos (hot paths) antes de fazer o scale out.
- Fixe workloads sensíveis ao desempenho em regiões e zonas com plataformas de CPU adequadas e considere discos persistentes de alta vazão (high-throughput) ou Hyperdisk quando necessário.

Modos de falha e trade-offs:

O autoscaling ilimitado pode exceder cotas e metas de custo; aumente as cotas antecipadamente, defina um número máximo de réplicas e use o autoscaling preditivo para picos conhecidos.
Spot VMs podem causar rotatividade (churn) parcial da frota; diversifique as zonas e implemente hooks de encerramento gradual (graceful termination).
Comprometer-se em excesso com CUDs ou ter reservas subutilizadas cria custos irrecuperáveis; revise os compromissos trimestralmente.

Custo-Performance de Armazenamento, Bancos de Dados e Analytics

Escolha classes de armazenamento e modelos de capacidade de banco de dados que reflitam os padrões de acesso, retenção e SLOs de performance.

Classes de armazenamento e políticas de ciclo de vida
- Use Standard para dados “hot” (quentes), Nearline para acesso mensal, Coldline para acesso trimestral e Archive para acesso raro a longo prazo. Mantenha os dados e a computação na mesma região para evitar custos de egress.
- Aplique o gerenciamento de ciclo de vida (lifecycle management) para transicionar ou excluir objetos automaticamente. Esteja ciente das durações mínimas de armazenamento e das taxas de recuperação; transições prematuras de classe podem custar mais do que economizam.
- Exemplo de política de ciclo de vida (excluir objetos com mais de 90 dias):

undefined

Transferência e arquivamento de dados
- O acesso entre regiões geralmente incorre em custos de egress; colocalize produtores e consumidores. Use o Private Google Access e o VPC-SC para um acesso seguro e com custo otimizado às APIs do Google. Para arquivos de longo prazo, evite a recuperação frequente da classe Archive para prevenir altas taxas de recuperação.
Dimensionamento e performance de bancos de dados
- Relacional: dimensione para o working set residente em memória, IOPS e réplicas de leitura (read replicas). Habilite o aumento automático de armazenamento e monitore o lag de replicação; escale verticalmente ou fragmente (shard) horizontalmente quando o lag ameaçar o RPO/RTO.
- NoSQL/séries temporais: use o Bigtable para ingestão de alta taxa de transferência (high-throughput) e baixa latência, com um design adequado de chave de linha (row key) para evitar hotspots.
Controles de custo e modelos de capacidade do BigQuery
- On-demand (por TB escaneado): rápido para começar, risco de picos de custo. Reservas baseadas em capacidade: gastos previsíveis, controle sobre concorrência e taxa de transferência (throughput). Compromissos Flex absorvem picos de curto prazo.
- Otimize as consultas com particionamento e clustering; exija filtros de partição para evitar varreduras completas da tabela (full-table scans):

undefined

Defina um máximo de bytes cobrados por job para limitar os gastos:

undefined

Use visualizações materializadas (materialized views), cache de resultados, agregações aproximadas e evite SELECT * em produção. Mantenha o armazenamento e a computação na mesma região.

Modos de falha e trade-offs:

Mover objetos “hot” para Coldline/Archive aciona custos de recuperação e taxas de exclusão antecipada.
O BigQuery on-demand sem controles pode incorrer em custos descontrolados devido a varreduras não filtradas; imponha um máximo de bytes cobrados e filtros de partição.
O “oversharding” (fragmentação excessiva) de bancos de dados aumenta a complexidade operacional; faça benchmarks antes de dividir.

Redes, Vazão, Cotas e Design Sustentável

O design do movimento de dados e da simultaneidade influencia fortemente o custo e o desempenho; as escolhas de sustentabilidade refinam ainda mais o posicionamento e o agendamento.

Egress de rede, tráfego entre regiões, CDN e cache
- Minimize os saltos entre regiões; replique dados apenas onde a proximidade do usuário ou a conformidade o exijam. Use o Cloud CDN para descarregar conteúdo estático e dinâmico armazenável em cache; ajuste chaves de cache, TTLs e URLs assinadas para obter altas taxas de acerto.
- Faça cache perto dos clientes (CDN), na borda da sua VPC (cache de proxy) e dentro dos serviços (caches em memória como o Memorystore). Cuidado com dados obsoletos e tempestades de invalidação; defina cabeçalhos de controle de cache explícitos.
Medição de desempenho, testes de carga e escalonamento
- Estabeleça SLOs e meça-os com o Cloud Monitoring, Uptime checks, Cloud Trace e Profiler. Monitore a latência p95/p99 e os sinais de saturação.
- Realize testes de carga com dados realistas e tempo de reflexão. Organize os testes em estágios para evitar o acionamento de limites de taxa globais; solicite aumentos temporários de cota.
- Escale a vazão usando réplicas horizontais, filas fragmentadas (sharded), tópicos particionados e autoscalers orientados por métricas de backlog. Prefira pipelines assíncronos sempre que possível.
Cotas, simultaneidade, limites de taxa e backpressure
- Faça um inventário das cotas por serviço por região; aplique backoff exponencial com jitter no lado do cliente para respostas 429/5xx. Implemente controle de admissão e backpressure baseado em filas para proteger as dependências.
- Ajuste o controle de fluxo do Pub/Sub (máximo de mensagens/bytes pendentes), o processamento em lote e o paralelismo. No Cloud Run e no GKE, dimensione corretamente a simultaneidade para corresponder à CPU e à memória, evitando a inflação da latência de cauda.
Design consciente da sustentabilidade
- Prefira serviços serverless e gerenciados com alta utilização. Escolha regiões com maiores percentuais de energia livre de carbono quando a latência e a conformidade permitirem.
- Agende jobs em lote e flexíveis durante janelas de baixa emissão de carbono; use os relatórios do Carbon Footprint para monitorar o impacto.
- Use tipos de máquina energeticamente eficientes e considere a computação baseada em ARM onde for compatível para melhorar o desempenho por watt.
Governança que equilibra confiabilidade, segurança, desempenho e custo
- Defina barreiras de proteção arquitetônicas: labels obrigatórios, alertas de orçamento, políticas da organização (por exemplo, restringir IPs externos), SLOs/orçamentos de erro e SLOs de custo.
- Realize revisões periódicas de custo-desempenho com as equipes de engenharia, segurança e finanças. Integre o Recommender e dashboards personalizados; crie runbooks de remediação.
- Equilibre os trade-offs explicitamente: multirregional versus regional (durabilidade e latência versus custo e egress), camadas de criptografia e inspeção (segurança versus CPU e latência) e autoscaling agressivo (desempenho versus cota e risco de gastos).

Modos de falha e trade-offs típicos:

Análises entre regiões em um conjunto de dados de região única geram egress sustentado; replique ou realoque a computação.
A configuração incorreta da CDN resulta em baixas taxas de acerto; monitore os acertos de cache e o egress da origem para validar a economia.
A falta de backpressure durante interrupções parciais amplifica a falha; implemente circuit breakers e descarte a carga de forma controlada.

Cenário de Problema Prático

A Acme Learn, uma empresa de educação online, enfrenta picos noturnos imprevisíveis durante eventos ao vivo. Os custos aumentam acentuadamente devido a consultas do BigQuery entre regiões, picos de autoscaling e egress de ativos estáticos. A liderança também deseja reduzir o impacto de carbono sem degradar a experiência do usuário.

Abordagem:

Consolidar a visibilidade do faturamento e impor a alocação de custos
- Crie uma exportação de faturamento para o BigQuery e dashboards segmentados por produto, ambiente e região usando labels e tags padronizados em templates de implantação.
- Justificativa: A visibilidade quase em tempo real vincula os gastos às equipes responsáveis, permitindo a responsabilização pelo orçamento. Os labels permitem o rateio de custos granular e a detecção de anomalias.
Rearquitetar as análises para colocalizar computação e armazenamento
- Mova os conjuntos de dados de análise de eventos e as consultas agendadas para a mesma região dos processadores de stream. Para o BigQuery, mude as equipes de alto volume do modelo sob demanda para reservas de capacidade dimensionadas para a simultaneidade de pico com um pequeno buffer flexível.
- Justificativa: A colocalização elimina o egress entre regiões. O BigQuery baseado em capacidade estabiliza os custos sob carga, preservando o desempenho.
Otimizar a entrega de conteúdo com cache de borda
- Disponibilize os ativos estáticos e semidinâmicos das aulas através do Cloud CDN, definindo cabeçalhos de controle de cache explícitos e URLs assinadas para conteúdo premium. Ajuste os TTLs com base na mutabilidade do conteúdo.
- Justificativa: Altas taxas de acerto de cache transferem o tráfego das origens para a borda, reduzindo o egress e a computação na origem, ao mesmo tempo que melhoram a latência durante os picos.
Reforçar o autoscaling e as reservas para eventos ao vivo
- Adicione um grupo de instâncias gerenciado regional para a camada de API com alvos de autoscaler tanto para CPU quanto para o backlog de requisições. Crie uma pequena reserva de capacidade zonal para garantir margem para picos de uso durante os eventos. Habilite o autoscaling preditivo antes das sessões agendadas.
- Justificativa: O autoscaling de sinal duplo reage tanto à utilização quanto à demanda, enquanto as reservas e o aquecimento preditivo evitam a latência de cold-start e os déficits de capacidade.
Aplicar um mix de computação: carga base em compromissos, picos em spot
- Adquira compromissos de 1 ano para as cargas de trabalho de linha de base da API e de processamento de dados. Configure jobs de transcodificação em lote e de enriquecimento em Spot VMs com checkpointing e grupos de instâncias multizonais.
- Justificativa: Os compromissos reduzem o custo do estado estacionário; as Spot VMs fornecem elasticidade de baixo custo para trabalho interrompível sem arriscar o tráfego do usuário.
Instituir ciclo de vida de armazenamento e posicionamento regional
- Mantenha os metadados e as miniaturas dos cursos de acesso frequente (hot) em armazenamento Standard regional, perto da computação que os serve. Transfira logs e clickstreams brutos para Nearline após 30 dias e exclua após 180 dias. Para arquivos de conformidade, use o Archive com SLAs de recuperação documentados.
- Justificativa: Alinha a classe de armazenamento aos padrões de acesso, reduzindo o custo contínuo e respeitando a retenção.
Colocar barreiras de proteção no uso do BigQuery
- Exija filtros de partição em tabelas grandes e defina padrões de job no nível do projeto para o máximo de bytes faturados. Introduza visualizações materializadas para agregações comuns e padrões de ingestão particionados.
- Justificativa: Evita varreduras completas acidentais, estabiliza os gastos e acelera as consultas frequentes.
Projetar para vazão com backpressure e cotas
- Integre o Cloud Tasks para fluxos de trabalho com taxa limitada e configure os assinantes do Pub/Sub com controle de fluxo. Implemente backoff exponencial com jitter para APIs de terceiros e defina tetos de simultaneidade por serviço no Cloud Run.
- Justificativa: Controla a demanda para respeitar as cotas, protege as dependências sob picos de uso e evita falhas em cascata.
Incorporar a sustentabilidade nas operações
- Prefira serverless sempre que viável, selecione regiões com maior percentual de energia livre de carbono para análises e agende jobs em lote não urgentes durante janelas de baixa emissão de carbono. Monitore as emissões com o Carbon Footprint e inclua-as nas revisões trimestrais.
- Justificativa: Melhora o desempenho por watt e reduz o impacto de carbono com mínimos trade-offs para o usuário.
Governar continuamente
- Crie orçamentos e alertas por produto, imponha o uso de labels por meio de políticas e estabeleça revisões mensais de custo-desempenho-SLO. Automatize a limpeza de recursos ociosos e discos não anexados com base no Recommender.
- Justificativa: A governança contínua sustenta os ganhos, previne regressões e equilibra confiabilidade, segurança, desempenho e custo ao longo do tempo.

Este design reduz o egress, estabiliza o custo das análises, garante um desempenho previsível durante eventos ao vivo e avança nas metas de sustentabilidade sem comprometer a experiência do usuário.

← DevOps · Todos os domínios

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