Überlegungen zur Datenplattform für unternehmenskritische Workloads in Azure

Die Auswahl einer effektiven Anwendungsdatenplattform ist ein weiterer wichtiger Entscheidungsbereich, der weitreichende Auswirkungen auf andere Designbereiche hat. Azure bietet letztendlich eine Vielzahl relationaler, nicht relationaler und analytischer Datenplattformen, die sich stark in der Funktion unterscheiden. Daher ist es wichtig, dass wichtige nicht funktionale Anforderungen zusammen mit anderen Entscheidungsfaktoren wie Konsistenz, Operierbarkeit, Kosten und Komplexität vollständig berücksichtigt werden. Beispielsweise hat die Fähigkeit, in einer Mehrregion-Schreibkonfiguration zu arbeiten, eine wichtige Rolle bei der Eignung für eine global verfügbare Plattform.

Dieser Designbereich erweitert sich auf das Anwendungsdesign und bietet wichtige Überlegungen und Empfehlungen, um die Auswahl einer optimalen Datenplattform zu informieren.

Wichtig

Dieser Artikel ist Teil der Reihe der unternehmenskritischen Arbeitsauslastungen von Azure Well-Architected. Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit dem zu beginnen, was eine unternehmenskritische Workload ist?

Die vier Vs of Big Data

Das "Four Vs of Big Data" bietet ein Framework, um die erforderlichen Merkmale für eine hochverwendende Datenplattform besser zu verstehen und wie Daten verwendet werden können, um den Geschäftswert zu maximieren. In diesem Abschnitt wird daher erläutert, wie die Merkmale "Volume", "Velocity", "Variety" und "Veracity" auf konzeptioneller Ebene angewendet werden können, um die Entwicklung einer Datenplattform mithilfe geeigneter Datentechnologien zu unterstützen.

• Volume: Wie viele Daten zur Information der Speicherkapazität und der Ebenenanforderungen kommen – das ist die Größe des Datasets.
• Velocity: die Geschwindigkeit, mit der Daten verarbeitet werden, entweder als Batches oder fortlaufende Datenströme - das ist die Geschwindigkeit des Flusses.
• Vriety: Die Organisation und das Format von Daten, das Erfassen strukturierter, halbstrukturierter und unstrukturierter Formate – d. h. Daten über mehrere Speicher oder Typen hinweg.
• V-Eracity: umfasst die Provenienz und die Curation von betrachteten Datasets für Governance und Datenqualitätssicherung - das ist Genauigkeit der Daten.

Entwurfsaspekte

Volumen

• Vorhandene (falls vorhanden) und erwartete zukünftige Datenvolumen basierend auf prognostizierten Datenwachstumsraten, die mit den Geschäftszielen und -plänen übereinstimmen.

  • Das Datenvolumen sollte die Daten selbst und Indizes, Protokolle, Telemetrie und andere anwendbare Datasets umfassen.
  • Große unternehmenskritische Anwendungen generieren und speichern in der Regel täglich hohe Volumina (GB und TB).
  • Es kann erhebliche Kostenauswirkungen im Zusammenhang mit der Datenerweiterung geben.

• Das Datenvolumen kann aufgrund sich ändernder Geschäftsbedingungen oder Housekeeping-Verfahren schwanken.

• Das Datenvolumen kann sich erheblich auf die Leistung von Datenplattformabfragen auswirken.

• Das Erreichen der Volumengrenzwerte der Datenplattform kann tiefgreifende Auswirkungen haben.

  • Führt dies zu Ausfallzeiten? und wenn ja, wie lange?
  • Was sind die Gegenmaßnahmen? und erfordert die Entschärfung Anwendungsänderungen?
  • Besteht das Risiko eines Datenverlusts?

• Features wie Gültigkeitsdauer (Time to Live, TTL) können zur Verwaltung des Datenwachstums verwendet werden, indem Datensätze nach einer bestimmten Zeit automatisch gelöscht werden, entweder bei der Erstellung oder bei der Änderung von Datensätzen.

  • Azure Cosmos DB bietet beispielsweise eine integrierte TTL-Funktion.

Geschwindigkeit

• Die Geschwindigkeit, mit der Daten aus verschiedenen Anwendungskomponenten ausgegeben werden, und die Durchsatzanforderungen für die Geschwindigkeit des Commits und Abrufens von Daten sind entscheidend, um eine optimale Datentechnologie für wichtige Workloadszenarien zu ermitteln.

  • Die Art der Durchsatzanforderungen unterscheidet sich je nach Arbeitsauslastungsszenario, z. B. von Denen, die leselastig oder schreibgelastig sind.
    • Beispielsweise müssen analytische Workloads in der Regel auf einen großen Lesedurchsatz ausgerichtet sein.
  • Was ist der erforderliche Durchsatz? Und wie wird erwartet, dass der Durchsatz wächst?
  • Was sind die Anforderungen an die Datenlatenz bei P50/P99 unter Referenzladeebenen?

• Funktionen wie die Unterstützung eines sperrfreien Designs, einer Indexoptimierung und Konsistenzrichtlinien sind wichtig, um einen hohen Durchsatz zu erzielen.

  • Die Optimierung der Konfiguration für hohen Durchsatz verursacht Kompromisse, die vollständig verstanden werden sollten.
  • Das Lastenabgleich von Persistenz- und Messagingmustern, z. B. CQRS und Event Sourcing, kann verwendet werden, um den Durchsatz weiter zu optimieren.

• Bei vielen Anwendungsszenarien kommt es zu natürlichen Lastschwankungen, wobei natürliche Spitzen ein ausreichendes Maß an Elastizität erfordern, um variable Anforderungen zu bewältigen und gleichzeitig den Durchsatz und die Latenz aufrechtzuerhalten.

  • Agile Skalierbarkeit ist der Schlüssel zur effektiven Unterstützung variabler Durchsatz- und Lastebenen ohne Überbereitstellung von Kapazitäten.
    • Sowohl der Lese- als auch der Schreibdurchsatz müssen den Anwendungsanforderungen und der Last entsprechend skaliert werden.
    • Sowohl vertikale als auch horizontale Skalierungsvorgänge können angewendet werden, um auf sich ändernde Lastniveaus zu reagieren.

• Die Auswirkungen von Durchsatzeinbußen können je nach Workloadszenario variieren.

  • Gibt es Verbindungsunterbrechungen?
  • Gibt einzelne Vorgänge Fehlercodes zurück, während die Steuerungsebene weiterhin funktioniert?
  • Wird die Datenplattform Drosselung aktivieren und wenn ja, wie lange?

• Die grundlegende Anwendungsentwurfsempfehlung zur Verwendung einer aktiv-aktiven geografischen Verteilung führt zu Herausforderungen bei der Datenkonsistenz.

  • Es gibt einen Kompromiss zwischen Konsistenz und Leistung in Bezug auf die vollständige ACID-Transaktionssemantik und das herkömmliche Sperrverhalten.
    • Die Minimierung der Schreiblatenz wird zu Kosten der Datenkonsistenz führen.

• In einer Konfiguration für Schreibvorgänge mit mehreren Regionen müssen Änderungen zwischen allen Replikaten synchronisiert und zusammengeführt werden, wobei die Konfliktlösung erforderlich ist, und dies kann sich auf Leistungsstufen und Skalierbarkeit auswirken.

• Schreibgeschützte Replikate (regionsinterne und regionenübergreifende Replikate) können verwendet werden, um roundtriplatenz zu minimieren und Datenverkehr zu verteilen, um Leistung, Durchsatz, Verfügbarkeit und Skalierbarkeit zu steigern.

• Eine Zwischenspeicherungsebene kann verwendet werden, um den Lesedurchsatz zu erhöhen, um die Benutzerfreundlichkeit und die End-to-End-Clientantwortzeiten zu verbessern.

  • Ablaufzeiten und Richtlinien für den Cache müssen berücksichtigt werden, um die Aktualität der Daten zu optimieren.

Vielfalt

• Das Datenmodell, die Datentypen, die Datenbeziehungen und das beabsichtigte Abfragemodell wirken sich stark auf Entscheidungen hinsichtlich der Datenplattform aus.

  • Erfordert die Anwendung ein relationales Datenmodell oder kann es ein Variable-Schema oder nicht relationales Datenmodell unterstützen?
  • Wie werden die Anwendungsabfragedaten verwendet? Und hängen Abfragen von Konzepten auf Datenbankebene wie relationalen Verknüpfungen ab? Oder stellt die Anwendung solche Semantik bereit?

• Die Art von Datasets, die von der Anwendung berücksichtigt werden, kann von unstrukturierten Inhalten wie Bildern und Videos oder strukturierteren Dateien wie CSV und Parkett variieren.

  • Zusammengesetzte Anwendungsworkloads weisen in der Regel unterschiedliche Datasets und dazugehörige Anforderungen auf.

• Zusätzlich zu relationalen oder nicht relationalen Datenplattformen können Graph- oder Key-Value-Datenplattformen auch für bestimmte Datenworkloads geeignet sein.

  • Einige Technologien richten sich an Variablenschemadatenmodelle, bei denen Datenelemente semantisch ähnlich sind und/oder zusammen gespeichert und abgefragt werden, aber strukturell unterschiedlich sind.

• In einer Microservice-Architektur können einzelne Anwendungsdienste mit unterschiedlichen szenariooptimierten Datenspeichern erstellt werden, anstatt von einem einzelnen monolithischen Datenspeicher abhängig zu sein.

  • Designmuster wie SAGA können angewendet werden, um Konsistenz und Abhängigkeiten zwischen verschiedenen Datenspeichern zu verwalten.
    • Direkte Interdatenbankabfragen können Einschränkungen für gemeinsame Speicherorte erzwingen.
  • Durch die Verwendung mehrerer Datentechnologien wird ein Verwaltungsaufwand für die Beibehaltung umfassender Technologien hinzugefügt.

• Die Featuresätze für jeden Azure-Dienst unterscheiden sich je nach Sprachen, SDKs und APIs, was sich erheblich auf das Maß der Konfigurationsoptimierung auswirken kann, die angewendet werden kann.

• Die Funktionen für eine optimierte Ausrichtung mit dem Datenmodell und den eingeschlossenen Datentypen wirken sich stark auf Datenplattformentscheidungen aus.

  • Abfrageebenen wie gespeicherte Prozeduren und objektrelationale Mapper.
  • Sprachneutrale Abfragefunktion, z. B. eine gesicherte REST-API-Ebene.
  • Geschäftskontinuitätsfunktionen, z. B. Sicherung und Wiederherstellung.

• Analytische Datenspeicher unterstützen in der Regel polyglot-Speicher für verschiedene Arten von Datenstrukturen.

  • Analytische Laufzeitumgebungen wie Apache Spark können Integrationseinschränkungen haben, um Polyglot-Datenstrukturen zu analysieren.

• In einem Unternehmenskontext kann die Nutzung vorhandener Prozesse und Tools und die Kontinuität der Fähigkeiten einen erheblichen Einfluss auf das Design und die Auswahl von Datenplattformtechnologien haben.

Wahrhaftigkeit

• Um die Genauigkeit der Daten in einer Anwendung zu überprüfen, müssen mehrere Faktoren berücksichtigt werden, und die Verwaltung dieser Faktoren kann einen erheblichen Einfluss auf den Entwurf der Datenplattform haben.

  • Datenkonsistenz.
  • Plattformsicherheitsfeatures.
  • Datengovernance.
  • Änderungsverwaltung und Schemaentwicklung.
  • Abhängigkeiten zwischen Datasets.

• In jeder verteilten Anwendung mit mehreren Datenreplikaten gibt es einen Kompromiss zwischen Konsistenz und Latenz, wie in den CAP - und PACELC-Theorems ausgedrückt.

  • Wenn Leser und Autoren eindeutig verteilt sind, muss eine Anwendung entscheiden, entweder die schnellste verfügbare Version eines Datenelements zurückzugeben, auch wenn sie nicht mehr aktuell im Vergleich zu einem just abgeschlossenen Schreibvorgang (Update) dieses Datenelements in einem anderen Replikat oder der aktuellsten Version des Datenelements ist, was zu einer zusätzlichen Latenz führen kann, um den aktuellen Zustand zu ermitteln und abzurufen.
  • Konsistenz und Verfügbarkeit können auf Plattformebene oder auf individueller Datenanforderungsebene konfiguriert werden.
  • Was ist die Benutzererfahrung, wenn Daten von einem Replikat bereitgestellt werden sollen, das dem Benutzer am nächsten kommt und nicht dem aktuellen Zustand eines anderen Replikats entspricht? Kann die Anwendungsunterstützung z. B. veraltete Daten unterstützen?

• Wenn dasselbe Datenelement in zwei separaten Schreibreplikaten geändert wird, bevor eine Änderung repliziert werden kann, wird in einem Mehrbereichsschreibkontext ein Konflikt erstellt, der aufgelöst werden muss.

  • Standardisierte Konfliktlösungsrichtlinien wie "Last Write Wins" oder eine benutzerdefinierte Strategie mit benutzerdefinierter Logik können angewendet werden.

• Die Implementierung von Sicherheitsanforderungen kann sich negativ auf den Durchsatz oder die Leistung auswirken.

• Die ruhende Verschlüsselung kann auf der Anwendungsschicht mithilfe der clientseitigen Verschlüsselung und/oder der Datenschicht mithilfe der serverseitigen Verschlüsselung implementiert werden.

• Azure-Support verschiedene Verschlüsselungsmodelle, einschließlich serverseitiger Verschlüsselung, die dienstverwaltete Schlüssel, vom Kunden verwaltete Schlüssel im Key Vault oder vom Kunden verwaltete Schlüssel auf kundengesteuerter Hardware verwendet.

  • Mit clientseitiger Verschlüsselung können Schlüssel im Key Vault oder an einem anderen sicheren Ort verwaltet werden.

• MACsec (IEEE 802.1AE MAC)-Datenverbindungsverschlüsselung wird verwendet, um den gesamten Datenverkehr zwischen Azure-Rechenzentren im Microsoft-Backbone-Netzwerk zu sichern.

  • Pakete werden auf den Geräten verschlüsselt und entschlüsselt, bevor sie gesendet werden, und verhindern physische "Man-in-the-Middle"- oder Snooping-/Verkabelungsangriffe.

• Authentifizierung und Autorisierung für die Datenebene und kontrollebene.

  • Wie authentifiziert und autorisiert die Datenplattform den Anwendungszugriff und den betriebsbereiten Zugriff?

• Observability through monitoring platform health and data access.

  • Wie werden Warnungen für Bedingungen außerhalb akzeptabler Betriebsgrenzen angewendet?

Entwurfsempfehlungen

Volumen

• Stellen Sie sicher, dass zukünftige Datenvolumen, die mit organischem Wachstum verbunden sind, nicht erwartet werden, dass die Datenplattformfunktionen überschritten werden.

  • Prognostizieren Sie Datenwachstumsraten, die auf Geschäftspläne abgestimmt sind, und verwenden Sie bekannte Raten, um die laufenden Kapazitätsanforderungen zu benennen.
  • Vergleichen Sie die aggregierten und datensatzbasierten Volumen mit den Grenzwerten der Datenplattform.
  • Wenn unter außergewöhnlichen Umständen das Risiko besteht, dass Grenzwerte erreicht werden, stellen Sie sicher, dass entsprechende Gegenmaßnahmen vorhanden sind, um Downtime und Datenverlust zu vermeiden.

• Überwachen Sie das Datenvolumen, und überprüfen Sie es anhand eines Kapazitätsmodells unter Berücksichtigung von Skalierungsgrenzen und erwarteten Datenwachstumsraten.

  • Stellen Sie sicher, dass Skalierungsvorgänge den Anforderungen an Speicher, Leistung und Konsistenz entsprechen.
  • Wenn eine neue Skalierungseinheit eingeführt wird, müssen möglicherweise zugrunde liegende Daten repliziert werden, die Zeit in Anspruch nehmen und wahrscheinlich eine Leistungseinbuße während der Replikation auftreten. Stellen Sie daher sicher, dass diese Vorgänge nach Möglichkeit außerhalb kritischer Geschäftszeiten ausgeführt werden.

• Definieren Sie Anwendungsdatenebenen, um Datasets basierend auf Verwendung und Kritischität zu klassifizieren, um das Entfernen oder Entladen älterer Daten zu erleichtern.

  • Erwägen Sie das Klassifizieren von Datasets in "hot", "warm" und "cold" ('archive') Ebenen.
    • Beispielsweise verwenden die grundlegenden Referenzimplementierungen Azure Cosmos DB, um "hot"-Daten zu speichern, die von der Anwendung aktiv verwendet werden, während Azure Storage für "cold"-Betriebsdaten für analytische Zwecke verwendet wird.

• Konfigurieren Sie Housekeeping-Verfahren, um das Datenwachstum zu optimieren und die Effizienz von Daten zu steigern, z. B. Abfrageleistung und Verwaltung von Datenerweiterungen.

  • Konfigurieren Sie den Time-To-Live -Ablauf (TTL) für Daten, die nicht mehr erforderlich sind und keinen langfristigen Analysewert aufweisen.
    • Überprüfen Sie, ob alte Daten ohne nachteilige Auswirkungen auf die Anwendung sicher in den sekundären Speicher verschoben oder vollständig gelöscht werden können.
  • Übertragen Sie nicht kritische Daten in sekundären kalten Speicher, behalten sie die Daten jedoch für Analysezwecke und zur Erfüllung von Überwachungsanforderungen bei.
  • Sammeln Sie Telemetrie- und Nutzungsstatistiken für Die Datenplattform, damit DevOps-Teams die Anforderungen an die Haushaltung und die Datenspeicher mit der richtigen Größe kontinuierlich auswerten können.

• Berücksichtigen Sie im Einklang mit einem Microservice-Anwendungsdesign die Verwendung mehrerer verschiedener Datentechnologien parallel mit optimierten Datenlösungen für bestimmte Workloadszenarien und Volumenanforderungen.

  • Vermeiden Sie das Erstellen eines einzelnen monolithischen Datenspeichers, in dem das Datenvolumen aus der Erweiterung schwer zu verwalten ist.

Geschwindigkeit

• Die Datenplattform muss inhärent entworfen und konfiguriert werden, um hohen Durchsatz zu unterstützen, wobei Workloads in verschiedene Kontexte unterteilt sind, um die Leistung mithilfe von szenariooptimierten Datenlösungen zu maximieren.

  • Stellen Sie sicher, dass der Lese- und Schreibdurchsatz für die einzelnen Datenszenarien entsprechend den erwarteten Auslastungsmustern mit ausreichender Toleranz für unerwartete Abweichungen skaliert werden kann.
  • Ordnen Sie verschiedene Datenworkloads, z. B. Transaktions- und Analysevorgänge, unterschiedlichen Leistungskontexten zu.

• Load-Level through the use of asynchron non-blocking messaging, for example using the CQRS or Event Sourcing patterns.

  • Es kann eine Latenz zwischen Schreibanforderungen geben und wenn neue Daten zum Lesen verfügbar sind, was sich möglicherweise auf die Benutzererfahrung auswirkt.
    • Diese Auswirkungen müssen im Kontext der wichtigsten Geschäftsanforderungen verstanden und akzeptabel sein.

• Stellen Sie eine agile Skalierbarkeit zur Unterstützung des variablen Durchsatzes und der Lastebene sicher.

  • Wenn Ladeebenen sehr veränderlich sind, sollten Sie die Kapazitätsebenen überschreiben, um sicherzustellen, dass der Durchsatz und die Leistung beibehalten werden.
  • Testen und überprüfen Sie die Auswirkungen auf zusammengesetzte Anwendungsworkloads, wenn der Durchsatz nicht aufrechterhalten werden kann.

• Priorisieren Sie native Azure-Datendienste mit automatisierten Skalierungsvorgängen, um eine schnelle Reaktion auf Volatilität der Lastebene zu ermöglichen.

  • Konfigurieren Sie die automatische Skalierung basierend auf dienstinternen und anwendungsspezifischen Schwellenwerten.
  • Die Skalierung sollte in Zeitrahmen initiiert und abgeschlossen werden, die den Geschäftsanforderungen entsprechen.
  • Richten Sie für Szenarien, in denen eine manuelle Interaktion erforderlich ist, automatisierte operative „Playbooks“ ein, die ausgelöst werden können, anstatt manuelle operative Aktionen durchzuführen.
    • Überlegen Sie, ob automatisierte Trigger im Rahmen nachfolgender Engineering-Investitionen angewendet werden können.

• Überwachen Sie den Lese- und Schreibdurchsatz von Anwendungsdaten anhand der Latenzanforderungen von P50/P99 und richten Sie sich an ein Anwendungskapazitätsmodell aus.

• Der übermäßige Durchsatz sollte von der Datenplattform oder Anwendungsschicht ordnungsgemäß behandelt und vom Integritätsmodell für die operative Darstellung erfasst werden.

• Implementieren Sie die Zwischenspeicherung für "hot"-Datenszenarien, um Die Reaktionszeiten zu minimieren.

  • Wenden Sie geeignete Richtlinien für den Cacheablauf und die Interne Aufbewahrung an, um das Wachstum von Daten zu vermeiden.
    • Ablaufen von Cacheelementen, wenn sich die Sicherungsdaten ändern.
    • Wenn der Ablauf des Caches streng time-to-Live (TTL) basiert, müssen die Auswirkungen und die Kundenerfahrung der Bereitstellung veralteter Daten verstanden werden.

Vielfalt

• Im Einklang mit dem Prinzip eines cloud- und azure-nativen Designs wird dringend empfohlen, verwaltete Azure-Dienste zu priorisieren, um die Betriebs- und Verwaltungskomplexität zu reduzieren und die zukünftigen Plattforminvestitionen von Microsoft zu nutzen.

• In Übereinstimmung mit dem Anwendungsentwurfsprinzip von lose gekoppelten Microservice-Architekturen ermöglichen sie es einzelnen Diensten, unterschiedliche Datenspeicher und szenariooptimierte Datentechnologien zu verwenden.

  • Bestimmen Sie die Datenstrukturtypen, die die Anwendung für bestimmte Workloadszenarien verarbeitet.
  • Vermeiden Sie die Abhängigkeit von einem einzelnen monolithischen Datenspeicher.
    • Betrachten Sie das SAGA-Entwurfsmuster , bei dem Abhängigkeiten zwischen Datenspeichern vorhanden sind.

• Überprüfen Sie, ob die erforderlichen Funktionen für ausgewählte Datentechnologien verfügbar sind.

  • Stellen Sie die Unterstützung für erforderliche Sprachen und SDK-Funktionen sicher. Nicht jede Funktion ist für jede Sprache/SDK auf die gleiche Weise verfügbar.

Wahrhaftigkeit

• Verwenden Sie einen Datenplattformentwurf mit mehreren Regionen, und verteilen Sie Replikate regionsübergreifend, um maximale Zuverlässigkeit, Verfügbarkeit und Leistung zu erzielen, indem Sie Daten näher an Anwendungsendpunkte verschieben.

  • Verteilen Sie Datenreplikate über Verfügbarkeitszonen (AZs) innerhalb einer Region (oder verwenden Sie zonenredundante Dienstebenen), um die Verfügbarkeit innerhalb der Region zu maximieren.

• Wenn die Konsistenzanforderungen dies ermöglichen, verwenden Sie ein Mehrregion-Datenplattformdesign, um die globale Verfügbarkeit und Zuverlässigkeit zu maximieren.

  • Berücksichtigen Sie geschäftliche Anforderungen für die Konfliktbehebung, wenn dasselbe Datenelement in zwei separaten Schreibreplikaten geändert wird, bevor beide Änderungen repliziert und somit einen Konflikt verursachen.
    • Verwenden Sie standardisierte Konfliktlösungsrichtlinien wie "Letzte gewinnt" nach Möglichkeit.
      • Wenn eine benutzerdefinierte Strategie mit benutzerdefinierter Logik erforderlich ist, stellen Sie sicher, dass CI/CD DevOps-Methoden angewendet werden, um benutzerdefinierte Logik zu verwalten.

