PERF04-BP02 Prüfen der verfügbaren Optionen - AWS Well-Architected Framework
ImplementierungsleitfadenGrad des Aufwands für den Implementierungsplan: Ressourcen

PERF04-BP02 Prüfen der verfügbaren Optionen

Verstehen Sie die verfügbaren Datenbankoptionen und wie sie Ihre Leistung optimieren können, bevor Sie Ihre Datenverwaltungslösung auswählen. Identifizieren Sie mithilfe von Lasttests Datenbankmetriken, die für Ihre Workload wichtig sind. Während Sie die Datenbanktoptionen erkunden, sollten Sie unterschiedliche Aspekte in Betracht ziehen, wie Parametergruppen, Speicheroptionen, Arbeitsspeicher, Rechenvorgänge, Read Replica, eventuelle Kohärenz, Verbindungs-Pooling und Caching-Optionen. Experimentieren Sie mit diesen unterschiedlichen Konfigurationsoptionen, um die Metriken zu verbessern.

Gewünschtes Ergebnis: Eine Workload könne eine oder mehrere Datenbanklösungen verwenden, basierend auf Datentypen. Die Funktionen und Vorteile der Datenbank entsprechen optimal den Datenmerkmalen, Zugriffsmustern und Workload-Anforderungen. Zur Optimierung der Leistung und Kosten Ihrer Datenbank müssen Sie die Datenzugriffsmuster auswerten, um die entsprechenden Datenbankoptionen zu bestimmen. Evaluieren Sie akzeptable Abfragezeiten, um sicherzustellen, dass die ausgewählten Datenbankoptionen die Anforderungen erfüllen können.

Gängige Antimuster:

  • Sie identifizieren Datenzugriffsmuster nicht.

  • Ihnen fehlt das Bewusstsein für die Wahl der Konfigurationsoptionen der Datenverwaltungslösung.

  • Sie verlassen sich ausschließlich auf das Vergrößern der Instance-Größe, ohne andere verfügbare Konfigurationsoptionen in Betracht zu ziehen.

  • Sie testen die Skalierungsoptionen der ausgewählten Lösung nicht.

Vorteile der Einführung dieser bewährten Methode: Indem Sie Datenbankoptionen erkunden und mit ihnen experimentieren, können Sie möglicherweise Infrastrukturkosten senken, die Leistung und Skalierbarkeit verbessern und den Aufwand zur Verwaltung Ihrer Workloads verringern.

Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: Hoch

  • Die Optimierung für eine Größe, die für alle Datenbanken passt, bedeutet, dass unnötige Kompromisse eingegangen werden müssen.

  • Da die Datenbanklösung nicht für die Datenverkehrsmuster konfiguriert ist, entstehen höhere Kosten.

  • Skalierungsprobleme können Schwierigkeiten beim Betrieb verursachen.

  • Daten werden möglicherweise nicht im erforderlichen Ausmaß gesichert.

Implementierungsleitfaden

Sie müssen die Datenmerkmale Ihrer Workload kennen, damit Sie Ihre Datenbankoptionen konfigurieren können. Führen Sie Lasttests durch, um Ihre wesentlichen Leistungsmetriken und Engpässe zu identifizieren. Verwenden Sie diese Merkmale und Metriken, um Datenbankoptionen zu evaluieren und unterschiedliche Konfigurationen auszuprobieren.

