Bereitstellen von Azure Spring Apps in mehreren Regionen

Diese Referenzarchitektur beschreibt einen Ansatz zum Ausführen mehrerer Azure Spring Apps-Instanzen in mehreren Regionen in einer Aktiv/Aktiv-Konfiguration.

Dieser Entwurf baut auf der Basisarchitektur von Azure Spring Apps auf. Die Baseline stellt eine Java Spring Boot-Anwendung in mehreren Verfügbarkeitszonen innerhalb einer einzelnen Region bereit. Die mehrere Zonen verteilen den Anwendungsworkload auf getrennte Standorte, damit die Workload lokale Fehler innerhalb der Azure-Region tolerieren kann.

Wenn es jedoch in der gesamten Region zu einem Ausfall kommt, ist die Baseline für den Benutzer nicht mehr verfügbar. Mit diesem Entwurf soll Hochverfügbarkeit geschaffen werden, die einem regionalen Ausfall standhalten kann.

Diese Architektur ist nützlich, um die folgenden Ziele zu erreichen:

• Erhöhung der allgemeinen Resilienz und des Servicelevelziels (Service Level Objective, SLO) der Anwendung.
• Ermöglichen globaler Reichweite für die Anwendung.
• Annäherung des Workloads an den Endbenutzer und maximal mögliche Verringerung der Wartezeit.
• Verwenden einer sekundären Region als Failoverstandort für die primäre Region, und Entscheidung für einen Aktiv/Passiv-Entwurf.

Um die Resilienz und Zuverlässigkeit der Anwendung zu erhöhen, können Sie die Anwendung in mehreren Regionen bereitstellen. Für diesen Entwurf benötigen Sie einen globalen Router, um Anforderungen an Ihre Anwendungen regionsübergreifend zu verteilen. Der globale Router in dieser Architektur erfüllt auch andere Ziele.

Die größte Herausforderung bei einer Einrichtung mit mehreren Regionen besteht in der Replikation der Daten für Ihre Anwendung zwischen mehreren Regionen. Dieses Problem ist bei der Einrichtung mit mehreren Zonen keine Unwägbarkeit. Azure-Verfügbarkeitszonen sind über ein Hochleistungsnetzwerk mit einer Roundtriplatenz von weniger als 2 ms verbunden. Die Dauer dieser Wartezeit ist für die meisten Anwendungen ausreichend.

Aufbau

Die folgende Abbildung zeigt die Architektur für diesen Ansatz:

Komponenten

Die Komponenten dieser Architektur sind identisch mit der Basisarchitektur. In der folgenden Liste werden nur die Änderungen an der Basisarchitektur hervorgehoben. Eine Produktdokumentation zu Azure-Diensten finden Sie im Abschnitt Zugehörige Ressourcen.

• Azure Front Door fungiert als globaler Lastenausgleich. Dieser Dienst wird aufgrund seiner Fähigkeit verwendet, höhere Verfügbarkeit mit geringerer Latenz, größerer Skalierung und Zwischenspeicherung am Edge bereitzustellen.

Workflow

Die Referenzarchitektur implementiert den folgenden Workflow:

1. Der Benutzer sendet eine Anfrage an den HTTP-Hostnamen der Anwendung, z. B. www.contoso.com. Azure DNS löst die Anforderung für diesen Hostnamen in Azure Front Door auf.

2. Azure Front Door verwendet verschiedene Lastenausgleichskonfigurationen, um die eingehenden Anforderungen an den öffentlichen Endpunkt von Azure Application Gateway in jeder Region weiterzuleiten. Die Application Gateway-Instanz wird mit demselben benutzerdefinierten Domänennamen und TLS-Zertifikatnamen wie Azure Front Door konfiguriert.

3. Application Gateway mit integrierter Azure Web Application Firewall untersucht die Anforderung. Web Application Firewall lässt eingehende Anforderungen nur aus dem angegebenen Azure Front Door-Profil zu.

4. Application Gateway leitet den zulässigen Datenverkehr an die IP-Adresse des Lastenausgleichs in der bereitgestellten Spring Apps-Instanz weiter.

