Запускать и закрывать экземпляры, подходящие для AWS ECS или Kubernetes?

Question

Я пытаюсь создать определенную сетевую инфраструктуру и смотрю на Amazon ECS и Kubernetes. Однако я не совсем уверен, что эти системы делают то, что я на самом деле ищу, или я искажаю их для чего-то другого. Если бы я мог описать свою задачу под рукой, мог бы кто-нибудь проверить, действительно ли Amazon ECS или Kubernetes помогут мне в этих усилиях, и это правильный способ думать об этом?

То, что я пытаюсь сделать, - это обработка одной задачи по требованию в экземпляре AWS. Под этим я подразумеваю, что у меня есть ресурсоемкое приложение, которое я хочу запустить в облаке и обработать кусок данных, представленных пользователем. Я хочу отправить эти данные для обработки в приложении, ускорить работу экземпляра EC2, обработать данные, загрузить результаты на S3 и затем завершить работу экземпляра EC2.

Я уже собрал работающее решение для этого, используя Simple Queue Service, EC2 и Lambda. Но мне интересно, ECS или Kubernetes сделали бы это проще? Я просматривал документацию ECS, и кажется, что она не очень связана с запуском и закрытием инстансов. Кажется, что он хочет иметь экземпляр, который постоянно работает, затем образы докера передаются ему как задача для запуска. Можно ли настроить Amazon ECS таким образом, чтобы при отсутствии задачи он автоматически выключал все экземпляры?

Также я не понимаю, как именно я бы отправил конкретный кусок данных для обработки. Кажется, что «Задачи», как они определены в Amazon ECS, действительно соответствуют одному контейнеру Docker, не так много, какие данные будет обрабатывать этот контейнер Docker. Это верно? Так нужно ли мне передавать данные, которые должны быть обработаны, в экземпляры через простой сервис очереди или другим способом? Затем используйте Lambda для опроса этих очередей, чтобы узнать, должны ли они отправлять задачи в ECS?

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

Answer 1

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

Многие функции ECS, kubernetes и т. Д. Направлены на то, чтобы позволить распределенному приложению, которое действует как единый сервис и которое можно масштабировать по горизонтали, обновлять и обслуживать. Это означает, что он помогает унифицировать взаимодействие сервисов, балансировку нагрузки, надежность сервиса, обслуживание без простоев, масштабирование количества рабочих узлов вверх / вниз на основе спроса (или других показателей) и т. Д.

Далее описывается идея высокого уровня для решения для вашего варианта использования с kubernetes (который немного более универсален, чем AWS ECS).

Таким образом, для вашего случая использования вы можете настроить кластер kubernetes, который запускает распределенную очередь событий, например кластер Apache Pulsar, а также кластер приложений, которому отправляются события очереди для обработки. Размер кластера приложения может автоматически масштабироваться в зависимости от количества необработанных событий в очереди ( custom pod autoscaler ). Инфраструктура кластера будет настроена на автоматическое масштабирование в зависимости от количества запланированных модулей (резервная емкость модулей в инфраструктуре).

Вы должны убедиться, что ваше приложение может работать в контейнере без состояния в контейнере.

Основным преимуществом вашего нынешнего решения, которое я вижу, будет независимость от облачного провайдера, а также некоторые общие преимущества от работы с контейнерной системой: 1. Не нужно беспокоиться о точной настройке ваших экземпляров EC2 с точки зрения зависимостей операционной системы. вашей рабочей нагрузки. 2. возможность обращаться к приложению обработки как к единой услуге. 3. Потенциально повышенная надежность, например, в случае ошибок.

По поводу ваших точных вопросов:

Может ли Amazon ECS быть настроен, чтобы при отсутствии задачи его запускать автоматически выключает все экземпляры?

Ключевое слово здесь - автомасштабирование. Обратите внимание, что существует два уровня масштабирования: 1. Масштабирование инфраструктуры (количество экземпляров EC2) и масштабирование службы приложения (количество развернутых контейнеров / задач приложения). Масштабирование инфраструктуры ECS работает на основе групп автоматического масштабирования EC2. Для получения дополнительной информации см. эту ссылку . Информацию о масштабировании службы приложений и бессерверной ECS (Fargate) см. по этой ссылке .

.

Также я не понимаю, как именно я бы представил конкретный кусок данных для обработки. Похоже, «Задачи», как определено в Amazon ECS действительно соответствует одному контейнеру Docker, не так много какие данные будет обрабатывать контейнер Docker. Это правильно?

« Определение задачи » в ECS описывает, как один или несколько контейнеров док-станции могут быть развернуты для какой-либо цели и каковы должны быть ее среда / ограничения. Задача - это отдельный экземпляр, который запускается в «Сервисе», который сам может развернуть одну или несколько задач. Сходными понятиями являются Pod и Service / Deployment в kubernetes.

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

Очередь всегда помогает отделить запросы на обслуживание от обработки и убедиться, что вы не потеряете запросы. Это не требуется, если ваш кластер службы приложений может предлагать интерфейс службы и надежно обрабатывать входящие запросы напрямую. Но если кластер приложений должен часто увеличиваться / уменьшаться, это может повлиять на его способность к надежной обработке.