Überlegungen zur Datenplattform für unternehmenskritische Workloads in Azure

Die Auswahl einer effektiven Anwendungsdatenplattform ist ein weiterer entscheidender Entscheidungsbereich, der weitreichende Auswirkungen auf andere Entwurfsbereiche hat. Azure bietet letztendlich eine Vielzahl relationaler, nicht relationaler und analytischer Datenplattformen, die sich in ihren Funktionen stark unterscheiden. Daher ist es wichtig, dass wichtige nicht funktionale Anforderungen zusammen mit anderen Entscheidungsfaktoren wie Konsistenz, Bedienbarkeit, Kosten und Komplexität vollständig berücksichtigt werden. Beispielsweise hat die Möglichkeit, in einer Schreibkonfiguration mit mehreren Regionen zu arbeiten, einen entscheidenden Einfluss auf die Eignung für eine global verfügbare Plattform.

Dieser Entwurfsbereich erweitert das Anwendungsdesign und bietet wichtige Überlegungen und Empfehlungen für die Auswahl einer optimalen Datenplattform.

Wichtig

Dieser Artikel ist Teil der Unternehmenskritisch-Workloadreihe von Azure Well-Architected . Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit einer unternehmenskritischen Workload zu beginnen?

Die vier Vs von Big Data

Die "Four Vs of Big Data" bieten ein Framework, um die erforderlichen Merkmale einer hochverfügbaren Datenplattform besser zu verstehen und zu verstehen, wie Daten zur Maximierung des Geschäftswerts verwendet werden können. In diesem Abschnitt wird daher untersucht, wie die Merkmale Volume, Velocity, Variety und Veracity auf konzeptioneller Ebene angewendet werden können, um den Entwurf einer Datenplattform mit geeigneten Datentechnologien zu unterstützen.

• Volume: Wie viele Daten zur Speicherkapazität und tiering-Anforderungen kommen , das ist die Größe des Datasets.
• V-Elocity: Die Geschwindigkeit, mit der Daten verarbeitet werden, entweder als Batches oder als fortlaufende Datenströme, d. h. die Flussrate.
• Variety: das organization und Format von Daten, das strukturierte, teilweise strukturierte und unstrukturierte Formate erfasst, d. h. Daten über mehrere Speicher oder Typen hinweg.
• Veracity: Umfasst die Provenienz und Zusammenstellung der betrachteten Datasets für Governance und Datenqualitätssicherung, also die Genauigkeit der Daten.

Entwurfsaspekte

Umfang

• Vorhandene (falls vorhanden) und erwartete zukünftige Datenvolumen basierend auf prognostizierten Datenwachstumsraten, die an den Geschäftszielen und Plänen ausgerichtet sind.

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

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

• Das Datenvolumen kann sich erheblich auf die Abfrageleistung der Datenplattform auswirken.

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

  • Wird dies zu Ausfallzeiten führen? und wenn ja, wie lange?
  • Was sind die Entschärfungsverfahren? 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 von verschiedenen Anwendungskomponenten ausgegeben werden, und die Anforderungen an den Durchsatz, wie schnell Daten committet und abgerufen werden müssen, sind entscheidend für die Bestimmung einer optimalen Datentechnologie für wichtige Workloadszenarien.

  • Die Art der Durchsatzanforderungen unterscheidet sich je nach Workloadszenario, z. B. lese- oder schreibintensiv.
    • Analytische Workloads müssen beispielsweise in der Regel einen großen Lesedurchsatz bieten.
  • Wie lautet der erforderliche Durchsatz? Und wie wird erwartet, dass der Durchsatz steigt?
  • Welche Datenlatenzanforderungen gelten bei P50/P99 unter Verweislastebenen?

• Funktionen wie die Unterstützung eines Entwurfs ohne Sperren, Indexoptimierung und Konsistenzrichtlinien sind entscheidend, um einen hohen Durchsatz zu erzielen.

  • Die Optimierung der Konfiguration für einen hohen Durchsatz verursacht Kompromisse, die vollständig verstanden werden sollten.
  • Persistenz- und Messagingmuster für den Lastenausgleich, z. B. CQRS und Ereignissourcierung, können 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 Durchsatzeinbrüchen können je nach Workloadszenario variieren.

  • Wird es zu Verbindungsunterbrechungen kommen?
  • Geben einzelne Vorgänge Fehlercodes zurück, während die Steuerungsebene weiterhin ausgeführt wird?
  • Wird die Datenplattform die Drosselung aktivieren, und wenn ja, wie lange?

• Die grundlegende Anwendungsentwurfsempfehlung für die Verwendung einer aktiv/aktiv-geografischen Verteilung stellt Herausforderungen in Bezug auf die Datenkonsistenz bereit.

  • Es gibt einen Kompromiss zwischen Konsistenz und Leistung in Bezug auf vollständige ACID-Transaktionssemantik und herkömmliches Sperrverhalten.
    • Die Minimierung der Schreiblatenz geht zu Lasten der Datenkonsistenz.

• In einer Schreibkonfiguration mit mehreren Regionen müssen Änderungen synchronisiert und zwischen allen Replikaten zusammengeführt werden, wobei ggf. eine Konfliktlösung erforderlich ist. Dies kann sich auf Leistungsstufen und Skalierbarkeit auswirken.

• Schreibgeschützte Replikate (regionsintern und regionsübergreifend) können verwendet werden, um die Roundtriplatenz und die Verteilung von Datenverkehr zu minimieren, um Leistung, Durchsatz, Verfügbarkeit und Skalierbarkeit zu steigern.

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

  • Cacheablaufzeiten und -richtlinien 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 sie ein Variablenschema oder nicht relationales Datenmodell unterstützen?
  • Wie fragt die Anwendung Daten ab? Und werden Abfragen von Konzepten auf Datenbankebene wie relationalen Joins abhängen? Oder stellt die Anwendung eine solche Semantik bereit?

• Die Art von Datasets, die von der Anwendung berücksichtigt werden, kann variiert werden, von unstrukturierten Inhalten wie Bildern und Videos bis zu strukturierten Dateien wie CSV und Parquet.

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

• Neben relationalen oder nicht relationalen Datenplattformen können auch Graph- oder Schlüssel-Wert-Datenplattformen für bestimmte Datenworkloads geeignet sein.

  • Einige Technologien eignen sich für Datenmodelle mit variablen Schemas, bei denen Datenelemente semantisch ähnlich sind und/oder zusammen gespeichert und abgefragt werden, sich aber strukturell unterscheiden.

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

  • Entwurfsmuster wie SAGA können angewendet werden, um Konsistenz und Abhängigkeiten zwischen verschiedenen Datenspeichern zu verwalten.
    • Direkte Datenbankabfragen können Einschränkungen für die gemeinsame Position erzwingen.
  • Die Verwendung mehrerer Datentechnologien erhöht einen gewissen Verwaltungsaufwand, um umfassende Technologien aufrechtzuerhalten.

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

• Funktionen für eine optimierte Ausrichtung mit dem Datenmodell und den eingeschlossenen Datentypen wirken sich stark auf Entscheidungen der Datenplattform 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 mehrfarbige Speicherung für verschiedene Arten von Datenstrukturen.

  • Analytische Laufzeitumgebungen wie Apache Spark können Integrationseinschränkungen für die Analyse polygloter Datenstrukturen aufweisen.

• Im Unternehmenskontext können der Einsatz vorhandener Prozesse und Tools sowie die Kontinuität der Fähigkeiten einen erheblichen Einfluss auf den Entwurf und die Auswahl von Datentechnologien haben.

Richtigkeit

• 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.
  • Änderungsmanagement und Schemaentwicklung.
  • Abhängigkeiten zwischen Datasets.