5. Der interne Lastenausgleich leitet den Datenverkehr nur von Application Gateway an die Back-End-Dienste weiter. Diese Dienste werden in der Spring Apps-Instanz in einem virtuellen Netzwerk in jeder Region gehostet.

6. Im Rahmen der Verarbeitung der Anforderung kommuniziert die Anwendung mit anderen Azure-Diensten innerhalb des virtuellen Netzwerks. Beispiele hierfür sind die Anwendung, die mit Azure Key Vault wegen Geheimnissen kommuniziert, sowie die Datenbank zum Speichern des Zustands.

Globale Verteilung

Wenn Sie eine hohe Verfügbarkeit anstreben, können Sie diese Architektur als Aktiv/Aktiv, Aktiv/Passiv mit unmittelbar betriebsbereitem Standbyserver oder Aktiv/Passiv und verzögert betriebsbereit einrichten.

Ihre Wahl ist abhängig von den Verfügbarkeitsanforderungen für Ihre Anwendung. Diese Architektur verwendet die Aktiv-Aktiv-Bereitstellung in zwei Regionen, da die Beispielorganisation eine globale Präsenz mit hoher Betriebszeit-SLA (Service Level Agreement, Vereinbarung zum Servicelevel) haben möchte. Wenn Sie unternehmenskritische Anwendungen ausführen und eine höhere Verfügbarkeit wünschen, müssen Sie mehr als zwei Regionen verwenden.

Aktiv-aktiv

Im Aktiv/Aktiv-Modus verarbeiten alle Regionen Anforderungen gleichzeitig. Die größte Herausforderung beim Aktiv/Aktiv-Modus besteht darin, die Datensynchronisierung zwischen den Regionen aufrecht zu halten. Dieser Modus ist ein kostspieliger Ansatz, da Sie für fast alle Komponenten doppelt bezahlen.

Aktiv/Passiv mit unmittelbar betriebsbereitem Standbyserver

Im Aktiv/Passiv-Modus mit unmittelbar betriebsbereitem Standbyserver empfängt die sekundäre Region keine Anforderungen von Azure Front Door, solange die primäre Region aktiv ist. Stellen Sie sicher, dass Sie Ihre Anwendungsdaten ordnungsgemäß von Ihrer primären in Ihre sekundäre Region replizieren. Wenn in Ihrer primären Region ein Fehler auftritt, müssen Sie die Rollen Ihrer Back-End-Datenbanken ändern und ein Failover für den gesamten Datenverkehr über Azure Front Door in Ihre sekundäre Region durchführen.

Im Aktiv/Passiv-Modus wird erwartet, dass das Failover einige Zeit in Anspruch nimmt, wodurch es einfacher ist, sicherzustellen, dass alle Daten synchronisiert bleiben. Der Aktiv/Passiv-Modus mit unmittelbar betriebsbereitem Standbyserver ist jedoch genauso kostspielig wie das Arbeiten im Aktiv/Aktiv-Modus.

Aktiv/Passiv mit verzögert betriebsbereit

Im Aktiv/Passiv-Modus mit verzögert betriebsbereitem Standbyserver verfügt die primäre Region über alle Ressourcen und bedient den Datenverkehr. Die sekundäre Region verfügt möglicherweise über weniger Komponenten oder über Komponenten mit geringeren Computeressourcen. Die Technologieauswahl hängt davon ab, wie viele Ausfallzeiten gemäß den geschäftsspezifischen Anforderungen akzeptabel sind. Der Umfang der Einrichtung Ihrer sekundären Region wirkt sich auch auf die Kosten aus. Stellen Sie sicher, dass zumindest die Anwendungsdaten in der sekundären Region vorhanden sind.

Wie bereits erwähnt, umfasst der Aktiv/Passiv-Modus, dass ein Failover einige Zeit in Anspruch nimmt, sodass es einfacher ist, alle Daten synchronisiert zu halten. Der Aktiv/Passiv-Modus mit verzögert betriebsbereitem Standbyserver ist der kostengünstigste Ansatz, da Sie nicht alle Ressourcen in beiden Regionen bereitstellen.

