Zuverlässiges Web-App-Muster für Java – Planen der Implementierung

In diesem Artikel erfahren Sie, wie Sie die Implementierung des zuverlässigen Web-App-Musters planen. Das zuverlässige Web-App-Muster besteht aus einer Reihe von Prinzipien und Implementierungstechniken, die definieren, wie Sie Web-Apps bei der Migration zur Cloud ändern (zu einer neuen Plattform verlagern) sollten. Es führt nur die Codeupdates durch, die für eine erfolgreiche Ausführung in der Cloud benötigt werden.

Um die Anwendung dieser Anleitung zu unterstützen, gibt es eine Referenzimplementierung des zuverlässigen Web-App-Musters, die Sie bereitstellen können.

Architektur der Referenzimplementierung: Laden Sie eine Visio-Datei dieser Architektur herunter.

In der folgenden Anleitung wird die Referenzimplementierung als Beispiel verwendet. Führen Sie die folgenden Schritte aus, um die Implementierung des zuverlässigen Web-App-Musters zu planen:

Definieren Sie die Unternehmensziele.

Der erste Schritt beim Wechsel zum Cloud Computing besteht in der Formulierung Ihrer geschäftlichen Ziele. Das zuverlässige Web-App-Muster betont die Bedeutung der Festlegung unmittelbarer und zukünftiger Ziele für Ihre Webanwendung. Diese Ziele sind für Ihre Wahl von Clouddiensten und die Architektur Ihrer Webanwendung in der Cloud relevant.

Beispiel: Das fiktive Unternehmen Contoso Fiber wollte seine lokale Customer Account Management System (CAMS)-Web-App erweitern, um weitere Regionen zu erreichen. Um die erhöhte Auslastung der Web-App zu bewältigen, hat das Unternehmen die folgenden Ziele festgelegt:

• Anwendung kostengünstiger, aber hochwertiger Codeänderungen
• Erreichen eines Servicelevel-Ziels (Service Level Objective, SLO) von 99,9 %
• Einführung von DevOps-Verfahren
• Entwicklung kostenoptimierter Umgebungen
• Verbesserung von Zuverlässigkeit und Sicherheit

Contoso Fiber hat festgestellt, dass seine lokale Infrastruktur keine kostengünstige Lösung für die Skalierung der Anwendung darstellte. Das Unternehmen kam zu dem Schluss, dass die Migration ihrer CAMS-Webanwendung zu Azure die kostengünstigste Möglichkeit war, die unmittelbaren und zukünftigen Ziele zu erreichen.

Wählen Sie die richtigen verwalteten Dienste aus.

Wenn Sie eine Web-App zur Cloud migrieren, sollten Sie Azure-Dienste auswählen, die Ihren geschäftlichen Anforderungen entsprechen und an den aktuellen Funktionen der lokalen Web-App ausgerichtet sind. Die Ausrichtung trägt zur Minimierung des Aufwands für die Verlagerung zu einer neuen Plattform bei. Sie könnten beispielsweise Dienste verwenden, mit denen Sie das Datenbankmodul beibehalten und vorhandene Middleware und Frameworks unterstützen können. In den folgenden Abschnitten finden Sie Anleitungen für die Auswahl der richtigen Azure-Dienste für Ihre Web-App.

Beispiel: Vor der Migration zur Cloud handelt es sich bei der CAMS-Web-App von Contoso Fiber um eine lokale, monolithische Java-Web-App. Es war eine Spring Boot-App mit einer PostgreSQL-Datenbank. Die Web-App erfüllte die Aufgabe einer branchenspezifischen Support-App. Sie ist für Mitarbeiter zugänglich. Die Mitarbeitenden von Contoso Fiber verwalten über die Anwendung Supportfälle ihrer Kunden. Die lokale Webanwendung leidet unter häufigen Problemen. Hierzu zählen unter anderem die lange Dauer der Erstellung und Bereitstellung neuer Features sowie Schwierigkeiten beim Skalieren verschiedener Anwendungskomponenten unter höherer Last.

Anwendungsplattform

Wählen Sie die Hostingplattform für Anwendungen aus, die für Ihre Web-App am besten geeignet ist. Azure bietet zahlreiche verschiedene Compute-Optionen an, um verschiedene Web-App-Anforderungen zu erfüllen. Wenn Sie Unterstützung bei der Einengung der Optionen benötigen, nutzen Sie die Compute-Entscheidungsstruktur von Azure.

Beispiel: Contoso Fiber hat sich aus den folgenden Gründen für Azure App Service als Anwendungsplattform entschieden:

• Natürlicher Fortschritt. Contoso Fiber hatte die Spring Boot-Datei jar auf dem lokalen Server bereitgestellt und wollte den Umfang der Architekturänderungen für dieses Bereitstellungsmodell minimieren. App Service stellt eine robuste Unterstützung für die Ausführung von Spring Boot-Apps bereit. Daher war die Verwendung von App Service ein natürlicher Schritt für Contoso Fiber. Azure Spring Apps ist auch eine attraktive Alternative für diese App. Wenn die CAMS-Web-App von Contoso Fiber Jakarta EE statt Spring Boot verwenden würde, wäre Azure Spring Apps die bessere Wahl. Weitere Informationen finden Sie unter Was ist Azure Spring Apps? und Java EE, Jakarta EE und MicroProfile auf Azure.

• Hoher SLA-Wert: Es bietet einen hohen SLA-Wert, der die Anforderungen für die Produktionsumgebung erfüllt.

• Geringerer Verwaltungsaufwand: Es handelt sich um eine vollständig verwaltete Hostinglösung.

• Möglichkeit zur Containerisierung: App Service funktioniert mit privaten Containerimageregistrierungen wie Azure Container Registry. Contoso Fiber kann diese Registrierungen verwenden, um die Web-App in der Zukunft zu containerisieren.

• Automatische Skalierung Die Web-App kann basierend auf Benutzerdatenverkehr schnell hoch- und herunterskaliert sowie auf- und abskaliert werden.

Identitätsverwaltung

Wählen Sie die Identitätsverwaltungslösung aus, die für Ihre Web-App am besten geeignet ist. Weitere Informationen finden Sie unter Vergleich von Identitätsverwaltungslösungen und Authentifizierungsmethoden.

Beispiel: Contoso Fiber hat sich aus den folgenden Gründen für Microsoft Entra ID entschieden:

• Authentifizierung und Autorisierung: Es übernimmt die Authentifizierung und Autorisierung von Mitarbeitern.

• Skalierbarkeit. Sie wird skaliert, um größere Szenarien zu unterstützen.

• Benutzeridentitätssteuerung: Mitarbeiter können ihre vorhandenen Unternehmensidentitäten verwenden.

• Unterstützung von Autorisierungsprotokollen. Die Lösung unterstützt OAuth 2.0 für verwaltete Identitäten.

Datenbank

Wählen Sie die Datenbank aus, die für Ihre Web-App am besten geeignet ist. Wenn Sie Unterstützung bei der Einengung der Optionen benötigen, nutzen Sie die Datenspeicher-Entscheidungsstruktur von Azure.

Beispiel: Contoso Fiber hat sich aus den folgenden Gründen für Azure Database for PostgreSQL und die Option mit flexiblem Server entschieden:

• Zuverlässigkeit. Das Bereitstellungsmodell für flexible Server unterstützt zonenredundante Hochverfügbarkeit über mehrere Verfügbarkeitszonen hinweg. Diese Konfiguration verwaltet einen betriebsbereiten Standbyserver in einer anderen Verfügbarkeitszone innerhalb derselben Azure-Region. Die Konfiguration repliziert Daten synchron auf den Standbyserver.

• Regionsübergreifende Replikation. Es ist ein Lesereplikatfeature vorhanden, mit dem Sie Daten asynchron in eine schreibgeschützte Replikatdatenbank in einer anderen Region replizieren können.

• Leistung. Es werden vorhersagbare Leistung und intelligente Optimierung geboten, um die Leistung Ihrer Datenbank mithilfe von realen Nutzungsdaten zu verbessern.

• Geringerer Verwaltungsaufwand: Es handelt sich um einen vollständig verwalteten Azure-Dienst, der die Verwaltungsverpflichtungen reduziert.

• Migrationsunterstützung: Es unterstützt die Datenbankmigration aus lokalen Einzelserver-PostgreSQL-Datenbanken. Das Unternehmen kann das Migrationstool verwenden, um die Migration zu vereinfachen.

• Konsistenz mit lokalen Konfigurationen: Die Lösung unterstützt verschiedene Community-Versionen von PostgreSQL, einschließlich der Version, die Contoso Fiber derzeit verwendet.

• Resilienz. Die Flexible Server-Bereitstellung erstellt automatisch Serversicherungen und speichert diese in zonenredundantem Speicher innerhalb der gleichen Region. Das Unternehmen kann die Datenbank zu jedem Zeitpunkt innerhalb des Aufbewahrungszeitraums der Sicherung wiederherstellen. Die Funktionalität für Sicherung und Wiederherstellung bietet ein besseres RPO (d. h. akzeptablen Umfang des Datenverlusts), als Contoso Fiber lokal erzielen könnte.

