Каков алгоритм масштабирования для функций Azure (никогда не был доступен для 7 параллельных экземпляров)

Я пытаюсь понять, как работает масштабирование с использованием функций azure. Мы тестировали приложение, которое генерирует 88 сообщений в очереди хранения, что запускает нашу функцию. Функция написана в С#. Функция загружает файл, выполняет некоторую обработку на нем (в конце концов он будет опубликован, но мы не делаем этого для тестирования). Для выполнения каждой функции требуется около 30 секунд (всего ~ 2500 секунд обработки). Для целей тестирования мы зацикливаем это 10 раз.

Наша идеальная ситуация состояла бы в том, что после некоторого потепления Azure автоматически масштабирует функцию, чтобы обрабатывать сообщения наиболее целесообразным образом. Использование какого-то алгоритма с учетом времени разворота и т.д. Или просто масштабировать до количества сообщений в отставании с какой-то кепкой.

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

Пара других задач масштабируемости... Наша функция - интенсивная работа с памятью, как распределяется память между масштабированными экземплярами функции? Я прошу, потому что мы видим некоторые ошибки в памяти, которые мы обычно не видим. Weve настраивает максимальную память для функции (1536MB). Увидев около 2,5% операций при ошибке из-за ошибки памяти

Заранее спасибо, действительно хотели сделать эту работу, так как это позволило бы нам переместить большую часть нашей работы с выделенных оконных виртуальных машин на EC2 и на функции Azure.

Ответ 1

Цель состоит в том, что платформа позаботится о автоматическом масштабировании для вас с конечной целью, которую вам не нужно думать или заботиться о количестве "единиц потребления" (иногда называемых экземплярами), которые назначены для вашего функция. Тем не менее, всегда будет возможность для улучшения, чтобы мы получили это право для большинства пользователей.:)

Но чтобы ответить на ваш вопрос о внутренних деталях (по мере обработки очереди), то, что мы имеем сейчас, это система, которая рассматривает длину очереди и время, когда каждое сообщение находится в очереди, прежде чем оно будет обработано вашим приложением. Если мы почувствуем, что ваше функциональное приложение "отстает" при обработке этих сообщений, тогда будет добавлено больше единиц потребления, пока мы не подумаем, что ваше приложение может не отставать от входящей нагрузки.

Одна вещь, которую очень важно упомянуть, заключается в том, что существует еще один аспект масштаба, помимо количества единиц потребления. Каждый блок потребления имеет возможность обрабатывать много сообщений параллельно. Часто мы видим, что проблема у людей - это не количество выделенных единиц потребления, а конфигурация по умолчанию concurrency для их рабочей нагрузки. Взгляните на настройки batchSize и newBatchThreshold, которые можно настроить в файле host.json. В зависимости от вашей рабочей нагрузки вы можете обнаружить, что при изменении этих значений вы получаете значительно лучшую пропускную способность (в некоторых случаях снижение concurrency значительно увеличивает пропускную способность). Например, вы можете наблюдать это, если для выполнения каждой функции требуется много памяти или ваши функции зависят от внешнего ресурса (например, базы данных), который может обрабатывать ограниченный одновременный доступ. Дополнительную документацию по этим элементам управления concurrency можно найти здесь: https://github.com/Azure/azure-webjobs-sdk-script/wiki/host.json.

Как я уже говорил, игра с единицей потребления concurrency может помочь в проблемах с памятью, с которыми вы столкнулись. Каждый блок потребления имеет свой собственный пул памяти (например, собственный 1,5 ГБ). Но если вы обрабатываете слишком много сообщений в одном блоке потребления, то это может быть источником ошибок в памяти, которые вы видите.

С учетом всего этого мы постоянно работаем над определением и оптимизацией определенных сценариев загрузки, которые, по нашему мнению, являются наиболее распространенными, независимо от того, сбрасывает ли он кучу сообщений из очереди, потребляя "поток" капли в контейнере для хранения, обрабатывая поток HTTP-запросов и т.д. Ожидайте изменения вещей по мере того, как мы узнаем, созрим и получим больше отзывов от таких людей, как вы. Лучшее место для предоставления такой обратной связи группе продуктов находится в в нашем списке выпусков репо GitHub, который регулярно пересматривается.

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