Google PCD: Computação, Contêineres e Plataformas de Execução Serverless — 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

O Google Cloud oferece múltiplas plataformas de tempo de execução, abrangendo serverless, contêineres e máquinas virtuais. A escolha da plataforma correta depende das características da carga de trabalho (workload), como padrões de requisição, gerenciamento de estado, disciplina de build e release, modelo operacional e restrições de rede. Esta seção aborda princípios de design, modos de falha e trade-offs para o Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) e Compute Engine, juntamente com serviços de suporte para imagens, identidade, rede, configuração e operações.

Runtimes Serverless: Cloud Run, App Engine, Cloud Functions

Cloud Run

• Modelo: Contêineres totalmente gerenciados com processamento de requisições HTTP ou Jobs em contêineres que rodam até a conclusão.
• Revisões e tráfego: Cada deploy cria uma revisão imutável. Dividir o tráfego por porcentagem entre as revisões permite padrões canary e blue-green com rollback instantâneo. Exemplo:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

• Concorrência e escalonamento: A concorrência padrão é 80; defina como 1 para código limitado por CPU (CPU-bound) ou que não seja thread-safe. Uma concorrência mais alta reduz a amplificação de cold-starts e o custo, mas pode aumentar a latência de cauda (tail latency) se a CPU/memória por requisição for inadequada. O Cloud Run escala até zero e aumenta com base na taxa de requisições recebidas; controle com instâncias mínimas/máximas para reduzir cold-starts e limitar o custo.
• Alocação de CPU: Escolha “CPU sempre alocada” para trabalho em segundo plano (background) entre as requisições, ao custo de faturamento adicional; caso contrário, a CPU só é alocada durante o processamento das requisições.
• Jobs: Os Cloud Run Jobs executam N tarefas paralelas até a conclusão, com um máximo de tentativas por tarefa e timeouts gerais; adequados para processamento de ETL, em lote (batch) e fan-out. Os modos de falha incluem a criação de hotspots nos backends quando muitas tarefas visam a mesma dependência; adicione limitação de taxa (rate limiting) e tentativas com backoff.
• Rede: Público, autenticado via IAM, ou privado por trás de uma VPC via Serverless VPC Access e Private Service Connect.

App Engine

• Ambientes:
  • Standard: Em sandbox, escalonamento rápido, runtimes fixos por linguagem; baixa latência de cold-start com escalonamento automático; sistema de arquivos restrito, timeouts de requisição e limites de tamanho para requisições de entrada. Use URLs assinadas do Cloud Storage para uploads grandes.
  • Flexible: Baseado em Docker, com capacidades semelhantes a VMs, runtimes personalizados, escalonamento mais lento que o Standard, suporta threads em segundo plano (background) e escrita no disco local.
• Serviços e versões: Um serviço (microsserviço) pode hospedar múltiplas versões; roteie o tráfego por porcentagem entre as versões, de forma semelhante ao Cloud Run. Use o dispatch.yaml para rotear caminhos ou hosts específicos para serviços, permitindo um roteamento simples e centralizado sem um balanceador de carga externo.
• Escalonamento: Manual, básico ou automático no Standard; escalonamento baseado na contagem de VMs no Flexible. Trade-off: o autoscaling agressivo melhora a responsividade, mas pode aumentar o custo e a contenção no backend.
• Armadilhas comuns: O escalonamento de instâncias ilimitado e sem cotas pode sobrecarregar sistemas downstream; aplique cotas e circuit breakers.

Cloud Functions

• Manipuladores orientados a eventos (event-driven handlers): Acionados por eventos de HTTP, Pub/Sub, Cloud Storage ou Eventarc. Use a 2ª geração para aproveitar o modelo de execução do Cloud Run, o controle de saída (egress) da VPC e a concorrência; a 1ª geração processa uma requisição por vez.
• Tentativas e idempotência: Funções de segundo plano (background) podem ser repetidas em caso de falha; projete handlers idempotentes e use chaves de desduplicação para evitar processamento duplicado. Gatilhos HTTP não são repetidos pela plataforma; implemente tentativas pelo cliente com backoff exponencial.
• Configuração de runtime: Variáveis de ambiente, integração com o Secret Manager e concorrência/máximo de instâncias por função. Defina timeouts para conter custos descontrolados. Cuidado com cold-starts longos com dependências grandes; mantenha os pacotes enxutos.

