Verwalten von Produktions-Workloads auf gehosteten Datenbanken

Zur Verfügung gestellt von Amazon Web-Services

AWS bietet mehrere Optionen zum Hosten Ihrer Datenbanken, die OLTP-Workloads bedienen – hosten Sie Ihre eigene verwaltete Datenbank auf Amazon EC2 Instanzen oder Verwendung Amazon RDS von AWS verwaltet. RDS verwaltet Hochverfügbarkeit, automatisierte Sicherungen, Datenbank-Upgrades, Betriebssystem-Patches, Sicherheit und Lesereplikate. RDS bietet auch die Cloud-native Option Amazonas-Aurora Datenbank-Engine, die mit MySQL und PostgreSQL kompatibel ist. Aurora liefert einen höheren Durchsatz im Vergleich zu den standardmäßigen MySQL- und PostgreSQL-Datenbanken.



Beim Ausführen von Produktions-Workloads auf gehosteten Datenbanken mit Amazon RDS oder Amazon EC2 sind Ihnen möglicherweise die folgenden Fragen begegnet:

  • Was sind die besten Optionen für Datenbankspeichertypen?
  • Wie können Probleme mit der Speicherleistung behoben werden?
  • Was sind die RAID-Konfigurationsoptionen für von EC2-Instanzen gehostete Datenbanken?
  • Was sind die Anwendungsmodifikationen für eine optimale Leistung?
  • So beheben Sie Probleme mit der Speicherleistung mit Amazon CloudWatch ?
  • Betriebsleistung von Amazon RDS im Vergleich zu Aurora?

In diesem Beitrag stelle ich bewährte Speicherpraktiken für die Ausführung von Produktions-Workloads auf Amazon RDS- oder EC2-Instance-gehosteten Datenbanken bereit.

Im Vergleich zu Test-, QA- oder Staging-Umgebungen erfordern Produktions-Workloads eine schnelle und konsistente E/A-Leistung. Während relationale Datenbanken für mehrere Zwecke verwendet werden können, besteht ihr häufigster Anwendungsfall darin, eine Workload für die Online-Transaktionsverarbeitung (OLTP) zu hosten. RDS, EC2-gehostete Datenbanken und Aurora verwenden verschiedene Arten von Speichertechniken, wie unten gezeigt:

  • Verwendung von Amazon RDS-Datenbankinstanzen Amazon EBS Volumen für die Speicherung.
  • Aurora-Instances verwenden proprietäre AWS-Speichervolumes.
  • EC2-Instances ermöglichen eine Vielzahl von Speicheroptionen.

Beste Optionen für Datenbankspeichertypen

Amazon RDS bietet drei Lagertypen :

  • Allzweck-SSD (auch als gp2-Volumen )
  • Bereitgestellte IOPS-SSD (auch als io1 )
  • Magnetisch

Die E/A-Kapazität der Instanz basiert auf dem Speichertyp und der Größe der Instanz. Wenn die DB-Instance mit einem gp2-Volume konfiguriert ist, beträgt die Basis-IOPS-Kapazität das Dreifache des GiB-Speichers. Wenn die DB-Instance ein 100-GiB-gp2-Volume zugewiesen hat, beträgt die Basis-IOPS-Kapazität 300. Je mehr Speicher Sie bereitstellen, desto höher ist die IOPS-Kapazität.

Zusätzlich zur Basis-IOPS-Kapazität bieten gp2-Volumes auch Burst-Kapazität von bis zu 3.000 IOPS für längere Zeiträume. Die Burst-Funktion ist auf Volumes kleiner oder gleich 1 TiB Speicher beschränkt. DB-Instances für MySQL, MariaDB, Oracle und PostgreSQL können mit 20 GiB–32 TiB konfiguriert werden, aber die maximale Baseline-IOPS ist auf 100 bis 16.000 IOPS begrenzt. Ein gp2-Volume von 5,34 TiB oder mehr liefert also dieselbe Basislinie: 16.000 IOPS.

