Блог

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

Например, у нас есть задача, которая должна выполняться каждые 5 минут, которая выполняет вызов API к внешнему API, интерпретирует данные, а затем, возможно, сохраняет некоторую новую информацию в базе данных. Ожидается, что эта конкретная задача будет выполняться в течение 30 секунд или около того, и ее нужно будет выполнять каждые 5 минут. Где это немного усложняется, так это в том, что мы запускаем приложение с несколькими арендаторами, и эта задача должна выполняться для каждого арендатора индивидуально. Это не удовлетворяет требованиям пользователя, чтобы один процесс выполнял указанную задачу для каждого клиента последовательно. Задача должна выполняться каждые x минут (иногда всего лишь каждую минуту), и она должна выполняться для каждого арендатора так быстро, как требуется для выполнения задачи ровно 1 раз. Другими словами, все 200, скажем, арендаторов должны выполнить задачу для них в полночь, чтобы каждая из них выполнила свою задачу за время, необходимое для запроса API и обновления базы данных для одного арендатора.

Чтобы немного усложнить задачу, это не единственная задача, которую мы будем выполнять по регулярному графику для наших арендаторов. В конце концов, у нас могут быть десятки уникальных задач, каждая из которых выполняется для сотен арендаторов, что приведет к тысячам или десяткам тысяч уникальных одновременных задач.

Я изучил Запланированные задачи ECS, в которых используются события CloudWatch (которые теперь являются мостом событий), но мост событий имеет ограничение в 300 правил на шину событий. Я думаю, что это означает, что нам не повезет, если нам понадобится 10 000 правил (по одному для каждой задачи * количество арендаторов), но я, честно говоря, не уверен, получает ли каждая учетная запись свою собственную шину событий или она разделена по-разному.

В любом случае, даже если бы это сработало, для меня все равно не очень привлекательный вариант-установить 10 000 различных правил в EventBridge. По крайней мере, мне кажется, что с этим может быть трудно справиться. С этой целью я сейчас больше рассматриваю возможность создания одного правила EventBridge для каждого типа событий, которое запускает родительскую задачу, которая, в свою очередь, асинхронно запускает столько асинхронных экземпляров дочерней задачи, сколько необходимо, по одному на каждого клиента. Это ограничило бы наши правила EventBridge где-то несколькими десятками. Каждый из них при запуске асинхронно порождает задачу для каждого клиента, которая может выполняться все вместе. Я не на 100% уверен в том, какой тип объекта это породит, это не будет Лямбда, так как это легко приведет к тому, что мы достигнем предела в 1000 одновременных функций Лямбда, но это может быть что-то вроде задачи ECS Fargate, которая выполняется в течение нескольких секунд, а затем исчезает, когда она завершена.

Я хотел бы услышать другие мысли об этих вариантах, моем текущем направлении и любых других вариантах, которых мне в настоящее время не хватает.