Überwachung der Anwendungsleistung

Wählen Sie eine Lösung für die Überwachung der Anwendungsleistung für Ihre Web-App aus. Application Insights ist die Azure-native Lösung für die Überwachung der Anwendungsleistung (Application Performance Management, APM). Es handelt sich um ein Feature der Überwachungslösung von Azure, Azure Monitor.

Beispiel: Contoso Fiber hat aus den folgenden Gründen Application Insights hinzugefügt:

• Anomalieerkennung Der Dienst erkennt automatisch Leistungsanomalien.

• Problembehandlung. Application Insights unterstützt Sie beim Diagnostizieren von Problemen in der ausgeführten App.

• Telemetrie. Es sammelt Informationen darüber, wie Benutzer die App verwenden, und ermöglicht es Ihnen, benutzerdefinierte Ereignisse, die Sie in Ihrer App nachverfolgen möchten, auf einfache Weise zu senden.

• Transparenzlücke für die lokale Lösung. Die lokale Lösung stellte keine Funktionalität für die Überwachung der Anwendungsleistung bereit. Application Insights bietet eine einfache Integration in die Anwendungsplattform und in den Code.

cache

Legen Sie fest, ob der Web-App-Architektur ein Zwischenspeicher hinzugefügt werden soll. Azure Cache for Redis ist die primäre Zwischenspeicherlösung von Azure. Es handelt sich um einen verwalteten In-Memory-Datenspeicher auf der Basis der Redis-Software.

Beispiel: Contoso Fiber benötigte einen Zwischenspeicher, der die folgenden Vorteile bietet:

• Geschwindigkeit und Umfang: Azure Cache for Redis bietet einen hohen Datendurchsatz und Lesevorgänge mit geringer Wartezeit für häufig verwendete Daten, die sich nur langsam ändern.

• Vielfältige Unterstützung: Azure Cache for Redis ist ein einheitlicher Cache, der von allen Instanzen der Web-App verwendet werden kann.

• Externer Datenspeicher. Von den lokalen Anwendungsservern wurde eine VM-lokale Zwischenspeicherung durchgeführt. Bei diesem Setup wurden häufig verwendete Daten nicht ausgelagert, und Daten konnten nicht ungültig gemacht werden.

• Nicht fixierte Sitzungen. Der Zwischenspeicher ermöglicht der Web-App die Externalisierung des Sitzungsstatus und die Verwendung nicht fixierter Sitzungen. Die meisten lokalen Java-Web-Apps verwenden die clientseitige Zwischenspeicherung im Arbeitsspeicher. Das clientseitige Zwischenspeichern im Arbeitsspeicher skaliert nicht gut und erhöht den Arbeitsspeicherbedarf auf dem Host. Mit der Verwendung von Azure Cache for Redis verfügt Contoso Fiber jetzt über einen vollständig verwalteten, skalierbaren Zwischenspeicherdienst, um die Skalierbarkeit und Leistung seiner Anwendungen zu verbessern. Contoso Fiber verwendete ein Framework für die Zwischenspeicherabstraktion (Spring Cache). Daher waren nur minimale Konfigurationsänderungen erforderlich, um den Zwischenspeicheranbieter zu wechseln. Dadurch konnten sie von einem Ehcache-Anbieter zum Redis-Anbieter wechseln.

Load Balancer

Wählen Sie den Load Balancer aus, der für Ihre Web-App am besten geeignet ist. Azure verfügt über mehrere Lastenausgleichsmodule. Hilfe bei der Einengung der Optionen finden Sie unter Wählen Sie den Load Balancer aus, der für Ihre Web-App am besten geeignet ist.

Beispiel: Contoso Fiber hat sich aus den folgenden Gründen für Front Door als globalen Load Balancer entschieden:

• Flexibles Routing: Sie ermöglicht es dem Anwendungsteam, den Eingangsbedarf zu konfigurieren, um zukünftige Änderungen in der Anwendung zu unterstützen.

• Beschleunigung des Datenverkehrs: Sie verwendet Anycast, um den nächstgelegenen Azure-PoP (Point of Presence) zu erreichen und die schnellste Route zur Web-App zu finden.

• Benutzerdefinierte Domänen: Sie unterstützt benutzerdefinierte Domänennamen mit flexibler Domänenvalidierung.

• Integritätstests: Die Anwendung benötigt eine intelligente Integritätstestüberwachung. Azure Front Door ermittelt anhand der Ergebnisse des Tests den besten Ursprung für die Weiterleitung Ihrer Clientanforderungen.