Wenn Ihr Produktions-Workload ein hohes OLTP und eine schnelle, konsistent hohe Durchsatzleistung erfordert, sollten Sie Ihre DB-Instance mit io1-Volumes konfigurieren. Im Vergleich zu gp2-Volumes, die eine maximale Baseline von 16.000 IOPS liefern, können io1-Volumes bis zu 40.000 IOPS für DB-Instances für MySQL, MariaDB, Oracle und PostgreSQL und bis zu 32.000 für SQL Server-Instances liefern.

Wenn Sie feststellen, dass das Muster der IOPS-Nutzung konstant über 16.000 liegt, sollten Sie dies tun den DB ändern instanceund ändern Sie den Speichertyp von gp2 in io1. Amazon RDS bietet auch Magnetspeicher, ist aber nicht für OLTP-Arbeitslasten geeignet, die eine konsistente E/A-Leistung und geringe Latenz erfordern.

Der magnetische Speichertyp wird für E/A-intensive Workloads nicht empfohlen, da der maximale Speicher geringer ist als der von gp2 oder io1. Die IOPS-Kapazität ist ebenfalls auf maximal 1.000 IOPS begrenzt.

Probleme mit der Speicherleistung

Die Verwendung von gp2-Speicher ist ideal für eine Vielzahl von DB-Workloads. Gestalten Sie für diesen Speichertyp die Lese- und Schreiblasten der Datenbank so, dass die Summe von ReadIOPS und WriteIOPS -Werte zu keinem Zeitpunkt die Basis-IOPS-Kapazität überschreiten.

Burst-Kapazität kann über einen längeren Zeitraum verfügbar sein. Nachdem die Burst-Kapazität jedoch verwendet wurde, verschlechtert ein konstant hoher Wert von Lese- und Schreib-IOPS die Instance-Leistung. Diese Verschlechterung ist durch erhöhte erkennbar WriteLatency oder ReadLatency Werte. Im Idealfall ist gp2-Speicher gut für Latenzzeiten im einstelligen Millisekundenbereich, aber eine übermäßige Nutzung von IOPS kann zu einer Latenzzeit von >10 ms führen.

Die folgenden Bilder zeigen vergrößert WriteLatency -Werte, da WriteIOPS auf einer Amazon RDS-DB-Instance konstant eine Basiskapazität von 300 IOPS verbraucht. In diesem Beispiel wird die Amazon RDS PostgreSQL-Instance auf einer t2.small-Instance mit einem 100-GiB-gp2-Volume gehostet.

Das obige Bild zeigt, dass Write IOPS konstant 300 IOPS verbraucht, was die Basisleistung ist.

Das obige Bild zeigt, dass die Schreiblatenz aufgrund einer übermäßigen Nutzung von IOPS auf 25 Millisekunden angestiegen ist.

Stellen Sie als Best Practice sicher, dass Ihre Workload die IOPS-Kapazität der Instance nicht überschreitet. Einige der Möglichkeiten zur Reduzierung ReadIOPS Werte sind:

  • Verwenden Sie eine Amazon RDS-Read Replica.
  • Verwenden Sie höheren RAM.

Verwenden einer Amazon RDS-Read Replica

Angebot von Amazon RDS-DB-Instances für MySQL, MariaDB, Oracle und PostgreSQL RDS-Read Replicas . Diese Instances sind separate DB-Instances, die mit der Quell-DB-Instance synchronisiert werden, indem Datenbank-Transaktionsprotokolle wiedergegeben werden. Jede Datenänderung auf der Quell-DB-Instance wird auf das Lesereplikat angewendet. Mit einem Lesereplikat reduzieren Sie die Last auf Ihrer Quell-DB-Instance, indem Sie Leseabfragen von Ihren Anwendungen an das Lesereplikat weiterleiten. Sie geben auch IOPS-Kapazität für zusätzliche Schreibaktivitäten in der Quell-DB-Instance frei.

Bei Lesereplikaten ist es wichtig, die Replikationsverzögerung zu überwachen. Im Allgemeinen wird eine hohe Replikationsverzögerung durch eine hohe Schreibaktivität auf der Quell-DB-Instance verursacht.