• In jeder verteilten Anwendung mit mehreren Datenreplikaten besteht ein Kompromiss zwischen Konsistenz und Latenz, wie in den CAP - und PACELC-Theoremen ausgedrückt.

  • Wenn Leser und Writer eindeutig verteilt sind, muss eine Anwendung entweder die schnellste verfügbare Version eines Datenelements zurückgeben, auch wenn es veraltet ist, im Vergleich zu einem gerade abgeschlossenen Schreibvorgang (Update) dieses Datenelements in einem anderen Replikat, oder die aktuellste Version des Datenelements, was zu einer zusätzlichen Latenz führen kann, um den neuesten Zustand zu ermitteln und abzurufen.
  • Konsistenz und Verfügbarkeit können auf Plattformebene oder auf einzelner Datenanforderungsebene konfiguriert werden.
  • Wie ist die Benutzererfahrung, wenn Daten von einem Replikat bereitgestellt werden sollten, das dem Benutzer am nächsten liegt und nicht den neuesten Zustand eines anderen Replikats widerspiegelt? d.h. kann die Anwendungsunterstützung möglicherweise veraltete Daten bereitstellen?

• Wenn in einem Schreibkontext mit mehreren Regionen dasselbe Datenelement in zwei separaten Schreibreplikaten geändert wird, bevor eine änderung repliziert werden kann, wird ein Konflikt erstellt, der gelöst werden muss.

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

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

• Die Verschlüsselung ruhender Daten kann in der Anwendungsebene mithilfe der clientseitigen Verschlüsselung und/oder der Datenebene mithilfe serverseitiger Verschlüsselung implementiert werden, falls erforderlich.

• Azure unterstützt verschiedene Verschlüsselungsmodelle, einschließlich serverseitiger Verschlüsselung, die dienstseitig verwaltete Schlüssel, kundenseitig verwaltete Schlüssel in Key Vault oder kundenseitig verwaltete Schlüssel auf kundengesteuerter Hardware verwendet.

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

• Die Datenverbindungsverschlüsselung MACsec (IEEE 802.1AE MAC) wird verwendet, um den gesamten Datenverkehr zwischen Azure-Rechenzentren im Microsoft-Backbonenetzwerk zu schützen.

  • Pakete werden vor dem Senden auf den Geräten verschlüsselt und entschlüsselt, um physische Man-in-the-Middle- oder Snooping-/Abhörangriffe zu verhindern.

• Authentifizierung und Autorisierung für die Daten- und Steuerungsebene.

  • Wie authentifiziert und autorisiert die Datenplattform anwendungs- und betriebsbereiten Zugriff?

• Beobachtbarkeit durch Überwachung der Plattformintegrität und des Datenzugriffs.

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

Entwurfsempfehlungen

Umfang

• Stellen Sie sicher, dass zukünftige Datenvolumen im Zusammenhang mit dem organischen Wachstum die Datenplattformfunktionen nicht überschreiten.

  • 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 die zugrunde liegenden Daten möglicherweise repliziert werden, was einige Zeit in Anspruch nimmt und während der Replikation wahrscheinlich zu Leistungseinbußen führt. Stellen Sie daher nach Möglichkeit sicher, dass diese Vorgänge außerhalb kritischer Geschäftszeiten ausgeführt werden.

• Definieren Sie Anwendungsdatenebenen, um Datasets basierend auf Nutzung und Kritikalität zu klassifizieren, um das Entfernen oder Auslagern älterer Daten zu erleichtern.

  • Erwägen Sie die Klassifizierung von Datasets in die Ebenen "heiß", "warm" und "kalt" ('Archiv').
    • Beispielsweise verwenden die grundlegenden Referenzimplementierungen Azure Cosmos DB, um "heiße" Daten zu speichern, die von der Anwendung aktiv verwendet werden, während Azure Storage für "kalte" Betriebsdaten zu Analysezwecken verwendet wird.

• Konfigurieren Sie Housekeeping-Verfahren, um das Datenwachstum zu optimieren und die Dateneffizienz zu steigern, z. B. die Abfrageleistung und die Verwaltung der Datenerweiterung.

  • Konfigurieren Sie den Ablauf der Laufzeit (Time-To-Live, TTL) für Daten, die nicht mehr benötigt werden und keinen langfristigen analytischen Wert 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.
  • Erfassen Sie Datenplattformtelemetriedaten und Nutzungsstatistiken, damit DevOps-Teams die Housekeepinganforderungen und Datenspeicher mit der richtigen Größe kontinuierlich auswerten können.

• In Übereinstimmung mit einem Microservice-Anwendungsentwurf sollten Sie die Verwendung mehrerer verschiedener Datentechnologien parallel mit optimierten Datenlösungen für bestimmte Workloadszenarien und Volumenanforderungen in Betracht ziehen.

  • 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 mit 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.

• Ladeebene durch die Verwendung von asynchronem, nicht blockierenden Messaging, z. B. mithilfe des CQRS - oder Event Sourcing-Musters .

  • Zwischen Schreibanforderungen und dem Zeitpunkt, an dem neue Daten zum Lesen verfügbar sind, kann es zu Wartezeiten kommen, was sich auf die Benutzerfreundlichkeit auswirken kann.
    • Diese Auswirkungen müssen im Kontext wichtiger geschäftsbezogener Anforderungen verstanden und akzeptabel sein.

• Stellen Sie agile Skalierbarkeit sicher, um variable Durchsatz- und Auslastungsstufen zu unterstützen.

  • Wenn die Auslastungsebenen sehr volatil sind, sollten Sie die Überbereitstellung von Kapazitätsstufen in Erwägung ziehen, um sicherzustellen, dass Durchsatz und Leistung erhalten bleiben.
  • 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 mit den geschäftsspezifischen Anforderungen übereinstimmen.
  • 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 späterer Engineeringinvestitionen angewendet werden können.

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

• Überschüssiger 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 "heiße" Datenszenarien, um die Antwortzeiten zu minimieren.

  • Wenden Sie geeignete Richtlinien für Cacheablauf und House-Keeping an, um ein auslaufendes Datenwachstum zu vermeiden.
    • Ablaufen von Cacheelementen, wenn sich die Sicherungsdaten ändern.
    • Wenn der Cacheablauf streng auf Time-To-Live (TTL) basiert, müssen die Auswirkungen und die Kundenfreundlichkeit der Bereitstellung veralteter Daten verstanden werden.

Vielfalt

• In Übereinstimmung mit dem Prinzip eines cloudbasierten und azure-nativen Designs wird dringend empfohlen, verwaltete Azure-Dienste zu priorisieren, um die Komplexität von Betrieb und Verwaltung zu verringern und die zukünftigen Plattforminvestitionen von Microsoft zu nutzen.

• In Übereinstimmung mit dem Anwendungsentwurfsprinzip von lose gekoppelten Microservicearchitekturen können einzelne Dienste unterschiedliche Datenspeicher und szenariooptimierte Datentechnologien 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/jedes SDK auf die gleiche Weise verfügbar.

Richtigkeit

• 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 auf Verfügbarkeitszonen (AZs) innerhalb einer Region (oder verwenden Sie zonenredundante Dienstebenen), um die Verfügbarkeit innerhalb der Region zu maximieren.

• Wenn Konsistenzanforderungen dies zulassen, verwenden Sie einen Entwurf für Schreibdatenplattformen mit mehreren Regionen, um die globale Verfügbarkeit und Zuverlässigkeit zu maximieren.

  • Berücksichtigen Sie geschäftliche Anforderungen für die Konfliktlösung, wenn dasselbe Datenelement in zwei separaten Schreibreplikaten geändert wird, bevor beide Änderungen repliziert werden können und so einen Konflikt erzeugen.
    • Verwenden Sie nach Möglichkeit standardisierte Konfliktlösungsrichtlinien wie "Letzte gewinnt".
      • 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 Sie Sicherungs- und Wiederherstellungsfunktionen sowie Failovervorgänge durch Chaostests innerhalb von Continuous Delivery-Prozessen.

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

  • Stellen Sie sicher, dass Continuous Delivery-Prozesse Auslastungstests anhand bekannter Leistungsvergleichstests 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 in eine breitere Organisationsimplementierung ist es wichtig, dass ein anwendungsorientierter Ansatz für die Bereitstellung und den Betrieb von Datenplattformkomponenten in einem Anwendungsentwurf angewendet wird.

