Los pipelines de procesamiento de datos que se ejecutan en infraestructura gestionada son, para la mayoría de los equipos, una mejor opción por defecto que los servidores autogestionados. Tú escribes la lógica de procesamiento; la plataforma se encarga del escalado, los parches y la disponibilidad. Google Cloud Run es una opción sólida para este patrón porque ejecuta cualquier contenedor, escala desde cero y se integra limpiamente con el resto de Google Cloud.

Este artículo recorre la construcción de un pipeline de procesamiento de datos serverless en Cloud Run, cubriendo ingesta, procesamiento, almacenamiento y disparadores orientados a eventos.

¿Por Qué Serverless para el Procesamiento de Datos?

Serverless funciona bien para pipelines de datos porque las cargas de trabajo de datos tienden a ser intermitentes. El tráfico no es constante: los archivos llegan en lotes, los eventos generan picos durante el horario laboral y algunos pipelines se ejecutan solo una vez por noche. Con serverless, pagas por cómputo únicamente cuando algo se está procesando de verdad. Un pipeline inactivo no cuesta nada.

La contrapartida es la latencia de cold start y la ejecución sin estado. Cloud Run maneja ambas con razonable eficacia, pero los pasos de pipeline que requieren tiempos de arranque inferiores a un segundo o estado persistente en memoria necesitan configuración adicional.

Google Cloud Run

Cloud Run ejecuta contenedores sin estado que responden a solicitudes HTTP. Subes una imagen de contenedor, configuras límites de memoria y concurrencia, y Google se ocupa del resto. Escala a cero cuando está inactivo y vuelve a escalar rápidamente bajo carga. Funciona cualquier lenguaje o framework que pueda ejecutarse en un contenedor.

Capacidades clave:

  • Sin infraestructura que gestionar.
  • Escala de cero a muchas instancias según el volumen de solicitudes entrantes.
  • Se integra con Cloud Pub/Sub y Eventarc para disparadores orientados a eventos.
  • Soporta cualquier lenguaje o runtime que pueda contenerizarse.

Construyendo el Pipeline

Paso 1: Configurar el Entorno

Antes de comenzar, necesitas:

  • Una cuenta de Google Cloud con facturación habilitada.
  • Google Cloud SDK instalado.
  • API de Cloud Run habilitada en tu proyecto.

Paso 2: Escribir la Aplicación de Procesamiento de Datos

Un servicio sencillo en Node.js y Express que recibe datos vía 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}`);
});

Paso 3: Contenerizar la Aplicación

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" ]

Paso 4: Build y Deploy en 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

Tras el despliegue, Google proporciona una URL para tu servicio de Cloud Run.

Paso 5: Conectar Fuentes de Eventos

Disparador vía Pub/Sub

Crea un tema y una suscripción en Pub/Sub que envíe mensajes a tu servicio de Cloud Run.

gcloud pubsub topics create data-topic

Crea una cuenta de servicio con el rol 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"

Crea una suscripción push apuntando a 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

Reemplaza YOUR_CLOUD_RUN_URL con la URL de tu servicio Cloud Run.

Eventos de Cloud Storage vía Eventarc

Para disparar el procesamiento cuando se sube un archivo a 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

Cualquier objeto finalizado en Cloud Storage dispara ahora tu servicio Cloud Run.

Paso 6: Escalado y Configuración

Establece límites de concurrencia y memoria:

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

Establece variables de entorno:

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

Paso 7: Monitoreo y Logging

Cloud Logging recopila los logs de la aplicación de forma automática. Cloud Monitoring proporciona dashboards y alertas para utilización de CPU, uso de memoria y latencia de solicitudes. Configura alertas para picos en la tasa de errores y aumentos de latencia antes de que se conviertan en problemas visibles para los usuarios.

Buenas Prácticas

Mitigación de Cold Start

Mantén al menos una instancia mínima en ejecución para eliminar cold starts en pipelines sensibles a la latencia:

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

Usa imágenes base ligeras para reducir el tiempo de arranque del contenedor.

Seguridad

Otorga a las cuentas de servicio solo los permisos que necesitan. Usa VPC Service Controls para pipelines que manejen datos sensibles.

Manejo de Errores e Idempotencia

Diseña la lógica de procesamiento para gestionar mensajes duplicados de forma segura. Pub/Sub garantiza entrega al menos una vez, por lo que un mensaje puede llegar más de una vez. Las reintentos deben producir el mismo resultado independientemente de cuántas veces se ejecuten.

Casos de Uso Reales

Analytics en tiempo real desde dispositivos IoT o eventos de usuarios, procesos ETL que cargan datos en BigQuery, procesamiento de imágenes y vídeos disparado por subidas de archivos, y pipelines de preprocesamiento para machine learning encajan de forma natural en esta arquitectura. El patrón es el mismo en todos los casos: un evento dispara una invocación de Cloud Run, el servicio procesa el payload y el resultado se almacena o se reenvía.

Conclusión

Cloud Run elimina la mayor parte de la carga operativa de ejecutar pipelines de procesamiento de datos. Escribes un contenedor, defines las fuentes de eventos y dejas que Google gestione el escalado, la disponibilidad y la infraestructura. El modelo de costos —pagar solo por el cómputo real— lo hace práctico para pipelines con carga variable o impredecible. La principal disciplina requerida es diseñar los pasos de procesamiento para que sean sin estado e idempotentes, lo cual es una buena práctica en cualquier sistema distribuido.