Веб-скрейпінг 1M сторінок/день: архітектура на кількох VPS

Для організації scraping 1m pages (парсингу 1 мільйона сторінок) на добу потрібна розподілена архітектура з 5 VPS (4 vCPU, 8 GB RAM кожна), що використовує Scrapy-Redis для координації черг, headless Chrome через Docker-контейнери Browserless для обробки JavaScript і комбіноване сховище Postgres + ClickHouse для метаданих і сирих даних. Така конфігурація забезпечує стабільну швидкість близько 12-15 сторінок в секунду, мінімізує ризик блокувань через ротацію резидентних проксі і дозволяє масштабувати систему простим додаванням нових нод-воркерів.

Які серверні потужності потрібні для scraping 1m pages на добу?

При плануванні large scale scraping першочерговим завданням стає розрахунок ресурсів CPU і RAM, так як робота з headless-браузерами споживає в 10-20 разів більше ресурсів, ніж звичайні HTTP-запити. Для обробки 1 мільйона сторінок за 24 години система повинна обробляти в середньому 700 сторінок в хвилину. Якщо цільові сайти перевантажені клієнтським кодом (React, Vue, Angular), використання headless Chrome vps стає обов'язковим, що накладає жорсткі вимоги до оперативної пам'яті. Оптимальна стратегія - розділення ролей між серверами. Один сервер виділяється під управління (Redis, Postgres, RabbitMQ/Celery), а інші чотири працюють як обчислювальні ноди. Тип ноди Конфігурація VPS Кількість Роль в архітектурі Орієнтовна ціна (за од.) Master Node 4 vCPU, 8 GB RAM, 160 GB NVMe 1 Redis (черги), Postgres (метадані), ClickHouse $12-15/міс Worker Node 4 vCPU, 8 GB RAM, 80 GB NVMe 4 Scrapy, Celery Workers, Browserless (Chrome) $10-12/міс Разом 20 vCPU, 40 GB RAM 5 Scraping 1m pages / day ~$60/міс Для складних проектів, таких як парсинг Wildberries/OZON/Avito на VPS, критично важливо мати запас по RAM, так як кожна вкладка Chrome споживає від 150 до 400 MB. На сервері з 8 GB RAM можна комфортно запускати до 15-20 паралельних інстансів браузера без переходу в swap.

Розподілена архітектура: Scrapy Distributed і Redis

Центральним елементом системи виступає scrapy distributed підхід, де стандартний планувальник Scrapy замінюється на чергу в Redis. Це дозволяє декільком незалежним VPS підключатися до єдиного списку URL і розбирати завдання по мірі звільнення ресурсів. Redis тут працює не просто як кеш, а як високопродуктивний брокер повідомлень, що зберігає як поточну чергу (Lpush/Rpop), так і сет (Set) вже відвіданих сторінок для виключення дублікатів (DupeFilter). Перевага такої схеми в відмовостійкості: якщо один воркер впаде через нестачу пам'яті або блокування IP, завдання залишаться в Redis і будуть підхоплені іншими нодами. Налаштування в `settings.py` проекту Scrapy виглядає наступним чином:

# Использование планировщика Scrapy-Redis
SCHEDULER = "scrapy_redis.scheduler.Scheduler"
DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter"

# Настройки подключения к мастер-серверу
REDIS_HOST = '10.0.0.1' # Внутренний IP Master VPS
REDIS_PORT = 6339

# Очередь не очищается после остановки (позволяет возобновить парсинг)
SCHEDULER_PERSIST = True

Використання Celery в зв'язці зі Scrapy виправдано, коли парсинг ініціюється зовнішніми подіями або вимагає складної постобробки (наприклад, завантаження зображень в S3 або виклику нейромереж). Celery воркери на розподілених VPS можуть приймати завдання на парсинг конкретних сутностей і запускати процес `crawler.crawl()`, повертаючи результат в загальну базу.

Headless Chrome на VPS: оптимізація через Browserless

Запуск "голого" Puppeteer або Playwright на кожному сервері - шлях до витоків пам'яті і складнощів з управлінням зомбі-процесами. Для стабільного large scale scraping рекомендується використовувати Browserless - це open-source рішення, яке упаковує Chrome в Docker-контейнер і надає API для управління пулом вкладок. Використання puppeteer cluster всередині Browserless дозволяє ефективно утилізувати CPU. Замість запуску нового процесу браузера на кожен запит, ви використовуєте вже відкриті вкладки (Contexts), що скорочує час відгуку на 300-500 мс. Основні параметри оптимізації Browserless на VPS:

• MAX_CONCURRENT_SESSIONS: обмежте кількість вкладок у відповідності з RAM (наприклад, 15 для 8GB).
• PREBOOT_CHROME: тримайте браузер запущеним, щоб не витрачати час на "холодний старт".
• CHROME_REFRESH_SECONDS: примусове перезавантаження процесу раз на годину для очищення накопичених витоків пам'яті.

