Cloud Run Worker Pools: Evoluindo de Web Apps para Processamento Baseado em Mensagens

O Cloud Run consolidou-se como um dos pilares mais respeitados no GCP para quem busca abstração de infraestrutura em microsserviços. Historicamente, contudo, a plataforma impunha um modelo mental rígido: ou você atendia requisições HTTP (Cloud Run Services), ou executava tarefas finitas de processamento (Cloud Run Jobs). Para cargas de trabalho persistentes, como processamento contínuo de streams de dados, pipelines de AI ou filas de mensagens, muitos times acabavam migrando forçadamente para o GKE ou GCE.

A introdução dos Cloud Run Worker Pools muda esse paradigma. Ao transformar o Cloud Run em uma plataforma de consumo pull-based, o Google endereça uma dor latente em arquiteturas serverless: gerenciar o backpressure e a natureza assíncrona de aplicações distribuídas sem recorrer ao overprovisioning ou sofrer com timeouts de requisições HTTP.

Um caso de uso real que ilustra essa evolução é a plataforma Rostrum, da Estée Lauder Companies. A empresa migrou seu serviço de chat baseado em LLM de um modelo request/response para um padrão produtor-consumidor. Ao desacoplar a camada de UI servida via FastAPI da inferência pesada de IA (processada por workers que extraem mensagens do Pub/Sub), o time alcançou durabilidade 100% nas mensagens e garantiu SLAs consistentes para a latência da UI, evitando gargalos durante picos sazonais de tráfego, como as festas de fim de ano.

Essa abordagem não apenas melhora a resiliência do sistema, mas introduz um ganho claro de eficiência financeira. Em cenários de processamento constante, os Worker Pools podem atingir até 40% de redução de custos em comparação com o modelo de Services ou Jobs tradicionais, devido à natureza mais adequada do runtime para tarefas background de longa duração.

Otimização com o ecossistema KEDA

Um ponto crítico da transição para Worker Pools é a estratégia de escalabilidade. Como não estamos mais vinculados a requisições HTTP, o escalonamento precisa ser guiado por métricas externas. O Google responde a isso através do CREMA (Cloud Run External Metrics Autoscaler), um projeto open-source que integra o poder do KEDA ao ambiente serverless. Com ele, você pode configurar o scale-out baseado na profundidade de filas (Kafka, Pub/Sub) ou até na demanda de GitHub Runners, permitindo que a infraestrutura se comporte de forma inteligente diante de variações de workload:

CopiarapiVersion: crema/v1
kind: CremaConfig
metadata:
  name: gh-demo
spec:
  scaledObjects:
    - spec:
        scaleTargetRef:
          name: projects/example-project/locations/us-central1/workerpools/example-workerpool
        triggers:
          - type: github-runner
            metadata:
              owner: repo-owner
              runnerScope: repo
              repos: repo-name
              targetWorkflowQueueLength: 1

Visão de infraestrutura para empresas brasileiras

Para gestores de TI e engenheiros, a grande oportunidade aqui é a redução do operational overhead. Ao utilizar Worker Pools, eliminamos a necessidade de gerenciar o ciclo de vida dos nós e a configuração complexa de VPCs com L4 ingress. A capacidade de anexar Worker Pools diretamente a redes VPC e receber IPs privados abre portas para integração com sistemas legados ou on-premises de forma segura, mantendo o modelo serverless.

Se o seu time ainda lida com a dor de configurar instâncias fixas ou clusters de Kubernetes para tarefas que poderiam ser orquestradas via filas, é prudente avaliar essa transição. A estabilidade operacional ganha fôlego quando removemos o componente HTTP da equação em processos background, permitindo um tratamento de erro mais robusto via dead-letter queues e escalonamento reativo.

---

Artigo originalmente publicado por Aniruddh ChaturvediEngineering Manager em Cloud Blog.