Muster mit geografischen Knoten

Das Muster mit geografischen Knoten umfasst die Bereitstellung einer Sammlung mit Back-End-Diensten für mehrere geografische Knoten (Englisch: „Geodes“, abgeleitet von „geographical nodes“), von denen jeweils die Anforderungen von Clients einer beliebigen Region verarbeitet werden können. Dieses Muster ermöglicht die Bereitstellung von Anforderungen im Aktiv/Aktiv-Stil, um die Latenz zu verbessern und die Verfügbarkeit zu erhöhen, indem die Verarbeitung der Anforderungen weltweit verteilt wird.

Kontext und Problem

Für viele größere Dienste müssen besondere Anforderungen in Bezug auf die geografische Verfügbarkeit und die Skalierbarkeit erfüllt werden. Bei klassischen Entwürfen werden Daten häufig für die Computeumgebung bereitgestellt, indem sie auf einem Remotecomputer mit SQL Server gespeichert werden, der als Computeebene für diese Daten dient. Bei einer Zunahme der Daten wird dann entsprechend hochskaliert.

Beim klassischen Ansatz können sich ggf. die folgenden Probleme ergeben:

• Probleme aufgrund von Netzwerklatenz für Benutzer, die von weit entfernten Standorten eine Verbindung mit dem Hostingendpunkt herstellen
• Verwaltung des Datenverkehrs für Bedarfsspitzen, die zu einer Überlastung der Dienste einer Region führen können
• Aus Kostensicht zu hohe Komplexität bei der Bereitstellung von Exemplaren der App-Infrastruktur in mehreren Regionen für einen rund um die Uhr verfügbaren Dienst

Die moderne Cloudinfrastruktur wurde weiterentwickelt, um einen geografischen Lastenausgleich für Front-End-Dienste zu ermöglichen, während für Back-End-Dienste die geografische Replikation erfolgen kann. Wenn Daten näher beim Benutzer angeordnet werden können, fördert dies die Verfügbarkeit und Leistung. Wenn Daten geografisch auf eine weit verstreute Benutzerbasis verteilt sind, sollten die geografisch verteilten Datenspeicher ebenfalls mit den Computeressourcen zusammengefasst werden, von denen die Daten verarbeitet werden. Beim Muster mit geografischen Knoten werden die Computeressourcen in der Nähe der Daten angeordnet.

Lösung

Richten Sie für den Dienst mehrere Satellitenbereitstellungen ein, die weltweit verteilt sind. Diese Bereitstellungen werden jeweils als Geode (geografischer Knoten) bezeichnet. Beim Muster mit geografischen Knoten werden wichtige Features von Azure genutzt, um Datenverkehr über den kürzesten Pfad an einen geografischen Knoten in der Nähe weiterzuleiten, um die Latenz und Leistung zu verbessern. Jeder geografische Knoten ist hinter einem globalen Lastenausgleich angeordnet, und es wird ein geografisch replizierter Lese-/Schreibdienst wie Azure Cosmos DB genutzt, um die Datenebene zu hosten und für die geografischen Knoten so die Einheitlichkeit der Daten sicherzustellen. Mit den Datenreplikationsdiensten wird sichergestellt, dass Datenspeicher für alle geografischen Knoten identisch sind, damit alle Anforderungen von allen geografischen Knoten aus bereitgestellt werden können.

Der Hauptunterschied zwischen einem Bereitstellungsstempel und einem geografischen Knoten ist, dass geografische Knoten niemals nur einzeln vorhanden sind. Eine Produktionsplattform sollte immer mehr als einen geografischen Knoten umfassen.

Geografische Knoten verfügen über die folgenden Merkmale:

• Sie umfassen unterschiedliche Arten von Ressourcen, die häufig in einer Vorlage definiert sind.
• Sie weisen keine externen Abhängigkeiten auf und sind eigenständig. Die einzelnen geografischen Knoten sind, was den Betrieb betrifft, nicht voneinander abhängig, und wenn ein Knoten ausfällt, sind die anderen davon nicht betroffen.
• Sie sind über ein Edgenetzwerk und eine Replikationsebene lose miteinander gekoppelt. Sie können beispielsweise Azure Traffic Manager oder Azure Front Door als Front-End für die geografischen Knoten nutzen, während Azure Cosmos DB als Replikationsebene im Hintergrund fungiert. Geografische Knoten unterscheiden sich von Clustern, weil sie über eine Replikationsebene verfügen und so dafür gesorgt ist, dass Quorumprobleme von der Plattform gelöst werden.

Das Muster mit geografischen Knoten wird in Big Data-Architekturen genutzt, für die Standardhardware zum Verarbeiten der Daten verwendet wird, die sich auf demselben Computer befinden. MapReduce wird genutzt, um die Ergebnisse übergreifend für die Computer zusammenzufassen. Eine andere Art der Nutzung ist die Anordnung von Computeressourcen in der Nähe des Edgebereichs, um diese näher am intelligenten Edgebereich des Netzwerks zu platzieren und so die Antwortzeit zu reduzieren.

