Überlegungen zur Mehrinstanzenfähigkeit für Azure App Service und Azure Functions

Azure
App Service
Functions

Azure App Service ist eine leistungsstarke Hostingplattform für Webanwendungen. Azure Functions basiert auf der App Service-Infrastruktur. Mit dieser Lösung können Sie problemlos serverlose und ereignisgesteuerte Computeworkloads erstellen. Beide Dienste werden häufig in mehrinstanzenfähigen Lösungen verwendet.

Features von Azure App Service und Azure Functions, die die Mehrinstanzenfähigkeit unterstützen

Azure App Service und Azure Functions enthalten viele Features, die die Mehrinstanzenfähigkeit unterstützen.

Benutzerdefinierte Domänennamen

Mit Azure App Service können Sie Platzhalter-DNS-Einträge verwenden und Ihre eigenen Platzhalter-TLS-Zertifikate hinzufügen. Wenn Sie mandantenspezifische Unterdomänen verwenden, können Sie mit Platzhalter-DNS-Einträgen und TLS-Zertifikaten Ihre Lösung problemlos auf eine große Anzahl von Mandanten skalieren, ohne dass für jeden neuen Mandanten eine manuelle Neukonfiguration erforderlich ist.

Wenn Sie mandantenspezifische benutzerdefinierte Domänennamen verwenden, müssen Sie möglicherweise eine große Anzahl benutzerdefinierter Domänennamen zu Ihrer App hinzufügen. Es kann umständlich sein, viele benutzerdefinierte Domänennamen zu verwalten, insbesondere wenn sie einzelne TLS-Zertifikate erfordern. App Service bietet verwaltete TLS-Zertifikate, wodurch die Arbeit mit benutzerdefinierten Domänen weniger aufwendig wird. Jedoch gibt es Grenzwerte, die berücksichtigt werden müssen, z. B. wie viele benutzerdefinierte Domänen auf eine einzelne App angewendet werden können.

Integration mit Azure Front Door

App Service und Azure Functions können mit Azure Front Door integriert werden, um als Komponente Ihrer Lösung zu fungieren, die über Internetzugriff verfügt.

Mit Azure Front Door können Sie eine Web Application Firewall (WAF) und Edgezwischenspeicherung hinzufügen. Auch bietet die Lösung weitere Leistungsoptimierungen. Sie können Ihre Datenverkehrsflüsse ganz einfach neu konfigurieren, um den Datenverkehr auf der Grundlage von sich ändernden geschäftlichen oder technischen Anforderungen an verschiedene Back-Ends zu leiten. Wenn Sie Azure Front Door mit einer mehrinstanzenfähigen App verwenden, können Sie die Lösung verwenden, um Ihre benutzerdefinierten Domänennamen zu verwalten und Ihre TLS-Verbindungen zu beenden. Ihre App Service-Anwendung wird dann mit einem einzelnen Hostnamen konfiguriert, und der gesamte Datenverkehr fließt an diese Anwendung, wodurch Sie es vermeiden können, benutzerdefinierte Domänennamen an mehreren Stellen zu verwalten.

Das Diagramm zeigt Anforderungen, die mit verschiedenen Hostnamen in Front Door eingehen. Die Anforderungen werden unter Verwendung eines einzigen Hostnamens an die App Service-App übergeben.

Wie im obigen Beispiel kann Azure Front Door so konfiguriert werden, dass der Host-Anforderungsheader geändert wird. Der ursprüngliche, vom Client gesendete Host-Header wird über den X-Forwarded-Host-Header propagiert, und Ihr Anwendungscode kann diesen Header verwenden, um die Anforderung dem richtigen Mandanten zuzuordnen.

Tipp

Wenn Ihre Anwendung Cookies oder Umleitungsantworten sendet, müssen Sie besonders darauf achten. Änderungen an den Host-Anforderungsheadern können diese Antworten ungültig machen. Weitere Informationen finden Sie in der Bewährten Methode zur Erhaltung des Hostnamens.

