Web-scraping de 1M de páginas/día: arquitectura en varios VPS

Para organizar el scraping de 1 millón de páginas (scraping 1m pages) al día se requiere una arquitectura distribuida de 5 VPS (4 vCPU, 8 GB de RAM cada uno), utilizando Scrapy-Redis para la coordinación de colas, headless Chrome a través de contenedores Docker de Browserless para el procesamiento de JavaScript y un almacenamiento combinado de Postgres + ClickHouse para metadatos y datos en bruto (raw data). Esta configuración garantiza una velocidad estable de unas 12-15 páginas por segundo, minimiza el riesgo de bloqueos mediante la rotación de proxies residenciales y permite escalar el sistema simplemente añadiendo nuevos nodos workers.

¿Qué potencia de servidor se requiere para el scraping de 1 millón de páginas al día?

Al planificar un large scale scraping, la tarea prioritaria es el cálculo de los recursos de CPU y RAM, ya que trabajar con headless browsers consume entre 10 y 20 veces más recursos que las peticiones HTTP convencionales. Para procesar 1 millón de páginas en 24 horas, el sistema debe procesar un promedio de 700 páginas por minuto. Si los sitios web de destino están cargados con código del lado del cliente (React, Vue, Angular), el uso de headless Chrome en VPS se vuelve obligatorio, lo que impone requisitos estrictos de memoria RAM. La estrategia óptima es la división de roles entre servidores. Un servidor se dedica a la gestión (Redis, Postgres, RabbitMQ/Celery), mientras que los otros cuatro funcionan como nodos de computación. Tipo de nodo Configuración VPS Cant. Rol en la arquitectura Precio orientativo (por unidad) Master Node 4 vCPU, 8 GB RAM, 160 GB NVMe 1 Redis (colas), Postgres (metadatos), ClickHouse $12-15/mes Worker Node 4 vCPU, 8 GB RAM, 80 GB NVMe 4 Scrapy, Celery Workers, Browserless (Chrome) $10-12/mes Total 20 vCPU, 40 GB RAM 5 Scraping 1m pages / día ~$60/mes Para proyectos complejos, como el scraping de Wildberries/OZON/Avito en VPS, es críticamente importante tener un margen de RAM, ya que cada pestaña de Chrome consume entre 150 y 400 MB. En un servidor con 8 GB de RAM, se pueden ejecutar cómodamente hasta 15-20 instancias paralelas del navegador sin recurrir al swap.

Arquitectura distribuida: Scrapy Distributed y Redis

El elemento central del sistema es el enfoque de scrapy distributed, donde el planificador estándar de Scrapy se sustituye por una cola en Redis. Esto permite que varios VPS independientes se conecten a una única lista de URLs y procesen las tareas a medida que se liberan recursos. Redis aquí no funciona simplemente como caché, sino como un broker de mensajes de alto rendimiento que almacena tanto la cola actual (Lpush/Rpop) como el conjunto (Set) de páginas ya visitadas para evitar duplicados (DupeFilter). La ventaja de este esquema es la tolerancia a fallos: si un worker se cae por falta de memoria o bloqueo de IP, las tareas permanecerán en Redis y serán retomadas por otros nodos. La configuración en el `settings.py` del proyecto Scrapy se ve de la siguiente manera:

# Uso del planificador Scrapy-Redis
SCHEDULER = "scrapy_redis.scheduler.Scheduler"
DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter"

# Configuración de conexión al servidor maestro
REDIS_HOST = '10.0.0.1' # IP interna del Master VPS
REDIS_PORT = 6339

# La cola no se limpia tras la parada (permite reanudar el scraping)
SCHEDULER_PERSIST = True

El uso de Celery junto con Scrapy está justificado cuando el scraping se inicia por eventos externos o requiere un post-procesamiento complejo (por ejemplo, subir imágenes a S3 o llamar a redes neuronales). Los workers de Celery en VPS distribuidos pueden recibir tareas para scrapear entidades específicas y ejecutar el proceso `crawler.crawl()`, devolviendo el resultado a la base de datos común.

Headless Chrome en VPS: optimización a través de Browserless

Ejecutar Puppeteer o Playwright "a pelo" en cada servidor es el camino hacia fugas de memoria y dificultades en la gestión de procesos zombie. Para un large scale scraping estable, se recomienda utilizar Browserless: una solución open-source que empaqueta Chrome en un contenedor Docker y proporciona una API para gestionar un pool de pestañas. El uso de puppeteer cluster dentro de Browserless permite utilizar la CPU de manera eficiente. En lugar de iniciar un nuevo proceso de navegador para cada petición, se utilizan pestañas ya abiertas (Contexts), lo que reduce el tiempo de respuesta entre 300 y 500 ms. Parámetros principales de optimización de Browserless en VPS:

• MAX_CONCURRENT_SESSIONS: limite el número de pestañas de acuerdo con la RAM (por ejemplo, 15 para 8GB).
• PREBOOT_CHROME: mantenga el navegador ejecutándose para no perder tiempo en el "cold start".
• CHROME_REFRESH_SECONDS: reinicio forzado del proceso una vez por hora para limpiar fugas de memoria acumuladas.

Comando para iniciar un worker a través de Docker:

docker run -d \
  --name browserless \
  -e "MAX_CONCURRENT_SESSIONS=15" \
  -e "MAX_QUEUE_LENGTH=30" \
  -p 3000:3000 \
  --restart always \
  browserless/chrome:latest