AWS-Services Amazon RDS, Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Skalieren der Rechenvorgänge Erhöhen der Instance-Größe, Aurora-Serverless-Instances skalieren automatisch als Reaktion auf Änderungen der Last Automatisches Skalieren der Lese- und Schreibvorgänge mit einem On-Demand-Kapazitätsmodus oder automatisches Skalieren von bereitgestellter Kapazität für Lese- und Schreibvorgänge im bereitgestellten Kapazitätsmodus Erhöhen der Instance-Größe Erhöhen der Instance-Größe, Hinzufügen von Knoten zu einem Cluster Erhöhen der Instance-Größe Skaliert automatisch, um sich der Kapazität anzupassen Automatisches Skalieren der Lese- und Schreibvorgänge mit einem On-Demand-Kapazitätsmodus oder automatisches Skalieren von bereitgestellter Kapazität für Lese- und Schreibvorgänge im bereitgestellten Kapazitätsmodus Skaliert automatisch, um sich der Kapazität anzupassen
Skalieren von Schreibvorgängen Alle Enginges unterstützen Read Replicas. Aurora unterstützt die automatische Skalierung von Read-Replica-Instances Erhöhen bereitgestellter Kapazitätseinheiten für bereitgestellte Lesevorgänge Read Replicas Read Replicas Read Replicas. Unterstützt die automatische Skalierung von Read-Replica-Instances Skaliert automatisch Erhöhen bereitgestellter Kapazitätseinheiten für bereitgestellte Lesevorgänge Skaliert automatisch zu dokumentierten Gleichzeitigkeitseinschränkungen hoch
Skalieren von Schreibvorgängen Erhöhen der Instance-Größe, Batching von Schreibvorgängen in der Anwendung oder Hinzufügen einer Warteschlange vor die Datenbank Horizontales Skalieren von mehreren Instances über Sharding auf Anwendungsebene Erhöhen bereitgestellter Kapazitätseinheiten für bereitgestellte Schreibvorgänge Sicherstellen von optimalen Partitionsschlüsseln, um die Drosselung von Schreibvorgängen auf Partitionsebene zu verhindern Erhöhen der primären Instance-Größe Verwenden von Redis im Cluster-Modus, um Schreibvorgänge auf Shards zu verteilen Erhöhen der Instance-Größe Schreibanforderungen können beim Skalieren gedrosselt werden. Wenn Drosselungsausnahmen auftreten, senden Sie Daten weiterhin mit dem gleichen (oder höheren) Durchsatz, um automatisch zu skalieren. Batch-Schreibvorgänge, um gleichzeitige Schreibanforderungen zu verringern Erhöhen bereitgestellter Kapazitätseinheiten für bereitgestellte Schreibvorgänge Sicherstellen von optimalen Partitionsschlüsseln, um die Drosselung von Schreibvorgängen auf Partitionsebene zu verhindern Skaliert automatisch zu dokumentierten Gleichzeitigkeitseinschränkungen hoch
Engine-Konfiguration Parametergruppen – Parametergruppen Parametergruppen Parametergruppen – – –
Caching In-Memory-Caching, über Parametergruppen konfigurierbar. Koppeln Sie mit einem dedizierten Cache wie ElastiCache für Redis, um Anforderungen für häufig genutzte Elemente auszulagern DAX (DAX) vollständig verwalteter Cache verfügbar In-Memory-Caching. Koppeln Sie optional mit einem dedizierten Cache wie ElastiCache für Redis, um Anforderungen für häufig genutzte Elemente auszulagern. Die primäre Funktion ist das Caching Verwenden Sie den Abfrageergebnis-Cache, um die Ergebnisse der Leseabfrage in den Cache zu speichern Timestream hat zwei Speicherstufen; eine davon ist eine Hochleistungs-In-Memory-Stufe Stellen Sie einen separaten dedizierten Cache wie ElastiCache für Redis bereit, um Anforderungen für häufig genutzte Elemente auszulagern –
Hohe Verfügbarkeit / Notfallwiederherstellung Die empfohlene Konfiguration für Produktions-Workloads ist das Ausführen einer Standby-Instance in einer zweiten Availability Zone, um Stabilität innerhalb einer Region zu bieten.  Für die Resilienz in Regionen kann Aurora Global Database verwendet werden Innerhalb einer Region hoch verfügbar. Tabellen können innerhalb von Regionen mithilfe von globalen DynamoDB-Tabellen repliziert werden. Erstellen Sie für die Verfügbarkeit mehrere Instances in Availability Zones.  Schnappschüsse können in Regionen und Clustern mithilfe von DMS repliziert werden, um regionsübergreifende Replikation / Notfallwiederherstellung zu bieten Die empfohlene Konfiguration für Produktions-Cluster ist, zumindest einen Knoten in einer sekundären Availability Zone zu erstellen.  Der ElastiCache Global Datastore kann verwendet werden, um Cluster in Regionen zu replizieren. Read Replicas in anderen Availability Zones dienen als Failover-Ziele.  Snaphots können innerhalb von Regionen geteilt werden und Cluster können mithilfe von Neptune-Streams repliziert werden, um die Daten zwischen zwei Clustern in zwei unterschiedlichen Regionen zu replizieren. Innerhalb einer Region hoch verfügbar, regionsübergreifende Replikation erfordert benutzerdefinierte Anwendungsentwicklung mithilfe des Timestream SDK. Innerhalb einer Region hoch verfügbar.  Regionsübergreifende Replikation erfordert Anwendungslogik oder Tools von Drittanbietern. Innerhalb einer Region hoch verfügbar.  Exportieren Sie zum regionsübergreifenden Replizieren den Inhalt des Amazon-QLDB-Journals zu einem S3-Bucket und konfigurieren Sie den Bucket für eine regionsübergreifende Replikation.

