Завдання може стабільно працювати на десяти цілях і втрачати надійність на тисячах. Класифікація помилок і дедуплікація, обмеження швидкості та паралельність, відновлення, збої мережевих виходів, перевірка узгодженості й кілька ключових метрик стають критичними саме у великому масштабі.
Скрипт збору даних може без проблем працювати на десяти цілях, а після розширення до тисяч почати втрачати відсоток успішних виконань. Додають повторні спроби, змінюють проксі, налаштовують паралельність, але проблеми повертаються. Якщо копнути глибше, вузьке місце часто не в логіці парсингу, а в кількох інженерних шарах, яких не було побудовано. На малому масштабі ці проблеми можуть зовсім не проявлятися.
Спочатку класифікуйте помилки, щоб повторні спроби мали сенс
Під час збору даних помилки неминучі. Головне — розрізняти їх: мережеві коливання та скидання з’єднання можна повторювати одразу; тимчасове обмеження швидкості потребує backoff перед новою спробою; якщо через зміну структури сторінки парсинг повертає порожній результат, навіть десять тисяч повторів не допоможуть — випадок треба записати й підняти попередження; якщо цілі не існує, завдання можна позначити завершеним; якщо середовище або мережевий вихід не запускається, слід перейти на інший і повторити спробу.
Повторювати все без розбору — одна з найпоширеніших помилок. Так проблеми, що потребують втручання людини, ховаються в циклах, а квоти й вихідні ресурси витрачаються даремно. Backoff теж потрібен: інтервали між спробами мають зростати, інакше весь пакет завдань повернеться в одному часовому вікні та ще сильніше посилить обмеження.
Повторні спроби безпосередньо ведуть до дедуплікації. Завдання може виконатися кілька разів, тому кожне завдання повинно мати стабільний унікальний ідентифікатор — наприклад, значення після нормалізації URL — а запис у базу має бути ідемпотентним щодо цього ідентифікатора. Інакше більше повторів означає більше забруднених даних.
Обмеження швидкості та паралельність — різні речі
Збільшення паралельності не гарантує зростання пропускної здатності. Одночасно діють три обмеження: скільки може витримати цільовий сайт до спрацювання rate limiting і падіння загальної пропускної здатності, пам’ять і CPU локальної машини, а також здатність одного середовища чи сесії виконувати кілька завдань одночасно.
Стабільніший підхід — почати з низької паралельності й поступово збільшувати навантаження, одночасно відстежуючи успішність і час відповіді, щоб знайти точку явного погіршення. Обмеження швидкості — окремий механізм: воно керує темпом доступу до однієї цілі й не дорівнює глобальній паралельності. Якщо пакет завдань розподілений між кількома сайтами, кожен сайт повинен мати власний темп.
Відновлення залежить від збереження стану
Для завдання, що працює кілька годин, переривання є нормальним; починати все з нуля часто занадто дорого. Потрібно постійно зберігати стан: очікує, виконується, завершено, а також кількість повторів, наступний дозволений час виконання та тип помилки. Після запуску процес має відновлювати чергу зі сховища, а не створювати її заново з пам’яті.
Тримати чергу лише в пам’яті — дуже поширений підхід, який здається працездатним. Щойно процес завершується аварійно, всі завдання в черзі зникають і облік перестає сходитися.
Окремо обробляйте збої проксі та мережевих виходів
Блокування виходу цільовим сайтом, відключення проксі або нестабільність регіонального вузла у великому масштабі відбуваються постійно. Це не винятки, а звичайні умови роботи. Сприймайте виходи як замінні ресурси: при помилці спочатку визначте, чи ціль обмежує швидкість, чи вихід недоступний; у першому випадку застосуйте backoff, у другому змініть вихід і повторіть спробу. Також фіксуйте відсоток збоїв кожного виходу та прибирайте групи, що явно деградують.
Якщо ж усі завдання використовують один вихід, одне завдання може порушити роботу каналу й вплинути на всі наступні. Для діагностики доведеться відмотувати журнали назад, щоб знайти завдання, яке спричинило проблему.
Перевірка узгодженості даних
Успішне виконання ще не означає правильні дані. Після запису треба мати змогу відповісти на кілька запитань: чи збігається кількість завершених завдань із кількістю записаних рядків, яка частка результатів парсингу порожня, чи не зросла аномально частка відсутніх критичних полів і скільки є дубльованих рядків?
Такі перевірки не мають бути складними. Достатньо вибіркової перевірки за пакетами, але хтось повинен переглядати результати. У великому масштабі неправильні дані можуть бути проблемнішими, ніж їх відсутність.
Які метрики відстежувати
Не потрібно збирати надто багато метрик. Достатньо кількох, що відображають стан системи.
- Відсоток успішних виконань і розподіл типів помилок, щоб бачити, які проблеми зростають
- Довжина черги та середній час очікування; постійне зростання backlog означає невідповідність між надходженням і здатністю обробки
- Кількість активних середовищ і пов’язаних процесів; тривале зростання в одному напрямку часто вказує на витік під час звільнення ресурсів
- Обсяг результату за одиницю часу, щоб зрозуміти, чи rate limiting не пригнічує пропускну здатність
- Частота збоїв виходів, щоб вирішити, чи потрібно замінити групу вузлів
Якщо хоча б одна з цих метрик тривалий час рухається лише в одному напрямку, спочатку перевірте звільнення ресурсів і логіку повторних спроб.
Винесіть шар середовища окремо
Усі ці питання приводять до одного висновку: шар середовища треба керувати незалежно від скриптів. Пул середовищ потребує централізованого планування, а не розподілення середовищ по окремих скриптах; звільнення ресурсів потребує стану, який можна запитати, а не спроб кожного скрипта відновитися самостійно; повторення з іншим середовищем або виходом працює лише тоді, коли середовища можна планувати незалежно.
Скрипти відповідають за логіку, а шар середовища — за ресурси та ідентичність. У такій архітектурі PurpleMark виконує саме цю роль, надаючи ресурси середовищ, які можна створювати пакетами, прив’язувати до незалежних мережевих виходів і перевіряти їхній стан.
Межі відповідності
Можливість масштабуватися не означає, що дані можна збирати довільно. Дотримуйтеся правил robots і умов використання цільового сайту, не збирайте персональні дані, не обходьте технічні заходи захисту та контролюйте частоту запитів, щоб не заважати нормальній роботі сервісу. Стабільність — технічне питання; дозвіл на збір — інше. Обидві умови мають виконуватися.
