Работа эластичной балансировки нагрузки Amazon WS

Question

Мне интересно знать работу ELB. У меня есть клиент, который отправляет CPU интенсивный запрос на сервер. Весь запрос, отправленный на сервер, проходит через AWS ELB. Я создал группу автомасштабирования для сервера с масштабирующей политикой со средним порогом использования процессора 80%.

Например, клиент будет отправлять только 5 запросов через ELB. 1-й запрос, отправленный на сервер, и его использование ЦП идет на 100%. Теперь, для второго запроса создается новый экземпляр, если я не ошибаюсь. Для этого нового экземпляра потребуется некоторое время для инициализации. & начинает обработку, так что его процессорный Util переходит на 100%. Это означает, что я должен поместить некоторую искусственную задержку больше, чем время инициализации экземпляра между двумя последовательными запросами, перенаправленными в ELB, чтобы один экземпляр сервера обрабатывал каждый запрос? Поправьте меня, если я ошибаюсь? Какая должна быть оптимальная задержка, добавленная в этом случае?

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

Желаемый результат: каждый экземпляр сервера обрабатывает один и все серверы параллельно. Я делаю это, чтобы ускорить общее время обработки, используя эластичность.

Благодаря в ожидании

Answer 1

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

У вас есть экземпляр, который получает запросы. Если это не так много запросов, это может быть даже микро-экземпляр. Затем этот экземпляр создаст задания в SQS. (Вы можете использовать другую систему очередей сообщений, но метрики SQS могут использоваться при автомасштабировании).

Ваши рабочие экземпляры получат сообщение от SQS, а затем обработают его. Вы сохранили бы результаты в s3 или базу данных в зависимости от того, что лучше всего подходит для вашего сценария (вы можете донести результаты до обратного вызова, предоставленного клиентом).