Облачная служба Azure — автоматическое масштабирование по количеству очередей Невидимые сообщения (не готовые к обработке)

Мы только что разработали систему, которая интегрирует очередь Azure с облачной службой Azure для пакетной обработки элементов. Одно требование, которое у нас было, состояло в том, чтобы элементы были установлены в будущем для обработки. Так, например, мы запаковываем его сейчас, но говорим, чтобы он не запускался в течение 5 часов.

Это встроено прямо в очереди Azure с помощью InitialVisibilityDelay, поэтому мы не рассматриваем это как проблему. Однако мы только что заметили, что когда мы добавляем автоматическое масштабирование в нашу облачную службу, оно уходит от общего количества элементов в очереди. В нашей ситуации мы добавили 100 000 элементов очереди, которые должны быть отправлены через 5 дней, однако это масштабирование предполагает, что эти 100 000 готовы к отправке прямо сейчас.

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

Я чувствую, что здесь не хватает чего-то простого.

Любая обратная связь будет очень полезна.

Энтони


autoscaling azure-cloud-services azure-queues
person Anthony Greco    schedule 16.11.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Рассматривали ли вы возможность использования одной очереди для ожидающих сообщений и другой очереди для обработки фактических сообщений и масштабирования этой последней очереди?

person Nick Heppleston    schedule 17.11.2015
comment
Мы уже делаем это для обработки сообщений, находящихся в очереди более 7 дней. У нас есть длинная очередь, которая переносит очередь до 7 дней. Это наш следующий вариант, но у нас есть десятки очередей, а это только увеличивает накладные расходы и увеличивает количество точек отказа. Я думаю, что наш лучший вариант — масштабировать себя через API, однако, опять же, это приводит к другому моменту, когда что-то может просто потерпеть неудачу, когда мы предполагаем, что это была встроенная базовая функция. Почему azure будет масштабироваться в зависимости от размера, но считать элементы которые не готовы бежать, не имеет для нас смысла. - person Anthony Greco; 17.11.2015
comment
Почему azure будет масштабироваться в зависимости от размера, но подсчитывать элементы, которые не готовы к запуску, для нас не имеет смысла — я согласен, функциональность действительно кажется базовой (например, я хотел бы масштабировать SB Queues / темы, а не только очереди хранения). - person Nick Heppleston; 17.11.2015
comment
Просто кажется, что должен быть лучший / встроенный способ. На данный момент я собираюсь оставить это открытым, чтобы посмотреть, сможет ли кто-нибудь еще ответить на него, но если через несколько дней никто не ответит, я отмечу это как ответ. На самом деле мы собираемся сделать это прямо сейчас, так как мы уже построили его с задержкой более 7 дней, и буквально просто нужно изменить int, чтобы это сработало. Однако в долгосрочной перспективе это не кажется хорошим решением и, вероятно, справится с масштабом нашего «я» в кодировании. - person Anthony Greco; 18.11.2015
comment
Служба поддержки Azure ответила тем же ответом, используйте 2-ю очередь (более того, вопрос заключается в том, как правильно масштабировать эту 2-ю очередь), поэтому, в конце концов, похоже, что мне нужно разобраться с масштабированием самостоятельно. Спасибо за совет! - person Anthony Greco; 18.11.2015