Autoscaling workers

Привет

Есть у меня проект на котором есть очередь ( rabbitmq) и воркеры (серверы на digital ocean с процессами, которые обрабатывают задачи из очереди).

Пытаюсь организовать autoscaling воркеров. Чтоб проверять если в очереди много задач — то создавать новые droplets.

Все работает, но есть проблема — время создания дроплета. Я их создаю из существующего image и время создания дроплета порядка 2-6 минут даже для минимального размера 512mb.

А хотелось бы иметь возможность поднимать новые воркеры за время до одной минуты.

Сталкивался ли кто-то с подобной проблемой? Как решали?

Посоветуйте пожалуйста какие-то может быть другие хостинги, где операция поднятия сервера более быстрая.

Буду очень признателен за советы.

Юрий

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Docker не пробовали? Digital Ocean Docker поддерживает. Ваша задача выглядит не особенно сложной для докеризации. Но тут нужно понимать, что именно отнимает время, если развертывание образа и профижининг, то Docker поможет, если старт приложения — то нет.

тут чуть-чуть другая задача. Да докер будет поднимать воркеры очень быстро. Но для этого, мне понадобиться держать digitalocean дроплет в живом состоянии постоянно (и платить за него), что тогда теряет смысл. Если есть какой-то хостинг где можно было бы платить за докер контейнеры — это было бы супер круто конечно т.к. время поднятия контейнера ничтожно мало.

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

готовый стендбай не хочется держать — т.к. нагрузка имеет слишком пиковый характер. За целый день может быть 10 пиковых нагрузок по 10 минут каждая и держать все сервера в живом состоянии не хотелось бы. С хостингом — обязательно попробуем амазон. Может что-то еще есть.

Амазоновие EC2 инстанси стартуют из готового имаджа 35-40 секунд. Если бистрее нужно тогда держать инстанси остановленними тогда время запуска линукс инстанса 10-20 секунд. Если нужно еще бистрее тогда нужно держать запущений инстанс в резерве запущенним.

Или опяятьже держать запущеними такое количество воркеров, которое может обработать входящую очередь планируемого размера до того как запустятся новие воркери.

Спасибо за информацию про время старта образов. Этого явно будет достаточно. Каким-то образом размер ЕС2 влияет на время старта? У нас образ порядка 3Гб на debian’е.

Тести робив з базовим імаджом на 8гб

aws.amazon.com/elasticloadbalancing Используем вот это, дороже конечно но работает

Loadbalanсer для етой задачи не подойдет. — Методи разние.

А можно подробнее, почему в данном случае не подойдет Internal Load Balancer?

В описі прожекту вже фігуруе черга на основі rebitmq в якійсь міру це і е те шо розкидуе задачі по воркерам. Запитаня було як швидше додати нових воркерів. До речі сам по собі лоад балансен від амазона коштуе тільки трафік вихідний. Ціна інстансів зара майже зрівнялась у океана з амазоном.

Ну так ТС хочет

Чтоб проверять если в очереди много задач — то создавать новые droplets.
. Мне кажется, что как раз в этом случае AWS Autoscaling Groups + Launch Configuration самое оно. Можно даже без внутреннего балансера в конце концов через SQS/SNS. Вобщем нужно на AWS переезжать :)
AWS Autoscaling Groups + Launch Configuration
з привязкою до
SQS
буду працювати.
Но ця штука нікуди не поспішае. Таймаут на зміну статусу може тревати хвилину й більше.

До тогож у топік стартера вже е аналог Autoscaling Groups та Launch Configuration.

Подписаться на комментарии