Команда для запуску воркера через Docker:

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

Такий підхід дозволяє Scrapy-скрипту підключатися до браузеру по протоколу WebSocket (`ws://10.0.0.x:3000`), передаючи навантаження по рендерингу на виділений сервіс. Якщо вам потрібно збирати дані для аналітики, наприклад, аналізувати тренди в месенджерах, така база стане в нагоді і для інших завдань, як Telegram-бот 24/7 на VPS, який буде повідомляти про важливі зміни на сайтах.

Проксі-пул і логіка обходу антифрод-систем

При досягненні обсягу в 1 мільйон сторінок на добу, звичайні дата-центр проксі перестають працювати. Захисні системи (Cloudflare, Akamai, DataDome) швидко обчислюють підмережі хостинг-провайдерів. Для успішного scraping 1m pages необхідно впровадити багаторівневу систему ротації IP. Рекомендована структура проксі-менеджменту: 1. **Резидентні проксі (Residential)**: використовуються тільки для сторінок за логіном або складних чекаутів. Оплата йде за трафік, тому їх економлять. 2. **Мобільні проксі (4G/5G)**: ідеальні для обходу найжорсткіших лімітів, так як мають високий траст. 3. **ISP-проксі**: статичні IP від домашніх провайдерів, поєднують швидкість дата-центрів і анонімність резидентних адрес. Алгоритм Retry Logic повинен бути інтелектуальним. Якщо Scrapy отримує 403 або 429 помилку, задача не просто повертається в чергу, а позначається прапором `proxy_fail`. При повторному запиті система повинна змінити тип проксі на більш "елітний". Для відстеження таких помилок корисно розгорнути Self-hosted Sentry, щоб в реальному часі бачити, на яких URL і типах проксі відбуваються збої.

Зберігання даних: гібрид Postgres і ClickHouse

Запис мільйона рядків на добу в класичну реляційну базу даних може створити вузьке місце в продуктивності (I/O Wait). Для ефективного управління даними при large scale scraping використовується розділення: Postgres (OLTP): використовується для зберігання стану задач, черг, даних користувачів та метаданих. Тут важлива підтримка транзакцій та індекси по ID. Якщо ви працюєте з векторними представленнями даних (наприклад, для пошуку схожих товарів), варто розглянути Vector DB на VPS як доповнення до Postgres. ClickHouse (OLAP): використовується для зберігання "сирих" результатів парсингу (HTML-теги, ціни, тексти). ClickHouse стискає дані в 10-20 разів ефективніше за Postgres і дозволяє виконувати аналітичні запити по мільйонах записів за мілісекунди. Приклад схеми таблиці в ClickHouse для зберігання результатів:

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);

Запис в ClickHouse має відбуватися пачками (batches) по 5 000 - 10 000 записів, що ідеально лягає в логіку Scrapy Pipelines.

Налаштування воркерів та автоматизація через Docker Compose

Для управління 5 серверами вручну потрібно занадто багато часу. Оптимальний стек автоматизації включає Docker Compose для локального запуску та Ansible для деплою на весь кластер VPS. Кожен воркер повинен містити інстанс Scrapy та локальний Browserless (якщо сайти вимагають JS). Приклад `docker-compose.yml` для воркер-ноди:

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

Для автоматизації запуску задач за розкладом або інтеграції з іншими сервісами (наприклад, відправка звітів в CRM), можна використовувати Self-hosted n8n. Це дозволить візуально налаштувати ланцюжок: "Парсинг завершено -> ClickHouse агрегація -> Звіт в Telegram".

Моніторинг продуктивності та бенчмарки

При scraping 1m pages критично важливо відслідковувати "здоров'я" кожного VPS. Основні метрики для моніторингу:

1. CPU Steal Time: якщо цей показник росте, значить, ваш VPS ділить фізичне ядро з занадто активним сусідом, що уповільнює парсинг.
2. Memory Usage: Chrome схильний "від'їдати" всю доступну пам'ять. Встановіть ліміти в Docker (mem_limit).
3. Network Bandwidth: 1 млн сторінок — це від 50 до 200 GB трафіку на добу. Переконайтеся, що ваш VPS-провайдер надає достатній канал (від 100 Mbps до 1 Gbps).

Бенчмарки показують, що при використанні Scrapy без браузера (чисті HTTP-запити) одна нода 4 vCPU може обробляти до 200 сторінок на секунду. Однак з headless Chrome продуктивність падає до 3-5 сторінок на секунду на одне ядро CPU. Саме тому розподілена архітектура на декількох VPS є єдиним економічно виправданим рішенням.

Висновки

Для стабільного scraping 1m pages на добу розгорніть кластер з 5 VPS з 4 vCPU та 8 GB RAM, використовуючи Scrapy-Redis для розподілу задач та Docker-контейнери Browserless для управління headless Chrome. Зберігайте оперативні дані в Postgres, а результати парсингу скидайте пачками в ClickHouse для забезпечення максимальної швидкості запису та стиснення даних.