Вероятно, это не очень хорошая идея, но только для проверки концепции это может быть выполнимо.
В стандартном развертывании Airflow работает один или несколько веб-серверов.С моими несколькими 1000 DAG-файлами запуск веб-сервера занимает почти 20 минут, хотя это было улучшено в 1.10.2 против 1.8 и 1.10, которые я использую.
У него также есть один планировщик, который в основном всегда работает.
Наконец, если у вас есть исполнитель сельдерея, вы хотите, чтобы рабочие узлы запускали подбор задач.OTOH, если у вас есть kubernetes executor, планировщик создает рабочие модули для работы в очереди (я думаю).Предполагается, что они также всегда работают.
Теперь в AWS вы можете создать zip-файл со всеми зависимостями Airflow, файл конфигурации и, возможно, скрипт shim для получения последних файлов DAG из S3.Планировщик имеет аргумент ограничения цикла, так что вы можете установить его в один цикл (или с очень небольшим количеством файлов DAG, почему бы не 50 циклов, обычно это <1 с на файл) вместо бесконечного.Тогда вы могли бы использовать какой-нибудь внешний триггер для регулярного запуска.Скажем, вы знаете, что вы планируете группы обеспечения доступности баз данных только на отметке 10 минут, и ваша задача обычно занимает около 7-9 минут, затем триггер каждые 10 минут для запуска этого планировщика, это может просто сработать.Используя Celery с SQS, вы, вероятно, можете запускать рабочие задачи как лямбда AWS, когда что-то находится в очереди.Или с Kubernetes вы бы оставили этот EKS-кластер включенным и позволили планировщику заставить его работать. </p>
Сложная часть становится веб-сервером.Хотя верно, что вы, вероятно, можете использовать образ докера EC2 или ECS или EKS и запускать и останавливать его только тогда, когда вы этого хотите, он действительно использует довольно много ресурсов для создания пакета DAG;как планировщик;но после этого он начинает обслуживать запросы, поэтому он вообще не подходит для работы в AWS Lambda.Я имею в виду ... если вы полностью перестроили пользовательский интерфейс, так что большая часть его представляет собой статические файлы в S3, и только некоторые запросы запускают лямбду для получения данных из БД ... да, это будет работать.Но вы будете использовать сильно настроенный Airflow.
В этот момент вы задаетесь вопросом: если у меня есть много возможностей для разработки в AWS Lambda для поддержки этого, сколько еще работы для разработки всего потока DAG?нужно с RDS и Lambda, но без Airflow?