Datenplattform für unternehmenskritische Arbeitsauslastungen in Azure

In einer unternehmenskritischen Architektur muss jeder Zustand außerhalb des Compute so viel wie möglich gespeichert werden. Die Auswahl der Technologie basiert auf diesen wichtigsten architektonischen Merkmalen:

In dieser Architektur gibt es zwei Datenspeicher:

• Datenbank

  Speicher im Zusammenhang mit der Arbeitslast. Es wird empfohlen, den gesamten Zustand global in einer Datenbank zu speichern, die von regionalen Stempeln getrennt ist. Erzeugen Sie Redundanz, indem Sie die Datenbank regionsübergreifend bereitstellen. Bei unternehmenskritischen Workloads sollte die regionsübergreifende Synchronisierung von Daten das wichtigste Anliegen sein. Auch im Falle eines Ausfalls sollten Schreibanforderungen an die Datenbank weiterhin funktionsfähig sein.

  Datenreplikation in einer Aktiv/Aktiv-Konfiguration wird sehr empfohlen. Die Anwendung sollte in der Lage sein, sofort eine Verbindung mit einer anderen Region herzustellen. Alle Instanzen sollten in der Lage sein, Lese- und Schreibanforderungen zu verarbeiten.

• Nachrichtenbroker

  Der einzige zustandsbehaftete Dienst im regionalen Stempel ist der Nachrichtenbroker, der Anforderungen für einen kurzen Zeitraum speichert. Der Broker bedient den Bedarf für Pufferung und zuverlässiges Messaging. Die verarbeiteten Anforderungen werden persistent in der globalen Datenbank gespeichert.

Weitere Überlegungen zu Daten finden Sie unter Unternehmenskritische Anleitungen im Well-Architected Framework: Überlegungen zur Datenplattform.

Datenbank

Diese Architektur verwendet Azure Cosmos DB for NoSQL. Diese Option wird ausgewählt, weil sie die meisten Features bietet, die in diesem Design benötigt werden:

• Schreiben in mehreren Regionen

  Multiregion-Schreibzugriff ist für Replikate aktiviert, die in jeder Region bereitgestellt sind, in der ein Stempel bereitgestellt ist. Jeder Stempel kann lokal schreiben, und Azure Cosmos DB übernimmt die Datenreplikation und Synchronisierung zwischen den Stempeln. Diese Funktion verringert die Wartezeit für geografisch verteilte Endbenutzer der Anwendung erheblich. Die Azure-Mission-Critical-Referenzimplementierung verwendet multimaster-Technologie, um maximale Resilienz und Verfügbarkeit bereitzustellen.

  Zonenredundanz ist auch innerhalb jeder replizierten Region aktiviert.

  Ausführliche Informationen zu Schreibvorgängen in mehreren Regionen finden Sie unter Konfigurieren von Schreibvorgängen in mehreren Regionen in Ihren Anwendungen, die Azure Cosmos DB verwenden.

• Konfliktmanagement

  Mit der Möglichkeit, Schreibvorgänge in mehreren Regionen auszuführen, kommt die Notwendigkeit auf, ein Konfliktmanagementmodell zu übernehmen, da gleichzeitige Schreibvorgänge Datensatzkonflikte einführen können. Last Writer Wins ist das Standardmodell und wird für das Mission Critical-Design verwendet. Der letzte Autor, wie durch die zugeordneten Zeitstempel der Datensätze definiert, gewinnt den Konflikt. Azure Cosmos DB for NoSQL ermöglicht zudem die Definition einer benutzerdefinierten Eigenschaft.

• Abfrageoptimierung

  Eine allgemeine Abfrageeffizienzempfehlung für Lese-Heavy-Container mit einer hohen Anzahl von Partitionen besteht darin, einen Gleichheitsfilter mit der identifizierten ItemID hinzuzufügen. Eine ausführliche Überprüfung der Abfrageoptimierungsempfehlungen finden Sie unter Problembehandlung von Abfrageproblemen bei Verwendung von Azure Cosmos DB.

• Sicherungsfunktion

  Es wird empfohlen, das native Sicherungsfeature von Azure Cosmos DB für den Schutz von Daten zu verwenden. Das Sicherungsfeature von Azure Cosmos DB unterstützt Onlinesicherungen und die Wiederherstellung von Daten nach Bedarf.

Datenmodell für die Arbeitsauslastung

Das Datenmodell sollte so gestaltet sein, dass die Features, die herkömmliche relationale Datenbanken bieten, nicht benötigt werden. Beispielsweise Fremdschlüssel, strenge Zeilen-/Spaltenschemas, Ansichten und andere.