Um die Zuverlässigkeit zu maximieren, ist es wichtig, dass einzelne Datenplattformkomponenten angemessen auf die Anwendungsintegrität reagieren, und zwar durch operative Aktionen, die andere Anwendungskomponenten enthalten können. Beispielsweise ist in einem Szenario, in dem zusätzliche Datenplattformressourcen benötigt werden, wahrscheinlich die Skalierung der Datenplattform zusammen mit anderen Anwendungskomponenten nach einem Kapazitätsmodell erforderlich, möglicherweise durch die Bereitstellung zusätzlicher Skalierungseinheiten. Dieser Ansatz wird letztendlich eingeschränkt, wenn ein zentralisiertes Betriebsteam stark abhängig ist, um Probleme im Zusammenhang mit der Datenplattform isoliert zu behandeln.

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

Weitere Verweise

Weitere Anleitungen zur Datenplattform finden Sie im Azure-Anwendung-Architekturhandbuch.

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

Global verteilter Schreibdatenspeicher mit mehreren Regionen

Um die global verteilten Aktiv-Aktiv-Ambitionen eines Anwendungsentwurfs vollständig zu berücksichtigen, empfiehlt es sich dringend, eine verteilte Schreibdatenplattform für mehrere Regionen in Betracht zu ziehen, bei der Änderungen an separaten schreibbaren Replikaten synchronisiert und zwischen allen Replikaten zusammengeführt werden, wobei bei Bedarf konfliktlösend ist.

Wichtig

Die Microservices erfordern möglicherweise nicht alle einen verteilten Schreibdatenspeicher mit mehreren Regionen. Daher sollten der Architekturkontext und die geschäftlichen Anforderungen jedes Workloadszenarios berücksichtigt werden.

Azure Cosmos DB bietet einen global verteilten und hochverfügbaren NoSQL-Datenspeicher, der schreibbare Schreibvorgänge in mehreren Regionen und eine sofort einsatzbereite Konsistenz bietet. Die Entwurfsüberlegungen und Empfehlungen in diesem Abschnitt konzentrieren sich daher auf eine optimale Nutzung von Azure Cosmos DB.

Überlegungen zum Entwurf

Azure Cosmos DB

• Azure Cosmos DB speichert Daten in Containern, bei denen es sich um indizierte, zeilenbasierte Transaktionsspeicher handelt, die für schnelle Transaktionslese- und Schreibvorgänge mit Antwortzeiten in der Größenordnung von Millisekunden ausgelegt sind.

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

  • Azure Cosmos DB for NoSQL bietet den größten Funktionsumfang und ist in der Regel die API, bei der neue Funktionen zuerst verfügbar werden.

• Azure Cosmos DB unterstützt Gateway- und Direct-Konnektivitätsmodi, wobei Direct die Konnektivität über TCP mit Back-End-Azure Cosmos DB-Replikatknoten erleichtert, um die Leistung mit weniger Netzwerkhops zu verbessern, während Gateway HTTPS-Konnektivität für Front-End-Gatewayknoten bereitstellt.

  • Der direkte Modus ist nur bei Verwendung von Azure Cosmos DB for NoSQL verfügbar und wird derzeit nur auf .NET- und Java SDK-Plattformen unterstützt.

• In Regionen, in denen Verfügbarkeitszonen aktiviert sind, bietet Azure Cosmos DB Unterstützung für Verfügbarkeitszonenredundanz (Availability Zone, AZ) für Hochverfügbarkeit und Resilienz bei Zonenfehlern innerhalb einer Region.

• Azure Cosmos DB verwaltet vier Replikate von Daten in einer einzelnen Region. Wenn die Verfügbarkeitszonenredundanz (Az) aktiviert ist, stellt Azure Cosmos DB sicher, dass Datenreplikate in mehreren AZs platziert werden, um sich vor Zonenfehlern zu schützen.

  • Das Paxos-Konsensprotokoll wird angewendet, um das Quorum für Replikate innerhalb einer Region zu erreichen.

• Ein Azure Cosmos DB-Konto kann problemlos für die Replikation von Daten in mehreren Regionen konfiguriert werden, um das Risiko zu verringern, dass eine einzelne Region nicht mehr verfügbar ist.

  • Die Replikation kann entweder mit Schreibvorgängen in einer einzelnen Region oder mit Schreibvorgängen in mehreren Regionen konfiguriert werden.
    • Bei Schreibvorgängen in einer einzelnen Region wird eine primäre "Hub"-Region verwendet, um alle Schreibvorgänge zu verarbeiten. Wenn diese "Hub"-Region nicht mehr verfügbar ist, muss ein Failovervorgang durchgeführt werden, um eine andere Region als beschreibbar hochzustufen.
    • 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 restlichen Regionen verwendet, um Schreibdatenverkehr zu verarbeiten.

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

• Azure Cosmos DB bietet zwei Konfliktlösungsrichtlinien, die angewendet werden können, um Konflikte automatisch zu beheben.

  • Last Write Wins (LWW) wendet ein Zeitsynchronisierungsuhrprotokoll an, das eine systemdefinierte Zeitstempeleigenschaft _ts als Konfliktlösungspfad verwendet. Wenn ein Konflikt besteht, wird das Element mit dem höchsten Wert für den Konfliktlösungspfad zum Gewinner, und wenn mehrere Elemente denselben numerischen Wert haben, wählt das System einen Gewinner aus, sodass alle Regionen zu derselben Version des committeten Elements konvergieren können.
    • Bei Löschkonflikten gewinnt die gelöschte Version unabhängig vom Wert des Konfliktlösungspfads immer entweder das Einfügen oder Ersetzen von Konflikten.
    • „Letzter Schreibvorgang gewinnt“ (Last Write Wins, LWW) ist der standardmäßige Konfliktauflösungsmodus.
    • Bei Verwendung von Azure Cosmos DB for NoSQL kann eine benutzerdefinierte numerische Eigenschaft wie eine benutzerdefinierte Zeitstempeldefinition zur Konfliktlösung verwendet werden.
  • Benutzerdefinierte Lösungsrichtlinien ermöglichen anwendungsdefinierte Semantik zum Ausgleich von Konflikten mithilfe einer registrierten gespeicherten Mergeprozedur, 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 for NoSQL verfügbar und kann nur zum Zeitpunkt der Containererstellung festgelegt werden.

• In einer Schreibkonfiguration mit mehreren Regionen besteht eine Abhängigkeit von einer einzelnen Azure Cosmos DB-Hubregion, um alle Konfliktlösungen durchzuführen, wobei das Paxos-Konsensprotokoll angewendet wird, um das Quorum für replikatübergreifende Replikate innerhalb der Hubregion zu erreichen.

  • Die Plattform stellt einen Nachrichtenpuffer für Schreibkonflikte innerhalb der Hubregion bereit, um die Ladeebene zu erreichen, und bietet Redundanz für vorübergehende Fehler.
    • Der Puffer kann Schreibupdates im Wert von einigen Minuten speichern, die einen Konsens erfordern.

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

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

  • Eine Prioritätsreihenfolge 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, um eine optimale Leistung und Verfügbarkeit zu erzielen.

• Bei der Bereitstellung mit einer einzelnen Schreibregion kann Azure Cosmos DB für das automatische Failover basierend auf einer definierten Failoverpriorität unter Berücksichtigung aller Leseregionreplikate konfiguriert werden.

• Die von der Azure Cosmos DB-Plattform bereitgestellte RTO beträgt ca. 10 bis 15 Minuten, wobei die verstrichene Zeit zum Ausführen eines regionalen Failovers des Azure Cosmos DB-Diensts erfasst wird, wenn sich ein katastrophaler Notfall auf die Hubregion auswirkt.

  • Diese RTO ist auch in einem Schreibkontext mit mehreren Regionen relevant, da die Abhängigkeit von einer einzelnen "Hub"-Region für die Konfliktlösung besteht.
    • Wenn die "Hub"-Region nicht mehr verfügbar ist, schlagen Schreibvorgänge in andere Regionen fehl, nachdem der Nachrichtenpuffer gefüllt wurde, da die Konfliktlösung erst auftreten kann, wenn der Dienst ein Failover ausführt und eine neue Hubregion eingerichtet wurde.

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