Sie können private Endpunkte oder App Service-Zugriffseinschränkungen verwenden, um sicherzustellen, dass der Datenverkehr über den Front Door-Dienst fließt, bevor er Ihre App erreicht.

Authentifizierung und Autorisierung

Azure App Service kann Authentifizierungstoken für Ihre App überprüfen. Wenn eine Anforderung kein Token enthält, ist das Token ungültig oder die Anforderung ist nicht autorisiert. App Service kann so konfiguriert werden, dass die Anforderung blockiert oder an Ihren Identitätsanbieter umgeleitet wird, damit sich der*die Benutzer*in anmelden kann.

Wenn Ihre Mandanten Azure Active Directory (Azure AD) als Identitätssystem verwenden, können Sie Azure App Service so konfigurieren, dass der /common endpoint zum Überprüfen von Benutzertoken verwendet wird. Dadurch wird sichergestellt, dass Token unabhängig vom Azure AD-Mandanten des Benutzers bzw. der Benutzerin überprüft und akzeptiert werden.

Sie können Azure App Service mit Azure AD B2C integrieren, um Heimanwender*innen zu authentifizieren.

Weitere Informationen:

Zugriffsbeschränkungen

Sie können den Datenverkehr zu Ihrer App mithilfe von Zugriffseinschränkungen einschränken. Diese können verwendet werden, um die IP-Adressbereiche oder die virtuellen Netzwerke anzugeben, die eine Verbindung mit der App herstellen dürfen.

Beachten Sie bei der Arbeit mit einer mehrinstanzenfähigen Lösung die maximale Anzahl der Regeln für Zugriffseinschränkungen. Wenn Sie beispielsweise eine Zugriffseinschränkungsregel für jeden Mandanten erstellen müssen, könnten Sie die maximal zulässige Anzahl von Regeln überschreiten. Wenn Sie eine größere Anzahl von Regeln benötigen, sollten Sie einen Reverseproxy wie Azure Front Door verwenden.

Isolationsmodelle

Wenn Sie in einem mehrinstanzenfähigen System mit Azure App Service oder Azure Functions arbeiten, müssen Sie entscheiden, welche Isolationsstufe Sie verwenden möchten. Informationen zur Auswahl des besten Isolationsmodells für Ihr Szenario finden Sie unter Zu berücksichtigende Mandantenmodelle für eine mehrinstanzenfähige Lösung und in der Anleitung unter Architekturansätze für Compute in mehrinstanzenfähigen Lösungen.

Wenn Sie mit Azure App Service und Azure Functions arbeiten, sollten Sie die folgenden wichtigen Konzepte kennen:

  • In Azure App Service entspricht ein Plan Ihrer Hostinginfrastruktur. Eine App entspricht einer einzelnen Anwendung, die in dieser Infrastruktur ausgeführt wird. Sie können mehrere Apps in einen einzelnen Plan bereitstellen.
  • In Azure Functions werden Ihr Hosting und Ihre Anwendung ebenfalls getrennt, aber Sie verfügen über zusätzliche Hostingoptionen für elastisches Hosting, bei dem Azure Functions die Skalierung für Sie verwaltet. Der Einfachheit halber wird die Hostinginfrastruktur diesem Artikel als Plan bezeichnet, da die hier beschriebenen Prinzipien sowohl für App Service als auch für Azure Functions gelten, unabhängig von dem von Ihnen verwendeten Hostingmodell.

In der folgenden Tabelle werden die Unterschiede der wichtigsten Mandantenisolationsmodelle für Azure App Service und Azure Functions erläutert:

Aspekt Freigegebene Apps Apps pro Mandant mit freigegebenen Plänen Pläne pro Mandant
Konfigurationsisolation Niedrig Mittel. Einstellungen auf App-Ebene sind für den Mandanten vorbehalten, Einstellungen auf Planebene werden freigegeben Hoch. Jeder Mandant kann über eine eigene Konfiguration verfügen
Leistungsisolation Niedrig Niedrig bis mittel. Unterliegt möglicherweise Problemen mit störenden Nachbarn High
Bereitstellungskomplexität Niedrig Medium High
Komplexität des Betriebs Niedrig High High
Ressourcenkosten Niedrig Niedrig hoch, je nach Anwendung High
Beispielszenario Große Lösung mit mehreren Mandanten mit freigegebener Anwendungsebene Migrieren Sie Anwendungen, die sich Mandanten nicht bewusst sind in Azure und erzielen Sie gleichzeitig eine Kosteneffizienz Einzelmandant-Logikschicht

Freigegebene Apps

Sie können eine freigegebene Anwendung für einen einzelnen Plan bereitstellen und die freigegebene Anwendung für alle Ihre Mandanten verwenden.

Dies ist in der Regel die kosteneffizienteste Option und erfordert den geringsten betrieblichen Mehraufwand, da weniger Ressourcen verwaltet werden müssen. Sie können den Gesamtplan basierend auf der Last oder der Nachfrage skalieren, und alle Mandanten, die den Plan gemeinsam nutzen, profitieren von der erhöhten Kapazität.

Es ist wichtig, die App Service-Kontingente und -Grenzwerte zu kennen, z. B. die maximale Anzahl benutzerdefinierter Domänen, die einer einzelnen App hinzugefügt werden können, und die maximale Anzahl der Instanzen eines Plans, die bereitgestellt werden können.

Um dieses Modell verwenden zu können, muss Ihr Anwendungscode auf Mehrinstanzenfähigkeit ausgelegt sein.

Apps pro Mandant mit freigegebenen Plänen

Sie können Ihren Plan auch für mehrere Mandanten freigeben, aber separate Apps für jeden Mandanten bereitstellen. Dadurch bewirken Sie eine logische Isolation zwischen den einzelnen Mandanten. Diese Ansatz hat folgende Vorteile:

  • Kosteneffizienz: Durch das Freigeben Ihrer Hostinginfrastruktur können Sie Ihre Gesamtkosten pro Mandant grundsätzlich senken.
  • Trennung der Konfiguration: Für die App jedes Mandanten können eigene Domänennamen, TLS-Zertifikate, Zugriffseinschränkungen und Tokenautorisierungsrichtlinien angewendet werden.
  • Trennung von Upgrades: Für die Anwendungsbinärdateien jedes Mandanten können unabhängig von anderen Apps im gleichen Plan Upgrades durchgeführt werden.

Da jedoch die Computeressourcen des Plans gemeinsam genutzt werden, kann bei den Apps das „Noisy Neighbor“-Problem auftreten. Darüber hinaus gibt es Grenzwerte für die Bereitstellung von Apps in einem einzelnen Plan.

Hinweis

Verwenden Sie keine Bereitstellungsslots für verschiedene Mandanten. Slots bieten keine Ressourcenisolation. Sie sind für Bereitstellungsszenarios konzipiert, in denen mehrere Versionen Ihrer App für eine kurze Zeit ausgeführt werden müssen, wie z. B. Blau-Grün-Bereitstellungen oder eine Canary-Rolloutstrategie.

Pläne pro Mandant

Die höchste Isolationsstufe besteht in der Bereitstellung eines dedizierten Plans für einen Mandanten. Dieser dedizierte Plan stellt sicher, dass der Mandant alle Serverressourcen, die diesem Plan zugeordnet sind, vollständig nutzen kann.

