In diesem Blogbeitrag erkläre ich Ihnen den Unterschied zwischen den EBS-Volumen GP2 und GP3. Ich verdeutliche, warum ein Wechsel zu GP3 bessere Leistung bei niedrigeren Kosten verspricht und wie unkompliziert so eine Migration sein kann. Zusätzlich stelle ich Ihnen ein Skript zur Verfügung, das die Umstellung erleichtert und eine Vorab-Kalkulation Ihrer Kosteneinsparungen ermöglicht.
Kurze Einführung in EBS mit GP2 und GP3
Was ist EBS?
Elastic Block Store (EBS) ist ein Blockspeicherdienst von Amazon Web Services, der dauerhaften Speicher für EC2-Instanzen bereitstellt. EBS-Volumens können dynamisch erstellt, skaliert und an EC2-Instanzen angehängt werden und unterstützen Funktionen wie Snapshots und Verschlüsselung für Datensicherheit und Wiederherstellung.
Und was ist nun GP2 und GP3?
GP2 und GP3 sind zwei Typen von SSD-basierten EBS-Volumen, die für allgemeine Zwecke (General Purpose) konzipiert wurden und sich in Leistung und Kosten unterscheiden.
GP2 sind general purpose SSDs (Solid State Drives), die eine Balance zwischen Leistung und Kosten bieten. Die Performance von GP2-Volumen skaliert mit der Größe des Volumens; größere Volumen bieten höhere Throughputs und mehr IOPS. GP2 eignet sich gut für eine Vielzahl von allgemeinen Anwendungsfällen, von Entwicklungs- und Testumgebungen bis hin zu Datenbanken.
GP3 ist die neuere Generation der general-purpose SSDs, die konsistente Performance unabhängig von der Volumengröße bietet. GP3-Volumen kommen mit einer Baseline-Performance, die unabhängig von der Größe des Volumens ist, und Benutzer können IOPS und Throughput unabhängig voneinander skalieren. Dies führt zu Kosteneinsparungen, da man nicht mehr Volumengröße hinzufügen muss, um die gewünschte Performance zu erreichen. GP3 bietet auch eine höhere maximale IOPS- und Throughput im Vergleich zu GP2.
Zusammenfassend bietet die neue GP3-Generation eine kostengünstigere Speicherlösung, die bei gleicher oder sogar höherer Performance Vorteile gegenüber GP2 aufweist.
Was sind IOPS und Throughput?
IOPS (Input/Output Operations Per Second) misst die Anzahl der Lese- und Schreibvorgänge, die ein Speichersystem wie Amazon EBS pro Sekunde bewältigen kann. Dies ist entscheidend für Workloads, die einen schnellen und häufigen Datenzugriff benötigen, wie beispielsweise Datenbanken.
Throughput quantifiziert die Datenübertragungsrate zu und von Speicher, typischerweise in MB/s, und ist wichtig für Anwendungen, die große Datenmengen bewegen, wie etwa Datenverarbeitungstasks.
Verschiedene EBS-Volumentypen balancieren diese Metriken, um verschiedene Anwendungen zu unterstützen—hohe IOPS für transaktionale Workloads und hohen Throughput für datenintensive Aufgaben.
Wann mehr IOPS benötigt wird: Betrachten wir eine hochtransaktionale Datenbank, die eine E-Commerce-Website betreibt, auf der Tausende von Transaktionen pro Minute durchgeführt werden, wobei jede Transaktion mehrere Lese- und Schreibvorgänge umfasst. Die Leistung dieser Website hängt davon ab, wie schnell jede Operation verarbeitet werden kann. In solchen Szenarien ist eine höhere IOPS-Kapazität unerlässlich, um eine schnelle, konsistente Transaktionsverarbeitung und ein reibungsloses Benutzererlebnis sicherzustellen.
Wann mehr Throughput benötigt wird: Nehmen wir ein Videobearbeitungsunternehmen an, das regelmäßig mit großen Videodateien arbeitet. Wenn die Redakteure diese Dateien rendern oder übertragen, liegt der Engpass nicht in der Anzahl der Operationen pro Sekunde, sondern darin, wie viele Daten gleichzeitig bewegt werden können. In diesem Fall ist ein höherer Throughput notwendig, um schnell vom Speicher zu lesen und auf den Speicher zu schreiben, was eine effiziente Handhabung großer Datenübertragungen ermöglicht.
Wie überprüft man die IOPS und den Throughput von EBS-Volumen?
Um einen allgemeinen Überblick über alle EBS-Volumes zu erhalten, ist AWS Compute Optimizer
ein nützliches Werkzeug. Es ist für EBS ohne zusätzliche Kosten verfügbar und bietet eine separate Ansicht für EBS-Volumes. AWS Compute Optimizer zeigt Details für jedes EBS-Volume, einschließlich der aktuellen und empfohlenen IOPS sowie Throughput. Es zeigt auch den aktuellen Volumentyp, wie GP2 oder GP3.
Sollten Sie mögliche EBS-Resize-Ergebnisse im AWS Compute Optimizer bezüglich IOPS und Throughput entdecken oder wenn Sie einzelne EBS-Volumes genauer untersuchen möchten, empfiehlt es sich, einen Blick auf CloudWatch zu werfen. Dort können Sie die detaillierten historischen Trends der IOPS und des Throughputs für jedes EBS-Volume einsehen.
CloudWatch hat jedoch keine direkten Metriken für IOPS und Throughput. Stattdessen stellt es Metriken für VolumeReadOps, VolumeWriteOps, VolumeReadBytes, und VolumeWriteBytes bereit. Um eine Metrik für IOPS und Throughput zu erstellen, muss man eine benutzerdefinierte Funktion definieren.
Für IOPS lautet die Funktion „(VolumeReadOps + VolumeWriteOps) / PERIOD“ wobei PERIOD das ausgewählte Intervall für sowohl VolumeReadOps als auch VolumeWriteOps ist. In diesem Beispiel beträgt das Intervall 1 Minute, also teilen wir durch 60 Sekunden. Die gewählte Statistik ist „Average“. Sobald die Funktion erstellt ist, werden die Metriken VolumeReadOps und VolumeWriteOps einer ID zugewiesen, die dann genutzt werden kann; somit ist der Ausdruck in diesem Fall (m1+m2)/60.
Ich habe einen Stresstest mit dem Linux-Tool „fio“ durchgeführt, um die Funktionalität zu validieren. Das hier verwendete Speichervolumen ist ein GP3 mit 3000 IOPS, und wie gezeigt, habe ich dieses Limit vollständig ausgenutzt.
Für den Throughput lautet die Formel ((VolumeReadBytes + VolumeWriteBytes) / 1048576) / PERIOD. Der Grund, warum wir durch 1.048.576 teilen, ist, dass VolumeReadBytes und VolumeWriteBytes in Bytes angegeben sind. Da 1.024 Bytes 1 KiB entsprechen und 1.024 KiB 1 MiB entsprechen, ergibt das Multiplizieren dieser Zahlen (1024 * 1024) 1.048.576. Diese Umrechnung ist notwendig, da EBS-Volumes ihren Throughput in MiB angeben. Die gewählte Statistik ist „Sum“.
Für diesen Screenshot habe ich auch einen Lasttest mit dem Linux-Tool „fio“ durchgeführt, um die Grenzen auszuloten. In diesem Fall wurde ein Throughput von 125 MiB/s auf dem GP3-Volume erreicht.
Der hier verwendete Ausdruck ist „((m1+m2)/1048576)/60“.
Wie kann von GP2 zu GP3 migriert werden?
Leider sehe ich immer noch AWS-Umgebungen, die GP2 verwenden, zumeist aus historischen Gründen oder Unwissenheit. Obwohl GP3 ausschließlich Vorteile gegenüber GP2 bietet und die Migration von GP2 auf GP3 ohne Ausfallzeiten durchgeführt werden kann, bleiben viele bei der älteren Technologie. Bei Umgebungen, die mit Infrastructure as Code aufgebaut wurden, sollte die Umstellung im Code vorgenommen werden, und zwar in den entsprechenden Templates von CloudFormation, CDK, Terraform etc. Bei statisch aufgebauten und manuell erstellten Umgebungen besteht die Möglichkeit, die EBS-Volumens der EC2-Instanzen mithilfe eines Skripts automatisiert und mit minimalem Aufwand umzustellen. Wie das funktioniert, zeige ich in diesem GitHub-Repository. Ich erläutere auch, wie ein Kostenvergleich vor der Migration von GP2 auf GP3 erstellt werden kann, sodass nachvollziehbar wird, wie hoch die Kosteneinsparung ist.
Das Skript ermöglicht es mir zudem, zu entscheiden, ob ich bei GP3 die gleichen IOPS- und Throughputs wie bei GP2 nutzen möchte. Dann hätte ich bei EBS-Volumens unter 1000 GB eine bessere Performance und bei über 1000 GB eine gleichbleibende Performance, jeweils mit geringeren Kosten, mit GP3.
Bevor mit der Migration von EBS Volumes fortgefahren wird, ist es wesentlich zu überprüfen, ob deren Nutzung die Baseline-Performance-Niveaus von GP3, welche 3000 IOPS und 125 MiB/s Durchsatz sind, überschreitet. Um diese Bewertung zu erleichtern, können Sie Tools wie den AWS Compute Optimizer und die zuvor erwähnten CloudWatch-Metriken verwenden. Falls keine Aktivitäten über der GP3 Baseline vorhanden sind, kann der Export des Skripts so angepasst werden, dass die Baseline-Werte für die Migration von GP2 zu GP3 verwendet werden können. Dies kann eine Einsparung von 20 % erzielen, siehe mittlere Spalte. Das Skript verwendet standardmäßig die „matching configuration“, siehe rechte Spalte:
Sobald die Migration von GP2 zu GP3 mit dem Skript gestartet wurde, dauert die Umstellung eines Volumens mit einer Größe von 30 GB circa 5–10 Minuten und für ein Volumen von 300 GB circa 30 Minuten. Wie bereits erwähnt, entsteht hierbei keine Downtime oder Beeinträchtigung der Performance.
Abschließende Worte
Ich hoffe, ich konnte Ihnen die Unterschiede zwischen GP2- und GP3-EBS-Volumens aufzeigen und die Einfachheit der Migration von GP2 zu GP3 verdeutlichen. Ich würde mich freuen, wenn Sie für die Umstellung mein Skript nutzen und ich Sie dazu bewegen konnte, die neueren GP3-EBS-Volumens zu verwenden. Bitte geben Sie mir gerne Rückmeldung, falls Sie eine Migration mit dem Skript durchgeführt haben und wie viel Kosten Sie dadurch einsparen konnten. So konnte ich beispielsweise bei einem Kunden mit dem Skript rund 500 GP2-EBS-Volumens zu GP3 migrieren und damit knapp 4000 US-Dollar im Monat an AWS-Kosten einsparen.