Amazon EC2 + S3 + Python + Scraping - самый дешевый способ сделать это?

Основная предпосылка вашей установки выглядит хорошо, однако, есть несколько пунктов, которые вы можете учитывать.

Во-первых, пропускная способность сети EC2 (и I / O) зависит от типа экземпляра. Если вы надеетесь использовать экземпляры t1.micro, не ожидайте "сверхбыстрого подключения к Интернету" - даже при использовании m1.small вы можете не увидеть требуемой производительности. Кроме того, имейте в виду, что вы платите за пропускную способность, используемую в EC2 (а не только за время).

Что касается вашего первого замечания, то не должно быть никаких трудностей при настройке Python для экземпляра EC2. Однако потенциальная трудность возникает из-за координации ваших инстанций. Например, если у вас запущено 2 экземпляра, как вы разделите задачу между ними? Как каждый экземпляр "узнает", что сделал другой (при условии, что вы не собираетесь вручную разбивать список URL-адресов). Более того, если вы запускаете экземпляр, будет ли один из экземпляров EC2 отвечать за его обработку или будет ли ваш локальный компьютер иметь с ним дело (если это один из экземпляров EC2, как определить, какой экземпляр будет отвечать за задачу? (т. е. для предотвращения выполнения задачи "запуск" каждым экземпляром) и как вы перераспределяете задачи для включения нового экземпляра? Как вы определяете, какие экземпляры будут закрываться автоматически?

Несомненно, все вышеперечисленное возможно (коросинхронизация / сердцебиение, кардиостимулятор, автоматическое масштабирование и т. Д.), Но на первый взгляд его легко пропустить. В любом случае, если вы ищете "лучшую цену", вы, вероятно, захотите использовать точечные экземпляры (в отличие от "по требованию"), однако для того, чтобы это работало, вам нужна достаточно надежная архитектура. (Стоит отметить, что спотовые цены значительно колеблются - в разы превышая цену по требованию; в зависимости от шкалы времени, в которой вы работаете, вы либо захотите установить низкую верхнюю спотовую цену, либо определите лучший подход (спот / по требованию) на регулярной (почасовой) основе, чтобы минимизировать ваши затраты.) Хотя я не могу подтвердить это в настоящий момент, самым простым (и самым дешевым) вариантом может быть автоматическое масштабирование AWS. Вам необходимо настроить сигналы тревоги Cloudwatch (но Cloudwatch предоставляет 10 бесплатных сигналов тревоги), и само масштабирование само по себе не связано с затратами (кроме стоимости новых экземпляров и затрат Cloudwatch).

Учитывая, что я действительно не имею представления о масштабах вашей работы, я мог бы спросить, почему бы просто не использовать EC2 для анализа и обработки. Особенно, если синтаксический анализ сложен, страницы могут быть извлечены быстрее, чем они могут быть обработаны, и у вас есть большое количество страниц (предположительно, в противном случае вам не понадобится настраивать AWS), это может быть более эффективно просто обрабатывать страницы в EC2, а когда все будет сделано, загрузить дамп базы данных. Возможно, это может немного упростить ситуацию - иметь один экземпляр MySQL (с данными, хранящимися на томе EBS), каждый экземпляр запрашивает экземпляр MySQL для следующего набора записей (и, возможно, помечает их как зарезервированные), выборки и процессы, и сохраняет данные в MySQL.

Если вы не собираетесь запускать MySQL на EC2, вы можете либо сохранить свои HTML-файлы на S3, как вы уже упоминали, либо продолжить их сохранение на томе EBS. Преимущество S3 заключается в том, что вам не нужно предварительно выделять хранилище (особенно полезно, если вы не знаете размер данных, с которыми вы имеете дело) - вы платите за PUT /GET и хранилище; Недостатком является скорость - S3 не предназначен для использования в качестве файловой системы, и (даже если вы можете смонтировать его как файловую систему), было бы довольно неэффективно сохранять каждый отдельный файл в S3 (так как вы захотите накопить несколько страниц и их загрузить их на S3). Кроме того, если у вас большой объем файлов (десятки тысяч), обработка извлечения всех имен файлов и т. Д. Может быть медленной. Тома EBS предназначены для использования в качестве хранилища, подключенного к экземпляру - преимущество заключается в скорости - как в скорости передачи, так и в том, что у нее есть "файловая система" (поэтому чтение списка файлов и т. Д. Происходит быстро) - тома EBS сохраняются и после завершение экземпляра (за исключением корневых томов EBS, которые по умолчанию отсутствуют (но могут быть выполнены)). Недостатки томов EBS заключаются в том, что вам необходимо предварительно выделить количество хранилища (которое нельзя изменить на лету) - и вы платите за этот объем хранилища (независимо от того, используется ли оно полностью); Вы также платите за операции ввода-вывода (также производительность томов EBS зависит от скорости сети - поэтому большие экземпляры получают лучшую производительность EBS). Другое преимущество EBS заключается в том, что, будучи файловой системой, вы можете очень легко выполнять такие задачи, как распаковка файлов (и я полагаю, что если вы загружаете много html-страниц, вы не захотите получать отдельные файлы S3 позже).

На самом деле я не собираюсь рассуждать о возможностях (имея в виду, что в очень крупном масштабе для управления задачами такого типа будет использоваться что-то вроде map-Reduction / Hadoop), но пока у вас есть подход для разделения Задача (например, экземпляр MySQL) и управление масштабированием экземпляров (например, автоматическое масштабирование), идея, которая у вас есть, должна работать нормально.