Планирование долгосрочных задач с использованием служб AWS

Question

Мое приложение сильно зависит от услуг AWS, и я ищу оптимальное решение на их основе. Веб-приложение запускает запланированное задание (предположительно повторяется бесконечно), которое требует определенного количества ресурсов, которые необходимо выполнить. Один запуск задачи обычно занимает максимум 1 мин.

Текущая идея состоит в том, чтобы передавать задания через SQS и создавать работников на экземплярах EC2 в зависимости от размера очереди. (эта часть более или менее ясна) Но я изо всех сил стараюсь найти правильное решение для фактического запуска заданий через определенные промежутки времени. Предположим, мы имеем дело с 10000 заданиями. Поэтому для планировщика запускать 10k cronjob (сама работа довольно проста, просто передавая описание задания через SQS) в то же время кажется безумной идеей. Таким образом, фактический вопрос заключается в том, как автомасштабировать сам планировщик (учитывая сценарии при перезапуске планировщика, создании нового экземпляра и т. Д.)? Или планировщик является избыточным как приложение, и разумнее полагаться на функции AWS Lambda (или другие сервисы, обеспечивающие планирование)? Проблема с использованием функций Lambda - это определенное ограничение, а объем памяти, предоставляемый 128mb, обеспечиваемый одной функцией, на самом деле слишком большой (20mb кажется более чем достаточно)

В качестве альтернативы, рабочий сам может подождать определенное количество времени и сообщить планировщик, что он должен запускать работу еще раз. Скажем, если частота 1 часы:

1. Scheduler sends job to worker 1 
2. Worker 1 performs the job and after one hour sends it back to Scheduler 
3. Scheduler sends the job again 

Проблема здесь, однако, является возможность того, что работник будет масштабируется в

Bottom Line Я пытаюсь достичь легкого планировщика, который будет. не требуют автомасштабирования и служат в качестве концентратора с единственной целью передачи описаний должностных обязанностей. И, конечно же, не следует затухать при перезагрузке службы.

Answer 1

Лямбда идеально подходит для этого. У вас много коротких запусков (~ 1 минута), а Lambda - для коротких процессов (до пяти минут в настоящее время). Очень важно знать, что скорость процессора напрямую связана с оперативной памятью. 1GB лямбда-функция эквивалентна экземпляру t2.micro, если я правильно помню, а RAM 1,5 ГБ - в 1,5 раза больше скорости процессора. Стоимость этих функций настолько мала, что вы можете просто выполнить это. ОЗУ 128 МБ имеет 1/8 скорость процессора микро-экземпляра, поэтому я не рекомендую использовать их на самом деле.

Как механизм очередей, вы можете использовать S3 (да, вы это правильно понимаете). Создайте ведро и позвольте работнику Lambda запускаться, когда объект создан. Когда вы хотите запланировать задание, поместите файл в ведро. Lambda запускает и обрабатывает его немедленно.

Теперь вы должны соблюдать некоторые ограничения. Таким образом, вы можете одновременно иметь только 100 рабочих (общее количество активных экземпляров Lambda), но вы можете попросить AWS увеличить это.

Затраты следующим образом:

• 0,005 за 1000 запросов PUT, так что $ 5 за миллион запросов на работу (это дороже SQS).
• Lambda время выполнения. Предполагая нормальную скорость процессора t2.micro (1 ГБ ОЗУ), это стоит $ 0.0001 за задание (60 секунд, первые 300.000 секунд бесплатны = 5000 заданий)
• Лямбда-запросы. $ 0,20 за миллион триггеров (первый миллион является бесплатным)

Эта установка не требует серверов с вашей стороны. Это не может спуститься (только если сам AWS).

(не забудьте удалить задание из S3, когда вы сделали)