Von Diensten kann dieses Muster über Dutzende oder Hunderte von geografischen Knoten hinweg verwendet werden. Darüber hinaus erhöht sich die Resilienz der gesamten Lösung mit jedem hinzugefügten geografischen Knoten, weil die Aufgaben von jedem anderen geografischen Knoten übernommen werden können, falls bei einem regionalen Ausfall einer oder mehrere geografische Knoten in den Offlinezustand versetzt werden.

Es ist auch möglich, die Verfahren für die lokale Verfügbarkeit zu verbessern, z. B. Verfügbarkeitszonen oder Regionspaare, indem das Muster mit geografischen Knoten zur Erzielung von globaler Verfügbarkeit genutzt wird. Diese Vorgehensweise erhöht zwar die Komplexität, aber sie ist hilfreich, wenn Ihre Architektur auf einer Speicher-Engine basiert, z. B. Blobspeicher, der nur in einer Region eines Regionspaars repliziert werden kann. Sie können geografische Knoten in einer Zone, zonenübergreifend oder regional bereitstellen, um die Bestimmungen oder latenzbezogenen Einschränkungen des jeweiligen Standorts zu berücksichtigen.

Probleme und Überlegungen

Verwenden Sie die folgenden Verfahren und Technologien, um dieses Muster zu implementieren:

• Moderne DevOps-Methoden und -Tools, um identische geografische Knoten für eine große Zahl von Regionen oder Instanzen zu erstellen und in kurzer Zeit bereitzustellen.
• Automatische Skalierung zum Aufskalieren von Compute- und Datenbankdurchsatz-Instanzen innerhalb eines geografischen Knotens. Jeder geografische Knoten wird einzeln aufskaliert, indem die Einschränkungen der gemeinsamen Hintergrundebene beachtet werden.
• Es wird ein Front-End-Dienst wie Azure Front Door für die dynamische Inhaltsbeschleunigung, geteiltes TCP und Anycast-Routing verwendet.
• Es wird ein Replikationsdatenspeicher wie Azure Cosmos DB genutzt, um die Datenkonsistenz zu steuern.
• Nach Möglichkeit werden serverlose Technologien eingesetzt, um die Kosten für Always On-Bereitstellungen zu reduzieren. Dies gilt vor allem, wenn die Auslastung häufig neu weltweit verteilt wird. Bei dieser Strategie können viele geografische Knoten mit geringem zusätzlichem Investitionsaufwand bereitgestellt werden. Mit serverlosen und verbrauchsbasierten Abrechnungstechnologien werden überflüssige Kapazitäten und Kosten reduziert, die aufgrund von doppelten geografisch verteilten Bereitstellungen entstehen.
• API Management ist zwar für die Implementierung des Entwurfsmusters nicht erforderlich, kann aber jedem geografischen Knoten hinzugefügt werden, der der Azure-Funktions-App der Region vorgeschaltet ist, um eine stabilere API-Ebene zu bieten, was die Implementierung zusätzlicher Funktionen wie etwa der Ratenbegrenzung ermöglicht.

Beachten Sie die folgenden Punkte bei der Entscheidung, wie dieses Muster implementiert werden soll:

• Geben Sie an, ob Daten lokal in jeder Region verarbeitet oder Aggregationen nur innerhalb eines geografischen Knotens mit anschließender weltweiter Replikation des Ergebnisses verteilt werden sollen. Der Änderungsfeedprozessor von Azure Cosmos DB ermöglicht diese präzise Steuerung über das Leasecontainer-Konzept und das leasecollectionprefix-Element in der entsprechenden Azure Functions-Bindung. Jeder Ansatz ist mit anderen Vor- und Nachteilen verbunden.
• Geografische Knoten können zusammenarbeiten, indem der Azure Cosmos DB-Änderungsfeed und eine Plattform für die Echtzeitkommunikation wie SignalR verwendet wird. Geografische Knoten können mit Remotebenutzern über andere geografische Knoten eines Meshmusters kommunizieren, ohne zu wissen bzw. sich darum zu kümmern, wo sich der Remotebenutzer befindet.
• Bei diesem Entwurfsmuster werden alle Komponenten implizit entkoppelt. Dies führt zu einer äußerst stark verteilten und entkoppelten Architektur. Überlegen Sie sich, wie Sie unterschiedliche Komponenten der gleichen Anforderung nachverfolgen können, da diese unter Umständen asynchron in verschiedenen Instanzen ausgeführt werden. Eine geeignete Überwachungsstrategie ist entscheidend. Sowohl Azure Front Door als auch Azure Cosmos DB können problemlos in Log Analytics integriert werden, und Azure Functions sollte parallel zu Application Insights bereitgestellt werden, um ein stabiles Überwachungssystem für jede Komponente in der Architektur bereitzustellen.
• Bei verteilten Bereitstellungen sind mehr Geheimnisse und Zugangspunkte vorhanden, die angemessene Sicherheitsmaßnahmen erfordern. Key Vault bietet eine sichere Ebene für die Geheimnisverwaltung, und jede Ebene innerhalb der API-Architektur muss ordnungsgemäß geschützt werden, sodass der Front-End-Dienst (beispielsweise Azure Front Door) der einzige Zugangspunkt für die API ist. Datenverkehr von Azure Cosmos DB an Azure-Funktions-Apps und von Funktions-Apps an Azure Front Door muss eingeschränkt werden – entweder mithilfe von Microsoft Entra ID oder mithilfe von Methoden wie IP-Einschränkung.
• Die Leistung hängt stark von der Anzahl bereitgestellter geografischer Knoten sowie von den spezifischen App Service-Plänen ab, die auf die API-Technologie der jeweiligen geografischen Knoten angewendet werden. Die Bereitstellung zusätzlicher geografischer Knoten oder der Wechsel zu Premium-Tarifen führt zu höheren Kosten für den zusätzlichen Arbeitsspeicher- und die Computeressourcen, aber nicht für die einzelnen Transaktionen. Führen Sie nach der Bereitstellung ggf. einen Auslastungstest für die API-Architektur durch, und vergleichen Sie die Erhöhung der Anzahl geografischer Knoten mit der Erhöhung des Tarifs, um das kostengünstigste Modell für Ihre Anforderungen zu ermitteln.
• Bestimmen Sie die Verfügbarkeitsanforderungen für Ihre Daten. Azure Cosmos DB verfügt über optionale Flags, um Verfügbarkeitszonen, Schreibvorgänge in mehreren Regionen und Ähnliches zu aktivieren. Diese erhöhen zwar die Verfügbarkeit für die Azure Cosmos DB-Instanz sowie die Resilienz der Datenschicht, sind aber auch mit zusätzlichen Kosten verbunden.
• Azure bietet verschiedene Lastenausgleichsmodule mit jeweils unterschiedlichen Funktionen für die Verteilung des Datenverkehrs. Verwenden Sie die Entscheidungsstruktur, um die richtige Option für das Front-End Ihrer API zu finden.

Verwendung dieses Musters

Verwenden Sie dieses Muster in folgenden Fällen:

• Implementierung einer umfassenden Plattform, deren Benutzer weit verstreut sind
• Für alle Dienste mit hohen Anforderungen an die Verfügbarkeit und Resilienz, da auf dem Muster mit geografischen Knoten basierende Dienste den gleichzeitigen Ausfall mehrerer Dienstregionen überstehen können

Dieses Muster ist für die folgendem Fälle unter Umständen nicht geeignet:

• Architekturen mit Einschränkungen, sodass nicht alle geografischen Knoten gleichermaßen für die Datenspeicherung genutzt werden können. Beispielsweise können „Data Residency“-Anforderungen bestehen, für eine Anwendung muss für eine bestimmte Sitzung ein vorübergehender Zustand aufrechterhalten werden, oder für eine bestimmte Region fallen sehr viele Anforderungen an. In diesem Fall sollten Sie die Nutzung von Bereitstellungsstempeln in Verbindung mit einer globalen Routingebene erwägen, die über den Speicherort der Daten eines Benutzers informiert ist. Dies kann beispielsweise die Komponente für Datenverkehrsrouting sein, die unter Muster mit Bereitstellungsstempeln beschrieben ist.
• Situationen, in denen keine geografische Verteilung erforderlich ist. Erwägen Sie stattdessen die Verwendung von Verfügbarkeitszonen und Regionspaaren für das Clustering.
• Situationen, in denen eine Legacy-Plattform nachgerüstet werden muss. Dieses Muster ist nur für die cloudnative Entwicklung geeignet, und die Nachrüstung kann sich schwierig gestalten.
• Einfache Architekturen und Anforderungen, bei denen die Georedundanz und geografische Verteilung nicht erforderlich oder vorteilhaft sind.

Workloadentwurf

Ein Architekt sollte evaluieren, wie das Geode-Muster im Design seiner Workloads verwendet werden kann, um die Ziele und Prinzipien zu erreichen, die in den Azure Well-Architected Framework-Säulen behandelt werden. Zum Beispiel:

Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.

Beispiele

• Mit Windows Active Directory wird eine frühe Variante dieses Musters implementiert. Die Multiprimärreplikation bedeutet, dass alle Updates und Anforderungen theoretisch von allen wartbaren Knoten bereitgestellt werden können, während FSMO-Rollen (Flexible Single Master Operation) bedeuten, dass nicht alle Geoknoten gleich sind.
• Der Accelerator für das Geoknotenmuster auf GitHub zeigt dieses Entwurfsmuster in der Praxis und hilft Entwicklern bei der Implementierung mit echten APIs.