Рекомендации по использованию Службы приложений Azure и Функций Azure для мультитенантности

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

Функции службы приложение Azure и Функции Azure, поддерживающие мультитенантность

приложение Azure служба и Функции Azure включают множество функций, поддерживающих мультитенантность.

Личные доменные имена

служба приложение Azure позволяет использовать ПОДстановочные знаки DNS и добавлять собственные сертификаты TLS с подстановочными знаками. При использовании поддоменов для конкретного клиента поддомен подстановочные знаки DNS и TLS позволяют легко масштабировать решение до большого количества клиентов, не требуя ручной перенастройки для каждого нового клиента.

При использовании пользовательских доменных имен для конкретного клиента может быть большое количество доменных имен, которые необходимо добавить в приложение. Это может стать громоздким для управления большим количеством пользовательских доменных имен, особенно если они требуют отдельных сертификатов TLS. Служба приложений предоставляет управляемые сертификаты TLS, что сокращает работу, необходимую при работе с пользовательскими доменами. Однако существуют ограничения, которые следует учитывать, например, сколько пользовательских доменов можно применить к одному приложению.

Интеграция с Azure Front Door

Служба приложений и Функции Azure могут интегрироваться с Azure Front Door, чтобы выступать в качестве компонента вашего решения, доступного к Интернету. Azure Front Door позволяет добавлять брандмауэр веб-приложения (WAF) и пограничный кэширование, а также обеспечивает другие оптимизации производительности. Вы можете легко перенастроить потоки трафика для перенаправления трафика в разные серверные части на основе изменения бизнес-требований или технических требований.

При использовании Azure Front Door с мультитенантным приложением вы можете использовать его для управления именами пользовательских доменов и завершения подключений TLS. Затем приложение Служба приложений настроено с одним именем узла, а весь трафик передается в это приложение, что помогает избежать управления именами пользовательских доменов в нескольких местах.

Как и в приведенном выше примере, Azure Front Door можно настроить для изменения заголовка Hostзапроса. Исходный Host заголовок, отправленный клиентом, распространяется через X-Forwarded-Host заголовок, и код приложения может использовать этот заголовок для сопоставления запроса с правильным клиентом.

Вы можете использовать частные конечные точки или Служба приложений ограничения доступа, чтобы обеспечить передачу трафика через Front Door перед достижением приложения.

Дополнительные сведения об использовании Azure Front Door в мультитенантном решении см. в статье "Использование Azure Front Door" в мультитенантном решении

Проверка подлинности и авторизация

служба приложение Azure может проверять маркеры проверки подлинности от имени приложения. Когда Служба приложений получает запрос, он проверяет, соответствует ли каждое из следующих условий:

• Запрос содержит маркер.
• маркер является действительным;
• Запрос авторизован.

Если какие-либо условия не выполнены, Служба приложений может заблокировать запрос или перенаправить пользователя в поставщик удостоверений, чтобы он смог войти в систему.

Если клиенты используют идентификатор Microsoft Entra в качестве системы удостоверений, можно настроить службу приложение Azure, чтобы использовать конечную точку /common для проверки маркеров пользователей. Это гарантирует, что независимо от клиента Microsoft Entra пользователя, их маркеры проверяются и принимаются.

Вы также можете интегрировать службу приложение Azure с Azure AD B2C для проверки подлинности потребителей.

Подробнее:

• авторизация Служба приложений
• Настройка проверки подлинности в примере веб-приложения с помощью Azure AD B2C
• Работа с мультитенантными удостоверениями Microsoft Entra

Ограничения доступа

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

При работе с мультитенантным решением следует учитывать максимальное количество правил ограничения доступа. Например, если необходимо создать правило ограничения доступа для каждого клиента, возможно, превышено максимальное количество разрешенных правил. Если требуется большее количество правил, рассмотрите возможность развертывания обратного прокси-сервера, например Azure Front Door.

Модели изоляции

При работе с мультитенантной системой с помощью службы приложение Azure или Функции Azure необходимо принять решение об уровне изоляции, которую вы хотите использовать. Ознакомьтесь с моделями аренды, которые следует учитывать для мультитенантного решения и рекомендации, приведенные в архитектурных подходах для вычислений в мультитенантных решениях, чтобы помочь вам выбрать оптимальную модель изоляции для вашего сценария.