• Testen und Überprüfen von Sicherungs- und Wiederherstellungsfunktionen sowie Failovervorgängen durch Chaostests innerhalb kontinuierlicher Übermittlungsprozesse.

• Führen Sie Leistungs-Benchmarks aus, um sicherzustellen, dass Durchsatz- und Leistungsanforderungen nicht durch die Einbeziehung der erforderlichen Sicherheitsfunktionen wie Verschlüsselung beeinträchtigt werden.

  • Stellen Sie sicher, dass kontinuierliche Übermittlungsprozesse Auslastungstests mit bekannten Leistungs-Benchmarks in Betracht ziehen.

• Beim Anwenden der Verschlüsselung wird dringend empfohlen, dienstseitig verwaltete Verschlüsselungsschlüssel zu verwenden, um die Verwaltungskomplexität zu verringern.

  • Wenn eine bestimmte Sicherheitsanforderung für kundenseitig verwaltete Schlüssel besteht, stellen Sie sicher, dass geeignete Schlüsselverwaltungsverfahren angewendet werden, um die Verfügbarkeit, Sicherung und Rotation aller berücksichtigten Schlüssel sicherzustellen.

Hinweis

Bei der Integration mit einer umfassenderen Organisationsimplementierung ist es wichtig, dass ein anwendungsorientierter Ansatz für die Bereitstellung und den Betrieb von Datenplattformkomponenten in einem Anwendungsdesign angewendet wird.

Genauer gesagt: Um die Zuverlässigkeit zu maximieren, ist es wichtig, dass einzelne Datenplattformkomponenten über betriebliche Maßnahmen, die andere Anwendungskomponenten enthalten können, angemessen auf den Anwendungsstatus reagieren. In einem Szenario, in dem zusätzliche Datenplattformressourcen benötigt werden, wird die Skalierung der Datenplattform zusammen mit anderen Anwendungskomponenten nach einem Kapazitätsmodell wahrscheinlich erforderlich sein, möglicherweise durch die Bereitstellung zusätzlicher Skalierungseinheiten. Dieser Ansatz wird letztendlich eingeschränkt, wenn es eine harte Abhängigkeit eines zentralisierten Betriebsteams gibt, um Probleme im Zusammenhang mit der Datenplattform isoliert zu beheben.

Letztendlich führt die Verwendung zentralisierter Datendienste (d. h. zentrale IT-DBaaS) zu betriebstechnischen Engpässen, die die Flexibilität durch eine weitgehend untextualisierte Managementerfahrung erheblich behindern und in einem unternehmenskritischen oder unternehmenskritischen Kontext vermieden werden sollten.

Weitere Verweise

Zusätzliche Datenplattformanleitungen finden Sie im Azure-App lizenzierungsarchitekturhandbuch.

• Azure Data Store Decision Tree
• Kriterien für die Auswahl eines Datenspeichers
• Nicht relationale Datenspeicher
• Relationale OLTP-Datenspeicher

Global verteilter Multi-Region-Schreibdatenspeicher

Um die global verteilten aktiv-aktiven Ziele eines Anwendungsdesigns vollständig zu berücksichtigen, empfiehlt es sich dringend, eine verteilte Mehrregion-Datenplattform zu berücksichtigen, bei der Änderungen an separaten schreibbaren Replikaten synchronisiert und zwischen allen Replikaten zusammengeführt werden, wobei bei Bedarf eine Konfliktauflösung besteht.

Wichtig

Die Microservices erfordern möglicherweise nicht alle einen verteilten Mehrregionen-Schreibdatenspeicher, daher sollten die Architekturkontexte und die geschäftlichen Anforderungen jedes Arbeitsauslastungsszenarios berücksichtigt werden.

Azure Cosmos DB bietet einen global verteilten und hochverwendbaren NoSQL-Datenspeicher, der Mehrregionen-Schreibvorgänge und tunbare Konsistenz sofort einsatzbereit bietet. Die Designüberlegungen und Empfehlungen in diesem Abschnitt konzentrieren sich daher auf optimale Azure Cosmos DB-Nutzung.

Überlegungen zum Entwurf

Azure Cosmos DB

• Azure Cosmos DB speichert Daten in Containern, die indiziert sind, zeilenbasierte Transaktionsspeicher, die es ermöglichen, schnelle transaktionsbezogene Lese- und Schreibvorgänge mit Antwortzeiten in der Reihenfolge von Millisekunden zu ermöglichen.

• Azure Cosmos DB unterstützt mehrere verschiedene APIs mit unterschiedlichen Featuresätzen, z. B. SQL, Cassandra und MongoDB.

  • Die Erstanbieter-Azure Cosmos DB für NoSQL bietet den besten Featuresatz und ist in der Regel die API, in der neue Funktionen zuerst verfügbar werden.

• Azure Cosmos DB unterstützt Gateway- und Direct-Verbindungsmodi, bei denen Direct die Konnektivität über TCP zum Back-End-Azure Cosmos DB-Replikatknoten erleichtert, um die Leistung mit weniger Netzwerkhüpfern zu verbessern, während Gateway HTTPS-Konnektivität zu Front-End-Gatewayknoten bereitstellt.

  • Der direkte Modus ist nur verfügbar, wenn Sie azure Cosmos DB für NoSQL verwenden und derzeit nur auf .NET- und Java SDK-Plattformen unterstützt werden.

• In aktivierten Regionen der Verfügbarkeitszone bietet Azure Cosmos DB Redundanzunterstützung für hohe Verfügbarkeit und Resilienz gegenüber Zonenfehlern innerhalb einer Region.

• Azure Cosmos DB verwaltet vier Replikate von Daten in einer einzelnen Region, und wenn die Verfügbarkeitszone (AZ)-Redundanz aktiviert ist, stellt Azure Cosmos DB sicher, dass Datenreplikate über mehrere AZs hinweg platziert werden, um sich vor Zonalfehlern zu schützen.

  • Das Konsensprotokoll von Paxos wird angewendet, um ein Quorum für replizierbare Replikate innerhalb einer Region zu erreichen.

• Ein Azure Cosmos DB-Konto kann einfach so konfiguriert werden, dass Daten in mehreren Regionen repliziert werden, um das Risiko zu verringern, dass eine einzelne Region nicht verfügbar wird.

  • Die Replikation kann mit Schreibvorgängen mit einer Region oder mit Mehreren Regionen-Schreibvorgängen konfiguriert werden.
    • Bei Schreibvorgängen in einzelnen Regionen wird ein primärer "Hub"-Bereich verwendet, um alle Schreibvorgänge zu bedienen, und wenn dieser "Hub"-Bereich nicht verfügbar ist, muss ein Failovervorgang erfolgen, um eine andere Region als schreibbar zu bewerben.
    • Bei Schreibvorgängen mit mehreren Regionen können Anwendungen in jede konfigurierte Bereitstellungsregion schreiben, wodurch Änderungen zwischen allen anderen Regionen repliziert werden. Wenn eine Region nicht verfügbar ist, werden die verbleibenden Regionen verwendet, um Schreibdatenverkehr zu bedienen.

• In einer Mehrregion-Schreibkonfiguration können Aktualisierungskonflikte (Einfügen, Ersetzen, Löschen) auftreten, bei denen Autoren gleichzeitig dasselbe Element in mehreren Regionen aktualisieren.

• Azure Cosmos DB bietet zwei Richtlinien für die Konfliktlösung, die automatisch auf Konflikte angewendet werden können.

  • Last Write Wins (LWW) wendet ein Zeitsynchronisierungsuhrprotokoll mit einer vom System definierten Timestamp-Eigenschaft _ts als Konfliktlösungspfad an. Wenn bei einem Konflikt das Element mit dem höchsten Wert für den Konfliktauflösungspfad zum Gewinner wird und mehrere Elemente denselben numerischen Wert aufweisen, wählt das System einen Gewinner aus, sodass alle Regionen mit derselben Version des zugesicherten Elements konvergen können.
    • Bei Löschkonflikten gewinnt die gelöschte Version unabhängig vom Wert des Konfliktlösungspfads immer vorrang vor Einfüge- oder Ersetzen von Konflikten.
    • „Letzter Schreibvorgang gewinnt“ (Last Write Wins, LWW) ist der standardmäßige Konfliktauflösungsmodus.
    • Bei Verwendung von Azure Cosmos DB für NoSQL kann eine benutzerdefinierte numerische Eigenschaft wie eine benutzerdefinierte Zeitstempeldefinition für die Konfliktauflösung verwendet werden.
  • Benutzerdefinierte Lösungsrichtlinien ermöglichen es anwendungsdefinierten Semantik, Konflikte mithilfe einer registrierten gespeicherten Zusammenführungsprozedur abzugleichen, die automatisch aufgerufen wird, wenn Konflikte erkannt werden.
    • Das System garantiert genau eine Ausführung der Mergeprozedur im Rahmen des Commitprotokolls.
    • Eine benutzerdefinierte Konfliktlösungsrichtlinie ist nur mit Azure Cosmos DB für NoSQL verfügbar und kann nur zur Erstellungszeit des Containers festgelegt werden.

• In einer Konfiguration mit mehreren Regionen gibt es eine Abhängigkeit von einer einzelnen Azure Cosmos DB -Hubregion, um alle Konfliktauflösungen auszuführen, wobei das Konsensprotokoll von Paxos angewendet wird, um das Quorum über Replikate innerhalb der Hubregion hinweg zu erreichen.

  • Die Plattform bietet einen Nachrichtenpuffer für Schreibkonflikte innerhalb des Hubbereichs, um den Ladegrad zu laden und Redundanz für vorübergehende Fehler bereitzustellen.
    • Der Puffer ist in der Lage, einige Minuten zu speichern, die Updates schreiben, die einen Konsens erfordern.

Die strategische Ausrichtung der Azure Cosmos DB-Plattform besteht darin, diese Abhängigkeit der einzelnen Regionen für die Konfliktlösung in einer Mehrregionen-Schreibkonfiguration zu entfernen, wobei ein 2-Phasen-Paxos-Ansatz verwendet wird, um das Quorum auf globaler Ebene und innerhalb einer Region zu erreichen.

• Die primäre "Hub"-Region wird durch die erste Region bestimmt, in der Azure Cosmos DB konfiguriert ist.

  • Eine Prioritätsbestellung wird für zusätzliche Satellitenbereitstellungsregionen für Failoverzwecke konfiguriert.

• Das Datenmodell und die Partitionierung über logische und physische Partitionen hinweg spielen eine wichtige Rolle bei der Optimalen Leistung und Verfügbarkeit.

• Bei Der Bereitstellung mit einem einzelnen Schreibbereich kann Azure Cosmos DB basierend auf einer definierten Failoverpriorität für das automatische Failover konfiguriert werden, wobei alle Lesebereichsreplikate berücksichtigt werden.

• Die von der Azure Cosmos DB-Plattform bereitgestellte RTO beträgt ca. 10-15 Minuten, wobei die verstrichene Zeit erfasst wird, um ein regionales Failover des Azure Cosmos DB-Diensts durchzuführen, wenn sich eine katastrophale Katastrophe auf die Hubregion auswirkt.

  • Dieses RTO ist auch in einem Mehrregion-Schreibkontext relevant, da die Abhängigkeit von einer einzelnen "Hub"-Region für die Konfliktlösung abhängt.
    • Wenn der Bereich "Hub" nicht verfügbar ist, schlagen Schreibvorgänge in andere Regionen fehl, nachdem der Nachrichtenpuffer gefüllt wurde, da die Konfliktauflösung erst auftreten kann, wenn der Dienst fehlschlägt und eine neue Hubregion eingerichtet wird.

Die strategische Ausrichtung der Azure Cosmos DB-Plattform besteht darin, das RTO auf ca. 5 Minuten zu reduzieren, indem Failover auf Partitionsebene zugelassen werden.