• Recovery Point Objectives (RPO) und Recovery Time Objectives (RTO) können über Konsistenzebenen mit einem Kompromiss zwischen Datenbeständigkeit und Durchsatz konfiguriert werden.

  • Azure Cosmos DB bietet eine minimale RTO von 0 für eine entspannte Konsistenzebene mit Schreibvorgängen in mehreren Regionen oder einen RPO von 0 für starke Konsistenz mit Einer Schreibregion.

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

  • Die SLA wird durch den Prozentsatz der monatlichen Betriebszeit dargestellt, der als 100 % – Durchschnittliche Fehlerrate berechnet wird.
  • Die durchschnittliche Fehlerrate ist definiert als die Summe der Fehlerraten für jede Stunde im Abrechnungsmonat dividiert durch die Gesamtzahl der Stunden im Abrechnungsmonat, wobei die Fehlerrate die Gesamtzahl der fehlgeschlagenen Anforderungen dividiert durch die Gesamtanzahl der Anforderungen während eines bestimmten Intervalls von einer Stunde ist.

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

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

• Es gibt zwei Typen von Durchsatz, die in Azure Cosmos DB bereitgestellt werden können: Standard und Automatische Skalierung, die mithilfe von Anforderungseinheiten pro Sekunde (RU/s) gemessen werden.

  • Der Standarddurchsatz weist Ressourcen zu, die erforderlich sind, um einen angegebenen RU/s-Wert zu gewährleisten.
    • Standard wird stündlich für den bereitgestellten Durchsatz in Rechnung gestellt.
  • Die automatische Skalierung definiert einen maximalen Durchsatzwert, und Azure Cosmos DB wird je nach Anwendungslast automatisch hoch- oder herunterskaliert, zwischen dem maximalen Durchsatzwert und mindestens 10 % des maximalen Durchsatzwerts.
    • Die automatische Skalierung wird stündlich für den maximalen Durchsatz abgerechnet.

• 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 hochskaliert werden kann, während gleichzeitig der Kostenschutz beibehalten wird, indem bei geringerer Auslastung ein rückskaliertes Herunterskalieren erfolgt.

• Wenn Azure Cosmos DB über mehrere Regionen repliziert wird, werden die bereitgestellten Anforderungseinheiten (Request Units, RUs) pro Region in Rechnung gestellt.

• Es gibt ein erhebliches Kostendelta zwischen einer Konfiguration mit Schreibvorgängen mit mehreren Regionen und einer einzelnen Region, was in vielen Fällen dazu führen kann, dass eine Azure Cosmos DB-Datenplattform mit mehreren master unerschwinglich ist.

Lese-/Schreibzugriff in einer region	Schreibvorgang in einer einzelnen Region – Lesebereich mit dualer Region	Lese-/Schreibzugriff in zwei Regionen
1 RU	2 RU	4 RU

Das Delta zwischen Schreib- und Schreibvorgängen mit mehreren Regionen 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 Schreibupdates in einer Konfiguration mit einmaligem Schreibvorgang verknüpft ist, die nicht wie bei der Schreibkonfiguration für mehrere Regionen innerhalb der RU-Kosten erfasst wird.

• Verbrauchter Speicher wird als Pauschalsatz für die Gesamtmenge des Speichers (GB) abgerechnet, die für Hostdaten und Indizes für eine bestimmte Stunde verbraucht wird.

• Session ist die standard- und am häufigsten verwendete Konsistenzebene , 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 über 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, was eine differenzierte Ressourcenzugriffssteuerung mithilfe Microsoft Entra rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) ermöglicht.

  • Das Einschränken des Zugriffs auf Steuerungsebene über Schlüssel oder Ressourcentoken deaktiviert Vorgänge auf Steuerungsebene für Clients, die Azure Cosmos DB SDKs verwenden, und sollte daher gründlich ausgewertet und getestet werden.
  • Die disableKeyBasedMetadataWriteAccess Einstellung kann über ARM-Vorlagen-IaC-Definitionen oder über eine integrierte Azure Policy konfiguriert werden.

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

  • Anwendungsadministratoren können Rollenzuweisungen für Benutzer, Gruppen, Dienstprinzipale oder verwaltete Identitäten erstellen, um den Zugriff auf Ressourcen und Vorgänge in Azure Cosmos DB-Ressourcen zu gewähren oder zu verweigern.
  • Für die Rollenzuweisung stehen mehrere integrierte RBAC-Rollen zur Verfügung, und benutzerdefinierte RBAC-Rollen können auch verwendet werden, um bestimmte Berechtigungskombinationen zu bilden.
    • Der Cosmos DB-Kontoleser ermöglicht den 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, aber keinen Zugriff auf Datenebene.
    • Der Cosmos DB-Operator ähnelt dem DocumentDB-Kontomitwirkenden, bietet aber nicht die Möglichkeit, Schlüssel oder Rollenzuweisungen zu verwalten.

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

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

• Der Azure Cosmos DB-Änderungsfeed stellt einen zeitgeordneten Feed mit Änderungen an Daten in einem Azure Cosmos DB-Container bereit.

  • Der Änderungsfeed enthält nur Einfüge- und Updatevorgänge für den Azure Cosmos DB-Quellcontainer. Es enthält keine Löschvorgänge.

• Der Änderungsfeed kann verwendet werden, um einen separaten Datenspeicher vom primären Container zu verwalten, der von der Anwendung verwendet wird, wobei laufende Updates des Zieldatenspeichers durch den Änderungsfeed aus dem Quellcontainer gespeist werden.

  • 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 gespeiste Speicher ungenau und unreflektiert von gelöschten Daten.

  • Ein Vorläufiges Löschen-Muster kann implementiert werden, sodass Datensätze im Änderungsfeed enthalten sind.
    • Anstatt Datensätze explizit zu löschen, werden Datensätze aktualisiert , indem ein Flag festgelegt wird (z. B. IsDeleted), um anzugeben, dass das Element als gelöscht gilt.
    • Jeder Zieldatenspeicher, der vom Änderungsfeed gespeist wird, muss Elemente mit einem gelöschten Flag erkennen und verarbeiten, das 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 Laufzeit (Time-To-Live, TTL) wird in der Regel mit dem Vorläufigen Löschen-Muster verwendet, sodass Azure Cosmos DB abgelaufene Daten automatisch löscht, aber erst, nachdem sie im Änderungsfeed widergespiegelt werden, wobei das gelöschte Flag auf True festgelegt ist.
    • Erreicht die ursprüngliche Löschabsicht und verteilt den Löschvorgang über den Änderungsfeed.

• Azure Cosmos DB kann als Analysespeicher konfiguriert werden, der ein Spaltenformat für optimierte analytische Abfragen anwendet, um die Komplexitäts- und Latenzprobleme zu bewältigen, die bei herkömmlichen ETL-Pipelines auftreten.

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

• Azure Cosmos DB kann nach zwei verschiedenen Sicherungsmodi konfiguriert werden.

  • Periodisch ist der Standardsicherungsmodus für alle Konten, bei dem Sicherungen in einem regelmäßigen Intervall erstellt und die Daten durch Erstellen einer Anforderung mit dem Supportteam wiederhergestellt werden.
    • Der standardmäßige aufbewahrungszeitraum für regelmäßige Sicherungen beträgt acht Stunden und das Standardsicherungsintervall vier Stunden. Dies bedeutet, dass standardmäßig nur die letzten beiden Sicherungen gespeichert werden.
    • Das Sicherungsintervall und der Aufbewahrungszeitraum sind innerhalb des Kontos konfigurierbar.
      • Der maximale Aufbewahrungszeitraum erstreckt sich auf einen Monat mit einem Mindestsicherungsintervall von einer Stunde.
      • Zum Konfigurieren der Sicherungsspeicherredundanz ist eine Rollenzuweisung zu Azure "Cosmos DB-Kontoleserrolle" erforderlich.
    • Zwei Sicherungskopien sind ohne zusätzliche Kosten enthalten, aber zusätzliche Sicherungen verursachen zusätzliche Kosten.
    • Standardmäßig werden regelmäßige Sicherungen in separaten Geo-Redundant Storage (GRS) gespeichert, auf die nicht direkt zugegriffen werden kann.
      • Der Sicherungsspeicher befindet sich innerhalb der primären Hubregion und wird über die zugrunde liegende Speicherreplikation in die gekoppelte Region repliziert.
      • Die Redundanzkonfiguration des zugrunde liegenden Sicherungsspeicherkontos kann als zonenredundanter Speicher oder Locally-Redundant Storage konfiguriert werden.
    • Für die Durchführung eines Wiederherstellungsvorgangs ist eine Supportanfrage erforderlich, da Kunden eine Wiederherstellung nicht direkt durchführen können.
      • Vor dem Öffnen eines Supporttickets sollte der Aufbewahrungszeitraum der Sicherung innerhalb von acht Stunden nach dem Datenverlustereignis auf mindestens sieben Tage erhöht werden.
    • Ein Wiederherstellungsvorgang erstellt ein neues Azure Cosmos DB-Konto, in 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 mit dem Namen <Azure_Cosmos_account_original_name>-restored<n> verwendet.
        • Dieser Name kann angepasst werden, z. B. durch erneute Verwendung 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 der wiederherzustellenden Container auszuwählen.
  • 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 Granularität von einer Sekunde zurückzukehren.
    • Das verfügbare Fenster für Wiederherstellungsvorgänge beträgt bis zu 30 Tage.
      • Es ist auch möglich, den Instanziierungszustand der Ressource wiederherzustellen.
    • Fortlaufende Sicherungen werden in jeder Azure-Region durchgeführt, in der das Azure Cosmos DB-Konto vorhanden ist.
      • Fortlaufende Sicherungen werden in derselben Azure-Region wie jedes Azure Cosmos DB-Replikat gespeichert, wobei Locally-Redundant Storage (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 durchgeführt werden.
    • Es gibt mehrere Einschränkungen bei Continuous Backup.
      • Der fortlaufende Sicherungsmodus ist derzeit in einer Konfiguration mit Schreibvorgängen mit mehreren Regionen nicht verfügbar.
      • Derzeit können nur Azure Cosmos DB for NoSQL und Azure Cosmos DB for MongoDB für Continuous Backup konfiguriert werden.
      • Wenn für einen Container TTL konfiguriert ist, können wiederhergestellte Daten, die die TTL überschritten haben, sofort gelöscht werden.
    • Ein Wiederherstellungsvorgang erstellt ein neues Azure Cosmos DB-Konto für die Zeitpunktwiederherstellung.
    • Für fortlaufende Sicherungen und Wiederherstellungsvorgänge fallen zusätzliche Speicherkosten an.

• Vorhandene Azure Cosmos DB-Konten können von Periodisch zu Kontinuierlich, aber nicht von Kontinuierlich 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 bereitgestellten Durchsatz, Indizierungsrichtlinien, Bereitstellungsregionen und Container-TTL-Einstellungen.

  • Sicherungen enthalten keine Firewalleinstellungen, Zugriffssteuerungslisten für virtuelle Netzwerke, Einstellungen für private Endpunkte, 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-Analysespeicherdaten sind auch nicht in Azure Cosmos DB-Sicherungen enthalten.

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

  • Ein benutzerdefinierter Ansatz führt zu erheblichen Kosten und zusätzlichem Verwaltungsaufwand, der verstanden und sorgfältig bewertet werden sollte.
    • Gängige Wiederherstellungsszenarien sollten modelliert werden, z. B. die Beschädigung oder Löschung eines Kontos, einer Datenbank, eines Containers, eines Datenelements.
    • Housekeeping-Verfahren sollten implementiert werden, um eine Zersiedelung von Sicherungen zu verhindern.
  • Azure Storage oder eine alternative Datentechnologie kann verwendet werden, z. B. ein alternativer Azure Cosmos DB-Container.
    • Azure Storage und Azure Cosmos DB bieten native Integrationen mit Azure-Diensten wie Azure Functions und Azure Data Factory.

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

  • Azure Cosmos DB ändert den Feed , um Daten in eine separate Speichereinrichtung zu schreiben.
    • Eine Azure-Funktion oder ein gleichwertiger Anwendungsprozess verwendet den Änderungsfeedprozessor , um sich an den Änderungsfeed zu binden und Elemente im Speicher zu verarbeiten.
  • Sowohl fortlaufende als auch regelmäßige (batched) benutzerdefinierte Sicherungen können mithilfe des Änderungsfeeds implementiert werden.
  • Der Azure Cosmos DB-Änderungsfeed spiegelt noch keine Löschvorgänge wider, sodass ein vorläufiges Löschmuster mithilfe einer booleschen Eigenschaft und TTL angewendet werden muss.
    • 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 for NoSQL- oder MongoDB-API-Connectors) zum Kopieren von Daten.
    • Azure Data Factory (ADF) unterstützt manuelle Ausführung und Zeitplan, Rollierendes Fenster und ereignisbasierte Trigger.
      • Bietet Unterstützung für Storage und Event Grid.
    • ADF eignet sich aufgrund seiner batchorientierten Orchestrierung in erster Linie für regelmäßige benutzerdefinierte Sicherungsimplementierungen.
      • Aufgrund des Mehraufwands für die Orchestrierungsausführung eignet es sich weniger für Implementierungen kontinuierlicher Sicherungen mit häufigen Ereignissen.
    • ADF unterstützt Azure Private Link für Szenarien mit hoher Netzwerksicherheit

Azure Cosmos DB wird im Rahmen des Entwurfs vieler Azure-Dienste verwendet, sodass ein erheblicher regionaler Ausfall für Azure Cosmos DB eine kaskadierende Auswirkung auf verschiedene Azure-Dienste innerhalb dieser Region hat. Die genauen Auswirkungen auf einen bestimmten Dienst hängen stark davon ab, wie der zugrunde liegende Dienstentwurf Azure Cosmos DB verwendet.

Entwurfsempfehlungen

Azure Cosmos DB

• Verwenden Sie Azure Cosmos DB als primäre Datenplattform, sofern die Anforderungen dies zulassen.

• Konfigurieren Sie Für unternehmenskritische Workloadszenarien Azure Cosmos DB mit einem Schreibreplikat in jeder Bereitstellungsregion, um die Latenz zu verringern und maximale Redundanz zu gewährleisten.

  • Konfigurieren Sie die Anwendung, um die Verwendung des lokalen Azure Cosmos DB-Replikats für Schreib- und Lesevorgänge zu priorisieren, um die Auslastung der Anwendung, die Leistung und den regionalen RU/s-Verbrauch zu optimieren.
  • Die Konfiguration von Schreibvorgängen mit mehreren Regionen hat erhebliche Kosten und sollte nur für Workloadszenarien priorisiert werden, die maximale Zuverlässigkeit erfordern.

• Priorisieren Sie bei weniger kritischen Workloadszenarien die Verwendung der Single-Region-Write-Konfiguration (bei Verwendung von Verfügbarkeitszonen) mit global verteilten Lesereplikaten, da dies ein hohes Maß an Datenplattformsicherheit (99,999 % SLA für Lesevorgänge, 99,995 % SLA für Schreibvorgänge) zu einem überzeugenderen Preis bietet.

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

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

  • Berücksichtigen Sie die Entfernung relativ zu anderen Bereitstellungsregionen und die zugehörige Latenz bei der Auswahl einer primären Region sowie erforderliche Funktionen wie Verfügbarkeitszonen-Unterstützung.

• Konfigurieren Sie Azure Cosmos DB mit Verfügbarkeitszonenredundanz (Availability Zone, AZ) in allen Bereitstellungsregionen mit AZ-Unterstützung, um Die Resilienz bei Zonenfehlern innerhalb einer Region sicherzustellen.

• Verwenden Sie Azure Cosmos DB for NoSQL, da es den umfassendsten Featuresatz bietet, insbesondere bei der Leistungsoptimierung.

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

• Verwenden Sie den Direktverbindungsmodus, um die Netzwerkleistung durch direkte TCP-Konnektivität mit Back-End-Azure Cosmos DB-Knoten mit einer reduzierten Anzahl von Netzwerk-Hops zu optimieren.