При работе со службой приложение Azure и Функции Azure следует учитывать следующие основные понятия:

• В службе приложение Azure план представляет инфраструктуру размещения. Приложение представляет одно приложение, работающее в этой инфраструктуре. Можно развернуть несколько приложений в одном плане.
• В Функции Azure размещение и приложение также разделены, но у вас есть дополнительные варианты размещения, доступные для эластичного размещения, где Функции Azure управляет масштабированием. Для простоты мы рассмотрим инфраструктуру размещения как план в этой статье, так как принципы, описанные здесь, применяются как к Служба приложений, так и к Функции Azure независимо от используемой модели размещения.

В следующей таблице перечислены различия между основными моделями изоляции аренды для службы приложение Azure и Функции Azure:

Общие приложения

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

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

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

Чтобы использовать эту модель, код приложения должен быть многотенантным.

Приложения для каждого клиента с общими планами

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

• Экономичность. Общий доступ к инфраструктуре размещения позволяет сократить общие затраты на каждого клиента.
• Разделение конфигурации. Приложение каждого клиента может иметь собственное доменное имя, сертификат TLS, ограничения доступа и политики авторизации маркеров.
• Разделение обновлений: двоичные файлы каждого приложения клиента можно обновлять независимо от других приложений в одном плане.

Тем не менее, так как вычислительные ресурсы плана являются общими, приложения могут быть подвержены проблеме Шумного соседа. Кроме того, существуют ограничения на то, сколько приложений можно развернуть в одном плане.

Планы для каждого клиента

Самый сильный уровень изоляции — развертывание выделенного плана для клиента. Этот выделенный план гарантирует, что клиент полностью использует все серверные ресурсы, выделенные этому плану.

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

API узла

Api можно размещать как в службе приложение Azure, так и в Функции Azure. Выбор платформы зависит от определенного набора функций и параметров масштабирования.

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

• Централизованная точка для всей проверки подлинности. Это может включать определение идентификатора клиента из утверждения токена или других метаданных запроса.
• Маршрутизация запросов на различные серверные серверы API, которые могут быть основаны на идентификаторе клиента запроса. Это может быть полезно при размещении нескольких меток развертывания с собственными независимыми приложениями API, но вам потребуется один URL-адрес API для всех запросов.

Сеть и мультитенантность

IP-адреса

Многие мультитенантные приложения должны подключаться к локальным сетям клиентов для отправки данных.

Если необходимо отправить исходящий трафик из известного статического IP-адреса или из набора известных статических IP-адресов, рассмотрите возможность использования шлюза NAT. Дополнительные сведения об использовании шлюза NAT в мультитенантных решениях см . в рекомендациях по мультитенантности шлюза Azure NAT. Служба приложений предоставляет рекомендации по интеграции с шлюзом NAT.

Если вам не нужен статический исходящий IP-адрес, но вместо этого необходимо периодически проверять IP-адрес, который используется приложением для исходящего трафика, можно запросить текущие IP-адреса развертывания Служба приложений.

Планы продаж

Так как Служба приложений является мультитенантной службой, необходимо заботиться о том, как вы используете общие ресурсы. Сеть — это область, в которую необходимо обратить особое внимание, так как существуют ограничения , влияющие на работу приложения с исходящими и исходящими сетевыми подключениями, включая преобразование сетевых адресов источника (SNAT) и ограничения TCP-портов.

Если приложение подключается к большому количеству баз данных или внешних служб, ваше приложение может столкнуться с угрозой исчерпания портов SNAT. Как правило, исчерпание портов SNAT указывает на то, что код неправильно использует TCP-подключения, а даже в мультитенантном решении следует соблюдать рекомендации по повторному использованию подключений.

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

• Разверните шлюз NAT, чтобы увеличить количество портов SNAT, доступных для вашего приложения. Дополнительные сведения об использовании шлюза NAT в мультитенантных решениях см . в рекомендациях по мультитенантности шлюза Azure NAT.
• Используйте конечные точки службы при подключении к службам Azure для обхода ограничений подсистемы балансировки нагрузки.

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Джон Даунс | Главный инженер программного обеспечения

Другие участники:

• Тиаго Алмейда | Главный диспетчер программ, Функции Azure
• Арсен Владимирский | Главный инженер клиента, FastTrack для Azure

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Просмотрите ресурсы для архитекторов и разработчиков мультитенантных решений.