• Wiederherstellungspunktziele (RPO) und Wiederherstellungszeitziele (Recovery Time Objectives, RTO) sind über Konsistenzstufen konfigurierbar, mit einem Kompromiss zwischen Datenbeständigkeit und Durchsatz.

  • Azure Cosmos DB bietet eine minimale RTO von 0 für eine entspannte Konsistenzstufe mit Schreibvorgängen mit mehreren Regionen oder einem RPO von 0 für eine starke Konsistenz mit Einem Schreibbereich.

• Azure Cosmos DB bietet eine SLA von 99,999 % für Lese- und Schreibzugriff für Datenbankkonten, die mit mehreren Azure-Regionen als schreibbar konfiguriert sind.

  • Die SLA wird durch den monatlichen Uptime-Prozentsatz dargestellt, der als 100 % - Durchschnittliche Fehlerrate berechnet wird.
  • Die durchschnittliche Fehlerrate wird als Die Summe der Fehlersätze für jede Stunde im Abrechnungsmonat dividiert durch die Gesamtanzahl der Stunden im Abrechnungsmonat, wobei die Fehlerrate die Gesamtanzahl der fehlgeschlagenen Anforderungen dividiert durch Gesamtanforderungen in einem bestimmten einstündigen Intervall.

• Azure Cosmos DB bietet eine SLA von 99,99 % für Durchsatz, Konsistenz, Verfügbarkeit und Latenz für Datenbankkonten, die auf eine einzelne Azure-Region ausgelegt sind, wenn sie mit einem der fünf Konsistenzstufen konfiguriert ist.

  • Eine SLA von 99,99 % gilt auch für Datenbankkonten, die mehrere Azure-Regionen umfassen, die mit einem der vier entspannten Konsistenzstufen konfiguriert sind.

• Es gibt zwei Arten von Durchsatz, die in Azure Cosmos DB, Standard- und Autoskalen bereitgestellt werden können, die mit Anforderungseinheiten pro Sekunde (RU/s) gemessen werden.

  • Der Standarddurchsatz weist Ressourcen zu, die erforderlich sind, um einen angegebenen RU/s-Wert zu garantieren.
    • Standard wird stündlich für den bereitgestellten Durchsatz in Rechnung gestellt.
  • Autoscale definiert einen maximalen Durchsatzwert, und Azure Cosmos DB wird je nach Anwendungslast automatisch nach oben oder unten skaliert, zwischen dem maximalen Durchsatzwert und einem Minimum von 10 % des maximalen Durchsatzwerts.
    • Die Automatische Skalierung wird stündlich für den maximalen Durchsatz in Rechnung gestellt.

• Statischer bereitgestellter Durchsatz mit einer variablen Workload kann zu Drosselungsfehlern führen, was sich auf die wahrgenommene Anwendungsverfügbarkeit auswirkt.

  • Die Automatische Skalierung schützt vor Drosselungsfehlern, indem Azure Cosmos DB bei Bedarf skaliert werden kann, während der Kostenschutz beibehalten wird, indem die Auslastung reduziert wird.

• Wenn Azure Cosmos DB in mehreren Regionen repliziert wird, werden die bereitgestellten Anforderungseinheiten (RUs) pro Region abgerechnet.

• Es gibt ein erhebliches Kostendelta zwischen einer Mehrregion-Schreib- und Einer-Region-Schreibkonfiguration, die in vielen Fällen eine Multimaster-Azure Cosmos DB-Datenplattform unerschwinglich machen kann.

Lese-/Schreibzugriff für einzelne Regionen	Schreibzugriff auf einzelne Regionen – Dual-Region-Lesezugriff	Duale Region Lese-/Schreibzugriff
1 RU	2 RU	4 RU

Das Delta zwischen Single-Region-Write und Multi-Region-Write ist tatsächlich kleiner als das Verhältnis von 1:2, das in der obigen Tabelle widergespiegelt wird. Genauer gesagt gibt es eine regionsübergreifende Datenübertragungsgebühr, die mit Schreibaktualisierungen in einer Einzelschreibkonfiguration verknüpft ist, die nicht in den RU-Kosten wie bei der Mehrregion-Schreibkonfiguration erfasst wird.

• Verbrauchter Speicher wird als Pauschalsatz für die Gesamtmenge des Speichers (GB) in Rechnung gestellt, der für hostende Daten und Indizes für eine bestimmte Stunde verbraucht wird.

• Session ist die Standard- und am häufigsten verwendete Konsistenzstufe , da Daten in der gleichen Reihenfolge wie Schreibvorgänge empfangen werden.

• Azure Cosmos DB unterstützt die Authentifizierung entweder über eine Microsoft Entra-Identität oder Azure Cosmos DB-Schlüssel und Ressourcentoken, die überlappende Funktionen bieten.

• Es ist möglich, Ressourcenverwaltungsvorgänge mithilfe von Schlüsseln oder Ressourcentoken zu deaktivieren, um Schlüssel und Ressourcentoken nur auf Datenvorgänge zu beschränken, sodass eine differenzierte Ressourcenzugriffskontrolle mithilfe der rollenbasierten Zugriffssteuerung (RBAC) von Microsoft Entra ermöglicht wird.

  • Wenn Sie den Zugriff auf die Steuerungsebene über Schlüssel oder Ressourcentoken einschränken, werden Die Steuerungsebenenvorgänge für Clients mit Azure Cosmos DB-SDKs deaktiviert und sollten daher gründlich ausgewertet und getestet werden.
  • Die disableKeyBasedMetadataWriteAccess Einstellung kann über ARM-Vorlagen-IaC-Definitionen oder über eine integrierte Azure-Richtlinie konfiguriert werden.

• Microsoft Entra RBAC-Unterstützung in Azure Cosmos DB gilt für Konto- und Ressourcensteuerungsebenen-Verwaltungsvorgänge.

  • Anwendungsadministratoren können Rollenzuweisungen für Benutzer, Gruppen, Dienstprinzipale oder verwaltete Identitäten erstellen, um Ressourcen und Vorgänge in Azure Cosmos DB-Ressourcen zu gewähren oder zu verweigern.
  • Es stehen mehrere integrierte RBAC-Rollen für die Rollenzuweisung zur Verfügung, und benutzerdefinierte RBAC-Rollen können auch verwendet werden, um bestimmte Berechtigungskombinationen zu bilden.
    • Cosmos DB Account Reader ermöglicht schreibgeschützten Zugriff auf die Azure Cosmos DB-Ressource.
    • DocumentDB-Kontomitwirkender ermöglicht die Verwaltung von Azure Cosmos DB-Konten, einschließlich Schlüsseln und Rollenzuweisungen, ermöglicht jedoch keinen Datenebenenzugriff.
    • Cosmos DB-Operator, der dem DocumentDB-Kontomitwirkenden ähnelt, bietet jedoch nicht die Möglichkeit, Schlüssel oder Rollenzuweisungen zu verwalten.

• Azure Cosmos DB-Ressourcen (Konten, Datenbanken und Container) können mithilfe von Ressourcensperren vor einer falschen Änderung oder Löschung geschützt werden.

  • Ressourcensperren können auf Konto-, Datenbank- oder Containerebene festgelegt werden.
  • Eine Ressourcensperre, die für eine Ressource festgelegt ist, wird von allen untergeordneten Ressourcen geerbt. Beispielsweise wird eine für das Azure Cosmos DB-Konto festgelegte Ressourcensperre von allen Datenbanken und Containern innerhalb des Kontos geerbt.
  • Ressourcensperren gelten nur für Steuerungsebenenvorgänge und verhindern keine Datenebenenvorgänge, z. B. das Erstellen, Ändern oder Löschen von Daten.
  • Wenn der Zugriff auf den Steuerebenenzugriff nicht eingeschränkt disableKeyBasedMetadataWriteAccessist, können Clients Steuerebenenoperationen mithilfe von Kontoschlüsseln ausführen.

• Der Azure Cosmos DB-Änderungsfeed bietet einen zeitgeordneten Feed von Änderungen an Daten in einem Azure Cosmos DB-Container.

  • Der Änderungsfeed umfasst nur Einfüge- und Aktualisierungsvorgänge an den Azure Cosmos DB-Quellcontainer; es enthält keine Löschvorgange.

• Der Änderungsfeed kann verwendet werden, um einen separaten Datenspeicher vom primären Container zu verwalten, der von der Anwendung verwendet wird, mit fortlaufenden Aktualisierungen des Zieldatenspeichers, der vom Änderungsfeed aus dem Quellcontainer bereitgestellt wird.

  • Der Änderungsfeed kann verwendet werden, um einen sekundären Speicher für zusätzliche Datenplattformredundanz oder für nachfolgende Analyseszenarien aufzufüllen.

• Wenn sich Löschvorgänge routinemäßig auf die Daten im Quellcontainer auswirken, ist der vom Änderungsfeed gefütterte Speicher ungenau und unreflektiert von gelöschten Daten.

  • Ein Soft Delete-Muster kann implementiert werden, sodass Datensätze im Änderungsfeed enthalten sind.
    • Anstatt Datensätze explizit zu löschen, werden Datensätze aktualisiert , indem ein Kennzeichen (z. B. IsDeleted) festgelegt wird, um anzugeben, dass das Element als gelöscht betrachtet wird.
    • Jeder Zieldatenspeicher, der vom Änderungsfeed gefüttert wird, muss Elemente erkennen und verarbeiten, wobei eine gelöschte Kennzeichnung auf "True" festgelegt ist. Anstatt vorläufig gelöschte Datensätze zu speichern, muss die vorhandene Version des Datensatzes im Zielspeicher gelöscht werden.
  • Eine kurze Time-To-Live (TTL) wird in der Regel mit dem Weichlöschmuster verwendet, sodass Azure Cosmos DB abgelaufene Daten automatisch löscht, sondern nur, nachdem sie im Änderungsfeed widergespiegelt wurde, wobei das gelöschte Flag auf "True" festgelegt ist.
    • Führt die ursprüngliche Löschabsicht durch und verteilt den Löschvorgang auch über den Änderungsfeed.

• Azure Cosmos DB kann als Analytischer Speicher konfiguriert werden, der ein Spaltenformat für optimierte Analyseabfragen anwendet, um die Komplexität und Latenzprobleme zu beheben, die mit den herkömmlichen ETL-Pipelines auftreten.

• Azure Cosmos DB sichert Daten automatisch in regelmäßigen Intervallen, ohne die Leistung oder Verfügbarkeit zu beeinträchtigen, und ohne RU/s zu verbrauchen.

