Задержка лямбда-выполнения по конкретным данным - PullRequest
Новая
       5

Задержка лямбда-выполнения по конкретным данным

0 голосов
/ 31 мая 2018

Я пытаюсь найти способ обработки фрагментов данных через определенные промежутки времени, вызывая aws lambda каждые N часов.

Например, анализировать страницу по определенному URL каждые 6 часов и сохранятьрезультат в s3 bucket.
Иметь много (~ 100k) URL-адресов, которые обрабатываются таким образом.

Конечно, у вас может быть виртуальная машина, на которой размещен какой-то планировщик, который будет запускать лямбда-выражения, как описано в этот ответ , но это нарушает подход без сервера.

Итак, есть ли способ сделать это, используя только службы aws?

То, что я пробовал, не работает:

  • SQS может задерживать сообщения, но толькомаксимум 15 минут (мне нужны часы) и нет встроенной интеграции между SQS и Lambda, поэтому вам нужно иметь некоторый агент опроса (lambda?), который будет постоянно опрашивать qeueu и отправлять новые сообщения на рабочую лямбду,что снова нарушает точку выполнения только в запланированное время;
  • CloudWatch Alarms может отправлять сообщения в SNS, который запускает Lambda.Периодические лямбда-вызовы могут быть реализованы таким образом, используя метрическую временную метку будущего , однако к аварийному сообщению не могут быть подключены пользовательские данные (например, URL из примера выше), так что это тоже не работает;
  • Я мог бы создать запланированных триггеров Lambda CloudWatch программно, но они также не могут передавать какие-либо данные в Lambda.

Единственный способ, о котором я мог подумать, - это иметь динамо-базу данныхтаблица с записями «url», каждая из которых имеет метку времени последней «обработки» и имеет периодическую лямбду, которая будет запрашивать таблицу и отправлять «старые» записи в качестве заданий другой «рабочей» лямбде (напрямую или через SNS).Это сработало бы, однако вам все равно нужна лямбда-опрос, которая может стать узким местом по мере увеличения числа обрабатываемых элементов.

Есть еще идеи?

Ответы [ 2 ]

0 голосов
/ 01 июня 2018

Похоже, он подходит Сценарий пакетной обработки с лямбда-функцией AWS в качестве задания.Это без сервера, но, очевидно, добавляет зависимость от другого сервиса AWS.

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

0 голосов
/ 01 июня 2018

100 000 заданий каждые 6 часов, не похоже на отличный вариант использования для бессерверной IMO.Лично я бы настроил событие CloudWatch с соответствующим выражением cron, которое вызвало лямбду, чтобы запустить экземпляр EC2, который обработал все URL-адреса (хранящиеся в DynamoDB), и заставить сценарий EC2 завершить работу после обработки последнего URL.

Но это не то, что вы просили.

Вы могли бы настроить событие CloudWatch с соответствующим выражением cron, которое порождает лямбда (оркестратор), считывает URL-адреса из DynamoDB или даже файла S3, затем вызывает вторую лямбду (рабочий) для каждого URL для фактического анализа страниц.

Используя этот шаблон, вы начнете сталкиваться с проблемами параллелизма на 1000 лямбд (1 оркестратор и 999 рабочих), меньше, если в том же регионе работают другие лямбды.Вы можете попросить AWS увеличить этот лимит, но я не знаю, по каким сценариям они это сделают или насколько высоко они увеличат лимит.

Отсюда у вас есть три варианта.

  1. Разделите полезную нагрузку на каждую рабочую лямбду, чтобы каждый экземпляр получил несколько URL-адресов для обработки.

  2. Добавьте еще один столбец в свой список URL-адресов и URL-адреса групп с этимстолбец (например, первые 500 помечены 1, вторые 500 помечены 2 и т. д.).Тогда ваш оркестратор лямбда может удалить URL из списка в пакетном режиме.Это потребует, чтобы вы запускали событие CloudWatch с большей частотой и управляли состоянием, чтобы лямбда-оркестратор при вызове знал, какой следующий пакет (я сделал это в меньшем масштабе, просто сохраняя переменную в файле S2).

  3. Будет использоваться некоторая комбинация вариантов 1 и 2.

...