Este enfoque permite que el script de Scrapy se conecte al navegador mediante el protocolo WebSocket (`ws://10.0.0.x:3000`), delegando la carga de renderizado al servicio dedicado. Si necesitas recopilar datos para analítica, por ejemplo, analizar tendencias en mensajería, esta base será útil para otras tareas, como un Bot de Telegram 24/7 en VPS, que notificará sobre cambios importantes en los sitios.

Pool de proxies y lógica de evasión de sistemas antifraude

Al alcanzar un volumen de 1 millón de páginas al día, los proxies de centros de datos convencionales dejan de funcionar. Los sistemas de protección (Cloudflare, Akamai, DataDome) detectan rápidamente las subredes de los proveedores de hosting. Para un scraping exitoso de 1m de páginas, es necesario implementar un sistema de rotación de IP multinivel. Estructura recomendada de gestión de proxies: 1. **Proxies residenciales (Residential)**: se utilizan solo para páginas tras login o procesos de checkout complejos. Se paga por tráfico, por lo que se deben economizar. 2. **Proxies móviles (4G/5G)**: ideales para evadir los límites más estrictos, ya que gozan de alta confianza (trust). 3. **Proxies ISP**: IPs estáticas de proveedores domésticos, combinan la velocidad de los centros de datos con el anonimato de las direcciones residenciales. El algoritmo de Retry Logic debe ser inteligente. Si Scrapy recibe un error 403 o 429, la tarea no solo vuelve a la cola, sino que se marca con el flag `proxy_fail`. En la siguiente petición, el sistema debe cambiar el tipo de proxy a uno más "élite". Para rastrear estos errores, es útil desplegar Self-hosted Sentry, para ver en tiempo real en qué URLs y tipos de proxies ocurren los fallos.

Almacenamiento de datos: híbrido de Postgres y ClickHouse

Registrar un millón de filas al día en una base de datos relacional clásica puede crear un cuello de botella en el rendimiento (I/O Wait). Para una gestión eficiente de los datos en un large scale scraping, se utiliza una división: Postgres (OLTP): se utiliza para almacenar el estado de las tareas, colas, datos de usuarios y metadatos. Aquí es importante el soporte de transacciones y los índices por ID. Si trabajas con representaciones vectoriales de datos (por ejemplo, para buscar productos similares), vale la pena considerar una Vector DB en VPS como complemento a Postgres. ClickHouse (OLAP): se utiliza para almacenar los resultados "raw" del scraping (etiquetas HTML, precios, textos). ClickHouse comprime los datos entre 10 y 20 veces más eficientemente que Postgres y permite realizar consultas analíticas sobre millones de registros en milisegundos. Ejemplo de esquema de tabla en ClickHouse para almacenar resultados:

CREATE TABLE scraped_data (
    url String,
    domain String,
    price Float64,
    content String,
    scraped_at DateTime DEFAULT now(),
    status_code UInt16
) ENGINE = MergeTree()
ORDER BY (domain, scraped_at);

La escritura en ClickHouse debe realizarse por lotes (batches) de 5,000 - 10,000 registros, lo que encaja perfectamente en la lógica de los Pipelines de Scrapy.

Configuración de workers y automatización mediante Docker Compose

Gestionar 5 servidores manualmente requeriría demasiado tiempo. El stack de automatización óptimo incluye Docker Compose para la ejecución local y Ansible para el despliegue en todo el clúster VPS. Cada worker debe contener una instancia de Scrapy y un Browserless local (si los sitios requieren JS). Ejemplo de `docker-compose.yml` para un nodo worker:

version: '3.8'
services:
  worker:
    build: .
    command: scrapy crawl general_spider
    environment:
      - REDIS_URL=redis://10.0.0.1:6339/0
      - BROWSERLESS_URL=http://browserless:3000
    depends_on:
      - browserless

  browserless:
    image: browserless/chrome:latest
    ports:
      - "3000:3000"
    environment:
      - MAX_CONCURRENT_SESSIONS=10
    restart: always

Para automatizar la ejecución de tareas programadas o la integración con otros servicios (por ejemplo, enviar informes a un CRM), se puede utilizar Self-hosted n8n. Esto permitirá configurar visualmente la cadena: "Scraping finalizado -> Agregación en ClickHouse -> Informe en Telegram".

Monitoreo de rendimiento y benchmarks

En el scraping de 1m de páginas, es fundamental monitorizar la "salud" de cada VPS. Métricas principales para el monitoreo:

1. CPU Steal Time: si este indicador aumenta, significa que su VPS está compartiendo el núcleo físico con un vecino demasiado activo, lo que ralentiza el scraping.
2. Memory Usage: Chrome tiende a "devorar" toda la memoria disponible. Establezca límites en Docker (mem_limit).
3. Network Bandwidth: 1 millón de páginas representa entre 50 y 200 GB de tráfico al día. Asegúrese de que su proveedor de VPS ofrezca un ancho de banda suficiente (de 100 Mbps a 1 Gbps).

Los benchmarks muestran que al usar Scrapy sin navegador (peticiones HTTP puras), un nodo de 4 vCPU puede procesar hasta 200 páginas por segundo. Sin embargo, con headless Chrome, el rendimiento cae a 3-5 páginas por segundo por núcleo de CPU. Es por esto que una arquitectura distribuida en varios VPS es la única solución económicamente viable.

Conclusiones

Para un scraping estable de 1 millón de páginas al día, despliegue un clúster de 5 VPS con 4 vCPU y 8 GB de RAM, utilizando Scrapy-Redis para la distribución de tareas y contenedores Docker de Browserless para gestionar headless Chrome. Almacene los datos operativos en Postgres y vuelque los resultados del scraping por lotes en ClickHouse para garantizar la máxima velocidad de escritura y compresión de datos.