Die Workload weist die folgenden Datenzugriffsmerkmale auf:

• Lesemuster:
  • Punktlesevorgänge – Abrufen eines einzelnen Datensatzes. Element-ID und den Partitionsschlüssel werden direkt zur maximalen Optimierung verwendet (1 RU pro Anforderung).
  • Listenlesevorgänge – Abrufen von Katalogelementen zur Anzeige in einer Liste. FeedIterator mit Begrenzung der Anzahl der Ergebnisse wird verwendet.
• Schreibmuster:
  • Kleine Schreibvorgänge – Anforderungen fügen in der Regel einen einzelnen oder eine kleine Anzahl von Datensätzen in eine Transaktion ein.
• Entwickelt für hohen Datenverkehr von Endbenutzern mit der Fähigkeit zur Skalierung, um einen Datenverkehr in der Größenordnung von Millionen von Benutzern zu bewältigen.
• Geringe Nutzdaten- oder Datasetgröße – in der Regel in der Größenordnung von KB.
• Geringe Antwortzeit (in der Größenordnung von Millisekunden).
• Geringe Wartezeit (in der Größenordnung von Millisekunden).

Konfiguration

Azure Cosmos DB ist wie folgt konfiguriert:

• Die Konsistenzebene ist auf die standardmäßige Sitzungskonsistenz festgelegt, da dies die am häufigsten verwendete Ebene für einzelne Regionen und global verteilte Anwendungen ist. Schwächere Konsistenz mit höherem Durchsatz ist aufgrund der asynchronen Natur der Schreibverarbeitung nicht erforderlich und erfordert keine geringe Wartezeit beim Schreiben in die Datenbank.

  Hinweis

  Die Session-Konsistenzebene bietet einen angemessenen Kompromiss hinsichtlich der Garantien für Wartezeit, Verfügbarkeit und Konsistenz für diese spezifische Anwendung. Es ist wichtig zu verstehen, dass die Konsistenzebene Strong (stark) für Multimaster-Schreibdatenbanken nicht verfügbar ist.

• Der Partitionsschlüssel ist für alle Sammlungen auf /id festgelegt. Diese Entscheidung basiert auf dem Verwendungsmuster, das hauptsächlich aus „Schreiben neuer Dokumente mit GUID als ID“ und „Lesen einer Vielzahl von Dokumenten anhand von IDs“ besteht. Unter der Voraussetzung, dass der Code der Anwendung seine ID-Eindeutigkeit beibehält, werden neue Daten von Azure Cosmos DB gleichmäßig in Partitionen verteilt. Dadurch wird eine unbegrenzte Skalierung ermöglicht.

• Die Indizierungsrichtlinie wird für Sammlungen konfiguriert, um Abfragen zu optimieren. Zur Optimierung der RU-Kosten und der Leistung wird eine benutzerdefinierte Indizierungsrichtlinie verwendet. Diese Richtlinie indiziert nur die Eigenschaften, die in Abfrageprädikaten verwendet werden. Die Anwendung verwendet z. B. das Kommentar-Textfeld nicht als Filter in Abfragen. Es wurde von der Richtlinie zur benutzerdefinierten Indizierung ausgeschlossen.

Hier ist ein Beispiel aus der Implementierung, das zeigt, wie Sie die Richtlinien für die Indizierung mithilfe von Terraform festlegen:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Informationen zur Verbindung zwischen der Anwendung und Azure Cosmos DB in dieser Architektur finden Sie unter Überlegungen zur Anwendungsplattform für unternehmenskritische Workloads.

Messagingdienste

Unternehmenskritische Systeme nutzen häufig Messaging-Dienste für die Nachrichten- oder Ereignisverarbeitung. Diese Dienste fördern die lose Kopplung und dienen als Puffer, der das System vor unerwarteten Nachfragespitzen isoliert.

• Azure Service Bus wird bei der Behandlung von nachrichtenbasierten Arbeitsauslastungen bei der Behandlung hochwertiger Nachrichten empfohlen.
• Azure Event Hubs wird für ereignisbasierte Systeme empfohlen, die hohe Mengen von Ereignissen oder Telemetrie verarbeiten.

Im Folgenden finden Sie Designaspekte und Empfehlungen für Azure Service Bus Premium und Azure Event Hubs in einer unternehmenskritischen Architektur.

Handlelast

Das Messagingsystem muss in der Lage sein, den erforderlichen Durchsatz (wie in MB pro Sekunde) zu verarbeiten. Beachten Sie Folgendes:

• Die nicht funktionalen Anforderungen (NFRs) des Systems sollten die durchschnittliche Nachrichtengröße angeben, und die Spitzenanzahl von Nachrichten/Sekunde muss jeder Stempel unterstützen. Diese Informationen können verwendet werden, um den erforderlichen Höchstwert MB/Sekunde pro Stempel zu berechnen.
• Die Auswirkungen eines Failovers müssen bei der Berechnung des erforderlichen Höchstwerts MB/Sekunde pro Stempel berücksichtigt werden.
• Für Azure Service Bus sollten die NFRs alle erweiterten Dienstbusfeatures wie Sitzungen und Dedupingnachrichten angeben. Diese Features wirken sich auf den Durchsatz von Service Bus aus.
• Der Durchsatz von Service Bus mit den erforderlichen Features sollte durch Tests als MB/Sekunde pro Messagingeinheit (MU) berechnet werden. Weitere Informationen zu diesem Thema finden Sie unter Service Bus Premium- und Standard-Preisstufe für Messaging.
• Der Durchsatz von Azure Event Hubs sollte durch Tests als MB/Sekunde pro Durchsatzeinheit (TU) für die Standardstufe oder Verarbeitungseinheit (PU) für die Premium-Stufe berechnet werden. Weitere Informationen zu diesem Thema finden Sie unter Skalierung mit Event Hubs.
• Die obigen Berechnungen können verwendet werden, um zu überprüfen, ob der Messagingdienst die erforderliche Last pro Stempel verarbeiten kann, und die erforderliche Anzahl von Skalierungseinheiten, die erforderlich sind, um diese Last zu erfüllen.
• Im Abschnitt "Vorgänge" wird die automatische Skalierung erläutert.

Jede Nachricht muss verarbeitet werden

Azure Service Bus Premium-Stufe ist die empfohlene Lösung für hochwertige Nachrichten, für die die Verarbeitung garantiert werden muss. Im Folgenden sind Details zu dieser Anforderung aufgeführt, wenn Azure Service Bus Premium verwendet wird:

• Um sicherzustellen, dass Nachrichten ordnungsgemäß an den Broker übertragen und akzeptiert werden, sollten Nachrichtenersteller einen der unterstützten Service Bus-API-Clients verwenden. Unterstützte APIs werden nur erfolgreich von einem Sendevorgang zurückgegeben, wenn die Nachricht in der Warteschlange/im Thema beibehalten wurde.

• Um sicherzustellen, dass Nachrichten im Bus verarbeitet werden, sollten Sie den PeekLock-Empfangsmodus verwenden. Dieser Modus aktiviert mindestens einmalige Verarbeitung. Nachfolgend wird der Prozess umschrieben:

  • Der Nachrichten-Consumer empfängt die zu verarbeitende Nachricht.
  • Der Consumer erhält eine exklusive Sperre für die Nachricht für eine bestimmte Zeitdauer.
  • Wenn der Consumer die Nachricht erfolgreich verarbeitet, sendet er eine Bestätigung zurück an den Broker, und die Nachricht wird aus der Warteschlange entfernt.
  • Wenn eine Bestätigung nicht vom Broker im zugewiesenen Zeitraum empfangen wird, oder der Handler die Nachricht explizit verlässt, wird die exklusive Sperre freigegeben. Die Nachricht ist dann für andere Consumer verfügbar, um die Nachricht zu verarbeiten.
  • Wenn eine Nachricht nicht erfolgreich eine konfigurierbare Anzahl von Durchgängen verarbeitet oder der Handler die Nachricht an die Warteschlange für unzustellbare Nachrichten weiterleitet.
    • Um sicherzustellen, dass Nachrichten, die an die Warteschlange für unzustellbare Nachrichten gesendet werden, bearbeitet werden, sollte die Unzustellbarwarteschlange überwacht werden, und Warnungen sollten festgelegt werden.
    • Das System sollte Tools für Operatoren umfassen, die das Untersuchen, Korrigieren und erneute Senden von Nachrichten ermöglichen.

• Da Nachrichten möglicherweise mehr als einmal verarbeitet werden können, sollten Nachrichtenhandler idempotent erstellt werden.

Idempotente Nachrichtenverarbeitung

In RFC 7231 gibt das Hypertext Transfer-Protokoll Folgendes an: „Eine Anforderungsmethode wird als idempotent betrachtet, wenn die beabsichtigte Auswirkung, die mehrere identische Anforderungen mit dieser Methode auf den Server haben, der Auswirkung einer einzelnen Anforderung dieser Art entspricht.“

