Работа с сельдереем в ECS Fargate

Для запуска типа запуска Fargate потребуется больше времени, чем для запуска типа запуска EC2, потому что AWS выполняет все «хост-функции» за вас, когда вы запускаете задачу, включая заведомо медленное подключение ENI и, вероятно, загрузку образа с Докер репо. Прямо сейчас конкурса нет, тип запуска EC2 с каждым разом быстрее.

Так что это действительно зависит от того, какую работу вы хотите, чтобы рабочие выполняли. Вы можете ожидать, что новая задача Fargate потребует несколько минут для перехода в состояние РАБОТА по вышеупомянутым причинам. С другой стороны, запуск EC2, поскольку ENI уже установлен на вашем хосте, а образ уже загружен (в лучшем случае) или в основном загружен (скорее всего, в худшем случае), очень быстро перейдет из состояния PENDING в RUNNING.

Используйте тип запуска EC2 для устойчивых рабочих нагрузок, используйте тип запуска Fargate для увеличения производительности.

Это распространенная в настоящее время мудрость, которую часто обсуждают как фактор стоимости, поскольку Fargate не может воспользоваться преимуществами типичных механизмов экономии затрат EC2, таких как зарезервированные инстансы и спотовые цены. Постоянно запускать Fargate дорого по сравнению с EC2.

Чтобы быть ясным, вполне нормально запускать 100% в Fargate (мы делаем), но вы должны быть готовы принять недостатки этого - более медленное масштабирование и стоимость.

Примечание вы можете запускать оба типа запуска в одном кластере. Кластеры в любом случае логичны, это просто способ организовать ваши ресурсы.

Пример кластера

В этом примере показана статическая служба типа запуска EC2, выполняющая 4 задачи сельдерея. Количество задач, спецификации, размер экземпляра и все такое на самом деле не имеет значения, делайте это как хотите. Важно то, что сервис типа запуска EC2 не требует масштабирования; Служба типа запуска Fargate может масштабироваться от ничего не работающего (в периоды, когда мало или совсем нет работы) до максимального количества рабочих, с которыми вы можете справиться, в соответствии с вашими правилами масштабирования.

EC2 запуск типа Celery service

Запуск 1 EC2 типа запуска t3.medium (2vcpu / 4GB).

Минимум задач: 2, Желаемое: 4, Максимальное количество задач: 4

Выполнение 4 задач сельдерея на 512/1024 в этом типе запуска EC2.

Нет политик масштабирования

Тип запуска Fargate Celery service

Минимум задач: 0, Желаемое: (x), Максимальное количество задач: 32

Запуск (x) задач с сельдереем (та же задача, что и для типа запуска EC2) на 512/1024

Добавить политики масштабирования к этому сервису

Ваша идея прекрасна! но ты что-то упустил,

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

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

Если сельдерей опущен, кто будет выращивать сельдерей, когда поставлена ​​задача? между вашим брокером обмена сообщениями и ECS нет связи для запуска сельдерея.

На самом деле сельдерей имеет возможность запускать задачу по запросу в соответствии с очередью обмена сообщениями, если она работает 24/7. В противном случае никто не знает, что была поставлена ​​новая задача.

Решение 1: замените сельдерей и перепишите всю логику для поддержки задач ECS и создайте механизм запуска для задач ECS в соответствии с вашими потребностями.

FYI: the above solution needs lot of efforts and not a practical