Wenn Ihre gesamte Lösungseinrichtung Vorlagen verwendet, können Sie ganz einfach eine verzögert betriebsbereite sekundäre Region bereitstellen, indem Sie die zugehörigen Ressourcen bei Bedarf erstellen. Sie können Terraform-, Bicep- oder Azure Resource Manager-Vorlagen verwenden und die Infrastruktureinrichtung in einer CI/CD-Pipeline (Continuous Integration/Continuous Deployment) automatisieren. Sie sollten Ihre Konfiguration regelmäßig testen, indem Sie Ihre sekundäre Region neu erstellen, um sicherzustellen, dass Ihre Vorlagen im Notfall bereitgestellt werden können.

Das Bereitstellungsstempelmuster wird empfohlen, da mehrere unabhängige Kopien einer Anwendung oder Komponente aus einer einzelnen Vorlage in mehreren Regionen bereitgestellt werden können.

Modusvergleich

In der folgenden Tabelle wird der für die Synchronisierung von Daten erforderliche Aufwand für jeden Modus zusammengefasst und die Kosten verglichen.

Routing zwischen Regionen

Diese Referenzarchitektur verwendet geografische Knoten (Geodes), wobei jede Region jede Anforderung bedienen kann.

Azure Front Door ist mit gleichem Routing zwischen den beiden Bereitstellungsregionen konfiguriert. Azure Front Door bietet auch andere Routingmethoden für Datenverkehr an den Ursprung. Wenn Sie Clients an ihren nächstgelegenen Ursprung weiterleiten möchten, ist latenzbasiertes Routing am sinnvollsten. Wenn Sie eine Aktiv/Passiv-Lösung entwerfen, ist das prioritätsbasierte Routing besser geeignet.

In diesem Referenzarchitekturbeispiel wird eine Lastenausgleichsregel mit gleicher Gewichtung zwischen den beiden Regionen verwendet. Azure Front Door wird mit Folgendem konfiguriert:

• Eine benutzerdefinierte Domäne und ein TLS-Zertifikat (Transport Layer Security) mit demselben Namen wie dem Namen des Anwendungshosts., z. B www.contoso.com.

• Ein Ursprung pro Region, in der die Anwendung bereitgestellt wird, wobei jeder Ursprung eine Azure Application Gateway-Instanz ist.

Layout der Ressourcengruppe

Verwalten Sie Ressourcen, die in jeder Region als einzelne Sammlung bereitgestellt werden, anhand von Azure-Ressourcengruppen. Sie sollten die primäre Region, die sekundäre Region und Azure Front Door unterschiedlichen Ressourcengruppen zuordnen (siehe folgendes Diagramm):

Das Diagramm zeigt die folgende Konfiguration von Ressourcengruppen:

• Azure Front Door wird in der Ressourcengruppe Application-shared bereitgestellt.
• Alle in „Europa, Westen“ gehosteten Ressourcen (weu) werden in der Ressourcengruppe Application-weu bereitgestellt.
• In der Region „USA, Osten“ gehostete Ressourcen (eus) werden in der Ressourcengruppe Application-eus gehostet.
• In der Region „Japan, Osten“ gehostete Ressourcen (jae) werden in der Ressourcengruppe Application-jae gehostet.

Ressourcen in derselben Ressourcengruppe teilen sich den gleichen Lebenszyklus und können einfach zusammen erstellt und gelöscht werden. Jede Region verfügt über einen eigenen Ressourcensatz in einer dedizierten Ressourcengruppe, die eine Namenskonvention befolgt, die auf dem Namen der Region basiert. Azure Front Door befindet sich in einer eigenen Ressourcengruppe, da der Dienst auch dann vorhanden sein muss, wenn andere Regionen hinzugefügt oder entfernt werden.

Reverseproxyeinrichtung