In Amazon RDS-DB-Instances können Sie Replikationsverzögerungen anhand der CloudWatch-Metrik überwachen ReplicaLag . Wenn Sie eine hohe Replikationsverzögerung feststellen, sollten Sie auch die Schreibaktivität auf der Quell-DB-Instance überwachen. Dies kann durch die Überwachung von CloudWatch-Metriken erreicht werden WriteIOPS und WriteThroughput . Wenn die Quell-DB-Instance IOPS-defizient ist (d. h. die gesamte IOPS-Kapazität wird vom Schreib- und Lese-Workload verwendet), bleibt auch das Replikat hinterher.

Einer der Gründe für verzögerte Replikate ist, dass in den meisten DB-Engines die Read Replica-Wiederherstellung Single-Tread-Prozesse umfasst. Das heißt, je höher die Last auf einer Masterinstanz ist, desto langsamer ist die Wiederherstellung bei Lesereplikaten. Jede zusätzliche hohe Schreibaktivität auf der Quell-DB-Instance erhöht die Verzögerung der Lesereplikate exponentiell. Abgesehen von CloudWatch-Metriken, mit ReplicaLag Sie können die Verzögerung auch durch SQL-Abfragen überwachen.

In PostgreSQL kann die Lesereplikatverzögerung mit der folgenden Abfrage berechnet werden:

|_+_|

In MySQL können Sie den Replikationsstatus mit dem folgenden Befehl überprüfen:

|_+_|

Konfigurieren Sie bei einer Amazon RDS-Lesereplikat den Client so, dass eine bestimmte Latenzstufe oder ein Replikationsfehler, der an einer Replik gefunden wird, dazu führt, dass ein anderer Replikat-Endpunkt versucht wird, eine Verbindung herzustellen.

Eine gute Möglichkeit, um sicherzustellen, dass Ihre Anwendung das fehlerfreiste Replikat finden kann, besteht darin, CloudWatch-Metriken aufzurufen, um die aktuellen Werte von zu ermitteln ReplicaLag und Lese-/Schreiblatenz. Replikationsverzögerungen können mit SQL-Befehlen gefunden werden, wie in den vorherigen Beispielen gezeigt. Sie können den aktuellen Status der Replik auch finden, indem Sie die aufrufen AWS-Befehlszeilenschnittstelle (AWS CLI) Befehl 'describe-db-instances'. Wenn der aktuelle Status des Replikats nicht repliziert wird, sollte der Client versuchen, eine Verbindung zu einem anderen Replikat herzustellen.

Abgesehen von dem Vorteil, Lesetransaktionen zu verteilen, können Lesereplikate auch verwendet werden, um Ihre Daten zu fragmentieren. Gemäß der Share-Nothing-Architektur von Shards können Sie Lesereplikate erstellen, die jedem Ihrer Shards entsprechen, und sie heraufstufen, wenn Sie sich entscheiden, sie in eigenständige Shards zu konvertieren.

Verwendung von höherem RAM

Amazon RDS-DB-Instances sollten über ausreichend RAM verfügen, damit sich Ihr vollständiger Arbeitssatz im Arbeitsspeicher befindet. Da die Leseabfragen Daten aus dem Speicher lesen können, wird die Kommunikation mit Speichervolumes reduziert. Als solches reduziert es die Verwendung von ReadIOPS Kapazität, die für Schreibzwecke verwendet werden kann.

Es gibt keinen einfachen Weg, die Größe eines Arbeitsdatensatzes zu ermitteln. Sehen Sie sich die Leseabfragen an und finden Sie heraus, wie viele Daten betroffen sind. Wenn die Größe einer Datenbank beispielsweise 100 GiB beträgt und der Arbeitssatz 20 GiB beträgt, sollten Sie eine verwenden Amazon RDS-DB-Instance mit mindestens 20 GiB Arbeitsspeicher. Dadurch haben Sie den gesamten Arbeitssatz im Speicher.

RAID-Konfigurationsoptionen für von EC2-Instances gehostete Datenbanken

EBS-Volumes sind Speichervolumes auf Blockebene, die dauerhaften Blockspeicher bereitstellen. Diese Volumes sind hochverfügbare Speichervolumes und können an eine EC2-Instance in derselben Availability Zone angehängt werden. EBS-Volumes sind ideal für von EC2-Instances gehostete Datenbanken. Die Verwendung von kurzlebigem EC2-Instance-Speicher für eine Datenbank wird nicht empfohlen.