Mit diesem Ansatz können Sie Ihr Lösung skalieren, um eine Leistungsisolation für jeden Mandanten zu ermöglichen und das „Nosy Neighbor“-Problem (Neugieriger Nachbar-Problem) zu vermeiden. Er kostet jedoch auch mehr, da die Ressourcen nicht für mehrere Mandanten freigegeben werden. Zudem müssen Sie die maximale Anzahl der Pläne berücksichtigen, die in einer einzelnen Azure-Ressourcengruppe bereitgestellt werden können.

Hosten von APIs

Sie können sowohl auf Azure App Service als auch auf Azure Functions hosten. Die Auswahl der Plattform hängt von den spezifischen Features und Skalierungsoptionen ab, die Sie benötigen.

Unabhängig davon, welche Plattform Sie zum Hosten Ihrer API verwenden, sollten Sie den Einsatz von Azure API Management vor Ihrer API-Anwendung in Betracht ziehen. API Management bietet viele Features, die für mehrinstanzenfähige Lösungen nützlich sein können, darunter die folgenden:

Netzwerk und Mehrinstanzenfähigkeit

IP-Adressen

Viele mehrinstanzenfähige Anwendungen müssen eine Verbindung mit den lokalen Netzwerken der Mandanten herstellen, um Daten zu senden.

Wenn Sie ausgehenden Datenverkehr von einer bekannten statischen IP-Adresse oder mehreren bekannten statischen IP-Adressen senden müssen, sollten Sie eine NAT Gateway-Instanz verwenden. App Service enthält Anleitungen zur Integration mit einer NAT Gateway-Instanz.

Wenn Sie keine statische ausgehende IP-Adresse benötigen, sondern stattdessen gelegentlich die IP-Adresse überprüfen müssen, die Ihre Anwendung für den ausgehenden Datenverkehr verwendet, können Sie die aktuellen IP-Adressen der App Service-Bereitstellung abfragen.

Kontingente

Da App Service selbst ein mehrinstanzenfähiger Dienst ist, müssen Sie darauf achten, wie Sie freigegebene Ressourcen verwenden. Sie müssen insbesondere auf das Netzwerk achten, da es Grenzwerte gibt, die sich darauf auswirken, wie Ihre Anwendung sowohl mit eingehenden als auch ausgehenden Netzwerkverbindungen arbeiten kann, einschließlich der Grenzwerte für die Übersetzung von Quellnetzwerkadressen (SNAT) und TCP-Ports.

Wenn Ihre Anwendung eine Verbindung zu einer großen Anzahl von Datenbanken oder externen Diensten herstellt, besteht für Ihre App das Risiko einer Auslastung des SNAT-Ports. Allgemein gibt die SNAT-Portauslastung an, dass Ihr Code TCP-Verbindungen nicht ordnungsgemäß wiederverwendet wird. Selbst in einer mehrinstanzenfähigen Lösung sollten Sie sicherstellen, dass Sie die empfohlenen Methoden zur erneuten Verwendung von Verbindungen befolgen.

In einigen mehrinstanzenfähigen Lösungen kann die Anzahl der ausgehenden Verbindungen mit unterschiedlichen Adressen jedoch zu einer Auslastung des SNAT-Ports führen, auch wenn Sie bewährte Codingmethoden befolgen. In diesen Szenarios sollten Sie den Einsatz einer NAT Gateway-Instanz in Betracht ziehen, um die Anzahl der SNAT-Ports zu erhöhen, die Ihrer Anwendung zur Verfügung stehen, oder Sie sollten Dienstendpunkte verwenden, wenn Sie sich mit Azure-Diensten verbinden, um die Grenzwerte des Lastausgleichs zu umgehen. Trotz dieser Kontrollen können Sie bei einer großen Anzahl von Mandanten Grenzwerte erreichen, so dass Sie die Skalierung auf zusätzliche App Service-Pläne oder Bereitstellungsstempel einplanen sollten.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

  • John Downs | Principal Customer Engineer, FastTrack for Azure

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Weitere Informationen finden Sie unter Ressourcen für Architekten und Entwickler mehrinstanzenfähiger Lösungen.