Contêineres no Google Kubernetes Engine

Workloads

• Deployments: Pods stateless com atualizações contínuas (rolling updates). Garanta rollouts seguros com limites de surge/unavailable:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

• StatefulSets: IDs de rede ordenados e estáveis e volumes persistentes para serviços stateful.
• DaemonSets, Jobs, CronJobs: Agentes no nível do nó e cargas de trabalho em lote (batch).

Services and Ingress

• Tipos de Service:
  • ClusterIP para uso apenas interno.
  • NodePort para acesso externo simples (operacionalmente limitado).
  • LoadBalancer para balanceamento de carga regional externo/interno.
• Ingress: Roteamento HTTP(S) e terminação TLS; prefira a Gateway API ou o Ingress com controladores gerenciados para políticas de L7. Modo de falha: verificações de saúde (health checks) falhando devido ao firewall; permita os intervalos de IP do balanceador de carga para os nós de backend.

Autoscaling and Node Pools

• Horizontal Pod Autoscaler (HPA): Escalona pods com base em CPU, memória ou métricas personalizadas; combine com Pod Disruption Budgets para proteger a disponibilidade.
• Vertical Pod Autoscaler (VPA): Dimensiona corretamente as solicitações/limites dos pods; evite HPA+VPA simultâneos na mesma dimensão para prevenir loops de feedback.
• Cluster Autoscaler: Adiciona/remove nós para atender às solicitações de recursos de pods pendentes.
• Pools de nós: Separe os pools por classe de carga de trabalho (workload). Use taints/tolerations e labels para agendamento. Misture instâncias spot/preemptible para workloads sensíveis a custo com tolerância a interrupções. Escolha tipos de máquina com largura de banda de memória/CPU suficientes para os limites por pod, a fim de evitar throttling.

Health and rollouts

• Sondas de liveness, readiness e startup: Evitam o envio de tráfego para pods que não estão prontos e reiniciam contêineres em deadlock. Sondas de liveness muito restritas podem causar reinicializações em cascata; ajuste os atrasos iniciais e os limiares de falha.
• Rollback com kubectl rollout undo. Para canary, use múltiplos Deployments e divisão de tráfego no nível do Service via Ingress/Gateway.

Compute Engine para Cargas de Trabalho de Aplicações

Design de VM

• Modelos de instância definem tipo de máquina, imagem, discos, escopos da conta de serviço, scripts de inicialização e metadados. Mantenha as imagens mínimas; use scripts de inicialização ou imagens preparadas com o Packer para uma inicialização determinística.
• Discos: Use discos persistentes balanceados ou SSD para aplicações sensíveis à latência. Compartilhe grandes conjuntos de dados somente leitura em um grupo de instâncias gerenciado por meio de um disco persistente somente leitura anexado a várias instâncias para baixa latência e inicialização rápida.
• Rede: Crie regras de firewall para as verificações de saúde (health checkers) ao usar balanceadores de carga. Exemplo:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

Grupos de Instâncias Gerenciados (MIGs)

• Autoescalonamento por CPU, solicitações por segundo do balanceador de carga, métricas personalizadas ou agendamentos. Defina períodos de resfriamento (cool-downs) para evitar oscilações excessivas (thrashing).
• A autorrecuperação (autohealing) com verificações de saúde reinicia VMs não íntegras; garanta que o caminho da verificação de saúde teste a prontidão da aplicação, e não apenas a alcançabilidade da porta, para evitar servir erros 500.
• Atualizações contínuas (rolling updates) e blue-green: Crie um novo modelo de instância e inicie uma atualização canário (canary update) para um subconjunto de instâncias. Se os erros aumentarem, reverta (rollback) para o modelo anterior. Verificações de tempo de atividade (uptime checks) e alertas baseados em SLO detectam degradações rapidamente.