Durch die Verwendung von EBS-Speichervolumes mit EC2-Instances können Sie Volumes mit beliebigen RAID-Leveln konfigurieren. Für eine höhere E/A-Leistung können Sie sich beispielsweise für RAID 0 entscheiden, das mehrere Volumes zusammenfassen kann. RAID 1 kann für Datenredundanz verwendet werden, da es zwei Volumes zusammen spiegelt.

Unabhängig von der RAID-Konfiguration werden EBS-Volume-Daten über sekundäre Server repliziert, um Datenverluste zu vermeiden. RAID 5 und RAID 6 werden für EC2-Instance-gehostete Datenbanken nicht empfohlen, da die E/A-Leistung nicht so gut ist wie RAID 0 oder RAID 1.

Die folgende Tabelle zeigt die Vor- und Nachteile zwischen der Verwendung dieser beiden unterschiedlichen RAID-Konfigurationen und schlägt mögliche Anwendungsfälle vor.

Aufbau Vorteile Nachteile Anwendungsfall
RAID 0 E/A-Leistung im Vergleich zur Fehlertoleranz überlegen Der Verlust eines einzelnen Volumes führt zu einem vollständigen Datenverlust Wenn die Datenbank im Vergleich zur Datenverfügbarkeit einen höheren Durchsatz erfordert und die Daten reproduzierbar sind
RAID 1 Die Fehlertoleranz ist der E/A-Leistung überlegen Niedrige Schreibleistung Wenn Daten kritisch sind und die Fehlertoleranz der Datenbank wichtiger ist als die E/A-Leistung

Anwendungsmodifikationen für optimale Leistung

Wenn eine Datenbankinstanz mit Speicherproblemen konfrontiert ist und auf Probleme wie hohe Commit-Zeiten und hohe Latenzen stößt, können Änderungen in der Anwendung diese Verschlechterung manchmal abmildern. Sie können Anwendungen ändern, um exponentielles Backoff oder Fehlerwiederholungen zu aktivieren.

Exponentielles Backoff ermöglicht Anwendungen zunehmend längere Wartezeiten zwischen Wiederholungsversuchen für aufeinanderfolgende Fehlerantworten. Während einige Algorithmen eine inkrementelle Verzögerung verwenden, verwenden die meisten exponentiellen Backoff-Algorithmen eine zufällige Verzögerung. Hier sind Beispiele für einen anderen Algorithmus:

Zufällige Verzögerung:

  1. Anwendung initiiert Anfrage.
  2. Wenn die Anfrage fehlschlägt, warten Sie rand(1000,3000) Millisekunden und starten Sie die Anfrage erneut.
  3. Wenn die Anfrage fehlschlägt, warten Sie rand(1000,3000) Millisekunden und starten Sie die Anfrage erneut.
  4. Wenn die Anfrage fehlschlägt, warten Sie rand(1000,3000) Millisekunden und starten Sie die Anfrage erneut.

Inkrementelle Verzögerung:

  1. Anwendung initiiert Anfrage.
  2. Wenn die Anfrage fehlschlägt, warten Sie 1 = 1000 Millisekunden und starten Sie die Anfrage erneut.
  3. Wenn die Anfrage fehlschlägt, warten Sie 2 = warten Sie 1 + 1000 Millisekunden und initiieren Sie die Anfrage erneut.
  4. Wenn die Anfrage fehlschlägt, warten Sie 3 = warten Sie 2 + 1000 Millisekunden und initiieren Sie die Anfrage erneut.

Verwenden Sie bestimmte Best Practices, um ein schnelleres Failover in Amazon RDS Multi-AZ-Instances und Aurora-Clustern zu erreichen. Aktivieren Sie TCP-Keepalive-Parameter und legen Sie sie aggressiv fest, um sicherzustellen, dass alle aktiven Verbindungen schnell geschlossen werden, wenn Ihr Client keine Verbindung mehr zur DB-Instance herstellen kann. Durch diese Änderung können Anwendungen auch schneller auf Failover reagieren und sich schnell mit dem neuen Endpunkt verbinden.

Sie können auch das DNS-Caching-Timeout auf dem Client reduzieren. Lese- und Schreibverbindungen werden schnell zu den entsprechenden Endpunkten aufgebaut. Einige der TCP-Einstellungsparameter des Servers können ebenfalls geändert werden. Diese Änderungen tragen zu einem schnelleren Failover bei. In PostgreSQL kann dies beispielsweise durch tcp_keepalives_count, tcp_keepalives_idle und tcp_keepalives_interval gesteuert werden Parameter .

Fehlerbehebung bei der Speicherleistung mit CloudWatch

Durch die regelmäßige Überwachung des Zustands des Instanzspeichers wird das frühe Auftreten eines Leistungsproblems erkannt, bevor es schwerwiegende Auswirkungen auf die Datenbankleistung hat. Einige der Speicher-CloudWatch-bezogenen Metriken, die Sie regelmäßig überwachen sollten, sind hier aufgelistet.

Schreiboperationen

  • WriteIOPS: Diese CloudWatch-Metrik wird mit einer Rate von Zählungen/Sekunde gemessen und bestimmt die durchschnittliche Anzahl von E/A-Vorgängen zum Schreiben von Festplatten pro Sekunde. Konzentrieren Sie sich auf diese Metrik, wenn Ihre Datenbankinstanz mit einer Multi-AZ-Einstellung konfiguriert ist.
    Bei Verwendung von Multi-AZ wird eine sekundäre Instance in einer anderen Availability Zone mit derselben Instance-Konfiguration wie das Master- und angeschlossene EBS-Speichervolume erstellt. Dieser Speicher wird synchron mit dem Speicher der Masterinstanz synchronisiert. Für Datenredundanz werden Daten in jedem EBS-Volume standardmäßig auf ein anderes, sekundäres EBS-Volume kopiert, das sich in derselben Availability Zone befindet. Dies bedeutet, dass eine Schreibtransaktion an vier Stellen festgeschrieben werden muss, bevor eine Bestätigung an den Client gesendet wird. Massive Schreibaktivitäten oberhalb der IOPS- und Durchsatzkapazität der Instanzen verschlechtern die Gesamtleistung.
  • Schreibdurchsatz: Diese CloudWatch-Metrik stellt die durchschnittliche Anzahl von Bytes dar, die pro Sekunde auf die Festplatte geschrieben werden. Das Überschreiten des Instance-Durchsatzes oder des Speicherdurchsatzlimits beeinträchtigt die Instance-Leistung. Ich schlage vor, die Schreibaktivität zu überwachen und die Schreibarbeitslast mit einer angemessenen Verzögerung zu verteilen, um die Leistung zu optimieren.
  • Schreiblatenz: Dies ist die durchschnittliche Zeit, die pro Festplatten-E/A-Vorgang benötigt wird. Meistens WriteLatency Anstiege sind auf eine Überbeanspruchung der Instance-Ressourcen wie CPU, IOPS und Durchsatz zurückzuführen.

Operationen lesen

  • ReadIOPS: Diese CloudWatch-Metrik wird mit einer Rate von Zählungen/Sekunde gemessen und bestimmt die durchschnittliche Anzahl von Festplattenlese-E/A-Vorgängen pro Sekunde. Der erhöhte Wert von ReadIOPS deutet darauf hin, dass entweder die Lesearbeitslast hoch ist oder die Instanz mehr freien Speicher benötigt.
  • Lesedurchsatz: Diese Metrik stellt die durchschnittliche Anzahl von Bytes dar, die pro Sekunde von der Festplatte gelesen werden. Das Überschreiten der Instanz- und EBS-Grenzen kann die Latenz erhöhen.
  • Leselatenz: Dies ist die durchschnittliche Zeit, die pro Festplatten-E/A-Vorgang benötigt wird. Wenn Sie einen hohen Wert für diese Metrik haben, sehen Sie sich die Lese-Workload an und stellen Sie sicher, dass die Instance-Ressourcen nicht überlastet werden.

Andere Metriken

Neben den zuvor erwähnten Metriken sollten Sie auch die folgenden CloudWatch-Metriken überwachen:

  • DiskQueueDepth stellt die Anzahl der ausstehenden I/Os (Lese-/Schreibanforderungen) dar, die auf den Zugriff auf die Festplatte warten. Typischerweise ist dies das Ergebnis einer hohen Arbeitsbelastung.
  • Kostenloser Speicherplatz bestimmt die Menge des verfügbaren Speicherplatzes. Als Best Practice sollten Sie festlegen CloudWatch-Warnungen damit Sie SNS-Benachrichtigungen erhalten, sobald der freie Speicherplatz der Instanz einen Schwellenwert unterschreitet, z. B. 15 %.

Betriebsleistung von Amazon RDS im Vergleich zu Aurora

Wie bereits erwähnt, haben Amazon RDS-DB-Instances und EC2-Instances eine IOPS-Abhängigkeit von Speichervolumes. Die Speichertypen gp2 und io1 haben ihre eigenen IOPS-Limits.

Wenn Ihre Workload eine höhere IOPS-Leistung und einen höheren Durchsatz erfordert, planen Sie möglicherweise eine Migration zu Aurora, einer hochleistungsfähigen, hochverfügbaren und kostengünstigen Lösung, die für Workloads mit hohem Durchsatz geeignet ist. Zur Zeit, Dämmerung bietet MySQL- und PostgreSQL-kompatible Engines.

Stellen Sie bei der Verwendung von Aurora sicher, dass es technisch gesehen keine Begrenzung der IOPS gibt, der Durchsatz jedoch auf den zugrunde liegenden Wert begrenzt sein könnte Aurora-Instanz Grenze. Wählen Sie für einen besseren Durchsatz eine höhere Aurora-Instance-Klasse.

Aurora eignet sich am besten für Anwendungen, die wenig bis gar keine Latenz für einen bestimmten IOPS erfordern. Es wurde entwickelt, um eine hohe Datengeschwindigkeit zu bewältigen und einen höheren Durchsatz im Vergleich zu herkömmlichen MySQL- und PostgreSQL-Engines zu bieten. Als Row-Store-Datenbank eignet sie sich ideal für hochvolumige, gleichzeitige OLTP-Workloads.

Ein weiterer Anwendungsfall von Aurora ist Hybrid Transaction Analytical Processing (HTAP). Aurora unterstützt bis zu 15 Replikate. Jedes dieser Replikate wird innerhalb von 15 bis 20 Millisekunden nach der Schreibinstanz ausgeführt. Mit den kürzlich hinzugefügten Parallele Amazon Aurora-Abfragefunktion , wird die Abfrageverarbeitung später in den Aurora-Speicher verschoben. Die Abfrage verwendet potenziell Tausende von Speicherknoten in einem Aurora-Cluster, um Daten zu verarbeiten, zu verfeinern und zu aggregieren, bevor sie an den Rechenknoten gesendet werden.

Fazit

In diesem Beitrag haben Sie bewährte Speicherpraktiken zum Ausführen einer Produktions-Workload auf Amazon RDS-DB-Instances und von EC2-Instances gehosteten Datenbanken kennengelernt. Diese Praktiken umfassten Folgendes:

  • Lese-Workloads einem Lesereplikat zuweisen.
  • Verstehen der IOPS-Kapazität und ihrer Abhängigkeit von Speichergröße und -typ.
  • Ändern der Anwendungsarchitektur.
  • Untersuchen von RAID-Optionen.
  • Überwachung von CloudWatch-Metriken.

Sie haben auch etwas über Aurora erfahren und wie sich sein proprietärer Speicher von EBS-Volumes unterscheidet. All dieses Wissen hilft Ihnen, einen Produktions-Workload reibungslos und ohne Probleme auf AWS-Datenbanken auszuführen. In diesem Datenbank-Blog-Beitrag können Sie auch nachsehen, wie Aurora die Geschwindigkeit und Verfügbarkeit von Datenbanken mithilfe der Speicherschicht handhabt: Einführung der Aurora-Speicher-Engine.

verbergen