• Azure Cosmos DB kann gemäß zwei unterschiedlichen Sicherungsmodi konfiguriert werden.

  • Periodisch ist der Standardsicherungsmodus für alle Konten, in dem Sicherungen in regelmäßigen Intervallen ausgeführt werden und die Daten wiederhergestellt werden, indem eine Anforderung mit dem Supportteam erstellt wird.
    • Der standardmäßige periodische Aufbewahrungszeitraum für die Sicherung beträgt acht Stunden, und das Standardsicherungsintervall beträgt vier Stunden, was bedeutet, dass nur die letzten beiden Sicherungen standardmäßig gespeichert werden.
    • Das Sicherungsintervall und der Aufbewahrungszeitraum können innerhalb des Kontos konfiguriert werden.
      • Der maximale Aufbewahrungszeitraum erstreckt sich auf einen Monat mit einem Mindestsicherungsintervall von einer Stunde.
      • Eine Rollenzuweisung zur Azure "Cosmos DB Account Reader Role" ist erforderlich, um Sicherungsspeicherredundanz zu konfigurieren.
    • Zwei Sicherungskopien sind ohne zusätzliche Kosten enthalten, aber zusätzliche Sicherungen verursachen zusätzliche Kosten.
    • Standardmäßig werden regelmäßige Sicherungen in separatem georedundanten Speicher (GRS) gespeichert, auf den nicht direkt zugegriffen werden kann.
      • Der Sicherungsspeicher ist innerhalb der primären "Hub"-Region vorhanden und wird über die zugrunde liegende Speicherreplikation in den gekoppelten Bereich repliziert.
      • Die Redundanzkonfiguration des zugrunde liegenden Sicherungsspeicherkontos ist für zonenredundanten Speicher oder lokal redundanten Speicher konfigurierbar.
    • Zum Ausführen eines Wiederherstellungsvorgangs ist eine Supportanfrage erforderlich, da Kunden eine Wiederherstellung nicht direkt ausführen können.
      • Vor dem Öffnen eines Supporttickets sollte der Aufbewahrungszeitraum für die Sicherung innerhalb von acht Stunden nach dem Datenverlust auf mindestens sieben Tage erhöht werden.
    • Ein Wiederherstellungsvorgang erstellt ein neues Azure Cosmos DB-Konto, bei dem Daten wiederhergestellt werden.
      • Ein vorhandenes Azure Cosmos DB-Konto kann nicht für die Wiederherstellung verwendet werden.
      • Standardmäßig wird ein neues Azure Cosmos DB-Konto <Azure_Cosmos_account_original_name>-restored<n> verwendet.
        • Dieser Name kann angepasst werden, z. B. durch erneutes Verwenden des vorhandenen Namens, wenn das ursprüngliche Konto gelöscht wurde.
    • Wenn der Durchsatz auf Datenbankebene bereitgestellt wird, erfolgt die Sicherung und Wiederherstellung auf Datenbankebene.
      • Es ist nicht möglich, eine Teilmenge von Containern auszuwählen, die wiederhergestellt werden sollen.
  • Der fortlaufende Sicherungsmodus ermöglicht eine Wiederherstellung zu einem beliebigen Zeitpunkt innerhalb der letzten 30 Tage.
    • Wiederherstellungsvorgänge können ausgeführt werden, um zu einem bestimmten Zeitpunkt (PITR) mit einer 1-Sekunden-Granularität zurückzukehren.
    • Das verfügbare Fenster für Wiederherstellungsvorgänge beträgt bis zu 30 Tage.
      • Es ist auch möglich, den Ressourceninstanziierungszustand wiederherzustellen.
    • Kontinuierliche Sicherungen werden in jeder Azure-Region durchgeführt, in der das Azure Cosmos DB-Konto vorhanden ist.
      • Kontinuierliche Sicherungen werden innerhalb derselben Azure-Region wie jedes Azure Cosmos DB-Replikat gespeichert, wobei lokal redundanter Speicher (LRS) oder Zonenredundanter Speicher (Zone Redundant Storage, ZRS) in Regionen verwendet wird, die Verfügbarkeitszonen unterstützen.
    • Eine Self-Service-Wiederherstellung kann mithilfe der Azure-Portal oder IaC-Artefakte wie ARM-Vorlagen ausgeführt werden.
    • Es gibt mehrere Einschränkungen bei fortlaufender Sicherung.
      • Der fortlaufende Sicherungsmodus ist derzeit nicht in einer Mehrregion-Schreibkonfiguration verfügbar.
      • Derzeit kann nur Azure Cosmos DB für NoSQL und Azure Cosmos DB für MongoDB für kontinuierliche Sicherung konfiguriert werden.
      • Wenn ein Container TTL konfiguriert hat, werden wiederhergestellte Daten, die seine TTL überschritten haben, möglicherweise sofort gelöscht.
    • Ein Wiederherstellungsvorgang erstellt ein neues Azure Cosmos DB-Konto für die Point-in-Time-Wiederherstellung.
    • Es gibt zusätzliche Speicherkosten für fortlaufende Sicherungen und Wiederherstellungsvorgänge.

• Vorhandene Azure Cosmos DB-Konten können von periodisch zu fortlaufend, aber nicht von fortlaufend zu periodisch migriert werden. Die Migration ist unidirektionale und nicht umkehrbar.

• Jede Azure Cosmos DB-Sicherung besteht aus den Daten selbst und Konfigurationsdetails für den bereitgestellten Durchsatz, Indizierungsrichtlinien, Bereitstellungsregionen und Container-TTL-Einstellungen.

  • Sicherungen enthalten keine Firewalleinstellungen, Zugriffssteuerungslisten für virtuelle Netzwerke, private Endpunkteinstellungen, Konsistenzeinstellungen (ein Konto wird mit Sitzungskonsistenz wiederhergestellt), gespeicherte Prozeduren, Trigger, UDFs oder Einstellungen für mehrere Regionen.
    • Kunden sind für die erneute Bereitstellung von Funktionen und Konfigurationseinstellungen verantwortlich. Diese werden nicht über die Azure Cosmos DB-Sicherung wiederhergestellt.
  • Azure Synapse Link analytical store data is also not included in Azure Cosmos DB backups.

• Es ist möglich, eine benutzerdefinierte Sicherungs- und Wiederherstellungsfunktion für Szenarien zu implementieren, in denen regelmäßige und fortlaufende Ansätze nicht gut geeignet sind.

  • Ein benutzerdefinierter Ansatz führt erhebliche Kosten und zusätzlichen Verwaltungsaufwand ein, der verstanden und sorgfältig bewertet werden sollte.
    • Häufige Wiederherstellungsszenarien sollten modelliert werden, z. B. die Beschädigung oder Löschung eines Kontos, einer Datenbank, eines Containers, eines Datenelements.
    • Die Verfahren zur Haushaltung sollten umgesetzt werden, um die Verwüstetung von Sicherungen zu verhindern.
  • Azure Storage oder eine alternative Datentechnologie können verwendet werden, z. B. einen alternativen Azure Cosmos DB-Container.
    • Azure Storage und Azure Cosmos DB bieten systemeigene Integrationen mit Azure-Diensten wie Azure Functions und Azure Data Factory.

• Die Azure Cosmos DB-Dokumentation zeigt zwei mögliche Optionen für die Implementierung von benutzerdefinierten Sicherungen an.

  • Azure Cosmos DB-Änderungsfeed zum Schreiben von Daten in eine separate Speichereinrichtung.
    • Eine Azure-Funktion oder ein gleichwertiger Anwendungsprozess verwendet den Änderungsfeedprozessor, um eine Bindung an den Änderungsfeed und die Verarbeitung von Elementen in den Speicher zu binden.
  • Sowohl kontinuierliche als auch periodische (batchierte) benutzerdefinierte Sicherungen können mithilfe des Änderungsfeeds implementiert werden.
  • Der Azure Cosmos DB-Änderungsfeed spiegelt noch keine Löschdaten wider, daher muss ein Weichlöschmuster mit einer booleschen Eigenschaft und TTL angewendet werden.
    • Dieses Muster ist nicht erforderlich, wenn der Änderungsfeed Updates mit voller Genauigkeit bereitstellt.
  • Azure Data Factory Connector für Azure Cosmos DB (Azure Cosmos DB für NoSQL- oder MongoDB-API-Connectors), um Daten zu kopieren.
    • Azure Data Factory (ADF) unterstützt manuelle Ausführung und Zeitplan, Tumbling-Fenster und ereignisbasierte Trigger.
      • Bietet Unterstützung für Speicher und Ereignisraster.
    • ADF eignet sich in erster Linie für regelmäßige benutzerdefinierte Sicherungsimplementierungen aufgrund der batchorientierten Orchestrierung.
      • Es eignet sich weniger für fortlaufende Sicherungsimplementierungen mit häufigen Ereignissen aufgrund des Orchestrierungs-Ausführungsaufwands.
    • ADF unterstützt Azure Private Link für Szenarien mit hoher Netzwerksicherheit

Azure Cosmos DB wird innerhalb des Designs vieler Azure-Dienste verwendet, sodass ein erheblicher regionaler Ausfall für Azure Cosmos DB über verschiedene Azure-Dienste innerhalb dieser Region hinweg kaskadierende Auswirkungen hat. Die genauen Auswirkungen auf einen bestimmten Dienst hängen stark davon ab, wie das zugrunde liegende Dienstdesign Azure Cosmos DB verwendet.

Entwurfsempfehlungen

Azure Cosmos DB

• Verwenden Sie Azure Cosmos DB als primäre Datenplattform, auf der Anforderungen zulässig sind.

• Konfigurieren Sie Azure Cosmos DB für unternehmenskritische Workloadszenarien mit einem Schreibreplikat in jeder Bereitstellungsregion, um die Latenz zu reduzieren und maximale Redundanz zu bieten.

  • Konfigurieren Sie die Anwendung so, dass die Verwendung des lokalen Azure Cosmos DB-Replikats für Schreibvorgänge und Lesevorgänge priorisiert wird, um die Auslastung, Leistung und regionale RU/s-Auslastung zu optimieren.
  • Die Mehrregion-Schreibkonfiguration hat erhebliche Kosten und sollte nur für Workloadszenarien priorisiert werden, die eine maximale Zuverlässigkeit erfordern.

• Priorisieren Sie bei weniger kritischen Arbeitsauslastungsszenarien die Verwendung der Single-Region-Write-Konfiguration (bei Verwendung von Verfügbarkeitszonen) mit global verteilten Lesereplikaten, da dies eine hohe Zuverlässigkeit der Datenplattform (99,999 % SLA für Lese-, 99,995 % SLA für Schreibvorgänge) zu einem überzeugenderen Preis bietet.

  • Konfigurieren Sie die Anwendung so, dass das lokale Azure Cosmos DB-Lesereplikat verwendet wird, um die Leseleistung zu optimieren.

• Wählen Sie eine optimale "Hub"-Bereitstellungsregion aus, in der die Konfliktlösung in einer Konfiguration mit mehreren Regionen-Schreibvorgängen erfolgt, und alle Schreibvorgänge werden in einer Konfiguration mit schreibgeschützter Region ausgeführt.

  • Erwägen Sie die Entfernung relativ zu anderen Bereitstellungsregionen und der zugehörigen Latenz bei der Auswahl einer primären Region und den erforderlichen Funktionen wie Verfügbarkeitszonen Unterstützung.

• Konfigurieren Sie Azure Cosmos DB mit Az-Redundanz (Availability Zone) in allen Bereitstellungsregionen mit AZ-Unterstützung, um Ausfallsicherheit für Zonalfehler innerhalb einer Region sicherzustellen.

• Verwenden Sie Azure Cosmos DB für NoSQL, da sie den umfassendsten Featuresatz bietet, insbesondere bei Leistungsoptimierungen.

  • Alternative APIs sollten in erster Linie für Migrations- oder Kompatibilitätsszenarien berücksichtigt werden.
    • Überprüfen Sie bei Verwendung alternativer APIs, ob erforderliche Funktionen mit der ausgewählten Sprache und dem SDK verfügbar sind, um eine optimale Konfiguration und Leistung sicherzustellen.

• Verwenden Sie den Direkten Verbindungsmodus, um die Netzwerkleistung durch direkte TCP-Konnektivität zum Back-End-Azure Cosmos DB-Knoten mit einer reduzierten Anzahl von Netzwerkhüpfungen zu optimieren.

Das Sla für Azure Cosmos DB wird durch durchschnittlich fehlgeschlagene Anforderungen berechnet, die möglicherweise nicht direkt mit einem Fehlerbudget der Zuverlässigkeitsstufe von 99,999 % übereinstimmen. Bei der Entwicklung für 99,999 % SLO ist es daher von entscheidender Bedeutung, die Verfügbarkeit regionaler und multiregionaler Azure Cosmos DB-Schreibvorgänge zu planen, um sicherzustellen, dass eine Fallbackspeichertechnologie positioniert wird, wenn ein Fehler auftritt, z. B. eine permanente Nachrichtenwarteschlange für nachfolgende Wiedergabe.

• Definieren Sie eine Partitionierungsstrategie für logische und physische Partitionen, um die Datenverteilung gemäß dem Datenmodell zu optimieren.

  • Minimieren Sie partitionsübergreifende Abfragen.
  • Iterativ testen und überprüfen Sie die Partitionierungsstrategie, um eine optimale Leistung sicherzustellen.

• Wählen Sie einen optimalen Partitionsschlüssel aus.

  • Der Partitionsschlüssel kann nicht geändert werden, nachdem er innerhalb der Auflistung erstellt wurde.
  • Der Partitionsschlüssel sollte ein Eigenschaftswert sein, der sich nicht ändert.
  • Wählen Sie einen Partitionsschlüssel mit einer hohen Kardinalität mit einem breiten Bereich möglicher Werte aus.
  • Der Partitionsschlüssel sollte den RU-Verbrauch und die Datenspeicherung gleichmäßig über alle logischen Partitionen verteilen, um sogar die RU-Verbrauch- und Speicherverteilung über physische Partitionen hinweg sicherzustellen.
  • Führen Sie Leseabfragen für die partitionierte Spalte aus, um den RU-Verbrauch und die Latenz zu reduzieren.

