Comments 22
UFO just landed and posted this here
Спасибо, как раз сейчас занимаюсь развертыванием ECS кластера, очень интересно и познавательно, продолжайте в том же духе.
Вопрос, успевают ли за 2 минуты запуститься новые ноды и контейнеры (которые на умирающих нодах были)?
Вопрос, успевают ли за 2 минуты запуститься новые ноды и контейнеры (которые на умирающих нодах были)?
Спасибо, будем продолжать!
Нет, новый инстанс подняться за 2 минуты не успеет, там не успевают так быстро отработать все проверки и развёртывание нового. Но если у вас есть свободное место на машинах, то контейнер обычно поднимается быстрее, чем за 2 минуты. Это зависит от контейнера, конечно, но на нашей практике не было дольше 1 минуты.
Чтобы всегда держать какое-то количество свободных инстансов, надо указать Target capacity % меньше 100%. Об этом есть в статье, актуально как для масштабирования, так и для случаев, когда нода умирает.
Но вообще кейс, что инстанс умирает, по нашему опыту, довольно редкий. Не скажу точный процент, но на сотни запущенных инстансов, у нас было меньше 10 таких случаев. Возможно, это связано с тем, что на ECS из-за постоянных деплоев и скейлов инстансы органически постоянно обновляются. То есть когда количество тасков увеличивается, а потом уменьшается, то свободные инстансы удаляются по нашему желанию. Из-за этого время жизни инстанса не очень большое, так что реже случаются кейсы удаления со стороны владельца. При этом у нас есть сервис, где нет масштабирования, и количество машин при деплое не меняется, и вот там спотовые инстансы почти 3 месяца уже живут, то есть всё это время их не убивали. Но их там всего 2, так что не очень репрезентативно.
Нет, новый инстанс подняться за 2 минуты не успеет, там не успевают так быстро отработать все проверки и развёртывание нового. Но если у вас есть свободное место на машинах, то контейнер обычно поднимается быстрее, чем за 2 минуты. Это зависит от контейнера, конечно, но на нашей практике не было дольше 1 минуты.
Чтобы всегда держать какое-то количество свободных инстансов, надо указать Target capacity % меньше 100%. Об этом есть в статье, актуально как для масштабирования, так и для случаев, когда нода умирает.
Но вообще кейс, что инстанс умирает, по нашему опыту, довольно редкий. Не скажу точный процент, но на сотни запущенных инстансов, у нас было меньше 10 таких случаев. Возможно, это связано с тем, что на ECS из-за постоянных деплоев и скейлов инстансы органически постоянно обновляются. То есть когда количество тасков увеличивается, а потом уменьшается, то свободные инстансы удаляются по нашему желанию. Из-за этого время жизни инстанса не очень большое, так что реже случаются кейсы удаления со стороны владельца. При этом у нас есть сервис, где нет масштабирования, и количество машин при деплое не меняется, и вот там спотовые инстансы почти 3 месяца уже живут, то есть всё это время их не убивали. Но их там всего 2, так что не очень репрезентативно.
рекомендуется регулярно обновлять AMI, потому что в новых версиях обновляются версии Docker, Linux, ECS агента и др.
Нет самого простого варианта — просто ссылаться на SSM.
$ export AWS_DEFAULT_REGION='eu-west-1'
$ aws ssm get-parameter --name /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id
{
"Parameter": {
"Version": 32,
"Type": "String",
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id",
"Value": "ami-060fdc00b63abc251"
}
}Еще очень рекоммендую ECS Task events. Для начала достаточно сделать Lambda, которая будет посылать в Slack(или что там у вас) детали по Stopped reason остановленных контейнеров. Очень удобно в множестве разных случаев: забыли запушить (не запушился) image в ECR, обновили task definitions и не понимаем почему ничего не обновляется. Или приложение работало-работало, потом поделило на ноль и вышло. Или на healthcheck вдруг не ответила одна из копий приложений и ее прибили.
С ECR у меня реально был случай недавно — запушил image, exit 0 от docker push, есть sha256 от него. Но самого image нет в ECR… Впервые такое видел, более пока не повторялось.
Ну и green/blue напишите, расскажите насколько сложно было и какие проблемы после хотябы полугода эксплуатации ;)
С ECR у меня реально был случай недавно — запушил image, exit 0 от docker push, есть sha256 от него. Но самого image нет в ECR… Впервые такое видел, более пока не повторялось.
Ну и green/blue напишите, расскажите насколько сложно было и какие проблемы после хотябы полугода эксплуатации ;)
Переходим на вкладку Capacity Providers и создаём новый
Очень странно выглядит когда сначала пишите что все у вас в Terraform, а потом «примеры с делаем чего-то в интерфейсе AWS». Или вы и вправду что-то делаете руками в интерфейсе AWS?
Интересно, после всех этих оптимизаций, во сколько раз дороже облака получаются, чем если тупо купить физические сервера в нужном количестве и самостоятельно собрать кластер нужной конфигурации? Казалось бы, в стоимость амазона входит отсутствие затрат на девопсов, но по сути для управления всем этим облаком нужно не меньше квалификации, чем физическими машинами.
Не могу сказать, мы не жили вне облака:) квалификация для управления всем этим нужна, безусловно, но кажется, что ручной работы всё же сильно меньше, а значит вероятность ошибиться. Плюс за нас делаются бэкапы, обновления, менеджится безопасность частично.
И самый большой плюс — это интеграция с другими сервисами внутри AWS. Нужно отправить пуши — есть SNS, для писем SES, для devops и аналитики Lambda + Kinesis, S3 очень удобный, CloudWatch тоже активно используем и много других сервисов. И на всё можно повесить триггеры, связать друг с другом, это очень удобно.
И самый большой плюс — это интеграция с другими сервисами внутри AWS. Нужно отправить пуши — есть SNS, для писем SES, для devops и аналитики Lambda + Kinesis, S3 очень удобный, CloudWatch тоже активно используем и много других сервисов. И на всё можно повесить триггеры, связать друг с другом, это очень удобно.
Интересно сколько у вас машин, cpu, ram в среднем и в пике? Сколько у вас devops которые этот парк обслуживают?
Что-то мне подсказывает что небольшая команда DevOps добилась сокращения расходов в 3 раза-вместо 9 тыр теперь платят 3. Значительное достижение. Классическая российская ситуация. Сисадмин экономит на спичках, а директор покупает новый мерс потому что старый разбил по пьянке на рыбалке.
У нас много сервисов (апи для сдк, апи для дашборда, кеш, асинхронные таски, pgbouncer, внутренние аналитики и др) и несколько окружений. Стабильно работает порядка 30 машин, почти на всех 2 vCPU и 2-4 GiB оперативки. На пиках может быть +10 машин, так как масштабируются не все сервисы.
У нас вообще нет выделенных devops, просто несколько разработчиков за этим следят фоново. В целом всё автономно работает, настроены уведомления по важным показателям, чтобы понимать, если вдруг что-то не по плану идёт, и надо посмотреть.
У нас вообще нет выделенных devops, просто несколько разработчиков за этим следят фоново. В целом всё автономно работает, настроены уведомления по важным показателям, чтобы понимать, если вдруг что-то не по плану идёт, и надо посмотреть.
Если не секрет — почему ECS, а не EKS?
Это всё интересно конечно с академической точки зрения, но вот даже и связываться бы не стал. Сразу вопрос возникает-это значит мои данные, данные клиентов, пойдут через неизвестно чьи сервера? Ждите в ближайшее время новости о похищени данных с подставных спотовых серверов.
Или я что-то не так понял в плане безопасности? Извиняюсь заранее, читал поверхностно.
Или я что-то не так понял в плане безопасности? Извиняюсь заранее, читал поверхностно.
Это такие же сервера в дата-центрах AWS, то есть там тот же уровень безопасности, та же виртуализация и тд. Единственное отличие, что они могут быть выключены не по вашей инициативе. Ну и цена:)
UFO just landed and posted this here
Почему просто не ALB + Lambda для API?
Sign up to leave a comment.
Создание масштабируемого API на спотовых инстансах AWS