Best Practices für Memorystore for Redis Cluster

Auf dieser Seite finden Sie eine Anleitung zur optimalen Verwendung von Memorystore for Redis Cluster. Außerdem werden potenzielle Probleme aufgeführt, die Sie vermeiden sollten.

**Hinweis**: Beispiele für die Clientkonfiguration von Redis Cluster finden Sie unter Codebeispiele für Clientbibliotheken.

Best Practices für die Speicherverwaltung

In diesem Abschnitt werden Strategien für die Speicherverwaltung für Cluster beschrieben, damit Memorystore for Redis Cluster effizient für Ihre Clientanwendungen funktioniert.

Konzepte zur Speicherverwaltung

• Schreiblast : Das Volumen und die Geschwindigkeit, mit der Sie Schlüssel in Ihrem Redis-Cluster hinzufügen oder aktualisieren. Je nach Redis-Anwendungsfall und Nutzungsmuster der Anwendung kann die Schreiblast normal bis sehr hoch sein.

• Entfernungsrichtlinie : Memorystore for Redis Cluster verwendet die volatile-lru Entfernungsrichtlinie. Mit Befehlen wie EXPIRE können Sie Entfernungen für Schlüssel festlegen.

Cluster mit normaler Schreiblast beobachten

Sehen Sie sich den /cluster/memory/maximum_utilization Messwert an. Wenn /cluster/memory/maximum_utilization bei 100% oder darunter liegt, funktioniert Ihr Redis-Cluster gut, wenn Sie eine normale Schreiblast verwenden.

Wenn sich die Arbeitsspeichernutzung jedoch 100% nähert und Sie mit einer Zunahme der Datennutzung rechnen, sollten Sie die Clustergröße erhöhen, um Platz für neue Daten zu schaffen.

Cluster mit hoher Schreiblast beobachten

Sehen Sie sich den /cluster/memory/maximum_utilization Messwert an. Je nach Schweregrad der hohen Schreiblast können bei den folgenden Grenzwerten Leistungsprobleme auftreten:

• Bei sehr hohen Schreiblasten können Probleme auftreten, wenn /cluster/memory/maximum_utilization 65% oder mehr erreicht.

• Bei mäßig hohen Schreiblasten können Probleme auftreten, wenn /cluster/memory/maximum_utilization 85% oder mehr erreicht.

In diesen Szenarien sollten Sie die Clustergröße erhöhen, um die Leistung zu verbessern.

Wenn Probleme auftreten oder Sie befürchten, dass Ihr Cluster eine hohe Schreib last hat, wenden Sie sich an den Google Cloud Support.

Shards skalieren

Wenn Sie die Anzahl der Shards in einem Cluster skalieren, sollten Sie dies in Zeiten geringer Schreiblast tun. Die Skalierung in Zeiten hoher Schreiblast kann den Arbeitsspeicher Ihres Clusters aufgrund des Speicheraufwands belasten, der durch die Replikation oder die Slotmigration verursacht wird.

Wenn in Ihrem Redis-Anwendungsfall Schlüssel entfernt werden, kann die Skalierung auf eine kleinere Clustergröße die Cache-Trefferquote verringern. In diesem Fall müssen Sie sich jedoch keine Sorgen um Datenverlust machen, da das Entfernen von Schlüsseln erwartet wird.

Bei Redis-Anwendungsfällen, in denen Sie keine Schlüssel verlieren möchten, sollten Sie nur auf einen kleineren Cluster herunterskalieren, der noch genügend Platz für Ihre Daten bietet. Die neue Zielshardanzahl sollte mindestens das 1,5-fache des von den Daten verwendeten Arbeitsspeichers betragen. Mit anderen Worten: Sie sollten genügend Shards für das 1, 5-fache der Datenmenge in Ihrem Cluster bereitstellen. Mit dem Messwert /cluster/memory/total_used_memory können Sie sehen, wie viele Daten in Ihrem Cluster gespeichert sind.

Best Practices für die CPU-Auslastung

Wenn ein unerwarteter zonaler Ausfall auftritt, führt dies zu weniger CPU-Ressourcen für Ihren Cluster, da die Kapazität der Knoten in der nicht verfügbaren Zone verloren geht. Wir empfehlen die Verwendung von Clustern mit hoher Verfügbarkeit. Wenn Sie mehrere Replikate pro Shard verwenden (im Gegensatz zu einem Replikat pro Shard), stehen bei einem Ausfall zusätzliche CPU-Ressourcen zur Verfügung. Sie können bis zu fünf Replikate pro Shard haben.

Außerdem empfehlen wir, die CPU-Auslastung der Knoten so zu verwalten, dass die Knoten genügend CPU-Overhead haben, um zusätzlichen Traffic aufgrund von Kapazitätsverlusten zu verarbeiten, wenn ein unerwarteter zonaler Ausfall auftritt. Sie sollten die CPU-Auslastung für primäre Instanzen und Replikate mit dem Messwert „CPU-Sekunden des Hauptthreads“ /cluster/cpu/maximum_utilization beobachten.

Je nach Anzahl der Replikate, die Sie pro Knoten bereitstellen, empfehlen wir die folgenden Ziele für die CPU-Auslastung /cluster/cpu/maximum_utilization:

• Bei Clustern mit einem Replikat pro Knoten sollte der Wert /cluster/cpu/maximum_utilization für die primäre Instanz und das Replikat 0, 5 Sekunden betragen.
• Bei Clustern mit mindestens zwei Replikaten pro Knoten sollte der Wert /cluster/cpu/maximum_utilization für die primäre Instanz 0,9 Sekunden und für jedes Replikat 0,5 Sekunden betragen.

Wenn die Werte für den Messwert diese Empfehlungen überschreiten, empfehlen wir, die Anzahl der Shards in Ihrem Cluster zu erhöhen. Wenn Ihr Cluster weniger als fünf Replikate hat, können Sie auch die Anzahl der Replikate auf maximal fünf erhöhen.

Wenn in Ihrem Cluster eine hohe CPU-Auslastung auftritt oder die Ressourcen des Clusters erschöpft sind (z. B. durch zu viele Verbindungen), kann es zu Fehlverhalten des Clusters kommen und externe Messwerte fehlen.

Ressourcenintensive Redis-Befehle

Wir empfehlen dringend, keine ressourcenintensiven Redis-Befehle zu verwenden. Die Verwendung dieser Befehle kann zu den folgenden Leistungsproblemen führen:

• Hohe Latenz und Client-Time-outs
• Speicherdruck aufgrund von Befehlen, die die Arbeitsspeichernutzung erhöhen
• Datenverlust bei der Knotenreplikation und -synchronisierung, weil der Redis-Hauptthread blockiert ist
• Zu wenige Ressourcen für Systemdiagnosen, Beobachtbarkeit und Replikation

In der folgenden Tabelle sind Beispiele für ressourcenintensive Redis-Befehle aufgeführt und ressourceneffiziente Alternativen werden genannt.

Tipp: Diese Befehle sind nicht nur ressourcenintensiv, sondern auch mit steigender Gesamtdatengröße teurer.

Mit SLOWLOG können Sie herausfinden, welche Befehle lange ausgeführt werden. Dieses Tool enthält eine Liste der Befehle, deren Ausführung am längsten dauert. So wissen Sie, welche Befehle Latenzprobleme verursachen. In der folgenden Tabelle finden Sie ressourceneffiziente Alternativen für diese Befehle.

Kategorie	Ressourcenintensiver Befehl	Ressourceneffiziente Alternative
Für den gesamten Schlüsselbereich ausführen	KEYS	SCAN
Für einen Schlüsselbereich mit variabler Länge ausführen	LRANGE	Beschränken Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden.
	ZRANGE	Beschränken Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden.
	HGETALL	HSCAN
	SMEMBERS	SSCAN
Ausführung eines Skripts blockieren	EVAL	Achten Sie darauf, dass Ihr Skript nicht unbegrenzt ausgeführt wird.
	EVALSHA	Achten Sie darauf, dass Ihr Skript nicht unbegrenzt ausgeführt wird.
Dateien und Links entfernen	DEL	UNLINK
Veröffentlichen und abonnieren	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Best Practices für Redis-Clients

Ihre Anwendung muss einen clusterfähigen Redis-Client verwenden, wenn sie eine Verbindung zu einem Cluster herstellt. Beispiele für clusterfähige Clients und Beispielkonfigurationen finden Sie unter Codebeispiele für Clientbibliotheken. Ihr Client muss eine Zuordnung von Hash-Slots zu den entsprechenden Knoten im Cluster verwalten, um Anfragen an die richtigen Knoten zu senden und den Leistungsaufwand zu vermeiden, der durch Clusterumleitungen verursacht wird.

Clientzuordnung

Clients müssen in den folgenden Situationen eine vollständige Liste der Slots und der zugeordneten Knoten abrufen:

• Wenn der Client initialisiert wird, muss er die anfängliche Zuordnung von Slots zu Knoten erstellen.

• Wenn vom Server eine MOVED-Umleitung empfangen wird, z. B. bei einem Failover, wenn alle Slots, die vom ehemaligen primären Knoten bereitgestellt wurden, vom Replikat übernommen werden, oder beim Resharding, wenn Slots vom primären Quellknoten zum primären Zielknoten verschoben werden.

• Wenn vom Server ein CLUSTERDOWN-Fehler empfangen wird oder bei Verbindungen zu einem bestimmten Server immer wieder Time-outs auftreten.

• Wenn vom Server ein READONLY-Fehler empfangen wird. Dies kann passieren, wenn eine primäre Instanz zu einem Replikat herabgestuft wird.

• Außerdem sollten Clients die Topologie regelmäßig aktualisieren, damit sie auf Änderungen vorbereitet sind und Änderungen erfahren, die nicht zu Umleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikatknoten hinzugefügt werden. Beachten Sie, dass alle veralteten Verbindungen im Rahmen der Topologieaktualisierung geschlossen werden sollten, um die Notwendigkeit zu verringern, fehlgeschlagene Verbindungen während der Befehlsausführung zu verarbeiten.

Clienterkennung

Die Clienterkennung erfolgt in der Regel durch Ausführen eines CLUSTER SLOT--, CLUSTER NODE- oder CLUSTER SHARDS-Befehls auf dem Redis-Server. Wir empfehlen die Verwendung des Befehls CLUSTER SHARDS. CLUSTER SHARDS ersetzt den Befehl CLUSTER SLOTS (veraltet) und bietet eine effizientere und erweiterbare Darstellung des Clusters.

Die Größe der Antwort für die Befehle zur Cluster-Clienterkennung kann je nach Clustergröße und -topologie variieren. Größere Cluster mit mehr Knoten erzeugen eine größere Antwort. Daher ist es wichtig, dass die Anzahl der Clients, die die Cluster-Topologieerkennung durchführen, nicht unbegrenzt wächst.

Diese Topologieaktualisierungen sind auf dem Redis-Server ressourcenintensiv, aber auch wichtig für die Verfügbarkeit der Anwendung. Daher ist es wichtig, dass jeder Client jeweils nur eine Erkennungsanfrage stellt (und das Ergebnis im Arbeitsspeicher speichert) und die Anzahl der Clients, die die Anfragen stellen, begrenzt wird, um eine Überlastung des Servers zu vermeiden.

Wenn die Clientanwendung beispielsweise gestartet wird oder die Verbindung zum Server verliert und eine Clustererkennung durchführen muss, wird häufig der Fehler gemacht, dass die Client anwendung mehrere Anfragen zur Wiederherstellung der Verbindung und zur Erkennung stellt, ohne beim Wiederholungsversuch einen exponentiellen Backoff hinzuzufügen. Dadurch kann der Redis-Server für längere Zeit nicht reagieren und die CPU-Auslastung sehr hoch sein.

Überlastung bei der Erkennung auf Redis vermeiden

Um die Auswirkungen eines plötzlichen Anstiegs von Verbindungs- und Erkennungsanfragen zu minimieren, empfehlen wir Folgendes:

• Implementieren Sie einen Clientverbindungspool mit einer begrenzten und kleinen Größe, um die Anzahl der gleichzeitigen eingehenden Verbindungen von der Clientanwendung zu begrenzen.

• Wenn die Verbindung des Clients zum Server aufgrund eines Time-outs getrennt wird, versuchen Sie es mit einem exponentiellen Backoff mit Jitter noch einmal. So wird verhindert, dass mehrere Clients den Server gleichzeitig überlasten.

• Verwenden Sie den Erkennungsendpunkt von Memorystore for Redis Cluster, um die Clustererkennung durchzuführen. Der Erkennungsendpunkt ist hochverfügbar und wird auf alle Knoten im Cluster verteilt. Außerdem versucht der Erkennungsendpunkt, die Clustererkennungsanfragen an Knoten mit der aktuellsten Topologieansicht weiterzuleiten.

Nicht reagierende Verbindungen erkennen und verarbeiten

Wir empfehlen dringend, Ihre Clientanwendung so zu konfigurieren, dass nicht reagierende Verbindungen zu Memorystore for Redis Cluster erkannt werden. Wenn eine nicht reagierende Verbindung erkannt wird, muss der Client sie zurücksetzen. Um eine robuste Anwendung zu erstellen, empfehlen wir die folgenden Clientkonfigurationen:

• TCP-Keep-Alive-Parameter konfigurieren: Legen Sie die Parameter TCP keepalive time, TCP keepalive interval und TCP keepalive probes so fest, dass Clients nicht reagierende Verbindungen proaktiv erkennen und trennen, auch wenn die Verbindungen im Leerlauf sind. Wenn Sie beispielsweise den Parameter TCP keepalive time auf 30 Sekunden, TCP keepalive interval auf 10 Sekunden und TCP keepalive probes auf 3 festlegen, setzen Clients nicht reagierende inaktive Verbindungen innerhalb einer Minute zurück.
• TCP-Time-outs für Nutzer konfigurieren: Legen Sie dieses Time-out in Ihren Clients fest, um Verbindungen zurückzusetzen, bei denen noch Anfragen ausstehen und die nicht mehr reagieren. Wenn Sie das Time-out beispielsweise auf 15 Sekunden festlegen, setzen Clients nicht reagierende Verbindungen mit ausstehenden Anfragen nach 15 Sekunden zurück.

Best Practices für die Persistenz

In diesem Abschnitt werden Best Practices für die Persistenz erläutert.

RDB-Persistenz und Hinzufügen von Replikaten

Um Ihren Cluster optimal mit RDB-Snapshots zu sichern oder Replikate zu Ihrem Cluster hinzuzufügen, verwenden Sie die folgenden Best Practices:

Speicherverwaltung

RDB-Snapshots verwenden eine Prozessverzweigung und einen „Copy-on-Write“-Mechanismus, um einen Snapshot der Knotendaten zu erstellen. Je nach Muster der Schreibvorgänge in Knoten wächst der verwendete Arbeitsspeicher der Knoten, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Der Speicherbedarf kann bis zu doppelt so groß wie die Datenmenge im Knoten sein.

Damit Knoten genügend Arbeitsspeicher haben, um den Snapshot zu erstellen, behalten Sie maxmemory bei 80% der Knotenskapazität oder legen Sie diesen Wert fest, sodass 20% für den Overhead reserviert sind. Dieser Speicher-Overhead hilft Ihnen zusätzlich zur Beobachtung von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Reduzieren Sie außerdem den Schreibtraffic so weit wie möglich, wenn Sie Replikate hinzufügen. Weitere Informationen finden Sie unter Cluster mit hoher Schreiblast beobachten.

Hinweis: Wenn Sie einem Cluster, der mehr als 80% des maximalen Arbeitsspeichers des Clusters verwendet, ein Replikat hinzufügen, schlägt der Vorgang fehl und Sie erhalten eine Fehlermeldung.

Um dieses Problem zu beheben, reduzieren Sie die Arbeitsspeichernutzung Ihres Clusters auf eine der folgenden Arten:

• Reduzieren Sie den Speicherbedarf Ihres Clusters auf weniger als 80% des maximal zulässigen Arbeitsspeichers des Knotens.
• Skalieren Sie den Knotentyp für Ihren Cluster so, dass er mehr Arbeitsspeicher hat.

Nachdem die Arbeitsspeichernutzung Ihres Clusters unter dem Grenzwert von 80% liegt, fügen Sie das Replikat noch einmal hinzu.

Veraltete Snapshots

Wenn Sie Knoten aus einem veralteten Snapshot wiederherstellen, kann dies zu Leistungsproblemen für Ihre Anwendung führen, da sie eine erhebliche Anzahl veralteter Schlüssel oder andere Änderungen an Ihrer Datenbank, z. B. eine Schemaänderung, abgleichen muss. Wenn Sie Bedenken haben, dass die Wiederherstellung aus einem veralteten Snapshot nicht funktioniert, können Sie die RDB-Persistenz deaktivieren. Sobald Sie die Persistenz wieder aktivieren, wird im nächsten geplanten Snapshot-Intervall ein Snapshot erstellt.

Auswirkungen von RDB-Snapshots auf die Leistung

Je nach Arbeitslastmuster können RDB-Snapshots die Leistung des Clusters beeinträchtigen und die Latenz für Ihre Anwendungen erhöhen. Sie können die Auswirkungen von RDB-Snapshots auf die Leistung minimieren, indem Sie sie in Zeiten mit geringem Cluster-Traffic ausführen lassen, wenn Sie mit weniger häufigen Snapshots zufrieden sind.

Wenn Ihr Cluster beispielsweise von 1:00 Uhr bis 4:00 Uhr wenig Traffic hat, können Sie die Startzeit auf 3:00 Uhr und das Intervall auf 24 Stunden festlegen.

Wenn Ihr System eine konstante Last hat und häufige Snapshots erforderlich sind, sollten Sie die Auswirkungen auf die Leistung sorgfältig prüfen und die Vorteile der Verwendung von RDB-Snapshots für die Arbeitslast abwägen.

Replikat hinzufügen

Zum Hinzufügen eines Replikats ist ein RDB-Snapshot erforderlich. Weitere Informationen zu RDB Snapshots finden Sie unter Speicherverwaltung.

Wann sollte ein Cluster mit einer einzelnen Zone verwendet werden?

Wenn Sie einen Cluster so konfigurieren, dass er keine Replikate verwendet, empfehlen wir die Verwendung eines Clusters mit einer einzelnen Zone. Das kann folgende Gründe haben:

Kosten und Leistung

Wenn es Ihnen in erster Linie darum geht, die Kosten zu minimieren und eine maximale Leistung für Ihre Clients in derselben Region zu erzielen, empfehlen wir Ihnen, einen Cluster mit einer einzelnen Zone zu verwenden.

Auswirkungen von Ausfällen minimieren

Wenn Sie einen Cluster mit einer einzelnen Zone auswählen, ist es weniger wahrscheinlich, dass zonale Ausfälle Ihren Cluster beeinträchtigen. Wenn Sie alle Knoten in einer einzelnen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein zonaler Ausfall Ihren Server beeinträchtigt, von 100% auf 33%. Es besteht eine Wahrscheinlichkeit von 33 %, dass die Zone, in der sich Ihr Cluster befindet, ausfällt, im Gegensatz zu einer Wahrscheinlichkeit von 100 %, dass Knoten, die sich in der nicht verfügbaren Zone befinden, betroffen sind.

Schnelle Erholung

Wenn bei einem Cluster mit einer einzelnen Zone ein zonaler Ausfall auftritt, optimiert Memorystore for Redis Cluster die Wiederherstellung Ihrer Daten. Sie können schnell einen neuen Cluster in einer funktionierenden Zone bereitstellen und Ihre Anwendung umleiten, um Unterbrechungen zu minimieren.

Best Practices für Lettuce

In diesem Abschnitt werden Best Practices für die Verwendung von Lettuce zum Herstellen einer Verbindung zu einem Cluster beschrieben.

Parameterwerte aktualisieren