Die Azure Cosmos DB-SLA wird durch die Mittelung fehlerhafter Anforderungen berechnet, die möglicherweise nicht direkt mit einem Fehlerbudget der Zuverlässigkeitsebene von 99,999 % übereinstimmen. Beim Entwerfen von 99,999 % SLO ist es daher wichtig, die Nichtverfügbarkeit von Azure Cosmos DB-Schreibvorgängen für regionale und mehrere Regionen zu planen, um sicherzustellen, dass bei einem Fehler eine Fallbackspeichertechnologie positioniert wird, z. B. eine persistente Nachrichtenwarteschlange für die nachfolgende Wiedergabe.

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

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

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

  • Der Partitionsschlüssel kann nicht mehr 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 den Datenspeicher gleichmäßig auf alle logischen Partitionen verteilen, um eine gleichmäßige RU-Nutzung und Speicherverteilung auf physische Partitionen 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.

  • Indizieren Sie nur die Felder, die zum Filtern innerhalb von Abfragen benötigt werden. entwerfen Sie Indizes 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 Wiederholungslogik im SDK auf Clients.

• Verwenden Sie dienstseitig verwaltete Verschlüsselungsschlüssel, um die Verwaltungskomplexität zu reduzieren.

  • Wenn eine bestimmte Sicherheitsanforderung für kundenseitig verwaltete Schlüssel besteht, stellen Sie sicher, dass geeignete Schlüsselverwaltungsverfahren angewendet werden, z. B. Sicherung und Rotation.

• Deaktivieren Sie den schlüsselbasierten Schreibzugriff auf Azure Cosmos DB-Metadaten, indem Sie die integrierte Azure Policy anwenden.

• Aktivieren Sie Azure Monitor zum Sammeln wichtiger Metriken und Diagnoseprotokolle, z. B. bereitgestellter Durchsatz (RU/s).

  • Weiterleiten von Azure Monitor-Betriebsdaten in einen Log Analytics-Arbeitsbereich für Azure Cosmos DB und andere globale Ressourcen innerhalb des Anwendungsentwurfs.
  • Verwenden Sie Azure Monitor-Metriken, um zu ermitteln, ob Anwendungsdatenverkehrmuster für die automatische Skalierung geeignet sind.

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

  • Erwägen Sie die automatische Skalierung des bereitgestellten Durchsatzes, um die Workloadanforderungen automatisch abzuskalieren.

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

• Bei Verwendung von AKS als Computeplattform: Wählen Sie bei abfrageintensiven Workloads eine AKS-Knoten-SKU aus, deren Netzwerkbeschleunigt wurde, um latenz- und CPU-Jitter zu reduzieren.

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

• Lastenebene durch die Verwendung von asynchronem, nicht blockierenden Messaging in Systemflows, die Updates in Azure Cosmos DB schreiben.

  • Betrachten Sie Muster wie Befehls- und Abfrageverantwortungstrennung und Ereignissourcierung.

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

  • Erwägen 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, sofern dies nicht unbedingt erforderlich ist.

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

• Definieren Sie IaC-Artefakte, um Konfigurationseinstellungen und Funktionen einer Azure Cosmos DB-Sicherungswiederherstellung wiederherzustellen.

• Evaluieren und Anwenden der Anleitung zur Steuerung der Azure-Sicherheitsbaseline für Azure Cosmos DB Backup and Recovery.

  • BR-1: Sicherstellen regelmäßiger automatisierter Sicherungen
  • BR-3: Überprüfen aller Sicherungen einschließlich kundenseitig verwalteter Schlüssel
  • BR-4, Verringern des Risikos von Schlüsselverlusten

• Verwenden Sie für analytische Workloads, die 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 Schreibkonfiguration mit mehreren Regionen 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 Database und Azure Database for Common OSS relationale Lösungen, einschließlich MySQL, PostgreSQL und MariaDB. Die Entwurfsüberlegungen und Empfehlungen in diesem Abschnitt konzentrieren sich daher auf die optimale Nutzung Azure SQL Datenbank- und Azure Database OSS-Varianten, um die Zuverlässigkeit und globale Verfügbarkeit zu maximieren.

Überlegungen zum Entwurf

• Während relationale Datentechnologien für eine einfache Skalierung von Lesevorgängen konfiguriert werden können, sind Schreibvorgänge in der Regel eingeschränkt, um eine einzelne primäre instance zu durchlaufen, was eine erhebliche Einschränkung für Skalierbarkeit und Leistung darstellt.

• Sharding kann angewendet werden, um Daten und Die Verarbeitung auf mehrere identische strukturierte Datenbanken zu verteilen, wobei Datenbanken horizontal partitioniert werden, um durch 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 Sekundärdateien werden in derselben oder unterschiedlichen Regionen unterstützt.
  • Sekundäre Replikate können auch für den schreibgeschützten Abfragezugriff verwendet werden, um die Leseleistung zu optimieren.
  • Das Failover muss manuell initiiert werden, kann aber in automatisierte Betriebsprozeduren eingeschlossen werden.

• Azure SQL-Datenbank stellt autofailover-Gruppen bereit, die Datenbanken auf einen sekundären Server replizieren und bei einem Fehler ein transparentes Failover ermöglichen.

  • 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.
  • Autofailover-Gruppen werden in der Hyperscale-Dienstebene derzeit nicht unterstützt.
  • Sekundäre Datenbanken können zum Auslagern von Lesedatenverkehr verwendet werden.

• Datenbankreplikate der Premium- oder Unternehmenskritisch-Dienstebene können ohne zusätzliche Kosten auf 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 Database bietet eine geplante SLA von 99,99 % für alle Dienstebenen, bietet jedoch eine höhere SLA von 99,995 % für die Tarife Unternehmenskritisch oder Premium in Regionen, die Verfügbarkeitszonen unterstützen.

  • Azure SQL Unternehmenskritisch oder Premium-Tarife, die nicht für zonenredundante Bereitstellungen konfiguriert sind, verfügen über eine Verfügbarkeits-SLA von 99,99 %.

• Bei Der Konfiguration mit Georeplikation bietet die Azure SQL Database Unternehmenskritisch-Ebene einen RTO -Wert (Recovery Time Objective) von 30 Sekunden für 100 % der bereitgestellten Stunden.

• Bei Konfiguration mit Georeplikation verfügt die Azure SQL Database Unternehmenskritisch-Ebene über einen RPO-Wert (Recovery Point Objective) von 5 Sekunden für 100 % der bereitgestellten Stunden.

• Azure SQL Datenbank-Hyperscale-Tarif verfügt bei Konfiguration mit mindestens zwei Replikaten über eine Verfügbarkeits-SLA von 99,99 %.

• Computekosten im Zusammenhang mit Azure SQL Datenbank können mithilfe eines Reservierungsrabatts reduziert werden.

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

• Die Zeitpunktwiederherstellung kann verwendet werden, um eine Datenbank und enthaltene Daten an einen früheren Zeitpunkt zurückzugeben.

• Die 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:

  • Einzelserver, SLA 99,99 %
  • Flexible Server, der Redundanz für Verfügbarkeitszonen bietet, SLA 99,99 %
  • Hyperscale (Citus), SLA 99,95 %, wenn der Hochverfügbarkeitsmodus aktiviert ist.

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

  • Das Verteilen von Tabellenzeilen auf mehrere PostgreSQL-Server ist entscheidend, um skalierbare Abfragen in Hyperscale (Citus) sicherzustellen.
  • Mehrere Knoten können zusammen mehr Daten als eine herkömmliche Datenbank enthalten, und in vielen Fällen können Worker-CPUs parallel verwendet werden, um die Kosten zu optimieren.

• Die automatische Skalierung kann über die Runbookautomatisierung konfiguriert werden, um die Elastizität als Reaktion auf sich ändernde Datenverkehrsmuster sicherzustellen.

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

• Es fallen keine zusätzlichen Gebühren für Sicherungsspeicher für bis zu 100 % des gesamten bereitgestellten Serverspeichers an.

  • Der zusätzliche Verbrauch des Sicherungsspeichers wird nach verbrauchtem GB/Monat berechnet.

