Entwerfen einer geografisch verteilten Anwendungsarchitektur
Wenn die Netzwerkkomponenten Anforderungen an mehrere Regionen weiterleiten, um die Auswirkungen eines regionalen Ausfalls einzuschränken, werden Anwendungsdienste benötigt, die auf diese Anforderungen in primären Regionen und Standbyregionen reagieren können.
Wie bereits erwähnt, möchten wir Azure Front End mit Prioritätszuweisungen für das Back-End konfigurieren. Weisen Sie die Region „USA, Osten“ als primäre Region und die Region „USA, Westen“ als Standbyregion zu. Wenn es zu einem regionalen Ausfall kommen sollte, werden Anforderungen an die App Service-Instanz in der jeweils anderen Region weitergeleitet. Sie müssen die Ressourcen in jeder Region so konfigurieren, dass diese Failover für den Benutzerzugriff, den replizierten Speicher und den Anwendungscode unterstützt werden.
Hier untersuchen wir die Anwendungsdienste in unserer Lösung und bestimmen, ob sie geändert werden müssen, um in einer Architektur mit mehreren Regionen zu funktionieren. Insbesondere sehen wir uns Active Directory, statische Inhaltsspeicher, Web-Apps, Web-APIs, Warteschlangen, Azure-Funktionen und Datencaches an.
Microsoft Entra ID
In Ihrem Sendungsportal können Benutzer die Lieferung ihrer Einkäufe nachverfolgen, indem sie eine Sendungsverfolgungsnummer eingeben. Reguläre Benutzer können sich jedoch auch als Mitglieder registrieren, um Zugriff auf erweiterte Features wie Expresslieferungen und Statistiken zu erhalten. Wir haben das Überwachungsportal so konfiguriert, dass Benutzerkonten in Microsoft Entra ID gespeichert werden.
Microsoft Entra ID ist standardmäßig als globales System konzipiert. Daher ist der Dienst nicht anfällig für regionale Ausfälle, und diese Komponente des Systems muss nicht geändert werden.
Azure Blob Storage
Statische Inhalte wie Bilder und Videos werden in Azure Storage-Konten als Binary Large Objects (Blobs) gespeichert und für Benutzer über Azure CDN bereitgestellt.
In unserem ursprünglichen Entwurf ist das Speicherkonto in einer einzelnen Region enthalten, da wir uns dafür entschieden haben, den lokal redundanten Speicher (Locally Redundant Storage, LRS) zu verwenden. Unsere Daten werden nur innerhalb eines Rechenzentrums mit dem LRS repliziert. Das Speicherkonto ist deshalb nicht verfügbar, wenn es bei dieser Konfiguration zu einem regionalen Ausfall kommt. Der gesamte statische Inhalt, der bereits vom CDN zwischengespeichert wurde, steht Benutzer*innen weiterhin zur Verfügung.
Das gleiche gilt auch für den zonenredundanten Speicher (ZRS). Obwohl Daten in dieser Konfiguration in verschiedene Rechenzentren repliziert werden, befinden sich alle diese Rechenzentren weiterhin in derselben Region. Ein regionaler Ausfall wirkt sich auch auf das Speicherkonto in dieser Konfiguration aus.
In unserem Entwurf sind wir stark von unserer CDN-Konfiguration abhängig, um statische Inhalte zwischenzuspeichern. Es besteht die Möglichkeit, dass der Benutzer während eines Ausfalls eine statische Datei anfordern kann, die sich noch nicht im CDN-Cache befindet. Für diese Anforderung würde eine Grafik oder ein Video bereitgestellt. Beide Optionen können nicht angezeigt werden.
Wir können diese Möglichkeit ausschließen, indem wir das Speicherkonto in mehreren Regionen replizieren, wenn wir eine georedundanten Speicher auswählen. Es ist auch eine schreibgeschützte Replikationsoption verfügbar, um das Hinzufügen statischer Inhalte während eines regionalen Ausfalls zu verhindern.
Es stehen zwei Optionen zur Auswahl, wenn wir die Georedundanz aktivieren möchten. Eine davon ist georedundanter Speicher mit Lesezugriff (Read-Access Geo-Redundant Storage, RA-GRS), die andere geozonenredundanter Speicher mit Lesezugriff (Read-Access Geo-Zone-Redundant Storage, RA-GZRS). Die Entscheidung, welche Option ausgewählt wird, hängt von unserem Budget und der prozentualen Uptime ab, die wir benötigen.
Azure App Service und Azure-Funktions-Apps
Unser Portal zur Sendungsnachverfolgung implementiert zwei Azure App Service-Instanzen. Die erste App Services-Instanz hostet eine Web-App, die die benutzerseitige Webschnittstelle implementiert. Die zweite hostet eine Web-API, die von mobilen Apps zum Nachverfolgen von Versanddaten verwendet wird. Alle unsere Hintergrundaufgaben werden als Azure-Funktions-Apps ausgeführt.
In unserem ursprünglichen Entwurf wird jeder Azure App Service-Dienst in eine einzelne Azure-Region lokalisiert. Wir erstellen eine zweite App Service-Instanz in der zweiten Region (USA, Westen), und stellen das Webprojekt dort bereit, um die neue Architektur mit mehreren Regionen zu unterstützen. Wir konfigurieren den prioritätsbasierten Routingmodus für Azure Front Door, um Anforderungen an unsere sekundäre Region zu senden, wenn die primäre Region nicht verfügbar ist.
Stellen Sie sicher, dass die Webanwendung keine Sitzungszustandsinformationen im Arbeitsspeicher speichert, damit das Failover so reibungslos wie möglich verläuft. Wir ändern unsere Website, um sicherzustellen, dass kein Datenverlust auftritt. Wenn unser Code beispielsweise eine Liste mit den Versandinformationen der Benutzer im Arbeitsspeicher speichert, dann ginge diese Liste bei einem Failover verloren.
Jede Webanforderung wird verarbeitet, ohne die anderen zu beeinträchtigen, wenn kein Sitzungszustand gespeichert wird. Wenn ein Failover in der Mitte der Sitzung eines Benutzers auftritt, sollte dieses Failover für den Benutzer transparent sein.
Wir nehmen eine ähnliche Änderung an unseren Azure-Funktions-Apps vor. Wir erstellen eine separate Instanz der Azure-Funktion in der sekundären Region und stellen denselben benutzerdefinierten Code für sie bereit, der auch in der primären Region ausgeführt wird.
Wichtig
Wenn Sie ein Update für den benutzerdefinierten Code im App Service- oder Funktions-App-Dienst bereitstellen, denken Sie daran, das Update an alle App Service-Instanzen zu verteilen. Wenn Sie diesen Prozess automatisieren möchten, finden Sie in Azure DevOps hilfreiche Tools.
Azure Storage-Warteschlangen
In unserer ursprünglichen Architektur mit einer einzelnen Region haben wir eine Warteschlange in einem Azure Storage-Konto verwendet, um die Kommunikation zwischen der App Service-Instanz und der Funktions-App zu verwalten. Wenn die Web-App oder die Web-API eine Hintergrundaufgabe ausführen muss, platziert sie eine Meldung mit allen erforderlichen Informationen in der Warteschlange. Die Funktions-App überwacht die Warteschlange auf neue Meldungen und führt die Hintergrundaufgabe durch Ausführen der erforderlichen Abfragen für die Datenspeicher aus.
Wir können einen hohen Bedarf an Webanforderungen ordnungsgemäß ausführen, wenn wir die Warteschlange so verwenden. Wenn viele Hintergrundaufgaben auszuführen sind, kann sich die Warteschlange füllen, aber keine Aufgabe wird verworfen. Sie bleiben in der Warteschlange, bis sie verarbeitet werden. Die Funktions-Apps arbeiten sich durch die Warteschlange und reduzieren deren Größe, wenn der Bedarf sinkt. Wenn der Bedarf weiterhin besteht, erhöhen wir die Anzahl der Instanzen der Funktions-App.
Für die Version des Portals zur Sendungsnachverfolgung mit mehreren Regionen müssen wir sicherstellen, dass Warteschlangenelemente bei einem auftretenden Failover nicht verloren gehen. Unsere Warteschlange ist in Azure Storage definiert, und wir können eine Redundanzoption für die Georeplikation verwenden.
Beachten Sie, dass wir keine Redundanzoption mit Lesezugriff verwenden können, da unsere Warteschlange Lese- und Schreibvorgänge unterstützt. Der App-Dienst muss Elemente zur Warteschlange hinzufügen, und die Funktions-App muss abgeschlossene Elemente aus der Warteschlange entfernen. Verwenden Sie stattdessen den georedundanten Speicher (GRS) oder den geozonenredundanten Speicher (GZRS).
Azure Redis Cache
Wir verwenden den Azure Redis Cache, um die Leistung des Datenspeichers zu maximieren. Redis Cache speichert alle Abfrageergebnisse zwischen, die von unseren Apps beim Anfordern von Daten aus unseren Datenbanken generiert wurden. Alle weiteren Abfragen für ähnliche Daten benötigen keine Datenbankabfrage und werden aus dem Redis-Cache abgerufen.
Für die Architektur mit mehreren Regionen erstellen wir eine Redis Cache-Instanz in den primären Regionen und Standbyregionen. Beachten Sie, dass bei Auftreten eines Failovers die Redis Cache-Instanz in der Standbyregion wahrscheinlich leer ist. Dieser leere Cache verursacht keine Fehler, die Leistung fällt aber möglicherweise vorübergehend ab, da Daten den neuen Cache füllen.