Бессерверный пайплайн данных на AWS

Задача

Для прогнозирования цен компании нужны были обширные и свежие рыночные данные. Цель — около 5 млн объявлений в день по 7 маркам автомобилей, с которыми она работает.

Пайплайн должен был работать надёжно, укладываться в бюджет и справляться с источником, который ограничивает скорость чтения.

Архитектура

1. Расписание EventBridge запускает каждый цикл сбора. Небольшая Lambda-функция сбрасывает цели на день.
2. Очередь SQS хранит задания и заменяет прежнюю схему, в которой очередью служила база данных. Сообщения с ошибками уходят в dead-letter queue.
3. Воркеры Lambda-функции, упакованные в Docker-образы, параллельно загружают и разбирают страницы.
4. Хранилище Объявления попадают в RDS PostgreSQL, а RDS Proxy обеспечивает пул соединений. Запись инкрементальная и атомарная.
5. Алерты Метрики и алерты CloudWatch с уведомлениями через SNS.

• Повторы и восстановлениеБезопасный захват целей, повторные попытки, восстановление зависших задач и повторная отправка из DLQ
• Lambda для мониторингаЗадача только для чтения, которая передаёт состояние базы данных в CloudWatch
• Проверки состоянияСкрипты на AWS CLI, которые работают в любой ОС

Замедляться, а не падать

Источник данных, который ограничивает частоту запросов, будет сопротивляться нагрузке. Пайплайн спроектирован с учётом этого:

• Circuit breaker. Когда страницы начинают блокироваться, воркеры встают на паузу, а не повторяют запросы ещё настойчивее. Общее состояние паузы хранится в PostgreSQL.
• Адаптивное ограничение частоты. Интервалы между запросами слегка случайны (jitter), пайплайн автоматически снижает темп, когда источник сопротивляется, а после паузы воркеры наращивают нагрузку постепенно.
• Безопасная параллельность. Воркеры безопасно берут цели в работу, повторяют попытки и восстанавливают зависшие задачи, поэтому многие из них могут работать параллельно без конфликтов.

Наблюдаемость и эксплуатация

• Алерты на то, что действительно важно. CloudWatch сообщает мне, когда оркестратор останавливается, воркеры падают, Lambda их ограничивает (троттлинг), очередь растёт или сообщения в ней стареют, страницы блокируются, запись в базу данных не проходит или число объявлений за день падает.
• Проверки состояния. Скрипты на AWS CLI проверяют пайплайн с любой машины, а небольшая Lambda-функция только для чтения отправляет данные о состоянии базы в CloudWatch.
• Письменные инструкции. В них описано, как ограничить или остановить Lambda-функции и очистить очереди, чтобы вышедшая из-под контроля задача не раздула расходы.

Укрепление после ревью старшего инженера

Старший инженер провёл ревью пайплайна, и по итогам ревью я его укрепил:

• У каждого запроса к базе данных есть таймаут, а каждая запись атомарна.
• Воркеры загружают только URL из списка разрешённых и отклоняют слишком большие ответы.
• Страница, которая приходит подозрительно пустой, сразу считается сбоем, и каждый сбой записывается вместе с его контекстом.
• Я убрал дорогой COUNT(*) из горячего пути и добавил инструменты обслуживания индексов.
• Сроки хранения образов ECR и логов CloudWatch не дают расти расходам на хранение.

Результаты

• 5 млн/деньцель, достигнутая на тестах на самом маленьком инстансе RDS
• ~5000/деньлимит источника в продакшене
• Ежедневносбор, хранение и алерты в продакшене
• 7 марокавтомобилей охвачено для исследования цен компании

Чему я научился: пайплайн справлялся с 5 млн объявлений в день, а источник — нет. Когда источник ужесточил лимиты запросов, устойчивый темп упал примерно до 5000 объявлений в день, и это стало обычным рабочим режимом. При таком масштабе предел задаёт источник данных, а не инфраструктура, поэтому снижение темпа (back-off) нужно закладывать в архитектуру с первого дня.

На этой странице нет кода работодателя, внутренних данных и закрытых URL, а источник данных не назван.