Azure Front Door führt einen globalen Lastenausgleich zwischen Regionen durch. Dieser Reverseproxy hilft beim Verteilen des Datenverkehrs, wenn Sie einen Workload in mehreren Regionen bereitstellen. Alternativ können Sie Azure Traffic Manager verwenden. Traffic Manager ist ein DNS-basierter Lastenausgleichsdienst, der den Lastenausgleich nur auf Domänenebene durchführt.

Azure Front Door verfügt über integrierte Content Delivery Networks (CDNs), die Inhalte aus dem globalen Edgenetzwerk von Microsoft mit auf der ganzen Welt verteilten PoPs (Point of Presence) bereitstellen.

Die aktuelle Lösung verwendet zwei Reverseproxys, um die Konsistenz mit der Basisarchitektur zu gewährleisten. Azure Front Door ist der globale Router. Application Gateway fungiert als Lastenausgleich pro Region. In den meisten Fällen ist diese Einrichtung nicht erforderlich. Sie können Application Gateway entfernen, wenn Sie die folgenden Anforderungen erfüllen:

• Da Azure Web Application Firewall an Application Gateway angefügt ist, müssen Sie Web Application Firewall stattdessen an den Azure Front Door-Dienst anfügen.
• Sie müssen sicherstellen, dass eingehende Aufrufe nur von Ihrer Azure Front Door-Instanz stammen. Sie können die X-Azure-FDID header-Überprüfung sowie die Azure Front Door-IP-Bereichsüberprüfung in der Spring Cloud Gateway-Anwendung hinzufügen. Weitere Informationen finden Sie unter Verwenden von Azure Front Door als Reverseproxymit Spring Cloud Gateway.

Informationen zu verschiedenen Reverseproxyszenarien, zu deren Einrichtung und den zugehörigen Sicherheitsüberlegungen finden Sie unter Verfügbarmachen von Azure Spring Apps über einen Reverseproxy.

Back-End-Datenbank

Für die Bereitstellung in mehreren Regionen benötigen Sie eine Strategie für die Datenreplikation. Wenn die Anwendung regionsübergreifend verfügbar ist, sollten die Daten synchronisiert werden, sodass Benutzern keine veralteten Daten angezeigt werden.

Die aktuelle Architektur verwendet eine MySQL-Datenbank als Back-End-Datenbank, aber diese Konfiguration behandelt nicht die Datensynchronisierung. Wenn Sie eine Datenbanktechnologie auswählen, überprüfen Sie, wie Sie Daten am besten zwischen Regionen replizieren und synchronisieren. Eine Option ist die Azure SQL-Datenbank, die über ein aktive Georeplikationsfeature verfügt, das eine fortlaufend synchronisierte, lesbare sekundäre Datenbank für eine primäre Datenbank bereitstellt.

Dieses Feature kann in folgenden Szenarien verwendet werden:

• Wenn Ihre sekundäre Region verzögert betriebsbereit ist und keine aktiven Anforderungen empfängt.
• Für ein Failover, wenn Ihre primäre Region fehlschlägt.
• Zum Einrichten primärer und sekundärer Datenbanken mit privaten Verbindungen zu ihren jeweiligen Regionen über Peering virtueller Netzwerke zwischen den beiden Regionen.

Ein weiterer Ansatz ist die Verwendung von Azure Cosmos DB. Dieser Dienst kann Daten global verteilen, indem sie transparent in alle Regionen in Ihrem Azure Cosmos DB-Konto repliziert werden. Sie können Azure Cosmos DB auch mit mehreren Schreibregionen konfigurieren. Weitere Informationen finden Sie unter Geode Pattern (Geoknotenmuster).

Automatisierte Bereitstellung

Automatisieren Sie Ihre Infrastrukturbereitstellung und Anwendungscodebereitstellungen so weit wie möglich.

Die Automatisierung von Infrastrukturbereitstellungen garantiert, dass die Infrastruktur identisch konfiguriert ist, was hilft, Konfigurationsabweichungen, z. B. zwischen Regionen, zu vermeiden. Die Infrastrukturautomatisierung kann auch Failovervorgänge testen.

