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.
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.
Warnung
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.
Weitere Informationen zur Verwendung von Azure Front Door in einer mehrinstanzenfähigen Lösung finden Sie unter Verwenden von Azure Front Door in einer mehrinstanzenfähigen Lösung.
Authentifizierung und Autorisierung
Azure App Service kann Authentifizierungstoken für Ihre App überprüfen. Wenn App Service eine Anforderung empfängt, wird überprüft, ob jede der folgenden Bedingungen erfüllt ist:
- Die Anforderung enthält ein Token.
- Das Token ist gültig.
- Die Anforderung ist autorisiert.
Wenn eine der Bedingungen nicht erfüllt ist, kann App Service die Anforderung blockieren oder den Benutzer/die Benutzerin an Ihren Identitätsanbieter umleiten, damit er sich anmelden kann.
Wenn Ihre Mandanten Microsoft Entra ID als Identitätssystem verwenden, können Sie Azure App Service so konfigurieren, dass der /common endpoint zum Überprüfen von Benutzertoken verwendet wird. So wird sichergestellt, dass Token unabhängig vom Microsoft Entra-Mandanten der Benutzer überprüft und akzeptiert werden.
Sie können Azure App Service mit Azure AD B2C integrieren, um Heimanwender*innen zu authentifizieren.
Weitere Informationen:
- App Service-Autorisierung
- Konfigurieren der Authentifizierung in einem Beispiel einer ASP.NET-Webanwendung mithilfe von Azure AD B2C
- Arbeiten mit mehrinstanzenfähigen Microsoft Entra-Identitäten
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:
- Ein zentraler Punkt für sämtliche Authentifizierungen. Dazu kann die Ermittlung des Mandantenbezeichners aus einem Tokenanspruch oder anderen Anforderungsmetadaten gehören.
- Weiterleiten von Anforderungen an verschiedene API-Back-Ends, die möglicherweise auf dem Mandantenbezeichner der Anforderung basieren. Dies kann hilfreich sein, wenn Sie mehrere Bereitstellungsstempel mit ihren eigenen unabhängigen API-Anwendungen hosten, aber eine einzelne API-URL für alle Anforderungen benötigen.
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. Weitere Informationen zur Verwendung von NAT Gateway in mehrinstanzenfähigen Lösungen finden Sie unter Überlegungen zu Azure NAT Gateway für die Mehrinstanzenfähigkeit. 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 Szenarien sollten Sie eine der folgenden Optionen verwenden:
- Stellen Sie NAT Gateway bereit, um die Anzahl der für Ihre Anwendung verfügbaren SNAT-Ports zu erhöhen. Weitere Informationen zur Verwendung von NAT Gateway in mehrinstanzenfähigen Lösungen finden Sie unter Überlegungen zu Azure NAT Gateway für die Mehrinstanzenfähigkeit.
- Verwenden Sie Dienstendpunkte, wenn Sie eine Verbindung mit Azure-Diensten herstellen, um Lastenausgleichsgrenzwerte 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:
- Thiago Almeida | Principal Program Manager, Azure Functions
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
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.