Как приложение-функция Azure масштабируется для миллионов одновременных запросов пользователей

Я пытаюсь понять, как функция Azure масштабируется при всплеске трафика при работе либо в плане потребления, либо в плане службы приложений. здесь сказано, что можно иметь неограниченный доступ в Интернет , Мобильный, Приложение API в плане обслуживания приложений.

Хотите знать, как ему это удается? В частности, если я запускаю свое приложение-функцию в одном из тарифных планов приложений, будет ли оно истекло или недоступно при определенных условиях пиковой нагрузки?

Поскольку для URI приложения-функции назначен только один IP-адрес, как Azure обеспечивает горизонтальное масштабирование в этом случае (условия экстремальной пиковой нагрузки)?

Использует ли он какой-то внутренний балансировщик нагрузки, а затем создает новую временную виртуальную машину (для распределения нагрузки и) для запуска экземпляра приложения-функции в условиях нагрузки (когда определенное количество одновременных пользователей / соединений пытается получить доступ к URI функции) ?

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

Итак, еще раз, как можно запустить неограниченное количество веб-приложений, мобильных приложений или приложений API в плане обслуживания приложений Azure с учетом этого сценария, не исчерпав пул внутренних IP-адресов?


person Andy    schedule 07.12.2018    source источник
comment
Боковое примечание: исчерпать даже обычный частный диапазон IPv4-адресов 10.x.x.x сложно, представьте, как сложно исчерпать IPv6 :)   -  person Alexei Levenkov    schedule 07.12.2018
comment
За многие годы существует обширная документация по веб-приложениям Azure (и функциям Azure). К сожалению, ваш вопрос здесь не по теме, поскольку это действительно обсуждение, а не конкретный вопрос программирования (и большая часть архитектуры службы приложений уже задокументирована, так что это скорее вопрос запроса документации). Тем не менее: вы делаете некоторые предположения (например, запуск временных виртуальных машин и поглощение IP-адресов), которые на самом деле не точны.   -  person David Makogon    schedule 07.12.2018
comment
Дэвид будет признателен, если вы предоставите ссылку на документацию по внутреннему устройству плана службы приложений, в которой объясняется, как он управляет неограниченным количеством веб-приложений и API мобильных приложений и может масштабироваться до 10 миллионов одновременных подключений без исчерпания пулов IP-адресов в заданном регионе Azure DC. Я просмотрел несколько документов и не нашел ни одного.   -  person Andy    schedule 07.12.2018


Ответы (1)


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

Центры обработки данных Azure состоят из разных масштабных единиц, каждая из которых состоит из сотен серверов (даже 1000). Это масштабируемая мощь, которую приносит с собой служба приложений. В одном центре обработки данных может быть несколько весов.

Внутренняя архитектура службы приложений состоит из: - внешнего интерфейса - семислойного балансировщика нагрузки Web Worker - файловых серверов веб-серверов - для хранения содержимого приложения.

Чтобы ответить на ваши вопросы ниже -

Вопрос: Поскольку для URI приложения-функции назначен только один IP-адрес, как Azure обеспечивает горизонтальное масштабирование в этом случае (условия экстремальной пиковой нагрузки)?

В. Использует ли он какой-то внутренний балансировщик нагрузки, а затем создает новую временную виртуальную машину (для распределения нагрузки и) для запуска экземпляра приложения-функции в условиях нагрузки (когда определенное количество одновременных пользователей / соединений пытается получить доступ к функции URI)?

A: Он не создает новую временную виртуальную машину, а использует веб-воркеров, которые представляют собой предварительно подготовленные виртуальные машины, выполняющие общую нагрузку. Внешний интерфейс - это многоуровневый балансировщик нагрузки, отвечающий за распределение трафика в случае горизонтального масштабирования.

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

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

person R Jain    schedule 07.12.2018
comment
Спасибо. Это то, чего я ожидал. Так как Unlimited не существует, и это слово в MS Doc вводит в заблуждение. Кстати, это реальные вопросы, которые задает мой клиент, и я просмотрел весь архитектурный документ по Azure о масштабируемости и все еще не мог определить максимальный предел, при котором план службы приложений начнет рушиться. Мой клиент хочет запустить 1-2 миллиона запросов в службе приложений, используя функцию. Было бы неплохо, если бы Microsoft обеспечила пиковую нагрузку одновременных пользователей, которую каждый план службы приложений Azure может обрабатывать в каждом регионе, чтобы мы могли лучше спланировать любой обходной путь. - person Andy; 07.12.2018