Implementierungsschritte

  1. Welche Konfigurationsoptionen sind für die ausgewählten Datenbanken verfügbar?

    1. Mithilfe von Parametergruppen für Amazon RDS und Aurora können Sie gemeinsame Einstellungen auf Datenbank-Engine-Ebene anpassen, wie den dem Cache zugewiesenen Arbeitsspeicher oder das Einstellen der Zeitzone der Datenbank.

    2. Bei bereitgestellten Datenbankservices wie Amazon RDS, Aurora, Neptune Amazon DocumentDB und jenen, die auf Amazon EC2 bereitgestellt werden, können Sie den Instance-Typ und den bereitgestellten Speicher ändern sowie Read Replicas hinzufügen.

    3. Mithilfe von DynamoDB können Sie zwei Kapazitätsmodi angeben: On-Demand und bereitgestellt. Sie können zwischen diesen Modi wechseln und die zugewiesene Kapazität im bereitgestellten Modus jederzeit erhöhen, um unterschiedliche Workloads zu bewältigen.

  2. Ist die Workload lese- oder schreiblastig? 

    1. Welche Lösungen sind zum Auslagern von Lesevorgängen verfügbar (Read Replicas, Caching usw.)? 

      1. Bei DynamoDB-Tabellen können Sie Lesevorgänge mithilfe von DAX für Caching auslagern.

      2. Sie können für relationale Datenbanken einen ElastiCache-for-Redis-Cluster erstellen und Ihre Anwendung so konfigurieren, dass sie zuerst aus dem Cache liest und dann auf die Datenbank zurückfällt, wenn das angeforderte Element nicht vorhanden ist.

      3. Relationale Datenbanken wie Amazon RDS und Aurora sowie bereitgestellte NoSQL-Datenbanken wie Neptune und Amazon DocumentDB unterstützen alle das Hinzufügen von Read Replicas, um die Lesevorgänge der Workload auszulagern.

      4. Serverless-Datenbanken wie DynamoDB skalieren automatisch. Stellen Sie sicher, dass Sie ausreichend Read Capacity Units (RCU) bereitstellen, um die Workload zu verarbeiten.

    2. Welche Lösungen sind zum Skalieren von Schreibvorgängen verfügbar (Partitionsschlüssel-Sharding, Einsetzen von Warteschlangen usw.)?

      1. Bei relationalen Datenbanken können Sie die Größe der Instance erhöhen, um eine erhöhte Workload zu bewältigen, oder die bereitgestellten IOPs erhöhen, um einen erhöhten Durchsatz in den zugrunde liegenden Speicher zu ermöglichen.

        • Sie können vor Ihrer Datenbank auch eine Warteschlange einrichten, anstatt direkt in die Datenbank zu schreiben. Mithilfe dieses Musters können Sie die Datenerfassung von der Datenbank entkoppeln und die Flow-Rate steuern, sodass die Datenbank nicht überwältigt wird. 

        • Das Batching Ihrer Schreibanforderungen, anstatt mehrere kurzlebige Transaktionen zu erstellen, kann Ihnen dabei helfen, den Durchsatz bei relationalen Datenbanken mit hohem Schreibvolumen zu verbessern.

      2. Serverless-Datenbanken wie DynamoDB können den Schreibdurchsatz automatisch skalieren oder indem die bereitgestellten Kapazitätseinheiten für Schreibvorgänge (Write Capacity Units, WCU) abhängig vom Kapazitätsmodus angepasst werden. 

        • Es können trotzdem Fehler mit einer „Hot Partition“ auftreten, wenn Sie die Durchsatzgrenzen für einen bestimmten Partitionsschlüssel erreichen. Dies kann verhindert werden, indem Sie einen Partitionsschlüssel auswählen, der gleichmäßiger verteilt ist, oder indem Sie die Schreibvorgänge des Partitionsschlüssels in Shards aufteilen. 

  3. Was sind derzeit die erwarteten höchsten Transaktionen pro Sekunde (TPS)? Testen Sie mithilfe dieser Datenverkehrsmenge und dieser Menge +X%, um die Skalierungsmerkmale zu verstehen.

    1. Native Tools wie pg_bench for PostgreSQL können eingesetzt werden, um die Datenbank einem Stresstest zu unterziehen und Engpässe sowie Skalierungsmerkmale zu verstehen.

    2. Produktionsdatenverkehr sollte erfasst werden, sodass er wiedergegeben werden kann, um zusätzlich zu künstlichen Workloads auch echte Bedingungen zu simulieren.

  4. Wenn Sie Serverless-Datenverarbeitung oder elastisch skalierbare Datenverarbeitung verwenden, testen Sie die Auswirkungen, wenn diese auf der Datenbank skaliert wird. Führen Sie Verbindungsverwaltung oder -Pooling ein, falls zutreffend, um die Auswirkungen auf die Datenbank zu verringern. 

    1. RDS Proxy kann mit Amazon RDS und Aurora verwendet werden, um Verbindungen mit der Datenbank zu verwalten. 

    2. Serverless-Datenbanken wie DynamoDB haben keine ihnen zugewiesenen Verbindungen, aber ziehen Sie die bereitgestellte Kapazität sowie automatische Skalierungsrichtlinien in Betracht, um Datenverkehrsspitzen zu bewältigen.

  5. Ist die Last vorhersehbar, gibt es Lastspitzen und Inaktivitätsphasen?

    1. Wenn es Inaktivitätsphasen gibt, erwägen Sie während dieser Zeitspanne das Herunterskalieren der bereitgestellten Kapazität oder Instance-Größe. Aurora Serverless V2 skaliert auf Basis der Last automatisch hoch oder herunter.

    2. Bei Instances außerhalb der Produktionsumgebung erwägen Sie das Pausieren oder Stoppen dieser Instances in arbeitsfreien Zeiten.

  6. Müssen Sie Ihre Datenmodelle basierend auf Zugriffsmustern und Datenmerkmalen segmentieren und verteilen?

    1. Erwägen Sie die Verwendung von AWS DMS oder AWS SCT, um Ihre Daten zu anderen Services zu verschieben.

Grad des Aufwands für den Implementierungsplan: 

Sie müssen Ihre aktuellen Dateneigenschaften und -metriken kennen, um diese bewährten Methoden einzurichten. Das Erfassen dieser Metriken, Festlegen einer Basislinie und Verwenden von Metriken zum Ermitteln der idealen Datenbankkonfiguration stellt einen niedrigen bis mittleren Grad des Aufwands dar. Die Validierung erfolgt am besten über Lasttests und Experimentieren.

Ressourcen

Zugehörige Dokumente:

Relevante Videos:

Zugehörige Beispiele: