Google ACE: Gerenciamento de Custos, Desempenho e Otimização de Capacidade — 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

O gerenciamento de custos e a otimização de desempenho/capacidade no Google Cloud exigem visibilidade contínua, decisões de dimensionamento correto (right-sizing) e governança que alinhe a utilização de recursos com os objetivos de negócio. Uma prática eficaz combina controles financeiros (orçamentos, alocação), alavancas técnicas (autoscaling, reservas, políticas de ciclo de vida), escolhas de arquitetura (localidade de dados, replicação) e feedback operacional (telemetria, testes de carga). Esta seção detalha as principais ferramentas, trade-offs e modos de falha em computação, armazenamento, processamento de dados, redes, bancos de dados, cotas e engenharia de desempenho.

Visibilidade de Custos, Orçamentos e Alocação

• Relatórios e exportações de faturamento:

  • Use os Cloud Billing Reports para análises rápidas de tendências e detalhamento por SKU; habilite a exportação de dados do Cloud Billing para o BigQuery para obter dados detalhados e consultáveis de custo e uso. Isso permite previsões diárias/mensais, detecção de anomalias e consolidação de múltiplos projetos com SQL padrão.
  • A exportação da tabela de preços ajuda a reconciliar os preços de lista com os custos e créditos por SKU.
  • Modos de falha: Usar apenas as visualizações do console limita a granularidade; não exportar para o BigQuery impede a modelagem histórica e a implementação precisa de showback/chargeback.

• Orçamentos e alertas:

  • Crie orçamentos com escopo para contas de faturamento, projetos, pastas, serviços ou filtros de labels/tags; configure alertas de limite (ex: 50/90/100%) sobre o custo real e previsto. Considere canais de notificação via Pub/Sub para acionar ações automatizadas (ex: pausar ambientes de não produção).
  • Trade-off: Desligamentos automáticos agressivos reduzem os gastos, mas podem prejudicar a confiabilidade se aplicados a caminhos de produção.

• Labels e tags para alocação:

  • Aplique labels de recursos e tags do Resource Manager de forma consistente (env, app, owner, cost-center). As tags suportam políticas da organização (org policies) e aparecem nos filtros de faturamento para uma alocação robusta.
  • Governança: Imponha políticas de labels/tags usando Organization Policy, templates de implantação e verificações de CI/CD.
  • Modos de falha: Chaves inconsistentes ou labels ausentes quebram os modelos de alocação; tags herdadas não são aplicadas a todos os tipos de recursos se as ferramentas forem inconsistentes.

• Modelos de alocação de custos:

  • Modelos de showback/chargeback geralmente usam uma hierarquia: projeto → serviço/SKU → label/tag. Custos de plataforma compartilhada (ex: load balancers, egresso de VPC) podem ser alocados por direcionadores como requisições, GB transferidos ou horas de CPU medidos via logs/métricas.
  • Trade-off: Modelos simples (divisão igual) são fáceis de executar, mas podem precificar incorretamente usuários intensivos; modelos granulares exigem telemetria confiável e mais sobrecarga.

Exemplo rápido (dry run no BigQuery para estimativa de custo):

• bq query –use_legacy_sql=false –dry_run ‘SELECT … FROM proj.ds.tbl WHERE dt >= “2026-08-01”’

Eficiência Computacional e Otimização do Ciclo de Vida

• Rightsizing e tipos de máquina personalizados:

  • Use a API/console do Recommender para dimensionar corretamente (rightsize) VMs com base em percentis de uso de CPU/memória. Prefira tipos de máquina personalizados para necessidades estáveis que não se encaixam nos tipos predefinidos (ex: 2 vCPU/10 GB de RAM) para evitar pagar por capacidade não utilizada.
  • Modos de falha: Reduzir o tamanho de serviços sensíveis à latência ou com picos de uso pode causar throttling. Valide com testes de carga e mantenha uma margem de segurança (headroom).

• Committed Use Discounts (CUDs):

  • Adquira CUDs baseados em recursos (vCPU, memória, GPUs) com escopo regional por períodos de 1 ou 3 anos via console ou CLI. Ideal para capacidade de base estável; adicione autoscaling por cima para lidar com picos de uso.
  • Trade-offs: Compromissos reduzem o preço unitário, mas são inflexíveis. Comprometer-se em excesso (overcommitting) trava os gastos; comprometer-se de menos (undercommitting) perde os descontos.

• Spot VMs:

  • Use Spot VMs para cargas de trabalho tolerantes a falhas e interrompíveis (batch, CI, camadas stateless). Implemente checkpointing e tratamento de preempção (aviso de 30 segundos via metadados/Pub/Sub).
  • Modos de falha: A capacidade pode desaparecer a qualquer momento; nunca coloque serviços stateful ou críticos para quórum exclusivamente em Spot VMs.