Logging e monitoramento

• Instale agentes para coletar logs da aplicação sem alterações no código; envie para o Cloud Logging e alerte via Cloud Monitoring. Use Debug Logpoints para diagnósticos em tempo real com interrupção mínima.

Build, Identidade, Rede, Segredos e Operações

Artifact Registry e imagens

• Use o Artifact Registry para imagens de contêiner e artefatos de linguagem. Habilite a verificação de vulnerabilidades e a geração de proveniência. Mantenha as imagens pequenas:
  • Builds de múltiplos estágios para separar o build do tempo de execução.
  • Evite ferramentas de desenvolvimento na imagem final; fixe as versões do SO e dos pacotes. Exemplo:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

• Promoção: Marque as imagens com tags imutáveis (ex: app:1.3.7, app:prod-20240901) e promova remarcando-as no Artifact Registry; evite a tag mutável latest em produção. Condicione as promoções aos resultados de testes de integração e canário.

Identidade de tempo de execução e privilégio mínimo

• Atribua uma conta de serviço (service account) dedicada por carga de trabalho com as funções mínimas do IAM necessárias. Evite funções amplas como Editor. No GKE, mapeie Kubernetes ServiceAccounts para contas de serviço do Google via Workload Identity. Para serverless, defina a conta de serviço de tempo de execução explicitamente e remova os escopos de token padrão (default-token scopes).

Conectores VPC e rede de serviços

• Os conectores do Serverless VPC Access roteiam o tráfego de saída (egress) do Cloud Run, Cloud Functions e App Engine para uma VPC. Escolha o modo de egress:
  • Somente intervalos privados (Private ranges only) para alcançar serviços RFC1918 e conectados à VPC, enquanto o tráfego de saída público vai diretamente.
  • Todo o tráfego via conector mais o Cloud NAT para IPs de saída determinísticos e políticas de saída restritas.
• Dependências privadas: Prefira o IP Privado para o Cloud SQL e o Private Service Connect para APIs do Google ou serviços de parceiros. Garanta que os conectores correspondam à região e sejam dimensionados para a vazão (throughput); monitore a CPU do conector para evitar limitação (throttling).

Configuração, segredos e verificações de integridade

• Use variáveis de ambiente para configurações não secretas. Armazene segredos no Secret Manager e monte-os ou injete-os em tempo de execução; rotacione as chaves regularmente. No GKE, use Secrets e o driver CSI para o Secret Manager. No App Engine e no Cloud Run, conceda à conta de serviço acesso a segredos específicos.
• Verificações de integridade (Health checks):
  • Cloud Run: a instância reinicia em caso de falha; use verificações no nível da requisição e SLIs de latência.
  • App Engine: verificações de integridade integradas; personalize liveness/readiness para o ambiente Flexível.
  • GKE: configure probes de liveness/readiness/startup.
  • Compute Engine atrás de LBs: use health checks HTTP(S) com endpoints específicos da aplicação.

Solução de problemas, rollback e padrões de lançamento

• Blue-green e canário com divisão de tráfego no Cloud Run e App Engine; no GKE, use Deployments paralelos ou controladores de entrega progressiva; em MIGs, use subconjuntos canário de instâncias. Sempre defina critérios de aborto com base no orçamento de erro (error budget) do SLO e na latência.
• Modos de falha comuns:
  • Manadas trovejantes (Thundering herds) após escalar para zero ou em grandes lançamentos; mitigue com instâncias mínimas, aquecimentos (warmups) e limitação de taxa (rate limiting).
  • Cotas de backend ou limites de conexão excedidos; aplique backoff exponencial e circuit breakers.
  • Partidas a frio (Cold starts) devido a imagens ou dependências grandes; enxugue as imagens e pré-inicialize os clientes.

Cenário de Problema Prático

A Acme Retail planeja migrar uma API de redimensionamento de imagens de VMs autogerenciadas para uma plataforma escalável e de baixo custo, com respostas de baixa latência, acesso privado a um bucket regional do Cloud Storage e lançamentos canário seguros.

Abordagem

1. Empacote o serviço como uma imagem de contêiner pequena e publique no Artifact Registry.

