#amazon-web-services #amazon-s3 #amazon-ec2 #aws-cli
#amazon-web-services #amazon-s3 #amazon-ec2 #aws-cli
Вопрос:
В настоящее время в среде, которую я создаю, файл отправляется в корзину S3 из веб-формы в виде файла JSON. Когда этот файл поступает в корзину S3, он запускает AWS Lambda для включения экземпляра EC2. Что EC2 необходимо загрузить этот файл в корзину S3 и передать его в приложение. Как только это будет сделано, файл отправляется в корзину S3 и запускает AWS Lambda, который отключает экземпляр EC2.
Каков наилучший способ загрузки этого файла? Вот некоторые идеи, которые у меня были, но я не уверен, возможны ли они / практичны:
- Передайте идентификатор объекта S3 файла, который запустил AWS Lambda, в EC2 (с помощью Lambda)
- Передайте идентификатор объекта S3 последнего загруженного файла в корзину S3 в EC2
- Получить идентификатор объекта S3 единственного файла в корзине (например: mybucket/uploaded_files /) с помощью AWS CLI
Как только экземпляру EC2 будет передан идентификатор объекта, он загрузит его. Мысли / мнения? Спасибо.
Редактировать для пояснения: файл, загружаемый в корзину S3, представляет собой файл JSON, содержащий параметры конфигурации для приложения. Когда-либо будет только один экземпляр EC2 (потому что это побочный проект).
Комментарии:
1. Рассматривали ли вы возможность обработки файла с помощью лямбда-функции?
2. @MCI Файл на самом деле представляет собой просто файл JSON с параметрами конфигурации для основного приложения, работающего на ec2. Файл JSON, который загружается в корзину S3, — это то, что необходимо передать / перенести в экземпляр EC2, чтобы приложение знало, что делать. Я отредактирую свой первоначальный вопрос, чтобы уточнить.
Ответ №1:
Вероятно, наиболее масштабируемым и отказоустойчивым способом является использование SQS.
В этом сценарии ваш лямбда-код передает идентификатор объекта в выделенную очередь SQS и запускает экземпляр. Экземпляр при загрузке считывает сообщения из очереди и обрабатывает изображения, что включает их загрузку.
Комментарии:
1. Этого достаточно для того, чего я пытаюсь достичь, спасибо. Он будет помечен как правильный ответ, потому что он решает то, что я хочу, самым простым способом, хотя ответ, предоставленный @denov, отличный, если мне нужна эластичность, встроенная в мое решение.
Ответ №2:
Я бы не стал связывать запуск / остановку ec2 с созданием каждого файла, если бы нагрузка была достаточно высокой. например, файлы создаются быстрее, чем время запуска вашего экземпляра.
Я бы использовал события S3 для отправки сообщений в SNS, на которые подписан SQS. Обычно я всегда ставлю SNS перед SQS, поскольку это дает вам хорошее место для фильтрации и разветвления сообщений.
Тогда моя служба обработки прослушивала бы эту очередь SQS. Я бы также поместил свою службу обработки в группу автоматического масштабирования. Тогда вы могли бы управлять масштабированием группы по очереди SQS
Вы также можете использовать рабочую среду Beanstalk для решения всех задач масштабирования e2 и подписки на SQS.
Используя группы автоматического масштабирования, очень возможно получить «более быстрое» приложение при меньших затратах. Например, вы можете обнаружить, что на 2x t3.large все работает быстрее, чем на 1x t3.xLarge, когда стоимость t3.large составляет половину от t3.xLarge. НО это сильно зависит от вашего кода…
Другой идеей было бы просто выполнить всю обработку в лямбде. Вы можете упаковывать пользовательские исполняемые файлы в свой лямбда-код. Вот проект github, показывающий другой способ использования claimAV.