• Überwachungsunterstützung: Sie unterstützt integrierte Berichte mit einem All-in-One-Dashboard für Front Door und Sicherheitsmuster. Sie können Warnungen konfigurieren, die in Azure Monitor integriert werden. Die Anwendung kann jede Anforderung sowie fehlerhafte Integritätstests protokollieren.

• DDoS-Schutz: Sie verfügt über integrierten DDoS-Schutz für Layer 3 und 4.

Web Application Firewall

Wählen Sie eine Webanwendungsfirewall aus, um Ihre Web-App vor Angriffen aus dem Web zu schützen. Azure Web Application Firewall (WAF) ist die Webanwendungsfirewall von Azure und bietet einen zentralisierten Schutz vor häufigen Web-Exploits und Sicherheitsrisiken.

Beispiel: Contoso Fiber hat sich aufgrund der folgenden Vorteile für Web Application Firewall entschieden:

• Globaler Schutz: Web Application Firewall bietet gesteigerten globalen Web-App-Schutz ohne Leistungsbeeinträchtigung.

• Botnet-Schutz: Sie können Botschutzregeln für die Überwachung auf Botnet-Angriffe konfigurieren.

• Parität mit der lokalen Umgebung: Die lokale Lösung wurde hinter einer Web Application Firewall ausgeführt, die von der IT verwaltet wurde.

Geheimnisverwaltung

Verwenden Sie Azure Key Vault, wenn Sie geheime Schlüssel in Azure verwalten müssen.

Beispiel: Contoso Fiber muss Geheimnisse verwalten. Das Unternehmen hat sich aus den folgenden Gründen für Key Vault entschieden:

• Verschlüsselung Sie unterstützt die Verschlüsselung im Ruhezustand und während der Übertragung.

• Unterstützung verwalteter Identitäten: Die Anwendungsdienste können verwaltete Identitäten verwenden, um auf den Geheimnisspeicher zuzugreifen.

• Überwachung und Protokollierung: Sie erleichtert den Überwachungszugriff und generiert Warnungen, wenn sich gespeicherte Geheimnisse ändern.

• Integration. Sie unterstützt zwei Methoden für den Zugriff der Web-App auf Geheimnisse. Contoso Fiber kann die App-Einstellungen der Hostingplattform verwenden (App Service) oder das Geheimnis im Anwendungscode (App-Eigenschaftendatei) referenzieren.

Endpunktsicherheit

Legen Sie fest, ob der ausschließlich private Zugriff auf Azure-Dienste aktiviert werden soll. Azure Private Link stellt den Zugriff auf Platform-as-a-Service-Lösungen über einen privaten Endpunkt in Ihrem virtuellen Netzwerk bereit. Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Dienst wird über das Microsoft-Backbone-Netzwerk übertragen.

Beispiel: Contoso Fiber hat sich aus den folgenden Gründen für Private Link entschieden:

• Erhöhte Sicherheit. Private Link ermöglicht den privaten Zugriff der Anwendung auf Dienste in Azure und verkleinert den Netzwerkfußabdruck von Datenspeichern zum Schutz vor Datenlecks.

• Minimaler Aufwand: Private Endpunkte unterstützen die von der Web-App verwendete Webanwendungsplattform und Datenbankplattform. Beide Plattformen spiegeln das vorhandene lokale Setup wider, sodass nur minimale Änderungen erforderlich sind.

Wählen Sie eine geeignete Architektur aus.

Nachdem Sie definiert haben, was verfügbar für Ihre Web-App bedeutet, und geeignete Clouddienste ausgewählt haben, müssen Sie die Architektur ermitteln, die für Ihre Web-App am besten geeignet ist. Ihre Architektur muss Ihre geschäftlichen Anforderungen, Ihre technischen Anforderungen und Ihr Servicelevel-Ziel unterstützen.

Legen Sie die Architekturredundanz fest.

Die geschäftlichen Ziele bestimmen die Ebene der Infrastruktur- und Datenredundanz, die Ihre Web-App benötigt. Das Web-App-SLO bietet einen guten Ausgangspunkt, um Ihre Redundanzanforderungen besser zu verstehen. Berechnen Sie das zusammengesetzte SLA-Niveau anhand aller Abhängigkeiten auf dem kritischen Pfad der Verfügbarkeit. Die Abhängigkeiten müssen Azure-Dienste und Lösungen umfassen, die nicht von Microsoft stammen.

Weisen Sie jeder Abhängigkeit eine Verfügbarkeitsschätzung zu. Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) bieten einen guten Ausgangspunkt. SLAs berücksichtigen jedoch keinen Code, keine Bereitstellungsstrategien und keine Konnektivitätsentscheidungen für die Architektur.

