In diesem Artikel wird beschrieben, wie Sie unternehmenskritische Webanwendungen mithilfe von Azure App Service bereitstellen können. Die Architektur verwendet das zuverlässige Web-App-Muster als Startpunkt. Verwenden Sie diese Architektur, wenn Sie über eine Legacy-Workload verfügen und Platform-as-a-Service (PaaS)-Dienste einführen möchten.
Das zuverlässige Web-App-Muster für .NET bietet einen Leitfaden zum Aktualisieren oder Neuformatieren von Web-Apps, die Sie in die Cloud verschieben, wobei erforderliche Codeänderungen minimiert werden und eine Servicelevelziel (Service Level Objective, SLO) von 99,9 % angestrebt wird. Unternehmenskritische Workloads weisen hohe Zuverlässigkeits- und Verfügbarkeitsanforderungen auf. Um einen SLO von 99,95 %, 99,99 % oder höher zu erreichen, müssen Sie zusätzliche unternehmenskritische Entwurfsmuster und operative Strenge anwenden. In diesem Artikel werden wichtige technische Bereiche und die Implementierung und Einführung unternehmenskritischer Entwurfspraktiken beschrieben.
Hinweis
Die Anleitung in diesem Artikel basiert auf der Entwurfsmethodik und den bewährten Methoden der Reihe unternehmenskritische Workload „Well-Architected Framework“.
In den folgenden Abschnitten erfahren Sie, wie Sie:
- die vorhandene Workload überprüfen, um die Komponenten, Benutzer- und Systemflows sowie die Verfügbarkeits- und Skalierbarkeitsanforderungen zu verstehen.
- eine Architektur mit Skalierungseinheiten entwickeln und implementieren, um die End-to-End-Skalierbarkeit durch Kompartimentierung zu optimieren und den Prozess des Hinzufügens und Entfernens von Kapazität zu standardisieren.
- zustandslose, kurzlebige Skalierungseinheiten oder Bereitstellungsstempel implementieren, um Skalierbarkeit und Bereitstellungen ohne Ausfallzeiten zu ermöglichen.
- ermitteln, ob Sie die Workload in Komponenten aufteilen können, um sich auf die Skalierbarkeit vorzubereiten. Einzelne Komponenten sind für Skalierbarkeits- und Entkopplungsflows erforderlich.
- Bereiten Sie sich auf die globale Verteilung vor, indem Sie eine Workload in mehr als einer Azure-Region bereitstellen, um die Nähe zum Kunden zu verbessern und sich auf potenzielle regionale Ausfälle vorzubereiten.
- Entkoppeln Sie Komponenten, und implementieren Sie eine ereignisgesteuerte Architektur.
Aufbau
Das folgende Diagramm wendet die vorherigen Überlegungen auf das zuverlässige Web-App-Muster an.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Das rote Feld stellt eine Skalierungseinheit mit Diensten dar, die zusammen skaliert werden. Um sie effektiv zusammen zu skalieren, optimieren Sie die Größe, die SKU und die verfügbaren IP-Adressen jedes Diensts. Beispielsweise korreliert die maximale Anzahl von Anforderungen, die App Configuration bedient, mit der Anzahl der Anforderungen pro Sekunde, die eine Skalierungseinheit bereitstellt. Wenn Sie in einer Region mehr Kapazität hinzufügen, müssen Sie auch weitere einzelne Skalierungseinheiten hinzufügen.
Diese einzelnen Skalierungseinheiten haben keine Abhängigkeiten und kommunizieren nur mit gemeinsam genutzten Diensten außerhalb der einzelnen Skalierungseinheit. Sie können unabhängige Skalierungseinheiten im Voraus testen. Um Auswirkungen auf andere Bereitstellungsbereiche zu vermeiden, führen Sie ein Rollout unabhängiger Skalierungseinheiten durch, und führen Sie die Option zum Ersetzen von Diensten in einer neuen Version ein.
Für unternehmenskritische Workloads sind unabhängige Skalierungseinheiten temporär, wodurch die Rolloutprozesse optimiert werden und Skalierbarkeit innerhalb und zwischen Regionen geboten wird. Speichern Sie den Zustand nicht in unabhängigen Skalierungseinheiten. Erwägen Sie die Verwendung von Azure Cache for Redis für die Speicherung in der Skalierungseinheit, und speichern Sie nur den kritischen Zustand oder Daten, die ebenfalls in der Datenbank gespeichert sind. Wenn es zu einem Ausfall der Skalierungseinheiten kommt oder Sie zu einer anderen Skalierungseinheit wechseln, tritt möglicherweise eine Verlangsamung auf oder eine neue Anmeldung ist erforderlich. Azure Cache for Redis wird jedoch weiterhin ausgeführt.
Application Insights wird von der Skalierungseinheit ausgeschlossen. Schließen Sie Dienste aus, die Daten speichern oder überwachen. Trennen Sie sie in ihre eigene Ressourcengruppe mit ihrem eigenen Lebenszyklus.
Wenn Sie eine Skalierungseinheit ersetzen oder eine neue bereitstellen, behalten Sie Verlaufsdaten bei, und verwenden Sie eine Instanz pro Region.
Weitere Informationen finden Sie unter Anwendungsentwurf unternehmenskritischer Workloads in Azure.
Komponenten
Diese Architektur verwendet die folgenden Komponenten.
- App Service ist die Anwendungshostingplattform.
- Azure Cache for Redis-Cacheanforderungen.
- App Configuration speichert Konfigurationseinstellungen.
- Azure SQL ist die Back-End-Datenbank.
- Application Insights ruft Telemetriedaten von der Anwendung ab.
Alternativen
Im Muster für zuverlässige Web-Apps können Sie:
- Azure Kubernetes Service (AKS) anstelle von App Service verwenden. Diese Option ist für komplexe Workloads, die über eine große Anzahl von Microservices verfügen, geeignet. AKS bietet mehr Kontrolle über die zugrunde liegende Infrastruktur und ermöglicht komplexe Mehrschicht-Setups.
- Containerisieren sie die Workload. App Service unterstützt die Containerisierung, aber in diesem Beispiel ist die Workload nicht containerisiert. Verwenden Sie Container, um die Zuverlässigkeit und Portabilität zu erhöhen.
Weitere Informationen finden Sie unter Überlegungen zur Anwendungsplattform für unternehmenskritische Workloads in Azure.
Auswählen der Anwendungsplattform
Die Verfügbarkeit hängt von der Wahl und Konfiguration der Anwendungsplattform ab. Beachten Sie den folgenden unternehmenskritischen Leitfaden:
- Verwenden Sie nach Möglichkeit Verfügbarkeitszonen.
- Wählen Sie den richtigen Plattformdienst für Ihre Workload aus.
- Containerisieren sie die Workload.
Verfügbarkeitsgruppen verteilen Bereitstellungen auf mehrere Fehler- und Updatedomänen innerhalb eines Rechenzentrums. Verfügbarkeitszonen verteilen Bereitstellungen auf einzelne Rechenzentren innerhalb einer Azure-Region. Verfügbarkeitszonen werden häufig priorisiert, es hängt jedoch von Ihrer Workload ab, welche Strategie Sie verwenden. Beispielsweise können latenzempfindliche oder „geschwätzige“ Workloads von der Priorisierung von Verfügbarkeitsgruppen profitieren. Wenn Sie die Workload auf Verfügbarkeitszonen verteilen, kann dies die Latenz und die Kosten für zonenübergreifenden Datenverkehr erhöhen. Wenn Sie Verfügbarkeitszonen verwenden, stellen Sie sicher, dass diese von allen Diensten in einer Skalierungseinheit unterstützt werden. Alle Dienste im zuverlässigen Web-App-Muster unterstützen Verfügbarkeitszonen.
Auswählen der Datenplattform
Die von Ihnen ausgewählte Datenbankplattform wirkt sich auf die gesamte Workloadarchitektur aus, insbesondere auf die Unterstützung der Aktiv/Aktiv- oder Aktiv/Passiv-Konfiguration der Plattform. Das zuverlässige Web-App-Muster verwendet Azure SQL, das Aktiv/Aktiv-Bereitstellungen mit Schreibvorgängen in mehreren Instanzen nicht nativ unterstützt. Daher ist die Datenbankebene auf eine Aktiv/Passiv-Strategie beschränkt. Eine Aktiv/Aktiv-Strategie auf Anwendungsebene ist möglich, wenn schreibgeschützte Replikate vorhanden sind und Sie nur in eine einzelne Region schreiben.
Laden Sie eine Visio-Datei dieser Architektur herunter.
In komplexen Architekturen sind mehrere Datenbanken üblich. Beispielsweise verfügen Microservicesarchitekturen über eine Datenbank für jeden Dienst. Mehrere Datenbanken ermöglichen die Einführung einer mehrinstanzenfähigen Schreibdatenbank wie Azure Cosmos DB, wodurch die Hochverfügbarkeit und die geringe Latenz verbessert werden. Regionsübergreifende Latenz kann zu Einschränkungen führen. Es ist wichtig, nicht funktionale Anforderungen und Faktoren wie Konsistenz, Bedienbarkeit, Kosten und Komplexität zu berücksichtigen. Ermöglichen Sie einzelnen Diensten die Verwendung separater Datenspeicher und spezialisierter Datentechnologien, um ihre individuellen Anforderungen zu erfüllen. Weitere Informationen finden Sie unter Überlegungen zur Datenplattform für unternehmenskritische Workloads in Azure.
Definieren eines Integritätsmodells
Bei komplexen Workloads mit mehreren Ebenen, die über mehrere Rechenzentren und geografische Regionen verteilt sind, müssen Sie ein Integritätsmodell definieren. Definieren Sie Benutzer- und Systemflows, geben Sie die Abhängigkeiten zwischen den Diensten an, und verstehen Sie, erkennen Sie die Auswirkungen, die Ausfälle oder eine Leistungsverschlechterung bei einem der Dienste auf die Gesamtworkload haben können, und überwachen und visualisieren Sie die Kundenerfahrung, um eine angemessene Überwachung zu ermöglichen und manuelle und automatisierte Maßnahmen zu verbessern.
Das vorherige Diagramm zeigt, wie ein Ausfall oder eine Beeinträchtigung einer einzelnen Komponente, z. B. App Configuration, zu einer potenziellen Leistungsbeeinträchtigung für den Kunden führen kann.
Wenn Sie Komponenten in Skaleneinheiten unterteilen, können Sie den Datenverkehr zu dem betroffenen Teil der Anwendung, z. B. einer betroffenen Skalierungseinheit oder der gesamten Region, anhalten.
Weitere Informationen finden Sie unter Integritätsmodellierung und Einblick für unternehmenskritische Workloads in Azure.
Sicherheit und Netzwerk
Für Workloads, die von einer lokalen Unternehmensbereitstellung migriert werden, gelten strenge Netzwerk- und Sicherheitsanforderungen. Nicht alle etablierten lokalen Prozesse werden in eine Cloudumgebung verschoben. Bewerten Sie diese Anforderungen, wenn sie in Cloudumgebungen anwendbar sind.
Identität ist häufig der primäre Sicherheitsperimeter für cloudnative Muster. Unternehmenskunden benötigen möglicherweise umfangreichere Sicherheitsmaßnahmen. Um ihre Netzwerksicherheitsanforderungen zu erfüllen, können die meisten Azure PaaS-Dienste Azure Private Link verwenden, um das Netzwerk als Sicherheitsperimeter zu implementieren. Private Link kann sicherstellen, dass nur innerhalb eines virtuellen Netzwerks auf Dienste zugegriffen werden kann. Auf alle Dienste kann nur über private Endpunkte zugegriffen werden. Das folgende Diagramm zeigt, dass Azure Front Door der einzige öffentliche Endpunkt mit Internetzugriff ist.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Damit das zuverlässige Web-App-Muster ein Netzwerk als Sicherheitsperimeter einrichten kann, muss es Folgendes verwenden:
- Private Link für alle Dienste, die es unterstützen.
- Azure Front Door Premium als einziger öffentlicher Endpunkt mit Internetzugriff.
- Jumpboxen für den Zugriff auf Dienste über Azure Bastion.
- Selbstgehostete Build-Agents, die auf die Dienste zugreifen können.
Eine weitere häufige Netzwerkanforderung für unternehmenskritische Anwendungen ist die Einschränkung des ausgehenden Datenverkehrs, um Datenexfiltration zu verhindern. Schränken Sie ausgehenden Datenverkehr ein, indem Sie eine Azure-Firewall über ein geeignetes Firewallgerät weiterleiten und mit dem Gerät filtern. Die unternehmenskritische Azure-Baselinearchitektur mit Netzwerksteuerungen verwendet eine Firewall und Private Link.
Bereitstellung und Tests
Ausfallzeiten, die durch fehlerhafte Releases oder menschliche Fehler verursacht werden, können ein Problem für eine Workload, die immer verfügbar sein muss, sein. Die folgenden wichtigen Bereiche sollten Sie beachten:
- Bereitstellungen ohne Ausfallzeiten
- Kurzlebige Blau-Grün-Bereitstellungen
- Analyse des Lebenszyklus einzelner Komponenten und Gruppieren dieser Komponenten
- Fortlaufende Validierung
Bereitstellungen ohne Ausfallzeiten sind für unternehmenskritische Workloads entscheidend. Für eine Workload, die immer ausgeführt werden muss, darf kein Wartungsfenster vorhanden sein, um neuere Versionen auszurollen. Um diese Einschränkung zu umgehen, folgt die unternehmenskritische Azure-Architektur dem Muster für Bereitstellungen ohne Ausfallzeiten. Änderungen werden als neue Skalierungseinheiten oder Stempel eingeführt, die End-to-End-getestet werden, bevor der Datenverkehr inkrementell an sie weitergeleitet wird. Nachdem der gesamte Datenverkehr an den neuen Stempel weitergeleitet wurde, werden alte Stempel deaktiviert und entfernt.
Weitere Informationen finden Sie unter Bereitstellung und Tests für unternehmenskritische Workloads in Azure.
Nächste Schritte
- Lernpfad: Erstellen von unternehmenskritischen Workloads in Azure
- Challenge-Project: Entwerfen einer unternehmenskritischen Web-Anwendung
- Lernmodul: Entwerfen eines Integritätsmodells für Ihre unternehmenskritische Workload