ElastiCache-Redis-Replikationsgruppen und Clustermodus

Eine ElastiCache-Replikationsgruppe ist eine logische Gruppierung aus einem primären Redis-Knoten und bis zu fünf Lesereplikaten. Der primäre Knoten verarbeitet alle Schreibvorgänge; Replikate werden asynchron vom primären Knoten repliziert und bedienen den Leseverkehr. Replikationsgruppen ermöglichen zwei zentrale Funktionen: Skalierung der Leseleistung (Verteilung von Leseanforderungen auf mehrere Replikate) und hohe Verfügbarkeit mit automatischem Failover (Hochstufung eines Replikats zum primären Knoten, wenn der primäre Knoten ausfällt). Alle Knoten einer Replikationsgruppe verfügen über denselben Datensatz.

ElastiCache stellt für eine Replikationsgruppe zwei DNS-Endpunkte bereit: Der primäre Endpunkt verweist immer auf den aktuellen primären Knoten (und wird bei einem Failover automatisch aktualisiert) – verwenden Sie ihn für alle Schreibvorgänge. Der Reader-Endpunkt verteilt Leseanforderungen per Load-Balancing auf alle verfügbaren Replikate – verwenden Sie ihn für Lesevorgänge, um die Last zu verteilen. Ihre Anwendung sollte zwei Verbindungspools verwalten: einen für Schreibvorgänge über den primären Endpunkt und einen für Lesevorgänge über den Reader-Endpunkt. Dies ist das empfohlene Verbindungsmuster für ElastiCache-Redis-Replikationsgruppen.

Wenn der primäre Knoten ausfällt (von ElastiCache innerhalb weniger Sekunden über Zustandsprüfungen erkannt), wählt das automatische Failover eines der Lesereplikate aus und stuft es zum primären Knoten hoch. Der Vorgang läuft folgendermaßen ab: (1) Das ausgewählte Replikat wird zum primären Knoten hochgestuft, (2) der DNS-Eintrag des primären Endpunkts wird aktualisiert und verweist auf den neuen primären Knoten (TTL ca. 1 Sekunde), (3) der alte primäre Knoten wird durch ein neues Replikat ersetzt. Die gesamte Failover-Zeit beträgt in der Regel 30–60 Sekunden. Anwendungen, die den DNS-Namen des primären Endpunkts verwenden, verbinden sich automatisch neu, sobald die DNS-Änderung propagiert wurde – fest codierte IP-Adressen sind nicht erforderlich.

Für maximale Ausfallsicherheit sollten Sie Replikate über mehrere Availability Zones verteilen. Wenn Sie Multi-AZ für eine Replikationsgruppe aktivieren, platziert ElastiCache den primären Knoten und die Replikate automatisch in unterschiedlichen AZs. Wenn eine gesamte AZ ausfällt, stuft das Failover ein Replikat aus einer weiterhin verfügbaren AZ hoch. Beim Erstellen der Replikationsgruppe können Sie außerdem die bevorzugten AZs für jeden Knoten mit der Option --preferred-cache-cluster-a-zs explizit angeben.

Redis Cluster Mode Enabled (CME) partitioniert den Datensatz über mehrere Knotengruppen (Shards), die jeweils einen primären Knoten und bis zu fünf Replikate enthalten. Dies ist die Lösung von Redis für horizontales Sharding. Mit dem Cluster-Modus können Sie die Speicherkapazität eines einzelnen Knotens überschreiten – Sie können bis zu 500 Knotengruppen mit jeweils 500 GB verwenden, sodass ein einzelner Redis-Cluster bis zu 500 × 500 GB = 250 TB an Daten aufnehmen kann. Der Cluster-Modus vervielfacht außerdem den Schreibdurchsatz, da jede Knotengruppe Schreibvorgänge für ihren Schlüsselbereich unabhängig verarbeitet.

Der Redis-Cluster-Modus teilt den Schlüsselbereich in 16.384 Hash-Slots auf. Jede Knotengruppe besitzt einen zusammenhängenden Bereich von Hash-Slots. Beim Schreiben eines Schlüssels berechnet Redis CRC16(key) % 16384, um den Hash-Slot und damit die zuständige Knotengruppe zu bestimmen. Ihre Anwendung muss einen Cluster-fähigen Redis-Client verwenden (z. B. redis-py-cluster oder Jedis im Cluster-Modus), der die Slot-Zuordnung kennt und jeden Befehl an den richtigen Knoten weiterleitet. Standardclients geben MOVED-Weiterleitungsfehler zurück, wenn sie einen Schlüssel an den falschen Shard senden.