Eine gängige Methode zum Festlegen der Nachrichtenverarbeitung als idempotent besteht darin, einen beständigen Speicher wie eine Datenbank daraufhin zu überprüfen, ob die Nachricht bereits verarbeitet wurde. Ist dies der Fall, wird die Logik nicht erneut ausgeführt, um sie noch einmal zu verarbeiten.

• Möglicherweise gibt es Situationen, in denen die Verarbeitung der Nachricht Datenbankvorgänge beinhaltet, insbesondere das Einfügen neuer Datensätze mit von der Datenbank generierten Bezeichnern. Neue Nachrichten, die diese Bezeichner enthalten, können an den Broker gesendet werden. Da keine verteilten Transaktionen vorhanden sind, die sowohl die Datenbank als auch den Nachrichtenbroker umfassen, kann eine Reihe von Komplikationen auftreten, wenn der den Code ausführende Prozess fehlschlägt. Sehen Sie sich die folgenden Beispielsituationen an:
  • Der Code, der die Nachrichten sendet, kann vor dem Committen der Datenbanktransaktion ausgeführt werden. Dies entspricht der Arbeitsweise vieler Entwickler nach dem Unit of Work-Muster. Diese Nachrichten können durchschlüpfen, wenn der Fehler zwischen dem Aufrufen des Brokers und dem Anfordern des Commits für die Datenbanktransaktion auftritt. Beim Rollback für die Transaktion werden auch diese von der Datenbank generierten IDs rückgängig gemacht, wodurch sie für andere Code verfügbar werden, der möglicherweise gleichzeitig ausgeführt wird. Dies kann dazu führen, dass Empfänger der durchgeschlüpften Nachrichten die falschen Datenbankeinträge verarbeiten, sodass die allgemeine Konsistenz und Richtigkeit Ihres Systems beeinträchtigt werden.
  • Wenn Entwickler den Code, der die Nachricht sendet, nach dem Abschluss der Datenbanktransaktion einfügen, kann der Prozess dennoch zwischen den Vorgängen zum Committen der Transaktion und dem Senden der Nachricht fehlschlagen. In diesem Fall wird die Nachricht erneut verarbeitet, aber dieses Mal stellt die Wächterklausel für Idempotenz anhand der in der Datenbank gespeicherten Daten fest, dass die Nachricht bereits verarbeitet wurde. Die Klausel überspringt die Nachricht, die den Code sendet, in dem Glauben, dass beim letzten Durchgang alles erfolgreich ausgeführt wurde. Nachgelagerte Systeme, die Benachrichtigungen über den abgeschlossenen Prozess erwarten, erhalten keine Nachricht. Diese Situation führt erneut zu einem inkonsistenten Gesamtzustand.
• Die Lösung für die oben genannten Probleme beinhaltet die Verwendung des Transaktionspostausgangs-Musters, bei dem die ausgehenden Nachrichten abseitig in demselben Transaktionsspeicher wie die Geschäftsdaten gespeichert werden. Die Nachrichten werden anschließend an den Nachrichtenbroker übermittelt, wenn die anfängliche Nachricht erfolgreich verarbeitet wurde.
• Da viele Entwickler nicht mit diesen Problemen oder den zugehörigen Lösungen vertraut sind, empfiehlt es sich, die Funktionalität des Postausgangs und die Interaktion mit dem Nachrichtenbroker in einer Art von Bibliothek zum umschließen, um eine konsistente Anwendung dieser Techniken in einem unternehmenskritischen System sicherzustellen. Alle Vorgänge zur Codeverarbeitung und zum Senden transaktionsrelevanter Nachrichten sollten diese Bibliothek nutzen, statt direkt mit dem Nachrichtenbroker zu interagieren.
  • Bibliotheken, die diese Funktionalität in .NET implementieren, sind beispielsweise NServiceBus und MassTransit.

Hochverfügbarkeit und Notfallwiederherstellung

Der Nachrichtenbroker muss für Produzenten verfügbar sein, um Nachrichten zu senden, und für Consumer, um sie zu empfangen. Nachfolgend die Details zu dieser Anforderung:

• Um die höchste Verfügbarkeit mit Service Bus sicherzustellen, verwenden Sie die Premium-Stufe, die Unterstützung für Verfügbarkeitszonen in unterstützenden Regionen hat. Mit Verfügbarkeitszonen werden Nachrichten und Metadaten in drei unterschiedlichen Rechenzentren in derselben Region repliziert.
• Verwenden Sie unterstützte Service Bus- oder Event Hubs-SDKs, um Lese- oder Schreibfehler automatisch erneut auszuführen.
• Erwägen Sie aktive Replikationsmuster oder aktiv-passive Replikationsmuster, um gegen regionale Katastrophen zu isolieren.

Überwachung

Das Messagingsystem fungiert als Puffer zwischen Nachrichtenerstellern und -consumern. Es gibt wichtige Indikatortypen, die Sie in einem unternehmenskritischen System überwachen sollten, das wertvolle Einblicke liefert, die unten beschrieben werden:

• Drosselung – Drosselung gibt an, dass das System nicht über die erforderlichen Ressourcen zum Verarbeiten der Anforderung verfügt. Sowohl Service Bus als auch Event Hubs unterstützen die Überwachung gedrosselter Anforderungen. Sie sollten auf diesem Indikator warnen.
• Warteschlangentiefe – Eine Warteschlangentiefe, die wächst, kann darauf hinweisen, dass Nachrichtenprozessoren nicht funktionieren oder es nicht genügend Prozessoren gibt, um die aktuelle Last zu verarbeiten. Die Warteschlangentiefe kann verwendet werden, um die Logik der automatischen Skalierung von Handlern zu informieren.
  • Für den Service Bus wird die Warteschlangentiefe als Nachrichtenanzahl verfügbar gemacht
  • Für Event Hubs müssen die Consumer die Warteschlangentiefe pro Partition berechnen und die Metrik an Ihre Überwachungssoftware übertragen. Für jeden Lesevorgang ruft der Consumer die Sequenznummer des aktuellen Ereignisses und die Ereigniseigenschaften des letzten in die Warteschlange eingereihten Ereignisses ab. Der Consumer kann den Offset berechnen.
• Warteschlange für unzustellbare Nachrichten – Nachrichten in der Warteschlange für unzustellbare Nachrichten stellen Nachrichten dar, die nicht verarbeitet werden konnten. Diese Nachrichten erfordern in der Regel manuelle Interventionen. Warnungen sollten in der Warteschlange für unzustellbare Nachrichten festgelegt werden.
  • Service Bus verfügt über eine Warteschlange für unzustellbare Nachrichten und eine DeadLetteredMessages-Metrik.
  • Für Event Hubs muss diese Funktionalität eine benutzerdefinierte Logik sein, die in den Consumer integriert ist.
• CPU/Arbeitsspeichernutzung – CPU und Arbeitsspeicher sollten überwacht werden, um sicherzustellen, dass das Messagingsystem über genügend Ressourcen verfügt, um die aktuelle Last zu verarbeiten. Sowohl Service Bus Premium als auch Event Hubs Premium machen CPU- und Arbeitsspeichernutzung verfügbar.
  • Messagingeinheiten (MUs) werden in Service Bus verwendet, um Ressourcen wie CPU und Arbeitsspeicher für einen Namespace zu isolieren. CPU und Arbeitsspeicher, der über einem Schwellenwert steigt, können darauf hinweisen, dass nicht genügend MUs konfiguriert sind, während unter andere Schwellenwerte zu fallen bedeutet, dass zu viele MUs konfiguriert sind. Diese Indikatoren können zum automatischen skalieren von MUs verwendet werden.
  • Event Hubs Premium-Ebene verwendet Verarbeitungseinheiten (PUs), um Ressourcen zu isolieren, während die Standardebene Durchsatzeinheiten (TUs) verwendet. Diese Ebenen erfordern keine Interaktion mit CPU/Arbeitsspeicher, um PUs oder TUs automatisch zu vergrößern.

Integritätsprüfung

Der Status des Messagingsystems muss in der Integritätsprüfung für eine unternehmenskritische Anwendung berücksichtigt werden. Berücksichtigen Sie die folgenden Faktoren:

• Das Messagingsystem fungiert als Puffer zwischen Nachrichtenerstellern und -consumern. Der Stempel kann als fehlerfrei angesehen werden, wenn Ersteller Nachrichten erfolgreich an den Broker senden und Consumer Nachrichten vom Broker erfolgreich verarbeiten können.
• Die Integritätsprüfung sollte sicherstellen, dass Nachrichten an das Nachrichtensystem gesendet werden können.

Nächste Schritte

Stellen Sie die Referenzimplementierung bereit, um ein umfassendes Verständnis der Ressourcen und ihrer Konfiguration in dieser Architektur zu erhalten.