Stellen Sie bei der Anwendungsbereitstellung sicher, dass Ihre Bereitstellungssysteme auf die verschiedenen Regionen ausgerichtet sind, in denen sie bereitstellen müssen. Sie können auch mehrere Regionen in einer Blau-Grün- oder Canary-Bereitstellungsstrategie verwenden. Mit diesen Bereitstellungsstrategien stellen Sie neue Versionen von Anwendungen als Test in einer Region bereit. Nach erfolgreichem Test werden sie dann in anderen Regionen bereitgestellt.

Leistung und Skalierbarkeit

Diese Architektur ist besser geeignet als die Baselinearchitektur, um die Anforderungen der Anwendungen zu erfüllen, da sie die Last auf mehrere Regionen verteilt. Wenn Sie Azure Front Door so konfigurieren, dass Anforderungen basierend auf der Wartezeit weitergeleitet werden, erhalten Benutzer bessere Antwortzeiten, da Anforderungen an die Regionen weitergeleitet werden, die ihnen am nächsten liegen.

Abhängig von Ihrer Datenbankeinrichtung kann es zu einer zusätzlichen Wartezeit kommen, wenn Daten zwischen Regionen synchronisiert werden müssen. Sie können diese Wartezeit beseitigen, indem Sie Azure Cosmos DB mit einer flexibleren Konsistenzebene verwenden.

Diese Referenzarchitektur verfügt über mehrere Komponenten, die basierend auf Metriken automatisch skaliert werden können:

• Azure Front Door kann bedarfsabhängig automatisch skaliert werden. Sie können andere Azure Front Door-Features wie Beschleunigung des Datenverkehrs und Zwischenspeicherung verwenden, um ihren Endbenutzern Ressourcen näher zu bringen.
• Application Gateway unterstützt automatische Skalierung. Weitere Informationen finden Sie unter Skalieren von Application Gateway v2 und Web Application-Firewall v2.
• Azure Spring Apps unterstützt automatische Skalierung ebenfalls. Weitere Informationen finden Sie unter Einrichten der Autoskalierung für Anwendungen.

Kostenbetrachtung

Diese Lösung verdoppelt die geschätzten Kosten der Baselinearchitektur.

Zu den Hauptkostentreibern im Zusammenhang mit der Lösung für mehrere Regionen gehören:

• Die primäre und sekundäre Datenbank müssen dieselbe Dienstebene verwenden. Andernfalls kann die sekundäre Datenbank mit Replikationsänderungen eventuell nicht Schritt halten.
• Erheblicher regionsübergreifender Datenverkehr erhöht die Kosten. Für den Netzwerkdatenverkehr zwischen Azure-Regionen fallen Gebühren an.

Um diese Kosten zu verwalten, berücksichtigen Sie die folgenden Empfehlungen für Ihre Implementierung:

• Verwenden Sie herunterskalierte Versionen von Ressourcen wie Azure Spring Apps und Application Gateway in der Standbyregion, und skalieren Sie die Ressourcen nur hoch, wenn der Standbymodus aktiv wird.
• Wenn Ihre Geschäftsszenarien dies zulassen, erstellen Sie eine Aktiv/Passiv-Einrichtung, um Kosten zu sparen.
• Implementieren Sie ein Setup mit mehreren Zonen in einer einzelnen Region, um die Geschäftsanforderungen an Verfügbarkeit und Resilienz zu erfüllen. Diese Option kann kostengünstiger sein, da Sie für die meisten Ressourcen nur einmal bezahlen.
• Wählen Sie die alternative Einrichtung, bei der nur ein Reverseproxy verwendet wird, um Kosten zu sparen. Denken Sie daran, dass Sie eine zusätzliche Konfiguration anwenden müssen, um die Sicherheit dieser Alternative zu gewährleisten.

Wir haben die Kosten für Dienste in dieser Architektur mit dem Azure-Preisrechner anhand angemessener Standardwerte für eine kleine Anwendung geschätzt. Sie können diese Schätzung basierend auf den für Ihre Anwendung erwarteten Durchsatzwerten aktualisieren.