• Computekosten im Zusammenhang mit Azure Database for PostgreSQL können entweder mithilfe eines Reservierungsrabatts für einzelne Server oder eines Hyperscale-Reservierungsrabatts (Citus) 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 verbreitet, wenn beim Anwendungsentwurf drei oder mehr Azure-Regionen berücksichtigt werden, da relationale Technologieeinschränkungen die global verteilten 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 auf virtuellen Kernen basierende 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 die Anforderungen an Compute- und Speicherressourcen zu informieren.
    • Ziehen Sie reservierte Kapazität in Betracht, um potenzielle Kostenoptimierungen bereitzustellen.

• Konfigurieren Sie das Zone-Redundant-Bereitstellungsmodell, um Unternehmenskritisch Datenbankreplikate innerhalb derselben Region auf Verfügbarkeitszonen zu verteilen.

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

• Verwenden Sie autofailover-Gruppen, um ein transparentes Failover in eine sekundäre Region bereitzustellen, wobei die Georeplikation angewendet wird, um die Replikation in zusätzliche Bereitstellungsregionen zur 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 betriebsbezogene Trigger basierend auf warnungen, die auf dem Anwendungsintegritätsmodell ausgerichtet sind, um Failover auf georeplizierte Instanzen durchzuführen, wenn sich ein Fehler auf die primäre und sekundäre Instanz innerhalb der Auto Failover-Gruppe auswirkt.

Wichtig

Bei Anwendungen, die mehr als vier Bereitstellungsregionen in Betracht ziehen, sollte das anwendungsbezogene Sharding oder das Refactoring der Anwendung zur Unterstützung von Schreibtechnologien in mehreren Regionen, z. B. Azure Cosmos DB, ernsthaft berücksichtigt werden. Wenn dies jedoch innerhalb des Anwendungsworkloadszenarios nicht möglich ist, empfiehlt es sich, eine Region innerhalb einer einzelnen Geografie zu einem primären status zu erhöhen, der eine georeplizierte instance für 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, um nahezu in Echtzeit operative Erkenntnisse in Azure SQL DB für die Erkennung von Zuverlässigkeitsvorfällen zu erhalten.

• 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äftsbezogenen Anforderungen und der Ressourcennutzung zu beobachten, und verwenden Sie Dabei Überwachung und Warnungen , um bei Bedarf automatisierte betriebliche Aktionen zu steuern.

  • Stellen Sie sicher, dass wichtige Abfrageleistungsmetriken integriert sind, damit schnelle Maßnahmen ergriffen werden können, wenn eine Dienstbeeinträchtigung auftritt.

• Optimieren Sie Abfragen, Tabellen und Datenbanken mithilfe von Query Performance Insights und allgemeinen Leistungsempfehlungen von Microsoft.

• Implementieren Sie Wiederholungslogik mithilfe des SDK, um vorübergehende Fehler zu minimieren, die sich auf Azure SQL Datenbankkonnektivität auswirken.

• Priorisieren Sie die Verwendung von dienstseitig verwalteten Schlüsseln beim Anwenden der serverseitigen Transparent Data Encryption (TDE) für die Verschlüsselung ruhender Daten.

  • Wenn kundenseitig verwaltete Schlüssel oder clientseitige Verschlüsselung (AlwaysEncrypted) erforderlich ist, stellen Sie sicher, dass Schlüssel mit Sicherungen und automatisierten Rotationsfunktionen angemessen resilient sind.

• Erwägen Sie die Verwendung der Point-in-Time-Wiederherstellung als betriebsbereites Playbook für die Wiederherstellung nach schwerwiegenden Konfigurationsfehlern.

Azure Database For PostgreSQL

• Flexible Server wird aufgrund der Verfügbarkeitszonenunterstützung empfohlen, ihn für unternehmenskritische Workloads zu verwenden.

• Wenn Sie Hyperscale (Citus) für unternehmenskritische Workloads verwenden, aktivieren Sie den Hochverfügbarkeitsmodus, um die SLA-Garantie von 99,95 % zu erhalten.

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

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

  • Ziehen Sie den Reservierungsrabatt für Hyperscale (Citus) in Betracht, um potenzielle Kostenoptimierungen bereitzustellen.

Zwischenspeichern für Daten der heißen Ebene

Eine In-Memory-Zwischenspeicherungsebene kann angewendet werden, um eine Datenplattform zu verbessern, indem der Lesedurchsatz erheblich erhöht und die End-to-End-Clientantwortzeiten für Datenszenarien der heißen Ebene verbessert werden.

Azure bietet mehrere Dienste mit anwendbaren Funktionen zum Zwischenspeichern von Schlüsseldatenstrukturen, wobei Azure Cache for Redis positioniert sind, um den Lesezugriff auf Die Datenplattform zu abstrahieren und zu optimieren. Dieser Abschnitt konzentriert sich daher auf die optimale Verwendung von Azure Cache for Redis in Szenarien, in denen zusätzliche Leseleistung und dauerhafter Datenzugriff erforderlich sind.

Entwurfsaspekte

• Eine Zwischenspeicherungsebene bietet eine zusätzliche Dauerhaftigkeit des Datenzugriffs, da auch bei einem Ausfall, der sich auf die zugrunde liegenden Datentechnologien auswirkt, auf anwendungsdaten Momentaufnahme weiterhin über die Zwischenspeicherungsebene zugegriffen werden kann.

• In bestimmten Workloadszenarien kann die In-Memory-Zwischenspeicherung innerhalb der Anwendungsplattform selbst implementiert werden.

Azure Cache for Redis

• Redis Cache ist ein Open Source NoSQL-Schlüssel-Wert-In-Memory-Speichersystem.

• Die Enterprise- und Enterprise Flash-Tarife können in einer Aktiv/Aktiv-Konfiguration über Verfügbarkeitszonen innerhalb einer Region und verschiedener Azure-Regionen durch Georeplikation bereitgestellt werden.

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

• Die Enterprise Flash-Ebene wird mit einer Kombination aus RAM und nicht flüchtigem Flash-Speicher ausgeführt. Dies führt zwar zu einer kleinen Leistungseinbuße, ermöglicht aber auch sehr große Cachegrößen von bis zu 13 TB mit Clustering.

• Bei der Georeplikation fallen zusätzlich zu den direkten Kosten für Cacheinstanzen auch Gebühren für die Datenübertragung zwischen Regionen an.

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

• Während eines Horizontalskalierungsvorgangs steigt die CPU-Auslastung, 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 in Verfügbarkeitszonen in jeder betrachteten Azure-Region bereitgestellt werden.

• Verwenden Sie Azure Monitor, um Azure Cache for Redis auszuwerten.

  • Berechnen Sie eine Integritätsbewertung für regionale Cachekomponenten, um die Integrität im Verhältnis zu Geschäftsanforderungen und Ressourcennutzung zu beobachten.
  • Beobachten und warnen Sie bei wichtigen Metriken, z. B. hohe CPU-Auslastung, hohe Arbeitsspeicherauslastung, hohe Serverauslastung und entfernte Schlüssel, um Erkenntnisse darüber zu erhalten, wann der Cache skaliert werden soll.

• Optimieren Sie die Verbindungsresilienz , indem Sie Wiederholungslogik, Timeouts und eine Singletonimplementierung des Redis-Verbindungsmultixers implementieren.

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

Analytische Szenarien

Bei unternehmenskritischen Anwendungen wird es immer häufiger vorkommen, analytische Szenarien als Mittel zu betrachten, um zusätzlichen Nutzen aus umfassenden Datenflüssen zu steigern. Anwendungs- und Betriebsanalyseszenarien (AIOps) bilden daher einen entscheidenden Aspekt einer äußerst zuverlässigen Datenplattform.

Analyse- und Transaktionsworkloads erfordern unterschiedliche Datenplattformfunktionen und Optimierungen für eine akzeptable Leistung in ihren jeweiligen Kontexten.