Wählen Sie für das SAA-C03-Examen den Nicht-Cluster-Modus, wenn: Ihre Daten auf einen einzelnen Knoten passen (< 400 GB nach Abzug der Reserve), Sie eine einfache Konfiguration aus primärem Knoten und Replikaten benötigen oder Ihre Anwendung komplexe Operationen mit mehreren Schlüsseln verwendet (Transaktionen über mehrere Schlüssel hinweg erfordern, dass sich alle Schlüssel im selben Slot befinden). Wählen Sie den Cluster-Modus, wenn: Ihr Datensatz den Arbeitsspeicher eines einzelnen Knotens übersteigt, Sie eine horizontale Skalierung des Schreibdurchsatzes benötigen oder Sie ein künftiges Wachstum erwarten, das Online-Resharding erfordern wird. Der Cluster-Modus unterstützt das Hinzufügen von Shards ohne Ausfallzeit (Online-Resharding).

ElastiCache Global Datastore erweitert die Redis-Replikation über mehrere AWS-Regionen hinweg. Sie bestimmen eine Region als primären Cluster und fügen sekundäre Cluster in anderen Regionen hinzu. Schreibvorgänge werden an den primären Cluster gesendet; die sekundären Cluster erhalten eine asynchrone Replikation mit einer typischen Verzögerung von unter 1 Sekunde. Sekundäre Cluster können lokale Lesevorgänge mit sehr geringer Latenz bedienen. Global Datastore ermöglicht globale Anwendungen, bei denen Benutzer auf verschiedenen Kontinenten aus der nächstgelegenen Region lesen, sowie eine regionsübergreifende Disaster Recovery, bei der Sie einen sekundären Cluster zum primären Cluster heraufstufen können, wenn die primäre Region ausfällt.

In einer nicht geclusterten Redis-Replikationsgruppe werden Pub/Sub-Nachrichten an alle Replikate verteilt – jeder Subscriber auf jedem Knoten empfängt Nachrichten, die in einem Channel veröffentlicht werden. Im Cluster Mode ist Pub/Sub jedoch auf Keyspace-Benachrichtigungen beschränkt, und Channel-basiertes Pub/Sub funktioniert nur innerhalb eines einzelnen Shards, sofern Sie nicht Redis 7+ mit Pub/Sub-Sharding verwenden (SSUBSCRIBE / SPUBLISH für shard-bewusstes Pub/Sub). Dies ist eine wichtige Einschränkung bei der Konzeption von Pub/Sub im großen Maßstab mit dem Cluster Mode.

Überwachen Sie die CloudWatch-Metrik ReplicationLag auf Lesereplikaten, um sicherzustellen, dass diese mit dem primären Cluster Schritt halten. Eine Verzögerung von mehr als einigen Sekunden weist auf einen Engpass beim Replikat hin, beispielsweise einen überlasteten Knoten, Netzwerkprobleme oder mehr Schreibvorgänge, als das Replikat verarbeiten kann. Überwachen Sie in Global-Datastore-Szenarien GlobalDatastoreReplicationLag. Eine hohe Replikationsverzögerung bedeutet, dass Lesereplikate möglicherweise veraltete Daten zurückgeben – besonders wichtig für Anwendungen, die eine letztendliche Konsistenz innerhalb enger Grenzen erwarten.

Sie können vertikal skalieren (den Knotentyp ändern) oder horizontal skalieren (Replikate hinzufügen oder entfernen). Das Ändern des Knotentyps erfordert einen Aufruf von modify-replication-group und führt bei sofortiger Anwendung zu einem kurzen Failover – der primäre Knoten wird durch einen neuen Knoten des neuen Typs ersetzt. Das Hinzufügen von Replikaten ist online und ohne Ausfallzeit möglich. Wenn Sie vom nicht geclusterten Modus in den Cluster Mode wechseln, müssen Sie eine neue Gruppe im Cluster Mode erstellen und die Daten migrieren – eine direkte Konvertierung zwischen Cluster Mode und nicht geclustertem Modus ist nicht möglich.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: Replikationsgruppen ermöglichen die Skalierung von Lesevorgängen mithilfe von Replikaten sowie hohe Verfügbarkeit durch automatisches Failover mit primären und Reader-Endpunkten. Der Cluster Mode verteilt Daten mithilfe von 16.384 Hash-Slots auf bis zu 500 Knotengruppen und ermöglicht so horizontale Skalierung über den Speicher eines einzelnen Knotens hinaus. Global Datastore repliziert Daten über Regionen hinweg und ermöglicht weltweit Lesevorgänge mit niedriger Latenz sowie regionsübergreifende Disaster Recovery. Als Nächstes untersuchen wir Caching-Strategien: Lazy Loading und Write-Through.