• Die Indizierung ist auch für die Leistung von entscheidender Bedeutung. Stellen Sie daher sicher, dass Indexausschlüsse verwendet werden, um RU/s und Speicheranforderungen zu reduzieren.

  • Indexieren Sie nur die Felder, die für die Filterung innerhalb von Abfragen erforderlich sind; Designindizes für die am häufigsten verwendeten Prädikate.

• Nutzen Sie die integrierten Fehlerbehandlungs-, Wiederholungs- und umfassenderen Zuverlässigkeitsfunktionen des Azure Cosmos DB SDK.

  • Implementieren Sie die Wiederholungslogik innerhalb des SDK auf Clients.

• Verwenden Sie vom Dienst verwaltete Verschlüsselungsschlüssel, um die Verwaltungskomplexität zu verringern.

  • Wenn es eine bestimmte Sicherheitsanforderung für vom Kunden verwaltete Schlüssel gibt, stellen Sie sicher, dass geeignete Schlüsselverwaltungsverfahren angewendet werden, z. B. Sicherung und Drehung.

• Deaktivieren Sie den Zugriffszugriff auf schlüsselbasierte Metadaten von Azure Cosmos DB, indem Sie die integrierte Azure-Richtlinie anwenden.

• Aktivieren Sie Azure Monitor , um wichtige Metriken und Diagnoseprotokolle zu erfassen, z. B. den bereitgestellten Durchsatz (RU/s).

  • Leiten Sie Azure Monitor-Betriebsdaten in einen Log Analytics-Arbeitsbereich, der Azure Cosmos DB und andere globale Ressourcen im Anwendungsdesign zugeordnet ist.
  • Verwenden Sie Azure Monitor-Metriken, um zu ermitteln, ob Anwendungsdatenverkehrsmuster für die automatische Skalierung geeignet sind.

• Bewerten Sie Anwendungsdatenverkehrsmuster, um eine optimale Option für bereitgestellte Durchsatztypen auszuwählen.

  • Erwägen Sie den automatischen bereitgestellten Durchsatz, um die Workloadnachfrage automatisch abzugleichen.

• Bewerten Sie Die Microsoft-Leistungstipps für Azure Cosmos DB , um die clientseitige und serverseitige Konfiguration für eine verbesserte Latenz und den Durchsatz zu optimieren.

• Wenn Sie AKS als Computeplattform verwenden: Wählen Sie für abfrageintensive Workloads eine AKS-Knoten-SKU aus, die eine beschleunigte Netzwerkverbindung aktiviert hat, um Latenz und CPU-Jitter zu reduzieren.

• Für Bereitstellungen mit einzelnen Schreibregionen wird dringend empfohlen, Azure Cosmos DB für automatisches Failover zu konfigurieren.

• Laden sie durch die Verwendung asynchroner nicht blockierenden Nachrichten innerhalb von Systemflüssen, die Updates in Azure Cosmos DB schreiben.

  • Berücksichtigen Sie Muster wie Befehls- und Abfrageverantwortungstrennung und Event Sourcing.

• Konfigurieren Sie das Azure Cosmos DB-Konto für fortlaufende Sicherungen, um eine feine Granularität der Wiederherstellungspunkte in den letzten 30 Tagen zu erhalten.

  • Berücksichtigen Sie die Verwendung von Azure Cosmos DB-Sicherungen in Szenarien, in denen enthaltene Daten oder das Azure Cosmos DB-Konto gelöscht oder beschädigt werden.
  • Vermeiden Sie die Verwendung eines benutzerdefinierten Sicherungsansatzes, es sei denn, es ist unbedingt erforderlich.

• Es wird dringend empfohlen, Wiederherstellungsverfahren für Nichtproduktionsressourcen und -daten im Rahmen der standardmäßigen Vorbereitung des Geschäftskontinuitätsvorgangs zu üben.

• Definieren Sie IaC-Artefakte, um Konfigurationseinstellungen und -funktionen einer Azure Cosmos DB-Sicherungswiederherstellung neu einzurichten.

• Bewerten und Anwenden der Azure Security Baseline-Steuerungsleitfaden für Azure Cosmos DB Backup and Recovery.

  • BR-1: Sicherstellen regelmäßiger automatisierter Sicherungen
  • BR-3: Überprüfen aller Sicherungen einschließlich vom Kunden verwalteter Schlüssel
  • BR-4, Minimieren des Risikos verlorener Schlüssel

• Verwenden Sie für analytische Workloads, die eine Verfügbarkeit in mehreren Regionen erfordern, den Azure Cosmos DB Analytical Store, der ein Spaltenformat für optimierte analytische Abfragen anwendet.

Relationale Datentechnologien

Für Szenarien mit einem stark relationalen Datenmodell oder Abhängigkeiten von vorhandenen relationalen Technologien ist die Verwendung von Azure Cosmos DB in einer Mehrregion-Schreibkonfiguration möglicherweise nicht direkt anwendbar. In solchen Fällen ist es von entscheidender Bedeutung, dass verwendete relationale Technologien so entwickelt und konfiguriert werden, dass sie den Ansprüchen an einen regionenübergreifendes Aktiv-Aktiv-Anwendungsentwurf gerecht werden.

Azure bietet viele verwaltete relationale Datenplattformen, einschließlich Azure SQL-Datenbank und Azure Database für gängige osS relationale Lösungen, einschließlich MySQL, PostgreSQL und MariaDB. Die Designüberlegungen und Empfehlungen in diesem Abschnitt konzentrieren sich daher auf die optimale Nutzung von Azure SQL-Datenbank und Azure Database OSS-Aromen, um die Zuverlässigkeit und die globale Verfügbarkeit zu maximieren.

Überlegungen zum Entwurf

• Während relationale Datentechnologien so konfiguriert werden können, dass Lesevorgänge einfach skaliert werden können, sind Schreibvorgänge in der Regel darauf beschränkt, eine einzelne primäre Instanz zu durchlaufen, die eine erhebliche Einschränkung der Skalierbarkeit und Leistung angibt.

• Sharding kann angewendet werden, um Daten und Die Verarbeitung über mehrere identische strukturierte Datenbanken zu verteilen, wobei Datenbanken horizontal partitioniert werden, um in Plattformeinschränkungen zu navigieren.

  • Beispielsweise wird Sharding häufig auf mehrinstanzenfähigen SaaS-Plattformen angewendet, um Gruppen von Mandanten in unterschiedlichen Datenplattformkonstrukten zu isolieren.

Azure SQL-Datenbank

• Azure SQL-Datenbank bietet ein vollständig verwaltetes Datenbankmodul, das immer mit der neuesten stabilen Version des SQL Server-Datenbankmoduls und des zugrunde liegenden Betriebssystems ausgeführt wird.

  • Bietet intelligente Features wie Leistungsoptimierung, Bedrohungsüberwachung und Sicherheitsrisikobewertungen.

• Azure SQL-Datenbank bietet integrierte regionale Hochverfügbarkeit und schlüsselfertige Georeplikation, um Lesereplikate in Azure-Regionen zu verteilen.

  • Bei der Georeplikation bleiben sekundäre Datenbankreplikate schreibgeschützt, bis ein Failover initiiert wird.
  • Bis zu vier Secondärdateien werden in denselben oder unterschiedlichen Regionen unterstützt.
  • Sekundäre Replikate können auch für schreibgeschützten Abfragezugriff verwendet werden, um die Leseleistung zu optimieren.
  • Failover muss manuell initiiert werden, kann aber in automatisierte Betriebsprozeduren eingeschlossen werden.

• Azure SQL-Datenbank bietet Automatische Failovergruppen, die Datenbanken auf einen sekundären Server repliziert und ein transparentes Failover ermöglichen, wenn ein Fehler auftritt.

  • Gruppen für automatisches Failover unterstützen die Georeplikation aller Datenbanken in der Gruppe auf nur einen sekundären Server oder eine sekundäre Instanz in einer anderen Region.
  • Automatische Failovergruppen werden derzeit nicht auf der Hyperscale-Dienstebene unterstützt.
  • Sekundäre Datenbanken können verwendet werden, um Lesedatenverkehr zu entladen.

• Premium- oder Unternehmenskritisch Dienstebenendatenbankreplikate können ohne zusätzliche Kosten über Verfügbarkeitszonen verteilt werden.

  • Der Steuerring wird auch in mehreren Zonen als drei Gatewayringe (GW) dupliziert.
    • Die Weiterleitung an einen bestimmten Gatewayring wird durch Azure Traffic Manager gesteuert.
  • Bei Verwendung des Tarifs „Unternehmenskritisch“ ist die zonenredundante Konfiguration nur verfügbar, wenn die Gen5-Computehardware ausgewählt ist.

• Azure SQL-Datenbank bietet eine geplante SLA für die Verfügbarkeit von 99,99 % in allen Dienstebenen, bietet jedoch eine höhere SLA von 99,995 % für die Unternehmenskritisch- oder Premium-Ebene in Regionen, die Verfügbarkeitszonen unterstützen.

  • Azure SQL-Datenbank Unternehmenskritisch oder Premium-Stufen, die nicht für redundante Zonenbereitstellungen konfiguriert sind, verfügen über eine Verfügbarkeits-SLA von 99,99 %.

• Bei der Konfiguration mit georeplikation stellt die Azure SQL-Datenbank Unternehmenskritisch-Ebene 30 Sekunden für 100 % der bereitgestellten Stunden ein Wiederherstellungszeitziel (Recovery Time Objective, RTO) bereit.

• Bei der Konfiguration mit georeplikation verfügt die Azure SQL-Datenbank Unternehmenskritisch-Ebene über ein Wiederherstellungspunktziel (Recovery Point Objective, RPO) von 5 Sekunden für 100 % der bereitgestellten Stunden.

• Azure SQL-Datenbank Hyperscale-Ebene, wenn sie mit mindestens zwei Replikaten konfiguriert ist, verfügt über eine Verfügbarkeits-SLA von 99,99 %.

• Berechnungskosten, die mit Azure SQL-Datenbank verbunden sind, können mit einem Reservierungsrabatt reduziert werden.

  • Es ist nicht möglich, reservierte Kapazität für DTU-basierte Datenbanken anzuwenden.

• Die Point-in-Time-Wiederherstellung kann verwendet werden, um eine Datenbank zurückzugeben und Daten an einen früheren Zeitpunkt zurückzugeben.

• Geowiederherstellung kann verwendet werden, um eine Datenbank aus einer georedundanten Sicherung wiederherzustellen.

Azure Database for PostgreSQL

• Azure Database for PostgreSQL wird in drei verschiedenen Bereitstellungsoptionen angeboten:

  • Single Server, SLA 99,99%
  • Flexibler Server, der Verfügbarkeitszonenredundanz bietet, SLA 99,99 %
  • Hyperscale (Citus), SLA 99,95 %, wenn der Modus für hohe Verfügbarkeit aktiviert ist.

• Hyperscale (Citus) bietet dynamische Skalierbarkeit durch Sharding ohne Anwendungsänderungen.

  • Das Verteilen von Tabellenzeilen über mehrere PostgreSQL-Server ist entscheidend, um skalierbare Abfragen in Hyperscale (Citus) sicherzustellen.
  • Mehrere Knoten können gemeinsam mehr Daten als eine herkömmliche Datenbank enthalten, und in vielen Fällen können Arbeits-CPUs parallel zur Optimierung der Kosten verwendet werden.

• Autoskalen können über die Runbook-Automatisierung konfiguriert werden, um die Flexibilität als Reaktion auf sich ändernde Verkehrsmuster sicherzustellen.

• Flexible Server bietet Kosteneffizienz für Nicht-Produktionsworkloads durch die Möglichkeit, den Server zu beenden/zu starten, und eine platzbare Computeebene, die für Workloads geeignet ist, die keine kontinuierliche Computekapazität erfordern.

