Назад | Перейти на главную страницу

Подходит ли Fargate для независимых контейнеров с низким уровнем использования ресурсов?

Я новичок в docker и ECS, поэтому могу использовать неправильные термины. Пожалуйста, дайте мне знать, если мне нужно уточнить.

Мой сценарий: У меня есть несколько независимых контейнеров. Каждый контейнер представляет собой веб-сайт. Каждый контейнер должен работать постоянно, но может длительное время бездействовать (например, нулевое использование ЦП). Для иллюстрации предположим, что у меня есть 10 контейнеров, и каждый контейнер требует до 200 МБ ОЗУ и до 1 виртуального ЦП. Предположим далее, что мне нужно всего 2vCPU для обработки комбинированной нагрузки от всех 10 контейнеров (поскольку они не видят высокой нагрузки одновременно).

Вариант 1 Фаргейт: Я создаю отдельную задачу для каждого контейнера: (2 ГБ, 1 виртуальный ЦП) x 10 (2 ГБ - минимальная оперативная память для 1 виртуального ЦП).

Вариант 2 Фаргейта: Создаю одну задачу со всеми контейнерами: (2GB, 2vCPU).

Вариант EC2: Я создаю задачу для каждого контейнера, привязанную к одному экземпляру EC2.

Если я правильно понимаю, Fargate Option 2 намного дешевле чем Fargate Option 1, потому что я знаю, что мне нужно максимум 2vCPU. Но вариант 2 намного менее гибкий, поскольку это задачи, которые останавливаются / запускаются / масштабируются, и я хочу рассматривать свои контейнеры как независимые друг от друга (например, останавливать / запускать / масштабировать независимо).

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

Итак: похоже, что для независимых контейнеров с низким уровнем использования ресурсов Fargate в настоящее время не подходит.

Я правильно понимаю?

Правильно, Fargate дороже EC2 при том же количестве vCPU / RAM.

Например:

  • В самый маленький контейнер Fargate с 0,25 vCPU и 0,5 ГБ RAM стоит 0,019 доллара в час, это примерно 14 долларов в месяц за контейнер.

  • Если вам нужен 1 виртуальный ЦП, минимальный объем ОЗУ составляет 2 ГБ (см. Поддерживаемые конфигурации Fargate) и вдруг цена ок. 55 $ / месяц за контейнер. В вашем случае раз 10 задач составляет 550 долларов в месяц.

  • С другой стороны, если вы уверены, что сможете сжать все это в один t3.small (2 виртуальных ЦП, 2 ГБ ОЗУ) это будет стоить 0,0208 доллара США в час, что составляет около 15 долларов в месяц. Даже если вам понадобится 2 или 3 t3.small экземпляров для поддержки вашего груза, это все еще намного дешевле, чем Fargate.

  • Если вы объедините все свои контейнеры в одну задачу Fargate (как предлагается в вашем Вариант 2) это по-прежнему дороже, чем использование EC2 ECS, плюс сложности, связанные с наличием нескольких независимых контейнеров в одной задаче. Это не стоит проблем.

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

С Fargate вы платите больше за гибкость.

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

Во многих случаях лучше работать на Fargate, даже если это дороже на виртуальный ЦП / ОЗУ. Мы запускаем партии из сотен контейнеров за один раз пару раз в день для некоторой обработки, и каждый контейнер работает всего около 10 минут. Если бы нам пришлось масштабировать кластер EC2 / ECS перед каждым запуском, ждать, пока он установится, разбираться с ошибками, затем запускать наше пакетное задание и затем снова уменьшать масштаб, накладные расходы были бы довольно высокими, а наша пакетная обработка заняла бы гораздо больше времени. .

Здесь у нас отлично работает Fargate. Я бы не стал использовать его для постоянного обслуживания.

Надеюсь, это поможет :)

Вы также можете использовать EKS (Elastic Kubernetes Service) вместо ECS.

Kubernetes дает больше контроля над модулями, сервисами, объемами и т. Д. Однако не уверен, что это дешевле, чем ECS, возможно, нет.