Web-scraping 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 для обеспечения максимальной скорости записи и сжатия данных.