Weitere Überlegungen

Die Entwurfsüberlegungen für die Basisarchitektur mit mehreren Zonen gelten auch für die in diesem Artikel beschriebene Lösung mit mehreren Regionen. Überprüfen Sie die folgenden Punkte im Kontext der Architektur mit mehreren Regionen:

• Netzwerksicherheit. Es ist wichtig, die Kommunikation über das Netzwerk zu steuern. Diese Lösung lässt nur eingehende Anrufe von Azure Front Door zu, wobei die Anrufe an Application Gateway in jeder Region weitergeleitet werden. Die Aufrufe werden von Application Gateway aus an den Back-End-Dienst von Azure Spring Apps weitergeleitet. Die Kommunikation von Azure Spring Apps mit unterstützenden Diensten wie Key Vault wird ebenfalls über private Endpunkte gesteuert. Weitere Informationen finden Sie unter Basisarchitektur: Netzwerksicherheit.

• Identitäts- und Zugriffsverwaltung. Implementieren Sie einen sichereren Zugriff, indem Sie verwaltete Identitäten verwenden, um eine Verbindung zwischen verschiedenen Komponenten herzustellen. Ein Beispiel ist, wie Azure Spring Apps mithilfe einer verwalteten Identität eine Verbindung mit Key Vault herstellt. Weitere Informationen finden Sie unter Baselinearchitektur: Identitäts- und Zugriffsverwaltung.

• Überwachung: Sie können Instrumentierung hinzufügen und die verteilte Ablaufverfolgung aktivieren, um Daten aus der Anwendung zu sammeln. Kombinieren Sie diese Datenquelle mit plattformbasierter Diagnose, um einen End-to-End-Einblick in Ihre Anwendung zu erhalten. Weitere Informationen finden Sie unter Basisarchitektur: Überwachung.

• Verwaltung von Geheimnissen. Die Lösung mit mehreren Regionen speichert die Anwendungsgeheimnisse und -zertifikate in einem einzelnen Schlüsseltresor. Weitere Informationen finden Sie unter Basisarchitektur: Geheimnisverwaltung.

Szenariobereitstellung

Eine Bereitstellung für diese Referenzarchitektur finden Sie unter Mehrregions-Referenzarchitektur für Azure Spring Apps auf GitHub. Die Bereitstellung verwendet Terraform-Vorlagen.

Befolgen Sie zum Bereitstellen der Architektur die Schritt-für-Schritt-Anweisungen.

Beitragende

Microsoft pflegt diesen Inhalt. Der folgende Mitwirkende hat den ursprünglichen Inhalt entwickelt.

Hauptautor:

• Gitte Vermeiren | FastTrack for Azure Engineer

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

Nächste Schritte

Um diese Workload in gemeinsam genutzte Dienste zu integrieren, die von zentralen Teams in Ihrer Organisation verwaltet werden, stellen Sie sie in der Zielzone der Azure-Anwendung bereit.

Zugehörige Ressourcen

Eine Dokumentation zu den in dieser Architektur verwendeten Azure-Diensten und -Features finden Sie in den folgenden Artikeln:

• Azure Spring Apps
• Azure Front Door
• Azure Application Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• Azure DNS
• Azure Web Application Firewall
• Azure Private Link
• Verwaltete Microsoft Entra-Identitäten für Azure-Ressourcen

Es wird empfohlen, die folgenden Leitfäden für ein tieferes Verständnis der Konfigurationsoptionen bei dieser Architektur zu erhalten:

• Verfügbarmachen von Azure Spring Apps über einen Reverseproxy
• Blau/Grün-Bereitstellung mit Hochverfügbarkeit für Anwendungen
• Beibehalten des ursprünglichen HTTP-Hostnamens zwischen einem Reverseproxy und seiner Back-End-Webanwendung

Diese Architektur wurde unter Berücksichtigung der Säulen des Microsoft Azure Well-Architected Frameworks konzipiert. Es wird empfohlen, die Entwurfsprinzipien für jede Säule zu überprüfen.