• Justificativa: Um build Docker enxuto e de múltiplos estágios minimiza as partidas a frio (cold starts) e a transferência de rede. O Artifact Registry centraliza as verificações e os fluxos de trabalho de promoção.

2. Implante a API no Cloud Run com um mínimo de 2 instâncias (min instances), concorrência de 40 e a opção de CPU sempre alocada (CPU always allocated) desativada.

• Justificativa: O Cloud Run fornece escalonamento horizontal instantâneo e HTTPS gerenciado. Um pequeno pool de instâncias mínimas reduz a latência de partida a frio durante os picos diurnos. Uma concorrência de 40 equilibra o custo e a latência de cauda (tail latency) para transformações de imagem limitadas por I/O. Desativar a CPU sempre ativa evita pagar por computação ociosa entre as requisições.

3. Crie um conector Serverless VPC Access e defina o egress como ‘private ranges only’; habilite o Private Google Access na sub-rede e configure um endpoint VPC-SC ou Private Service Connect para o Cloud Storage, se necessário.

• Justificativa: A API deve buscar e gravar imagens de forma privada, sem saída para a internet (public egress). O modo ‘private ranges’ garante que apenas o tráfego da VPC passe pelo conector, mantendo as chamadas públicas diretas e eficientes. O Private Google Access ou o Private Service Connect fornece acesso privado às APIs do Google a partir da VPC.

4. Conceda a uma conta de serviço (service account) de tempo de execução dedicada acesso de privilégio mínimo ao bucket de destino do Cloud Storage e aos segredos necessários.

• Justificativa: O princípio do privilégio mínimo limita o raio de impacto (blast radius). A identidade de tempo de execução recebe as permissões storage.objectViewer e storage.objectAdmin no bucket específico, e accessor nos segredos necessários do Secret Manager.

5. Armazene chaves de API e configurações por ambiente no Secret Manager e em variáveis de ambiente; injete os segredos em tempo de execução.

• Justificativa: Rotação centralizada de segredos e acesso auditável. A configuração não secreta via variáveis de ambiente apoia as práticas de 12 fatores (12-factor).

6. Implemente backoff exponencial e escritas idempotentes para lidar com erros 429/5xx do Cloud Storage.

• Justificativa: Durante picos de tráfego ou eventos regionais, erros transitórios podem ocorrer. O backoff com jitter protege tanto a API quanto o Cloud Storage de tempestades de novas tentativas (retry storms).

7. Configure uma revisão canário e divida 10% do tráfego para ela; monitore a taxa de erros, a latência P95 e a saturação.

• Justificativa: A divisão de tráfego no Cloud Run permite um lançamento progressivo seguro. Monitores baseados em SLOs fornecem gatilhos de rollback automático se os orçamentos de erro (error budgets) se esgotarem muito rapidamente.

8. Adicione um endpoint de verificação de integridade (health) HTTP que exercite as dependências downstream; configure alertas em verificações de tempo de atividade (uptime checks) do Cloud Monitoring e em métricas baseadas em logs.

• Justificativa: A verificação de integridade de ponta a ponta (end-to-end) detecta falhas de dependência precocemente. As verificações de tempo de atividade (uptime checks) fornecem uma perspectiva externa; métricas baseadas em logs capturam padrões de falha específicos da aplicação.

9. Estabeleça limites de autoescalonamento e orçamentos; defina um número máximo de instâncias (max instances) para limitar os gastos e defina o tratamento de erros 429 para sobrecarga.

• Justificativa: Limitar a escala evita custos descontrolados e o esgotamento do backend. Um comportamento de sobrecarga elegante (graceful) mantém a estabilidade do serviço.

10. Documente o rollback: desvie 100% do tráfego de volta para a revisão anterior do Cloud Run com um único comando.

• Justificativa: Revisões imutáveis tornam o rollback seguro e rápido, minimizando o tempo médio de recuperação (mean time to recovery).

← Arquitetura de Aplicações Nativas da Nuvem e Seleção de Serviços · Todos os domínios · Design de API →

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

Navegar Google →