Beschreibung	Analytisch	Transaktionsreplikation
Anwendungsfall	Analysieren sehr großer Datenmengen ("Big Data")	Verarbeiten sehr großer Mengen einzelner Transaktionen
Optimiert für	Lesen von Abfragen und Aggregationen für viele Datensätze	CRUD-Abfragen (Create/Read/Update/Delete) für wenige Datensätze nahezu in Echtzeit
Hauptmerkmale	– Konsolidieren aus Datenquellen des Datensatzes – Spaltenbasierter Speicher – Verteilter Speicher - Parallelverarbeitung -Denormalisierten – Lese- und Schreibvorgänge mit geringer Parallelität – Optimieren für Speichervolume mit Komprimierung	- Datenquelle des Datensatzes für die Anwendung – Zeilenbasierter Speicher - Zusammenhängender Speicher – Symmetrische Verarbeitung -Normalisierte - Lese- und Schreibvorgänge mit hoher Parallelität, Indexaktualisierungen – Optimieren für schnellen Datenzugriff mit In-Memory-Speicher

Azure Synapse stellt eine Analyseplattform für Unternehmen bereit, 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-Analysen zu ermöglichen. Die Entwurfsüberlegungen und Empfehlungen in diesem Abschnitt konzentrieren sich daher auf optimale Azure Synapse und Azure Cosmos DB-Nutzung 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.
  • ETL-Pipelines (Extrahieren, Transformieren und Laden) werden verwendet, um Daten zu extrahieren, die den Durchsatz verbrauchen und sich auf die Leistung von Transaktionsworkloads auswirken.
  • Wenn ETL-Pipelines selten ausgeführt werden, um den Durchsatz und die Auswirkungen auf die Leistung zu reduzieren, führt dies zu weniger aktuellen Analysedaten.
  • Der Entwicklungs- und Wartungsaufwand für ETL-Pipelines steigt, wenn 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 analytische Abfragen über einen additiv/versionsbasierten Ansatz, speicherabbilden und neu laden oder direkte Änderungen an den analytischen Daten berücksichtigen. Jeder dieser Ansätze hat abgeleitete Auswirkungen, z. B. die Neuerstellung oder Aktualisierung von Indizes.

Azure Cosmos DB

• Analytische Abfragen, die für Azure Cosmos DB-Transaktionsdaten ausgeführt werden, werden in der Regel partitionsübergreifend über große Datenmengen hinweg aggregiert und verbrauchen einen erheblichen Ru(Request Unit)-Durchsatz, was sich auf die Leistung von umgebenden Transaktionsworkloads auswirken kann.

• Der Azure Cosmos DB-Analysespeicher bietet einen schematisierten, vollständig isolierten spaltenorientierten Datenspeicher, der umfangreiche Analysen von Azure Cosmos DB-Daten aus Azure Synapse ohne Auswirkungen auf Azure Cosmos DB-Transaktionsworkloads ermöglicht.

  • Wenn ein Azure Cosmos DB-Container als Analysespeicher aktiviert ist, wird intern aus den Betriebsdaten im Container ein neuer Spaltenspeicher 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 Analysespeicher synchronisiert, sodass kein Änderungsfeed oder keine ETL-Verarbeitung erforderlich ist.
  • Die Datensynchronisierung aus dem betriebsbereiten mit dem Analysespeicher verbraucht keinen Durchsatz von Anforderungseinheiten (Request Units, RUs), die für den Container oder die Datenbank bereitgestellt werden. Es gibt keine Auswirkungen auf die Leistung von Transaktionsworkloads. Der Analysespeicher erfordert keine Zuordnung zusätzlicher RUs für eine Azure Cosmos DB-Datenbank oder einen Container.
  • Die automatische Synchronisierung ist der Prozess, bei dem Änderungen an betriebsbezogenen Daten automatisch mit dem Analysespeicher synchronisiert werden. Die Wartezeit für die automatische Synchronisierung beträgt in der Regel weniger als zwei (2) Minuten.
    • Die Latenz für die automatische Synchronisierung kann für eine Datenbank mit gemeinsam genutztem Durchsatz und einer großen Anzahl von Containern bis zu fünf (5) Minuten betragen.
    • Sobald die automatische Synchronisierung abgeschlossen ist, können die neuesten Daten von Azure Synapse abgefragt werden.
  • Der Analysespeicher verwendet ein verbrauchsbasiertes Preismodell , bei dem die Datenmenge und die Anzahl von Lese- und Schreibvorgängen berechnet werden. Die Preise für den Analysespeicher unterscheiden sich von den Preisen für Transaktionsspeicher.

• Mit Azure Synapse Link kann der Azure Cosmos DB-Analysespeicher 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 nahezu in Echtzeit abgefragt werden können.

• Der Azure Cosmos DB-Analysespeicher ist standardmäßig nicht partitioniert.

  • Bei bestimmten Abfrageszenarien verbessert sich die Leistung durch Partitionieren von Analysespeicherdaten mithilfe von Schlüsseln, die häufig in Abfrage-Prädikaten verwendet werden.
  • Die Partitionierung wird durch einen Auftrag in Azure Synapse ausgelöst, der ein Spark-Notebook mit Synapse Link ausführt, das die Daten aus dem Azure Cosmos DB-Analysespeicher 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 Analysespeicher über automatisch aktualisierte Ansichten oder über SELECT / OPENROWSET Befehle abfragen.

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

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

• Azure Cosmos DB-Analysespeicherdaten können mit Azure Synapse Spark abgefragt werden.

  • Spark-Notebooks ermöglichen Spark-Datenrahmenkombinationen zum Aggregieren und Transformieren von Azure Cosmos DB-Analysedaten mit anderen Datasets und verwenden andere erweiterte Synapse Spark-Funktionen, z. B. das Schreiben von transformierten Daten in andere Speicher oder das Trainieren von AIOps Machine Learning-Modellen.

• 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 wie SQL Data Warehousing, 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 in Synapse Analytics über Copy-Aktivität aus unterstützten Quellen erfasst werden. Dies ermöglicht Datenanalysen in Synapse, ohne dass sich dies auf den Quelldatenspeicher auswirkt, erhöht jedoch den Zeit-, Kosten- und Latenzaufwand aufgrund der Datenübertragung.
  • Daten können auch direkt in unterstützten externen Speicher abgefragt werden, um den Mehraufwand für die Datenerfassung und -verschiebung zu vermeiden. Azure Storage mit Data Lake Gen2 ist ein unterstützter Speicher für exportierte Synapse- und Log Analytics-Daten, die über Synapse Spark abgefragt werden können.

• Azure Synapse Studio vereint Erfassungs- und Abfrageaufgaben.

  • Quelldaten, einschließlich Azure Cosmos DB-Analysespeicherdaten 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 für Azure Cosmos DB-Betriebsdaten durchzuführen, indem Sie einen optimierten Datenspeicher erstellen, der sich nicht auf die Transaktionsleistung auswirkt.

  • Aktivieren Sie Azure Synapse Link für Azure Cosmos DB-Konten.
  • Erstellen Sie einen Container, der für den Analysespeicher aktiviert ist, oder aktivieren Sie einen vorhandenen Container für den Analysespeicher.
  • Verbinden Sie den Azure Synapse Arbeitsbereich mit dem Azure Cosmos DB-Analysespeicher, 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 den Azure Cosmos DB-Analysespeicher mit Azure Synapse Link, anstatt den Azure Cosmos DB-Änderungsfeed zu verwenden, um einen Analysedatenspeicher zu verwalten.

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

AIOps und betriebsbezogene Analysen

• Erstellen Sie einen einzelnen Azure Synapse Arbeitsbereich mit verknüpften Diensten und Datasets 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 Speicherkonto des Arbeitsbereichs, um die Katalogdaten und Metadaten des Synapse-Arbeitsbereichs zu speichern. Konfigurieren Sie ihn mit einem hierarchischen Namespace, um Azure Data Lake Gen2 zu aktivieren.

  • Behalten Sie die Trennung zwischen den Analytischen Quelldaten und den Synapse-Arbeitsbereichsdaten und Metadaten bei.
    • Verwenden Sie keins der regionalen oder globalen Azure Storage-Konten, an die Betriebsdaten gesendet werden.

Nächster Schritt

Überprüfen Sie die Überlegungen zu Netzwerküberlegungen.

Netzwerk und Konnektivität