Pipelines de processamento de dados executados em infraestrutura gerenciada são, para a maioria das equipes, um ponto de partida melhor do que servidores autogerenciados. Você escreve a lógica de processamento; a plataforma cuida do escalonamento, das atualizações e da disponibilidade. O Google Cloud Run é uma escolha sólida para esse padrão porque executa qualquer container, escala a partir de zero e se integra de forma limpa ao restante do ecossistema Google Cloud.

Este post percorre a construção de um pipeline de processamento de dados serverless no Cloud Run, cobrindo ingestão, processamento, armazenamento e gatilhos orientados a eventos.

Por Que Serverless para Processamento de Dados?

Serverless funciona bem para pipelines de dados porque cargas de trabalho de dados tendem a ser intermitentes. O tráfego não é constante: arquivos chegam em lotes, eventos disparam picos durante o horário comercial e alguns pipelines rodam apenas uma vez por noite. Com serverless, você paga por computação somente quando algo está sendo processado de fato. Um pipeline ocioso não custa nada.

A contrapartida é a latência de cold start e a execução sem estado. O Cloud Run lida com ambos de forma razoável, mas etapas de pipeline que exigem tempo de inicialização abaixo de um segundo ou estado persistente em memória requerem configuração adicional.

Google Cloud Run

O Cloud Run executa containers sem estado que respondem a requisições HTTP. Você envia uma imagem de container, configura limites de memória e concorrência, e o Google cuida do restante. Ele escala a zero quando ocioso e volta rapidamente sob carga. Qualquer linguagem ou framework que possa ser executado em um container funciona.

Capacidades principais:

  • Sem infraestrutura para gerenciar.
  • Escala de zero a muitas instâncias com base no volume de requisições recebidas.
  • Integra-se ao Cloud Pub/Sub e ao Eventarc para gatilhos orientados a eventos.
  • Suporta qualquer linguagem ou runtime que possa ser conteinerizado.

Construindo o Pipeline

Passo 1: Configurando o Ambiente

Antes de começar, você precisa de:

  • Uma conta Google Cloud com faturamento habilitado.
  • Google Cloud SDK instalado.
  • API do Cloud Run habilitada no seu projeto.

Passo 2: Escrevendo a Aplicação de Processamento de Dados

Um serviço simples em Node.js e Express que recebe dados via HTTP POST:

app.js:

const express = require('express');
const app = express();
app.use(express.json());

app.post('/', async (req, res) => {
  const data = req.body;

  // Perform data processing here
  const processedData = processData(data);

  // Optionally, store or forward the processed data
  // For example, publish to a Pub/Sub topic, write to BigQuery, etc.

  res.status(200).send('Data processed successfully');
});

function processData(data) {
  // Simulate data transformation
  data.processedAt = new Date().toISOString();
  return data;
}

const PORT = process.env.PORT || 8080;
app.listen(PORT, () => {
  console.log(`Service listening on port ${PORT}`);
});

Passo 3: Conteinerizando a Aplicação

Dockerfile:

# Use the official Node.js 14 runtime as a parent image
FROM node:14-slim

# Create and set the working directory
WORKDIR /usr/src/app

# Copy package.json and package-lock.json
COPY package*.json ./

# Install dependencies
RUN npm install --only=production

# Copy the rest of the application code
COPY . .

# Expose the port
ENV PORT 8080
EXPOSE 8080

# Start the application
CMD [ "node", "app.js" ]

Passo 4: Build e Deploy no Cloud Run

# Build the container image
gcloud builds submit --tag gcr.io/PROJECT_ID/data-processor

# Replace PROJECT_ID with your Google Cloud project ID

# Deploy the image to Cloud Run
gcloud run deploy data-processor \
  --image gcr.io/PROJECT_ID/data-processor \
  --platform managed \
  --region REGION \
  --allow-unauthenticated

# Replace REGION with your preferred deployment region

Após o deploy, o Google fornece uma URL para o seu serviço Cloud Run.

Passo 5: Conectando Fontes de Eventos

Acionamento via Pub/Sub

Crie um tópico e uma assinatura no Pub/Sub que encaminhe mensagens para o seu serviço Cloud Run.

gcloud pubsub topics create data-topic

Crie uma conta de serviço com o papel de Pub/Sub Subscriber:

gcloud iam service-accounts create pubsub-invoker \
  --display-name "Pub/Sub Invoker"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:pubsub-invoker@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/pubsub.subscriber"

Crie uma assinatura push apontando para o Cloud Run:

gcloud pubsub subscriptions create data-subscription \
  --topic=data-topic \
  --push-endpoint=YOUR_CLOUD_RUN_URL \
  --push-auth-service-account=pubsub-invoker@PROJECT_ID.iam.gserviceaccount.com

Substitua YOUR_CLOUD_RUN_URL pela URL do seu serviço Cloud Run.

Eventos do Cloud Storage via Eventarc

Para acionar o processamento quando um arquivo é enviado ao Cloud Storage:

gcloud eventarc triggers create storage-trigger \
  --destination-run-service=data-processor \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --location=REGION \
  --service-account=pubsub-invoker@PROJECT_ID.iam.gserviceaccount.com

Qualquer objeto finalizado no Cloud Storage agora aciona o seu serviço Cloud Run.

Passo 6: Escalonamento e Configuração

Defina limites de concorrência e memória:

gcloud run services update data-processor \
  --concurrency=80 \
  --memory=512Mi

Defina variáveis de ambiente:

gcloud run services update data-processor \
  --update-env-vars "ENV=production,DEBUG=false"

Passo 7: Monitoramento e Logging

O Cloud Logging coleta logs da aplicação automaticamente. O Cloud Monitoring fornece dashboards e alertas para utilização de CPU, uso de memória e latência de requisições. Configure alertas para picos de taxa de erros e aumentos de latência antes que se tornem problemas visíveis para os usuários.

Boas Práticas

Mitigação de Cold Start

Mantenha ao menos uma instância mínima em execução para eliminar cold starts em pipelines sensíveis à latência:

gcloud run services update data-processor \
  --min-instances=1

Use imagens base enxutas para reduzir o tempo de inicialização do container.

Segurança

Conceda às contas de serviço apenas as permissões de que precisam. Use VPC Service Controls para pipelines que lidam com dados sensíveis.

Tratamento de Erros e Idempotência

Projete a lógica de processamento para lidar com mensagens duplicadas com segurança. O Pub/Sub garante entrega pelo menos uma vez, portanto uma mensagem pode chegar mais de uma vez. As retentativas devem produzir o mesmo resultado independentemente de quantas vezes forem executadas.

Casos de Uso Reais

Analytics em tempo real a partir de dispositivos IoT ou eventos de usuários, processos ETL carregando dados no BigQuery, processamento de imagens e vídeos acionado por uploads de arquivos e pipelines de pré-processamento para machine learning se encaixam naturalmente nessa arquitetura. O padrão é o mesmo em todos os casos: um evento aciona uma invocação do Cloud Run, o serviço processa o payload e o resultado é armazenado ou encaminhado.

Conclusão

O Cloud Run elimina a maior parte da carga operacional de executar pipelines de processamento de dados. Você escreve um container, define as fontes de eventos e deixa o Google cuidar do escalonamento, da disponibilidade e da infraestrutura. O modelo de custo — pagando apenas pelo compute efetivamente utilizado — torna a solução viável para pipelines com carga variável ou imprevisível. A principal disciplina exigida é projetar as etapas de processamento para serem sem estado e idempotentes, o que é uma boa prática em qualquer sistema distribuído.