Beispiel: Die Referenzimplementierung verwendet zwei Regionen in einer Aktiv-Passiv-Konfiguration. Contoso Fiber strebte ein SLO von 99,9 % an und benötigte zwei Regionen, um dieses SLO zu erreichen. Die Aktiv-Passiv-Konfiguration entspricht dem Ziel von Contoso Fiber, in dieser Phase der Cloud-Journey nur minimale Codeänderungen vornehmen zu müssen. Die Aktiv/Passiv-Konfiguration bietet eine einfache Datenstrategie. Sie vermeidet, dass ereignisbasierte Datensynchronisierung, Datenshards oder eine andere Datenverwaltungsstrategie eingerichtet werden müssen. Der gesamte eingehende Datenverkehr wird in die aktive Region geleitet. Wenn es in der aktiven Region zu einem Ausfall kommt, kann Contoso Fiber seinen Failoverplan manuell auslösen und den gesamten Datenverkehr zur passiven Region leiten.

Wählen Sie eine Netzwerktopologie aus.

Wählen Sie die richtige Netzwerktopologie für Ihre Web- und Netzwerkanforderungen aus. Die Hub-Spoke-Netzwerktopologie ist die Standardkonfiguration in Azure. Sie bietet Vorteile in Bezug auf Kosten, Verwaltung und Sicherheit. Außerdem werden hybride Konnektivitätsoptionen für lokale Netzwerke unterstützt.

Beispiel: Contoso Fiber entschied sich für eine Hub-Spoke-Netzwerktopologie, um die Sicherheit der multiregionalen Bereitstellung bei gleichzeitiger Reduzierung von Kosten und Verwaltungsaufwand zu erhöhen.

Wählen Sie die Datenredundanz aus.

Stellen Sie die Zuverlässigkeit der Daten sicher, indem Sie die Daten über die Regionen und Verfügbarkeitszonen von Azure verteilen. Je größer die geografische Trennung, desto höher ist die Zuverlässigkeit.

• Legen Sie eine Wiederherstellungspunktvorgabe (Recovery Point Objective, RPO) fest. Der RPO-Wert definiert den maximalen tolerierbaren Datenverlust während eines Ausfalls und zeigt an, wie häufig Daten repliziert werden müssen. Beispielsweise bedeutet ein RPO-Wert von einer Stunde, dass Datenverluste entsprechend einer Stunde Dauer akzeptiert werden.

• Implementieren Sie eine Datenreplikation. Richten Sie die Datenreplikation an Ihrer Architektur und Ihrem RPO-Wert aus. Azure unterstützt in der Regel die synchrone Replikation innerhalb von Verfügbarkeitszonen. Nutzen Sie mehrere Zonen, um die Zuverlässigkeit auf einfache Weise zu verbessern. Replizieren Sie Daten für multiregionale Web-Apps in einer Aktiv-Passiv-Konfiguration zur passiven Region gemäß dem RPO-Wert der Web-App, um sicherzustellen, dass die Replikationshäufigkeit den RPO-Wert überschreitet. Aktiv-Aktiv-Konfigurationen erfordern eine Datensynchronisierung nahezu in Echtzeit über alle Regionen, was möglicherweise Codeanpassungen erfordert.

• Erstellen Sie einen Failoverplan. Entwickeln Sie einen Failoverplan (für die Notfallwiederherstellung), der die Reaktionsstrategien bei Ausfällen beschreibt, die durch Ausfallzeiten oder Funktionsverluste verursacht werden. Geben Sie die Ziele für die Wiederherstellungszeit (Recovery Time Objectives, RTO) in Bezug auf die maximal akzeptable Ausfallzeit an. Stellen Sie sicher, dass der Failoverprozess in kürzerer Zeit als der RTO-Wert ausgeführt wird. Entscheiden Sie sich für automatisierte oder manuelle Failovermechanismen hinsichtlich Konsistenz und Kontrolle, und geben Sie die Rückkehr zur normalen Ausführung an. Testen Sie den Failoverplan, um die Effektivität sicherzustellen.

Beispiel: Die Referenzimplementierung verwendet für Azure Database for PostgreSQL eine zonenredundante Hochverfügbarkeit mit Standbyservern in zwei Verfügbarkeitszonen. Die Datenbank wird darüber hinaus asynchron zum Lesereplikat in der passiven Region repliziert.

Nächster Schritt

In diesem Artikel haben Sie erfahren, wie Sie die Implementierung des zuverlässigen Web-App-Musters planen. Der nächste Schritt besteht in der Anwendung der Implementierungstechniken des zuverlässigen Web-App-Musters.