• Autoscaling, agendamento e ciclo de vida:

  • Managed instance groups (MIGs) com autoscaling (baseado em CPU, load balancer ou métricas personalizadas do Cloud Monitoring) lidam com cargas variáveis. Ajuste os controles de cool-down e scale-in para evitar oscilação; alinhe o atraso inicial do health check (initial delay) com a prontidão da aplicação.
  • Agendamento: Pare ou suspenda VMs de dev/test fora do horário de expediente; use Instance Schedules ou automação com Cloud Scheduler e Cloud Functions para minimizar o custo ocioso.
  • Ciclo de vida e manutenção: Habilite o reinício automático e a migração para manutenção do host (host maintenance migrate) para alta disponibilidade; esteja ciente de que a migração em tempo real (live migration) pode não se aplicar a VMs com GPUs ou SSDs locais.
  • Limpeza de ociosos: Recupere discos persistentes não anexados, snapshots antigos e IPs estáticos não utilizados usando o Recommender.
  • Modos de falha: Atrasos curtos no health check ou sinais de prontidão ausentes causam provisionamento excessivo; um scale-in muito agressivo derruba conexões; desabilitar a autorrecuperação (autohealing) esconde nós com falha.

Exemplos rápidos:

• gcloud compute commitments create base-36mo –region=us-central1 –plan=36-month –resources=vcpu=64,memory=240Gi
• gcloud compute instances add-labels vm-1 –labels=env=prod,app=api,cost-center=cc123

Economia de Armazenamento e Processamento de Dados

• Classes e ciclo de vida do Cloud Storage:

  • Escolha as classes pelo padrão de acesso: Standard (hot), Nearline (mín. ≥30 dias), Coldline (mín. ≥90 dias), Archive (mín. ≥365 dias). Aplique regras de ciclo de vida para rebaixar a classe e excluir de acordo com a programação.
  • Trade-offs de recuperação: Classes de custo mais baixo impõem taxas de recuperação por GB e cobranças por duração mínima de armazenamento; leituras frequentes em Coldline/Archive anulam a economia. Planeje fluxos de trabalho de restauração para picos de custo de leitura.
  • Governança: Use políticas de retenção e bloqueios de objeto (object holds) para conformidade; habilite o “requester-pays” para conjuntos de dados compartilhados para evitar surpresas de faturamento entre equipes.

• Exemplo de política de ciclo de vida (rebaixar e depois excluir):

  • Defina ações SetStorageClass e Delete baseadas em idade (Age) para automatizar transições e a limpeza de dados obsoletos.

• Controles de custo do BigQuery:

  • Consultas on-demand cobram por bytes processados; minimize com a poda de partição (partition pruning) e clusterização. Particione por ingestão ou coluna de data; clusterize até quatro colunas com alta cardinalidade/seletividade.
  • Use simulações (dry runs) para estimar o custo, visualizações materializadas (materialized views) para agregações frequentes e decoradores de tabela (table decorators) para restringir as janelas de tempo.
  • Reservas (slots) fornecem desempenho e gastos previsíveis; use atribuições por projeto/pasta e considere compromissos flexíveis (flex commitments) para picos curtos.
  • Modos de falha: Varreduras não particionadas, SELECT * em tabelas largas ou clusterização mal ordenada geram uma quantidade massiva de bytes lidos; tabelas intermediárias efêmeras podem inflar o armazenamento se não expirarem.

Exemplo curto (trecho de JSON do ciclo de vida do Cloud Storage):

• { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

Redes, Bancos de Dados e Escalabilidade Consciente de Cotas

• Egress de rede e impacto na arquitetura:

  • O tráfego de saída (egress) para a internet, entre regiões e via IPs externos incorre em cobranças; o tráfego na mesma região sobre IP interno geralmente é gratuito. Escolha o Premium Network Tier para desempenho ou o Standard para cargas de trabalho sensíveis ao custo com requisitos de latência/jitter menos rigorosos.
  • Load balancers: L7 HTTP(S) e L4 TCP/UDP têm cobranças de processamento de dados e por regra de encaminhamento; LBs entre regiões podem adicionar egress inter-regional. Consolidar LBs economiza custos fixos, mas pode aumentar o raio de impacto (blast radius).
  • Otimização: Mantenha o tráfego dentro da região (intra-region); use buckets e serviços regionais; evite o “hairpinning” através de IPs externos. Armazene em cache ativos estáticos na borda (edge) para reduzir o egress da origem.
  • Modos de falha: Usar acidentalmente IPs externos entre serviços na mesma VPC gera egress desnecessário; a replicação multirregional dobra o egress para os caminhos de escrita.

• Dimensionamento de banco de dados, réplicas e disponibilidade:

  • Cloud SQL: Dimensione vCPU/RAM para a carga do 95º percentil; habilite o redimensionamento automático de armazenamento; use réplicas de leitura (read replicas) para escalar leituras; HA dobra o custo de computação, mas reduz o RTO de failover. O pool de conexões (connection pooling) evita sobrecarga excessiva de conexões.
  • Spanner: A capacidade é provisionada como nós ou unidades de processamento; configurações multirregionais melhoram a disponibilidade e a latência de leitura, mas aumentam o custo e a latência de escrita; planeje divisões (splits) e pontos de acesso intenso (hotspots) com cuidado.
  • Bigtable: O número de nós determina a taxa de transferência (throughput); o autoscaler ajuda a acompanhar o tráfego; a replicação multi-cluster adiciona disponibilidade e custo; projete o esquema para uma distribuição uniforme de chaves.
  • Trade-offs: Réplicas melhoram a taxa de transferência de leitura e a disponibilidade, mas aumentam a amplificação de escrita e o egress; consistência forte e escritas multirregionais adicionam latência.

• Cotas, limites de taxa e contrapressão (backpressure):

  • Entenda as cotas por API e a concorrência por serviço. Implemente exponential backoff com jitter para erros 429/5xx. Aplique nivelamento de carga baseado em fila com Pub/Sub e Dataflow ou jobs do Cloud Run.
  • Configurações de concorrência: No Cloud Run, uma concorrência mais alta reduz o custo, mas arrisca a latência de cauda (tail latency); ajuste a alocação de CPU sob demanda para uma taxa de transferência estável.
  • Contrapressão (Backpressure): Use controle de fluxo (flow control) nos assinantes do Pub/Sub, circuit breakers e controle de admissão (admission control) para prevenir falhas em cascata.
  • Modos de falha: Ignorar cotas leva a uma limitação (throttling) repentina; o autoscaling pode amplificar a carga nos serviços dependentes (downstreams) sem contrapressão, causando novas tentativas e aumentando o custo.

Governança de Medição e Otimização de Desempenho

• Medição e testes de carga:

  • Estabeleça SLIs/SLOs para latência, taxa de erros e saturação. Use dashboards do Cloud Monitoring, verificações de tempo de atividade (uptime checks) e alertas. Instrumente o rastreamento (Cloud Trace) e a análise de perfil (Cloud Profiler) para localizar caminhos críticos (hot paths) e contenção de locks.
  • Realize testes de carga com modelos de tráfego realistas, cardinalidade de dados e tempos de reflexão (think times). Valide os parâmetros do autoscaler, o aquecimento (warm-up) e os gates de prontidão (readiness gates). Inclua cenários de failover e de caos para observar a margem de capacidade e o tempo de recuperação.
  • Diagnóstico de gargalos: Use o método USE (Utilization, Saturation, Errors - Utilização, Saturação, Erros) em CPU, memória, disco, rede e dependências downstream; correlacione com logs e traces.

• Governança equilibrando custo, segurança e confiabilidade:

  • Guardrails de FinOps: Labels/tags obrigatórios; orçamentos com alertas de previsão; exportações de faturamento centralizadas e cadências de revisão de custos. Incorpore as descobertas do Recommender (IPs/discos ociosos, rightsizing) no backlog com SLAs por proprietário.
  • Segurança: Prefira conectividade privada (sem IPs externos), VPC Service Controls para riscos de exfiltração de dados — reconheça que caminhos privados podem alterar os padrões de egress e os custos. Criptografe em repouso e em trânsito; considere o uso do KMS nos modelos de custo.
  • Confiabilidade: Reserve capacidade de base via CUDs ou reservas do BigQuery; mantenha uma margem para picos (burst) para os SLOs; realize game days regularmente. Documente quando o uso de instâncias Spot ou autoscaling agressivo é inaceitável para caminhos críticos.
  • Gerenciamento de mudanças: Trate parâmetros que afetam custos (limites do autoscaler, reservas do BigQuery, topologia de LB) como código, com planos de revisão e rollback.

Cenário de Problema Prático

A Contoso Media opera uma plataforma multirregional de análise de vídeo que está enfrentando custos crescentes e violações ocasionais do SLO de latência durante picos de tráfego. A liderança deseja uma redução de custos de 20% sem comprometer um SLO de latência p95 de 300 ms para a API e um SLA de 2 horas para a conclusão do processamento em lote (batch) noturno.

1. Estabelecer baselines de custo e desempenho

• Ação: Habilitar a exportação do Cloud Billing para o BigQuery e criar dashboards correlacionando custos de SKU com SLIs do Cloud Monitoring (latência, CPU, bytes de egress). Executar

undefined

nas 20 principais consultas para estimar os bytes lidos.

• Justificativa: Baselines identificam os serviços de alto impacto e mapeiam os gastos com os direcionadores de desempenho, permitindo uma otimização direcionada.

2. Impor tagueamento de alocação e orçamentos

• Ação: Exigir labels/tags (env, service, owner, cost-center) via templates de implantação; definir orçamentos por ambiente com alertas de previsão para um tópico Pub/Sub de FinOps.
• Justificativa: Dados de alocação completos e alertas proativos permitem a identificação rápida do proprietário e a ação corretiva antes que os custos excedam o orçamento.

3. Fazer o rightsizing e commitar a computação de base

• Ação: Aplicar o rightsizing de VM do Recommender a serviços estáveis; converter a capacidade de estado estável em CUDs regionais de 1 ano; manter um buffer de 20–30% no máximo do autoscaler para picos.
• Justificativa: O rightsizing e os compromissos de uso reduzem o custo unitário em cargas previsíveis, preservando a margem para os SLOs.

4. Otimizar autoscaling e prontidão

• Ação: Para MIGs, alterar os sinais de autoscaling para métricas baseadas em requisições ou métricas personalizadas de QPS/latência, definir o período de resfriamento (cool-down) para 120–180 segundos e alinhar o atraso inicial da verificação de saúde (health check) com o aquecimento da aplicação. Habilitar controles de scale-in para evitar a redução rápida de escala.
• Justificativa: Sinais cientes da carga de trabalho e estabilização evitam oscilação excessiva (thrash) e superprovisionamento, que inflacionam o custo e prejudicam a latência.

5. Reduzir o egress de rede e a sobrecarga do balanceador de carga

• Ação: Remover a comunicação por IP externo entre serviços; garantir que todo o tráfego leste-oeste use balanceamento de carga interno; colocalizar serviços com alta comunicação (chatty) dentro das regiões; fazer cache de ativos estáticos na borda (edge).
• Justificativa: Caminhos internos eliminam egress desnecessário e reduzem o processamento L7, melhorando a latência e o custo.

6. Ciclo de vida e arquivamento de armazenamento

• Ação: Aplicar regras de ciclo de vida do Cloud Storage para mover artefatos frios (cold) para o Coldline em 90 dias e excluir em 365 dias; configurar requester-pays em buckets compartilhados; revisar as implicações da duração mínima de armazenamento para dados de acesso raro.
• Justificativa: O uso de tiers e a retenção reduzem os custos de armazenamento e recuperação, mantendo a conformidade.

7. Ajuste de consultas e capacidade do BigQuery

• Ação: Particionar grandes tabelas de fatos por data, clusterizar por colunas de alta seletividade; substituir

undefined

por projeções de colunas; introduzir views materializadas para as principais agregações; comprar uma pequena reserva para janelas de pico de ETL e usar flex slots durante picos de processamento em lote.

• Justificativa: Particionamento/clusterização reduzem os bytes lidos; reservas de capacidade estabilizam o desempenho e o custo para cargas de trabalho críticas.

8. Escala e réplicas de banco de dados

• Ação: Para serviços no Cloud SQL com uso intenso de leitura, adicionar réplicas de leitura; ajustar o pool de conexões; configurar o redimensionamento automático do armazenamento; testar o failover para validar RTO/RPO. Para o Bigtable, habilitar o autoscaler e tratar chaves com hotspot.
• Justificativa: Réplicas descarregam as leituras e protegem os caminhos de escrita; o autoscaling mantém o throughput alinhado com a demanda sem superprovisionamento manual.

9. Cotas, concorrência e backpressure

• Ação: Implementar backoff exponencial com jitter; configurar o controle de fluxo (flow control) do assinante do Pub/Sub; definir a concorrência do Cloud Run para balancear throughput e latência; adicionar circuit breakers nas fronteiras com dependências downstream.
• Justificativa: O backpressure adequado previne falhas em cascata e tentativas de repetição descontroladas que degradam os SLOs e inflam os custos.

10. Validação e governança contínuas

• Ação: Executar testes de carga mensais e exercícios de caos (chaos drills); acompanhar os orçamentos de erro/SLO; integrar o Recommender e anomalias de custo no planejamento da sprint com proprietários e prazos definidos.
• Justificativa: A validação iterativa garante que a economia persista e que os SLOs permaneçam em conformidade (verdes) à medida que as cargas de trabalho evoluem.

← Confiabilidade · Todos os domínios

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

Navegar Google →