Entwerfen einer geografisch verteilten Architektur
Bei Azure handelt es sich um ein globales System. Durch das Entwerfen einer Architektur, die in mehr als einer Azure-Region präsent ist, können wir eine Anwendung erstellen, die sogar im Falle von regionsweiten Notfällen resilient ist.
Ihr Sendungsverfolgungsportal ist skalierbar, da es mithilfe einer Reihe von skalierbaren Azure-Ressourcen erstellt wurde. Auch bei vielen Ausfällen ist das Portal resilient, da seine Komponenten über mehrere Instanzen verfügen können. Jedoch befürchtet Ihr Vorstand, dass ein Notfall in großem Umfang zu einer Unterbrechung führen könnte, da das Portal vollständig in der Azure-Region „USA, Osten“ enthalten ist. Sie möchten eine geänderte Architektur vorschlagen, die ein Failover auf eine zweite Region ausführen kann, falls die Region „USA, Osten“ ausfällt.
Hier erfahren Sie, wie Sie die Architektur unserer Anwendung so anpassen, dass sie eine geografisch verteilte Anwendung unterstützt. Sie erfahren zudem, wieso eine solche Architektur für unternehmenskritische Anwendungen von Vorteil ist.
Ursprüngliche Web-App-Architektur
Sehen wir uns nun an, wie der Architekturentwurf des Sendungsverfolgungsportals und die Komponenten in der Lösung verwendet werden. Nachdem wir verstanden haben, wie wir alle Komponenten verwenden, können wir untersuchen, wie diese Komponenten in georedundanten Szenarios unterstützt werden.
Der Entwurf des Sendungsverfolgungsportals basiert auf der im folgenden Diagramm dargestellten Referenzarchitektur.
Beachten Sie, dass die Anwendung eine einzelne Azure-Ressourcengruppe verwendet. Diese Ressourcengruppe ermöglicht uns, alle unsere Ressourcen logisch zu gruppieren und zu verwalten, und vereinfacht die Verwaltung. Wir haben uns entschieden, diese Ressourcengruppe in der Region „USA, Osten“ bereitzustellen. Obwohl wir aufgrund der Ressourcengruppe nicht unbedingt dieselbe Azure-Region für die enthaltenen Ressourcen verwenden müssen, haben wir uns dazu entschieden, die Region „USA, Osten“ für alle in unserer Anwendung bereitgestellten Ressourcen zu verwenden.
Unsere Anwendung verwendet drei Kategorien von Azure-Ressourcen. Sehen wir uns nun jede Kategorie und die verwendeten Ressourcen an.
Netzwerkkomponenten
Das Sendungsverfolgungsportal verwendet die folgenden Netzwerkdienste.
| Dienst | Beschreibung |
|---|---|
| Azure DNS | Wir haben Azure DNS zum Hosten unserer DNS-Einträge in Azure konfiguriert. Mit Azure DNS können wir unsere DNS-Einträge mithilfe unserer Azure-Anmeldeinformationen im Azure-Portal verwalten. |
| Application Gateway | Wir haben den Application Gateway-Lastenausgleich so konfiguriert, dass der Datenverkehr zwischen mehreren Instanzen des Web-Front-Ends ausgeglichen wird. Dieser Dienst ist in einer Azure-Region lokalisiert. |
| Azure CDN | Wir haben Azure CDN so konfiguriert, dass die Übermittlung von nicht gesichertem statischem Inhalt, z. B. Grafiken für den Inhalt der Website, maximiert wird. Dieser globale Dienst speichert statischen Inhalt an allen Points of Presence auf der ganzen Welt zwischen. |
Anwendungskomponenten
Das Sendungsverfolgungsportal verwendet die folgenden Dienste zum Unterstützen von Code, Cache und mittleren Speicheranforderungen.
| Dienst | Beschreibung |
|---|---|
| Microsoft Entra ID | Benutzer*innen greifen über Microsoft Entra-Konten auf das Portal zur Nachverfolgung zu. Das Verzeichnis und das Konto werden automatisch global repliziert. |
| Azure App Service | Das Sendungsverfolgungsportal verwendet zwei Azure-App-Dienste. Der erste führt einige dynamische Webseiten aus, der zweite eine Web-API. |
| Azure-Funktions-Apps | Das Sendungsverfolgungsportal verwendet Azure-Funktions-Apps zum Ausführen aller Hintergrundaufgaben. Einige dieser Aufgaben werden regelmäßig ausgeführt, andere nach den Meldungen in einer Warteschlange. |
| Azure Storage-Warteschlangen | Das Sendungsverfolgungsportal verwendet Azure Storage-Warteschlangen mit Azure-Funktions-Apps. Das Sendungsverfolgungsportal platziert generierte Meldungen in der Warteschlange, von wo aus diese von den Funktions-Apps verarbeitet werden. |
| Redis Cache | Das Sendungsverfolgungsportal verwendet Redis Cache zwischen dem Front-End-App-Dienst und den Datenspeichersystemen, um die Leistung von Abfragen zu maximieren. |
| Azure Blob Storage | Statische Inhalte, z. B. Grafiken und Videodateien, werden in einem Azure Storage-Konto als Blobs (Binary Large Objects) gespeichert und über die Azure CDN übermittelt. |
| Azure Search | Wir haben Azure Search im Sendungsverfolgungsportal aktiviert. Mit Azure Search können wir alle Inhalte durchsuchbar machen und unseren Benutzern Suchvorschläge und Fuzzysuchergebnisse bereitstellen. |
Datenspeicherkomponenten
Das Sendungsverfolgungsportal verwendet die folgenden persistenten Speicherdienste.
| Dienst | Beschreibung |
|---|---|
| Azure SQL-Datenbank | Wir speichern relationale Daten, z. B. Bestell- und Kundendetails, in Azure SQL-Datenbank. |
| Cosmos DB | Wir speichern halbstrukturierte Daten, einschließlich unseres Produktkatalogs, in Cosmos DB. |
Probleme mit der ursprünglichen Architektur
Die vorhandene Architektur für das Sendungsverfolgungsportal ist auf Skalierbarkeit und Verfügbarkeit ausgelegt.
Wenn die Nachfrage beispielsweise hoch ist und Antworten auf Benutzerwebanforderungen langsam sind, können Sie in Betracht ziehen, mehr Instanzen der Front-End-Web-App im App-Dienst hinzuzufügen. Dort kann Application Gateway Anforderungen an diese neu erstellten Instanzen weiterleiten.
Es gibt jedoch Szenarios, in denen unser Architekturentwurf Herausforderungen überwinden muss oder sogar nicht zum Ziel führt. Sehen wir uns nun jedes Szenario an, um die Auswirkung auf das Sendungsverfolgungsportal besser zu verstehen.
Regionale Ausfälle
Einige bedeutende Ereignisse haben das Potenzial, eine gesamte Azure-Region zu unterbrechen. Azure-Rechenzentren sind mit hoher Resilienz konzipiert. Ein massives Wetterereignis, z. B. ein Hurrikan oder eine Überschwemmung, kann den Dienst aus der Region jedoch unterbrechen.
Bei diesen Ereignissen handelt es sich um ungewöhnliche Vorkommen, und viele Unternehmen sind der Meinung, dieses Risiko in Kauf nehmen zu können. Die Folge eines regionalen Ausfalls, der zum Ausfall des Sendungsverfolgungsportals führt, ist jedoch so riskant, dass die Unternehmensführung beschlossen hat, dieses Risiko zu beseitigen.
Vereinbarungen zum Servicelevel
Die meisten Azure-Dienste bieten eine Vereinbarung zum Servicelevel (SLA) oder eine garantierte Betriebszeit. Beim Entwerfen einer Anwendungsarchitektur, die aus mehreren Azure-Diensten besteht, berechnen wir die gesamte SLA für die App als Verbund der SLAs aller anderen Dienste.
Sie berechnen diese SLA, indem Sie die SLAs der Komponentendienste multiplizieren. Nehmen wir beispielsweise an, dass unsere App aus Azure App Service (SLA: 99,95 %) und Microsoft Entra ID (SLA: 99,9 %) besteht. Die final errechnete SLA ist 99,85 %.
Wenn diese prozentuale Betriebszeit für unsere Anwendung nicht ausreicht, können wir veranlassen, dass für die Anwendung ein Failover auf eine andere Region durchgeführt werden soll.
Globale, regionale und konfigurierbare Komponenten
In unserem Entwurf sind einige Komponenten standardmäßig global und nicht anfällig für einen regionalen Ausfall.
Einige Komponenten sind auf eine einzelne Region beschränkt, z. B. Application Gateway. Wir müssen einen alternativen Dienst für diese Komponententypen auswählen.
Einige Komponenten können für die Unterstützung mehrerer Regionen konfiguriert werden. Beispielsweise können Sie die Option „Georedundanter Speicher (GRS)“ im Azure Storage-Konto verwenden, das statischen Inhalt speichert. GRS repliziert Blobs in eine andere Region.
Die folgende Tabelle zeigt, welche Komponenten global, regional und konfigurierbar sind.
| Komponente | Unterstützung für mehrere Regionen | Kommentare |
|---|---|---|
| Azure DNS | Global | Es sind keine Änderungen erforderlich. |
| Application Gateway | Länderspezifisch | Jede Instanz von Application Gateway befindet sich in einer einzelnen Region. |
| Azure CDN | Global | Es sind keine Änderungen erforderlich, der Inhalt wird standardmäßig global zwischengespeichert. |
| Microsoft Entra ID | Global | Es sind keine Änderungen erforderlich. |
| Azure App Service | Länderspezifisch | Jede Instanz der App befindet sich in einer einzelnen Region. |
| Azure Function-Apps | Länderspezifisch | Jede Instanz der Funktions-App befindet sich in einer einzelnen Region. |
| Azure Storage-Warteschlangen | Konfigurierbar | Sie können auswählen, dass ein Azure Storage-Konto in mehrere Regionen repliziert wird. |
| Azure Redis Cache | Länderspezifisch | Jede Instanz des Caches befindet sich in einer einzelnen Region. |
| Azure Blob Storage | Konfigurierbar | Sie können auswählen, dass ein Azure Storage-Konto in mehrere Regionen repliziert wird. |
| Azure Search | Länderspezifisch | Jede Instanz des Suchdiensts befindet sich in einer einzelnen Region. |
| Azure SQL-Datenbank | Konfigurierbar | Sie können die Georeplikation zum Synchronisieren von Daten in mehreren Regionen verwenden. |
| Azure Cosmos DB | Konfigurierbar | Sie können die Georeplikation zum Synchronisieren von Daten in mehreren Regionen verwenden. |
Vorgeschlagene verteilte Architektur
Nach einigen Untersuchungen schlagen Sie die Architektur im folgenden Diagramm vor.
In diesem Entwurf gibt es eine aktive Region (USA, Osten) und eine Standbyregion (USA, Westen). In der Region „USA, Osten“ werden alle Anforderungen von den Komponenten unter normalen Umständen verarbeitet. Wenn ein Notfall zu einem regionalen Ausfall führt, führt die Anwendung ein Failover auf die Region „USA, Westen“ durch.
Sehen wir uns aus allgemeiner Sicht an, wie Sie die ursprüngliche Architektur geändert haben. Diese Änderungen werden in späteren Lerneinheiten ausführlicher erläutert.
Netzwerkfunktionen
Azure DNS und Azure CDN sind standardmäßig globale Systeme und bereits gegenüber regionalen Ausfällen resilient. Wir belassen sie so.
Beim Erstellen einer Azure Application Gateway-Instanz wird der Dienst einer einzelnen Region zugewiesen. Wir beseitigen dieses Sicherheitsrisiko, indem wir diesen Dienst durch Azure Front Door ersetzen. Front Door kann mehrere App-Dienste abfragen und das Failover des App-Diensts von der Region „USA, Osten“ auf die Region „USA, Westen“ durchführen.
Anwendungsdienste
Microsoft Entra ID ist ein globales System und erfordert keine Änderung.
Azure Storage-Konten können so konfiguriert werden, dass sie Inhalte in mehrere Regionen replizieren. Wir verwenden eine der georedundanten Speicheroptionen, um unsere Konfiguration zu ändern.
Die anderen Komponenten, einschließlich App Service, Funktions-Apps, Redis Cache und Azure Search, sind regional. Wir erstellen in unserem neuen Architekturentwurf doppelte Instanzen dieser Komponenten in der Region „USA, Westen“. Bei diesem Entwurf kann die neue Region übernehmen, wenn ein Failover auftritt.
Datenspeicher
Azure SQL-Datenbank und Azure Cosmos DB unterstützen beide die Georeplikation von Daten in andere Regionen. Wir konfigurieren diese Dienste für die Replikation von Daten aus der Region „USA, Osten“ in die entsprechenden Dienste in der Region „USA, Westen“.
Regionspaare
Eine Azure-Region ist ein einzelner geografischer Bereich, der mindestens ein Azure-Rechenzentrum enthält. Alle Regionspaare bilden mit anderen Regionen im gleichen geografischen Bereich Paare. Innerhalb dieser Paare werden Updates und geplante Wartungen jeweils nur für eine Region durchgeführt. Wenn ein Ausfall auftritt, der sich auf mehrere Regionen auswirkt, wird mindestens eine Region in jedem Paar für die schnelle Wiederherstellung priorisiert.
Die bewährte Vorgehensweise besteht darin, eine Architektur mit zwei Regionen für Ihre App in den beiden Regionen in einem Regionspaar zu platzieren. Beispielsweise bildet „USA, Osten“ ein Paar mit „USA, Westen“. Unser vorgeschlagener Entwurf verwendet „USA, Osten“ als aktive Region und „USA, Westen“ als Standbyregion.