• Es gibt keine zusätzliche Gebühr für den Sicherungsspeicher für bis zu 100 % des gesamten bereitgestellten Serverspeichers.

  • Der zusätzliche Verbrauch des Sicherungsspeichers wird entsprechend verbrauchtem GB/Monat in Rechnung gestellt.

• Berechnungskosten, die mit Azure-Datenbank für PostgreSQL verbunden sind, können entweder mit einem Reservierungsrabatt für einen einzelnen Server oder einem Citus-Reservierungsrabatt (Hyperscale) reduziert werden.

Entwurfsempfehlungen

• Erwägen Sie horizontales Partitionieren, um relationale Datenbanken basierend auf unterschiedlichen Anwendungs- und Datenkontexten zu partitionieren. Dadurch lassen sich Herausforderungen wie Plattformeinschränkungen, die Maximierung von Skalierbarkeit und Verfügbarkeit sowie die Fehlerisolation meistern.

  • Diese Empfehlung ist besonders häufig, wenn das Anwendungsdesign drei oder mehr Azure-Regionen berücksichtigt, da relationale Technologieeinschränkungen global verteilte Datenplattformen erheblich behindern können.
  • Da horizontales Partitionieren nicht für alle Anwendungsszenarien geeignet ist, ist eine kontextbezogene Auswertung erforderlich.

• Priorisieren Sie die Verwendung von Azure SQL-Datenbank, wenn aufgrund ihres Reifegrads auf der Azure-Plattform und verschiedensten Zuverlässigkeitsfunktionen relationale Anforderungen bestehen.

Azure SQL-Datenbank

• Verwenden Sie die Dienstebene „Unternehmenskritisch“, um Zuverlässigkeit und Verfügbarkeit zu maximieren (einschließlich Zugriff auf kritische Resilienzfunktionen).

• Verwenden Sie das vCore-basierte Verbrauchsmodell, um die unabhängige Auswahl von Compute- und Speicherressourcen zu erleichtern, die auf Die Anforderungen an Workloadvolumen und Durchsatz zugeschnitten sind.

  • Stellen Sie sicher, dass ein definiertes Kapazitätsmodell angewendet wird, um rechen- und speicherressourcenanforderungen zu informieren.
    • Berücksichtigen Sie reservierte Kapazität , um potenzielle Kostenoptimierungen bereitzustellen.

• Konfigurieren Sie das zonenredundante Bereitstellungsmodell, um Unternehmenskritisch Datenbankreplikate innerhalb derselben Region Verfügbarkeitszonen zu verteilen.

• Verwenden Sie die aktive Georeplikation , um lesbare Replikate in allen Bereitstellungsregionen (bis zu vier) bereitzustellen.

• Verwenden Sie automatische Failovergruppen, um ein transparentes Failover für eine sekundäre Region bereitzustellen, wobei die Georeplikation angewendet wird, um die Replikation für zusätzliche Bereitstellungsregionen für die Leseoptimierung und Datenbankredundanz bereitzustellen.

  • Bei Anwendungsszenarien, die auf nur zwei Bereitstellungsregionen beschränkt sind, sollte die Verwendung von Autofailover-Gruppen priorisiert werden.

• Erwägen Sie automatisierte Betriebsauslöser basierend auf der Warnung, die an das Anwendungsintegritätsmodell ausgerichtet ist, um Failovers für geo-replizierte Instanzen durchzuführen, wenn ein Fehler, der sich auf die primäre und sekundäre Innerhalb der Automatischen Failovergruppe auswirkt.

Wichtig

Bei Anwendungen, die mehr als vier Bereitstellungsregionen in Betracht ziehen, sollte eine ernsthafte Berücksichtigung der Anwendungsbereichsshardware oder der Umgestaltung der Anwendung zur Unterstützung von Mehrregionenschreibtechnologien wie Azure Cosmos DB gegeben werden. Wenn dies jedoch nicht innerhalb des Anwendungsworkloadszenarios machbar ist, wird empfohlen, eine Region innerhalb einer einzelnen Geografie auf einen primären Status zu erhöhen, der eine georeplizierte Instanz auf gleichmäßiger verteilten Lesezugriff umfasst.

• Konfigurieren Sie die Anwendung so, dass zur Optimierung der Leseleistung Replikatinstanzen für Leseabfragen abgefragt werden.

• Verwenden Sie Azure Monitor und Azure SQL Analytics für nahezu echtzeitbezogene Betriebseinblicke in Azure SQL DB für die Erkennung von Zuverlässigkeitsvorfällen.

• Verwenden Sie Azure Monitor, um die Nutzung für alle Datenbanken auszuwerten. So lässt sich ermitteln, ob sie optimal dimensioniert wurden.

  • Stellen Sie sicher, dass bei CD-Pipelines Auslastungstests mit repräsentativen Auslastungsebenen berücksichtigt werden, um das entsprechende Verhalten der Datenplattform zu überprüfen.

• Berechnen Sie eine Integritätsmetrik für Datenbankkomponenten, um die Integrität im Verhältnis zu geschäftlichen Anforderungen und der Ressourcenauslastung zu beobachten, indem Sie überwachung und Warnungen verwenden, um bei Bedarf automatisierte betriebliche Maßnahmen zu fördern.

  • Stellen Sie sicher, dass wichtige Abfrageleistungsmetriken integriert werden, damit schnelle Aktionen ausgeführt werden können, wenn die Dienstbeeinträchtigung auftritt.

• Optimieren Sie Abfragen, Tabellen und Datenbanken mithilfe von Abfrageleistungserkenntnissen und allgemeinen Leistungsempfehlungen , die von Microsoft bereitgestellt werden.

• Implementieren Sie die Wiederholungslogik mithilfe des SDK, um vorübergehende Fehler zu vermeiden, die sich auf Azure SQL-Datenbank Konnektivität auswirken.

• Priorisieren Sie die Verwendung von dienstverwalteten Schlüsseln beim Anwenden serverseitiger transparenter Datenverschlüsselung (TDE) für die At-Rest-Verschlüsselung.

  • Wenn vom Kunden verwaltete Schlüssel oder clientseitige Verschlüsselung (AlwaysEncrypted) erforderlich ist, stellen Sie sicher, dass Schlüssel mit Sicherungen und automatisierten Drehungseinrichtungen angemessen robust sind.

• Erwägen Sie die Verwendung der Point-in-Time-Wiederherstellung als operatives Playbook, um schwerwiegende Konfigurationsfehler wiederherzustellen.

Azure Database for PostgreSQL

• Flexible Server wird empfohlen, sie aufgrund der Unterstützung der Verfügbarkeitszone für geschäftskritische Workloads zu verwenden.

• Wenn Sie Hyperscale (Citus) für geschäftskritische Workloads verwenden, aktivieren Sie den Modus "Hohe Verfügbarkeit", um die SLA-Garantie von 99,95 % zu erhalten.

• Verwenden Sie die Hyperscale-Serverkonfiguration (Citus), um die Verfügbarkeit über mehrere Knoten zu maximieren.

• Definieren Sie ein Kapazitätsmodell für die Anwendung, um rechen- und speicherressourcenanforderungen innerhalb der Datenplattform zu informieren.

  • Berücksichtigen Sie den Hyperscale-Reservierungsrabatt (Citus), um potenzielle Kostenoptimierungen bereitzustellen.

Zwischenspeichern für Hot Tier-Daten

Eine Speicherzwischenspeicherungsebene kann angewendet werden, um eine Datenplattform zu verbessern, indem der Lesedurchsatz erheblich erhöht und die End-to-End-Clientantwortzeiten für Hot Tier-Datenszenarien verbessert werden.

Azure bietet mehrere Dienste mit anwendbaren Funktionen zum Zwischenspeichern wichtiger Datenstrukturen, wobei Azure Cache für Redis positioniert ist, um den Lesezugriff auf die Datenplattform abstrahieren und zu optimieren. Dieser Abschnitt konzentriert sich daher auf die optimale Verwendung von Azure Cache für Redis in Szenarien, in denen zusätzliche Leseleistung und Datenzugriffsdauer erforderlich sind.

Entwurfsaspekte

• Eine Zwischenspeicherungsebene bietet zusätzliche Datenzugriffsdauer, da auch dann, wenn sich ein Ausfall auf die zugrunde liegenden Datentechnologien auswirkt, über die Zwischenspeicherungsschicht weiterhin auf eine Anwendungsdatenmomentaufnahme zugreifen kann.

• In bestimmten Arbeitsauslastungsszenarien kann die Zwischenspeicherung im Arbeitsspeicher innerhalb der Anwendungsplattform selbst implementiert werden.

Azure Cache for Redis

• Redis cache is an open source NoSQL key-value in-memory storage system.

• Die Enterprise- und Enterprise Flash-Ebenen können in einer aktiven Konfiguration in Verfügbarkeitszonen innerhalb einer Region und verschiedenen Azure-Regionen über die Georeplikation bereitgestellt werden.

  • Bei der Bereitstellung über mindestens drei Azure-Regionen und drei oder mehr Verfügbarkeitszonen in jeder Region, wobei die aktive Georeplikation für alle Cacheinstanzen aktiviert ist, bietet Azure Cache für Redis eine SLA von 99,999 % für die Konnektivität mit einem regionalen Cacheendpunkt.
  • Wenn sie in drei Verfügbarkeitszonen innerhalb einer einzelnen Azure-Region bereitgestellt wird, wird eine SLA zur Konnektivität von 99,99 % bereitgestellt.

• Die Enterprise Flash-Ebene wird auf einer Kombination aus RAM- und Flashspeicher ausgeführt, der nicht veränderlich ist, und dies führt zu einer geringen Leistungseinbußen, die auch sehr große Cachegrößen ermöglicht, bis zu 13 TB mit Clustering.

• Bei der Georeplikation gelten zusätzlich zu den direkten Kosten, die mit Cacheinstanzen verbunden sind, Gebühren für die Datenübertragung zwischen Regionen.

• Das Feature "Geplante Updates" enthält keine Azure-Updates oder -Updates, die auf das zugrunde liegende VM-Betriebssystem angewendet werden.

• Während eines Skalierungsvorgangs wird die CPU-Auslastung erhöht, während Daten zu neuen Instanzen migriert werden.

Entwurfsempfehlungen

• Erwägen Sie eine optimierte Zwischenspeicherungsebene für Szenarien mit „heißen“ Daten, um den Lesedurchsatz zu erhöhen und die Antwortzeiten zu verbessern.

• Wenden Sie geeignete Richtlinien für Cacheablauf und Housekeeping an, um ein endloses Datenwachstum zu vermeiden.

  • Erwägen Sie das Festlegen des Ablaufs von Cachelementen, wenn sich die Sicherungsdaten ändern.

Azure Cache for Redis

• Verwenden Sie die Premium- oder Enterprise-SKU, um Zuverlässigkeit und Leistung zu maximieren.

  • Bei Szenarien mit extrem großen Datenvolumen sollte die Enterprise Flash-Ebene in Erwägung gezogen werden.
  • In Szenarien, in denen nur die passive Georeplikation erforderlich ist, kann auch der Premium-Tarif in Betracht gezogen werden.

• Stellen Sie Replikatinstanzen mithilfe der Georeplikation in einer aktiven Konfiguration in allen betrachteten Bereitstellungsregionen bereit.

• Stellen Sie sicher, dass Replikatinstanzen über Verfügbarkeitszonen in jeder als Azure-Region betrachteten Region bereitgestellt werden.

• Verwenden Sie Azure Monitor, um Azure Cache für Redis auszuwerten.

  • Berechnen Sie eine Integritätsbewertung für regionale Cachekomponenten, um die Integrität im Verhältnis zu geschäftlichen Anforderungen und der Ressourcenauslastung zu beobachten.
  • Beobachten und warnen Sie bei wichtigen Metriken wie hoher CPU-Auslastung, hoher Arbeitsspeicherauslastung, hoher Serverlast und gelöschten Schlüsseln für Einblicke, wann der Cache skaliert werden soll.

• Optimieren Sie die Verbindungsresilienz , indem Sie Wiederholungslogik, Timeouts und eine Singleton-Implementierung des Redis-Verbindungs-Multiplexers implementieren.