Wenn Sie Lettuce verwenden, ändern Sie den Parameter validateClusterNodeMembership in false. Andernfalls können bei Änderungen an der Topologie unknownPartition-Fehler auftreten.

Transport Layer Security (TLS) aktivieren

In diesem Abschnitt werden die Sicherheitsvorteile und Auswirkungen auf die Leistung der Verwendung von Transport Layer Security (TLS) sowie Empfehlungen für die Aktivierung erläutert.

Sicherheitsvorteile

Die Verwendung von TLS bietet folgende Sicherheitsvorteile:

• Authentifizierung über Identity and Access Management (IAM): TLS verwendet diese Art der Authentifizierung, um vor Server-Spoofing-Angriffen wie Man-in-the-Middle-Angriffen zu schützen.
• Verschlüsselung während der Übertragung: Google CloudDie integrierte Verschlüsselung von schützt den Traffic im Google-Netzwerk auf Infrastrukturebene. Dazu müssen Sie jedoch sowohl den Host- als auch den Netzwerkstack von Google vertrauen. Diese Verschlüsselung ist zwar transparent und standardmäßig aktiviert, aber keine Ende-zu-Ende-Verschlüsselung. TLS verwendet hingegen die Verschlüsselung während der Übertragung auf der Anwendungsebene. Diese Ende-zu-Ende-Verschlüsselung bietet Ihnen mehr Kontrolle über Ihre Verschlüsselungsschlüssel und -prozesse.
• Schutz von Authentifizierungstokens: Wenn Sie die IAM Authentifizierung verwenden, minimiert die Aktivierung von TLS das Risiko, dass Ihre Authentifizierungstokens offengelegt und missbraucht werden.

Auswirkungen auf die Leistung

TLS wirkt sich folgendermaßen auf die Leistung aus:

• Verbindungen herstellen: Ein Client und ein Server, die eine TLS-Sitzung eingerichtet haben, können die Sitzung fortsetzen, ohne den ressourcenintensiven Prozess der Verbindungsherstellung zwischen Client und Server zu wiederholen. Wenn Sie die TLS-Wiederaufnahme aktivieren, reduzieren Sie den Aufwand für die Verbindungsherstellung zwischen Client und Server.

  Wenn Sie die TLS-Wiederaufnahme nicht einrichten, ist die Verbindungsherstellung ressourcenintensiv. Sowohl bei neuen als auch bei bestehenden Verbindungen können viele Verbindungen zwischen Client und Server zu Time-outs bei der Verbindung führen. Dies kann einen Schneeballeffekt verursachen, da Memorystore for Redis Cluster versucht, Time-out-Verbindungen wiederherzustellen, wodurch die Ressourcen erhöht werden, die für die Verbindungsherstellung verwendet werden.

• Daten verschlüsseln und entschlüsseln: Die Datenverschlüsselung und ‑entschlüsselung umfassen CPU-intensive Vorgänge, die sich sowohl auf den Client als auch auf den Server auswirken. Dies kann die Kapazität Ihres Clusters verringern und die Latenz des Clusters erhöhen.

Empfehlungen

Wenn Sie überlegen, ob Sie TLS aktivieren möchten, empfehlen wir Ihnen, Ihre Sicherheitsrichtlinien zu prüfen und dabei die Vor- und Nachteile von TLS zu berücksichtigen. Wenn Sie TLS aktivieren, beachten Sie Folgendes:

• Die Aktivierung der TLS-Wiederaufnahme reduziert den Aufwand für die Verbindungsherstellung. Eine Verbindung zwischen Client und Server ist nur für die erste Verbindung erforderlich. Eine plötzliche Erweiterung der Clustergröße des Clients kann jedoch zu einer kurzen Unterbrechung führen, die durch den anfänglichen vollständigen Handshake jedes neuen Clienthosts verursacht wird.
• Obwohl einige Clientbibliotheken möglicherweise keine integrierten Steuerelemente zum Aktivieren von TLS bieten, können Sie benutzerdefinierten Code verwenden, um diese Funktion in Ihre Cluster zu integrieren.