• Konfigurieren Sie geplante Updates , um die Tage und Uhrzeiten zu verschreiben, die Redis Server-Updates auf den Cache angewendet werden.

Analytische Szenarien

Es ist immer häufiger für unternehmenskritische Anwendungen üblich, analytische Szenarien als Mittel zu betrachten, um zusätzlichen Wert aus erfassten Datenflüssen zu fördern. Anwendungs- und Betriebsanalysen (AIOps) bilden daher einen entscheidenden Aspekt der hochversicherten Datenplattform.

Analytische und transaktionsbezogene Workloads erfordern unterschiedliche Datenplattformfunktionen und Optimierungen für eine akzeptable Leistung in ihren jeweiligen Kontexten.

Beschreibung	Analytisch	Transaktionen
Anwendungsfall	Analysieren sehr großer Datenmengen ("Big Data")	Verarbeiten sehr großer Mengen einzelner Transaktionen
Optimiert für	Lesen von Abfragen und Aggregationen über viele Datensätze	Nahezu echtzeitbasierte CruD-Abfragen (Create/Read/Update/Delete) über wenige Datensätze
Hauptmerkmale	- Konsolidieren aus Datensatzquellen - Spaltenbasierter Speicher - Verteilter Speicher - Parallele Verarbeitung -Denormalisierten - Lese- und Schreibvorgänge mit geringer Parallelität – Optimieren des Speichervolumes mit Komprimierung	- Datenquelle des Datensatzes für die Anwendung - Zeilenbasierter Speicher - Zusammenhängende Lagerung - Symmetrische Verarbeitung -Normalisiert - Hohe Parallelitätslese- und Schreibvorgänge, Indexaktualisierungen – Optimieren des schnellen Datenzugriffs mit Speicher im Arbeitsspeicher

Azure Synapse bietet eine unternehmensanalytische Plattform, die relationale und nicht relationale Daten mit Spark-Technologien zusammenführt, wobei die integrierte Integration in Azure-Dienste wie Azure Cosmos DB verwendet wird, um Big Data Analytics zu erleichtern. Die Designüberlegungen und Empfehlungen in diesem Abschnitt konzentrieren sich daher auf optimale Nutzung von Azure Synapse und Azure Cosmos DB für analytische Szenarien.

Entwurfsaspekte

• In der Regel werden umfangreiche Analyseszenarien durch die Extraktion von Daten auf eine separate Datenplattform unterstützt, die für nachfolgende analytische Abfragen optimiert ist.
  • Extrahieren, Transformieren und Laden (ETL)-Pipelines werden zum Extrahieren von Daten verwendet, was den Durchsatz und die Leistung der Transaktionsauslastung beeinträchtigt.
  • Die Ausführung von ETL-Pipelines führt selten dazu, Durchsatz- und Leistungseinbußen zu reduzieren, was zu analyserelevanten Daten führt, die weniger aktuell sind.
  • Der ETL-Pipelineentwicklungs- und Wartungsaufwand erhöht sich, da Datentransformationen komplexer werden.
    • Wenn z. B. Quelldaten häufig geändert oder gelöscht werden, müssen ETL-Pipelines diese Änderungen in den Zieldaten für Analyseabfragen durch einen additiven/versionsgesteuerten Ansatz, das Abbilden und Neuladen oder direkte Änderungen an den Analysedaten berücksichtigen. Jede dieser Ansätze hat abgeleitete Auswirkungen, z. B. die Index-Neuerstellung oder Aktualisierung.

Azure Cosmos DB

• Analytische Abfragen, die auf Transaktionsdaten von Azure Cosmos DB ausgeführt werden, werden in der Regel über Partitionen über große Datenmengen aggregiert, was einen erheblichen Anforderungseinheitsdurchsatz (REQUEST Unit, RU) verbraucht, was sich auf die Leistung der umgebenden Transaktionsworkloads auswirken kann.

• Der Azure Cosmos DB Analytical Store bietet einen schematisierten, vollständig isolierten spaltenorientierten Datenspeicher, der umfangreiche Analysen für Azure Cosmos DB-Daten aus Azure Synapse ohne Auswirkungen auf Transaktionsarbeitslasten von Azure Cosmos DB ermöglicht.

  • Wenn ein Azure Cosmos DB-Container als Analytical Store aktiviert ist, wird intern ein neuer Spaltenspeicher aus den Betriebsdaten im Container erstellt. Dieser Spaltenspeicher wird getrennt vom zeilenorientierten Transaktionsspeicher für den Container beibehalten.
  • Erstellungs-, Aktualisierungs- und Löschvorgänge für die Betriebsdaten werden automatisch mit dem Analytischen Speicher synchronisiert, sodass keine Änderungsfeed- oder ETL-Verarbeitung erforderlich ist.
  • Die Datensynchronisierung vom betriebsbereiten mit dem Analytischen Speicher verbraucht keine Durchsatzanforderungseinheiten (RUs), die im Container oder in der Datenbank bereitgestellt werden. Es gibt keine Auswirkungen auf die Leistung von Transaktionsworkloads. Der analytische Speicher erfordert keine Zuordnung zusätzlicher RUs für eine Azure Cosmos DB-Datenbank oder einen Container.
  • Die automatische Synchronisierung ist der Prozess, bei dem Betriebsdatenänderungen automatisch mit dem Analytischen Speicher synchronisiert werden. Die Automatische Synchronisierungslatenz beträgt in der Regel weniger als zwei (2) Minuten.
    • Die Automatische Synchronisierungslatenz kann bis zu fünf (5) Minuten für eine Datenbank mit freigegebenem Durchsatz und einer großen Anzahl von Containern betragen.
    • Sobald die automatische Synchronisierung abgeschlossen ist, können die neuesten Daten aus Azure Synapse abgefragt werden.
  • Der Analysespeicherspeicher verwendet ein verbrauchsbasiertes Preismodell , das für das Datenvolumen und die Anzahl der Lese- und Schreibvorgänge berechnet wird. Die Preise für analytische Stores unterscheiden sich von den Preisen für Transaktionsspeicher.

• Mit Azure Synapse Link kann der Azure Cosmos DB Analytical Store direkt aus Azure Synapse abgefragt werden. Dies ermöglicht no-ETL, Hybrid Transactional-Analytical Processing (HTAP) von Synapse, sodass Azure Cosmos DB-Daten zusammen mit anderen analytischen Workloads von Synapse in nahezu Echtzeit abgefragt werden können.

• Der Azure Cosmos DB Analytical Store ist standardmäßig nicht partitioniert.

  • Bei bestimmten Abfrageszenarien wird die Leistung verbessert, indem Analytische Speicherdaten mithilfe von Schlüsseln partitioniert werden, die häufig in Abfrage-Prädikaten verwendet werden.
  • Die Partitionierung wird durch einen Auftrag in Azure Synapse ausgelöst, der ein Spark-Notizbuch mit Synapse Link ausführt, das die Daten aus dem Azure Cosmos DB Analytical Store lädt und in den partitionierten Synapse-Speicher im primären Speicherkonto des Synapse-Arbeitsbereichs schreibt.

• Azure Synapse Analytics SQL Serverless-Pools können den Analytischen Speicher über automatisch aktualisierte Ansichten oder befehle SELECT / OPENROWSET abfragen.

• Azure Synapse Analytics Spark Pools können den Analytischen Speicher über automatisch aktualisierte Spark-Tabellen oder den spark.read Befehl abfragen.

• Daten können auch aus dem Azure Cosmos DB Analytical Store in einen dedizierten Synapse SQL-Pool mit Spark kopiert werden, sodass bereitgestellte Azure Synapse SQL-Poolressourcen verwendet werden können.

• Azure Cosmos DB Analytical Store-Daten können mit Azure Synapse Spark abgefragt werden.

  • Spark-Notizbücher ermöglichen Spark-Datenframe-Kombinationen zum Aggregieren und Transformieren von Azure Cosmos DB-Analysedaten mit anderen Datensätzen und verwenden andere erweiterte Synapse Spark-Funktionen, einschließlich des Schreibens transformierter Daten in andere Speicher oder schulungen AIOps Machine Learning-Modelle.

• Der Azure Cosmos DB-Änderungsfeed kann auch verwendet werden, um einen separaten sekundären Datenspeicher für Analyseszenarien zu verwalten.

Azure Synapse

• Azure Synapse vereint Analysefunktionen, einschließlich SQL Data Warehouse, Spark Big Data und Data Explorer für Protokoll- und Zeitreihenanalysen.

  • Azure Synapse verwendet verknüpfte Dienste , um Verbindungen mit anderen Diensten wie Azure Storage zu definieren.
  • Daten können über Copy-Aktivität aus unterstützten Quellen in Synapse Analytics aufgenommen werden. Dies ermöglicht die Datenanalyse in Synapse ohne Auswirkungen auf den Quelldatenspeicher, fügt jedoch zeit-, Kosten- und Latenzaufwand aufgrund der Datenübertragung hinzu.
  • Daten können auch in unterstützten externen Speichern direkt abgefragt werden, was den Aufwand der Datenaufnahme und -bewegung verhindert. Azure Storage mit Data Lake Gen2 ist ein unterstützter Speicher für Synapse und Log Analytics exportierte Daten können über Synapse Spark abgefragt werden.

• Azure Synapse Studio vereint Aufnahme- und Abfrageaufgaben.

  • Quelldaten, einschließlich Azure Cosmos DB Analytical Store-Daten und Log Analytics-Exportdaten, werden abgefragt und verarbeitet, um Business Intelligence und andere aggregierte analytische Anwendungsfälle zu unterstützen.

Entwurfsempfehlungen

• Stellen Sie sicher, dass analytische Workloads keine Auswirkungen auf transaktionale Anwendungsworkloads haben, um die Transaktionsleistung aufrechtzuerhalten.

Anwendungsanalyse

• Verwenden Sie Azure Synapse Link mit Azure Cosmos DB Analytical Store, um Analysen zu Azure Cosmos DB-Betriebsdaten durchzuführen, indem Sie einen optimierten Datenspeicher erstellen, der sich nicht auf die Transaktionsleistung auswirkt.

  • Aktivieren Sie den Azure Synapse-Link für Azure Cosmos DB-Konten.
  • Erstellen Sie einen Container, der für den Analytischen Speicher aktiviert ist, oder aktivieren Sie einen vorhandenen Container für den Analytischen Speicher.
  • Verbinden Sie den Azure Synapse-Arbeitsbereich mit dem Azure Cosmos DB Analytical Store , um analytische Workloads in Azure Synapse zum Abfragen von Azure Cosmos DB-Daten zu ermöglichen. Verwenden Sie eine Verbindungszeichenfolge mit einem schreibgeschützten Azure Cosmos DB-Schlüssel.

• Priorisieren Sie azure Cosmos DB Analytical Store mit Azure Synapse Link, anstatt den Azure Cosmos DB-Änderungsfeed zu verwenden, um einen analytischen Datenspeicher zu verwalten.

  • Der Azure Cosmos DB-Änderungsfeed eignet sich möglicherweise für sehr einfache analytische Szenarien.

AIOps und Operational Analytics

• Erstellen Sie einen einzelnen Azure Synapse-Arbeitsbereich mit verknüpften Diensten und Datensätzen für jedes Azure Storage-Quellkonto, an das Betriebsdaten aus Ressourcen gesendet werden.

• Erstellen Sie ein dediziertes Azure Storage-Konto, und verwenden Sie es als primäres Arbeitsbereichsspeicherkonto, um die Daten und Metadaten des Synapse-Arbeitsbereichkatalogs zu speichern. Konfigurieren Sie ihn mit hierarchischem Namespace, um Azure Data Lake Gen2 zu aktivieren.

  • Trennen Sie die Trennung zwischen den Quellanalysedaten und Synapse-Arbeitsbereichsdaten und Metadaten.
    • Verwenden Sie keins der regionalen oder globalen Azure Storage-Konten, bei denen Betriebsdaten gesendet werden.

Nächster Schritt

Überprüfen Sie die Überlegungen zu Netzwerkaspekten.

Netzwerk und Konnektivität