Best Practices für Memorystore for Valkey

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

Best Practices für die Speicherverwaltung

In diesem Abschnitt werden Strategien zur Verwaltung des Instanzspeichers beschrieben, damit Memorystore for Valkey effizient für Ihre Anwendung funktioniert.

Konzepte zur Speicherverwaltung

  • Arbeitsspeichernutzung: Die Menge an Arbeitsspeicher, die von Ihrer Instanz verwendet wird. Sie haben eine feste Speicherkapazität. Mit Messwerten können Sie die Speichernutzung überwachen.

  • Entfernungsrichtlinie: Memorystore for Valkey verwendet die volatile-lru Entfernungs richtlinie. Sie können Valkey-Befehle wie den Befehl EXPIRE verwenden, um Entfernungen für Schlüssel festzulegen.

Arbeitsspeichernutzung für eine Instanz überwachen

Wenn Sie die Arbeitsspeichernutzung für eine Memorystore for Valkey-Instanz überwachen möchten, empfehlen wir Ihnen, den /instance/memory/maximum_utilization Messwert anzusehen. Wenn die Speichernutzung der Instanz sich 80% nähert und Sie mit einer Zunahme der Datennutzung rechnen, skalieren Sie die Größe der Instanz nach oben, um Platz für neue Daten zu schaffen.

Wenn die Instanz eine hohe Arbeitsspeichernutzung aufweist, gehen Sie so vor, um die Leistung zu verbessern:

Wenn Probleme auftreten, wenden Sie sich an den Google Cloud Kundensupport.

Shards im Modus „Cluster“ aktivieren

Wenn Sie die Anzahl der Shards in einer Instanz skalieren, empfehlen wir, dies in Zeiträumen mit wenigen Schreibvorgängen zu tun. Die Skalierung in Zeiten hoher Nutzung kann den Arbeitsspeicher Ihrer Instanz aufgrund des durch die Replikation oder die Slotmigration verursachten Speicheraufwands belasten.

Wenn in Ihrem Valkey-Anwendungsfall Schlüsselentfernungen verwendet werden, kann die Skalierung auf eine kleinere Instanzgröße die Cache-Trefferquote verringern. In diesem Fall müssen Sie sich jedoch keine Sorgen um Datenverlust machen, da die Schlüsselentfernung erwartet wird.

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

Best Practices für die CPU-Auslastung

Wenn ein unerwarteter zonaler Ausfall auftritt, führt dies zu weniger CPU-Ressourcen für Ihre Instanz, da die Kapazität von Knoten in der nicht verfügbaren Zone verloren geht. Wir empfehlen die Verwendung hochverfügbarer Instanzen. Die Verwendung mehrerer Replikate pro Shard (im Gegensatz zu einem Replikat pro Shard) bietet zusätzliche CPU-Ressourcen während eines Ausfalls. 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“ /instance/cpu/maximum_utilization überwachen.

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

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

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

Wenn Ihre Instanz entweder eine hohe CPU-Auslastung aufweist oder die Ressourcen der Instanz erschöpft sind (z. B. durch zu viele Verbindungen), kann es zu Fehlverhalten der Instanz kommen und externe Messwerte fehlen.

Ressourcenintensive Valkey-Befehle

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

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

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

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 DELETE UNLINK
Veröffentlichen und abonnieren PUBLISH SPUBLISH
SUBSCRIBE SSUBSCRIBE

Best Practices für Valkey-Clients

Verbindungsüberlastung in Valkey vermeiden

Um die Auswirkungen eines plötzlichen Anstiegs der Verbindungen zu minimieren, empfehlen wir Folgendes:

  • Bestimmen Sie die für Sie optimale Größe des Client-Verbindungspools. Eine gute Startgröße für jeden Client ist eine Verbindung pro Valkey-Knoten. Sie können dann Benchmarks durchführen, um zu sehen, ob mehr Verbindungen helfen, ohne die maximal zulässige Anzahl von Verbindungen zu überschreiten.

  • Wenn die Verbindung zum Server getrennt wird, weil der Server ein Zeitlimit überschreitet, versuchen Sie es mit exponentiellem Backoff und Jitter noch einmal. So wird verhindert, dass mehrere Clients den Server gleichzeitig überlasten.

Nicht reagierende Verbindungen erkennen und verarbeiten

Wir empfehlen dringend, Ihre Clientanwendung so zu konfigurieren, dass nicht reagierende Verbindungen zu Memorystore for Valkey 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 inaktiv 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-Nutzer-Time-outs konfigurieren: Legen Sie dieses Zeitlimit in Ihren Clients fest, um Verbindungen zurückzusetzen, die ausstehende Anfragen haben und nicht mehr reagieren. Wenn Sie das Zeitlimit beispielsweise auf 15 Sekunden festlegen, setzen Clients nicht reagierende Verbindungen mit ausstehenden Anfragen nach 15 Sekunden zurück.

Für Instanzen mit aktiviertem Clustermodus

Ihre Anwendung muss einen clusterfähigen Valkey-Client verwenden, wenn sie eine Verbindung zu einer Memorystore for Valkey-Instanz mit aktiviertem Clustermodus 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 in der Instanz verwalten, um Anfragen an die richtigen Knoten zu senden. So wird der Leistungsaufwand durch Weiterleitungen vermieden.

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-Weiterleitung empfangen wird, z. B. bei einem Failover, wenn alle Slots, die vom ehemaligen primären Knoten bereitgestellt wurden, vom Replikat übernommen werden, oder bei der erneuten Shard-Aufteilung, wenn Slots vom primären Quellknoten zum primären Zielknoten verschoben werden.

  • Wenn vom Server ein CLUSTERDOWN-Fehler empfangen wird oder Verbindungen zu einem bestimmten Server immer wieder Zeitlimits überschreiten.

  • 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, um für alle Änderungen bereit zu sein und Änderungen zu erfahren, die nicht zu Weiterleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikatknoten hinzugefügt werden. Veraltete Verbindungen sollten im Rahmen der Topologieaktualisierung ebenfalls geschlossen werden, 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 SLOTS--, NODES- oder CLUSTER SHARDS-Befehls auf dem Valkey-Server. Wir empfehlen die Verwendung des Befehls CLUSTER SHARDS. CLUSTER SHARDS ersetzt den Befehl SLOTS (veraltet) und bietet eine effizientere und erweiterbare Darstellung der Instanz.

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

Diese Aktualisierungen der Knotentopologie sind auf dem Valkey-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 Knotenerkennung durchführen muss, besteht ein häufiger Fehler darin, dass die Client anwendung mehrere Anfragen zur Wiederherstellung der Verbindung und zur Erkennung stellt, ohne beim Wiederholen exponentielles Backoff zu verwenden. Dies kann dazu führen, dass der Valkey-Server für längere Zeit nicht reagiert und eine sehr hohe CPU-Auslastung verursacht.

Erkennungs-Endpunkt für die Knotenerkennung verwenden

Verwenden Sie den Memorystore for Valkey-Erkennungs-Endpunkt, um die Knotenerkennung durchzuführen. Der Erkennungs-Endpunkt ist hochverfügbar und wird auf alle Knoten in der Instanz verteilt. Außerdem versucht der Erkennungs-Endpunkt, die Knotenerkennungsanfragen an Knoten mit der aktuellsten Topologieansicht weiterzuleiten.

Für Instanzen mit deaktiviertem Clustermodus

Wenn Sie eine Verbindung zu einer Instanz mit deaktiviertem Clustermodus herstellen, muss Ihre Anwendung eine Verbindung zum primären Endpunkt herstellen, um in die Instanz zu schreiben und die letzten Schreibvorgänge abzurufen. Ihre Anwendung kann auch eine Verbindung zum Reader-Endpunkt herstellen, um Daten aus Replikaten zu lesen und den Traffic vom primären Knoten zu isolieren.

Wenn Sie die Strategie „Erstellen vor dem Löschen“ verwenden, wenn Sie Wartungsarbeiten an Ihrer Instanz durchführen, wird möglicherweise die folgende Fehlermeldung angezeigt:

READONLY You can't write against a read only replica.

Um dieses Problem zu beheben, beenden Sie die Verbindung zu Ihrer Instanz. Stellen Sie dann die Verbindung wieder her.

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 Ihre Instanz optimal mit RDB-Snapshots zu sichern oder Replikate zu Ihrer Instanz 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 oder legen Sie maxmemory bei 80% der Knotenauslastung fest, sodass 20% für den Overhead reserviert sind. Dieser Speicher-Overhead hilft Ihnen zusätzlich zur Überwachung von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Verringern Sie außerdem den Schreibtraffic so weit wie möglich, wenn Sie Replikate hinzufügen. Weitere Informationen finden Sie unter Arbeitsspeichernutzung für eine Instanz überwachen.

Veraltete Snapshots

Die Wiederherstellung von Knoten aus einem veralteten Snapshot kann 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, aus einem veralteten Snapshot wiederherzustellen, können Sie die RDB-Persistenzfunktion 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 sich RDB-Snapshots auf die Leistung der Instanz auswirken 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 Zeiträumen mit geringem Instanz-Traffic ausführen lassen, wenn Sie mit weniger häufigen Snapshots zufrieden sind.

Wenn Ihre Instanz 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, empfehlen wir, die Auswirkungen auf die Leistung sorgfältig zu prüfen und die Vorteile der Verwendung von RDB-Snapshots für die Arbeitslast abzuwägen.

Replikat hinzufügen

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

Wann ist eine Instanz mit einer einzelnen Zone sinnvoll?

Wenn Sie eine Instanz so konfigurieren, dass sie keine Replikate verwendet, empfehlen wir , dass Sie eine Instanz mit einer einzelnen Zone verwenden. Das kann folgende Gründe haben:

Kosten und Leistung

Wenn es Ihnen in erster Linie darum geht, Kosten zu minimieren und eine maximale Leistung für Ihre Clients in derselben Region zu erzielen, empfehlen wir, eine Instanz mit einer einzelnen Zone auszuwählen.

Auswirkungen von Ausfällen minimieren

Wenn Sie eine Instanz mit einer einzelnen Zone auswählen, wirken sich zonale Ausfälle weniger wahrscheinlich auf Ihre Instanz aus. Wenn Sie alle Knoten in einer einzelnen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein zonaler Ausfall Ihren Server betrifft, von 100% auf 33%. Es besteht eine Wahrscheinlichkeit von 33 %, dass die Zone, in der sich Ihre Instanz 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 es bei einer Instanz mit einer einzelnen Zone zu einem zonalen Ausfall kommt, optimiert Memorystore for Valkey die Wiederherstellung Ihrer Daten. Sie können schnell eine neue Instanz in einer funktionierenden Zone bereitstellen und Ihre Anwendung umleiten, um Unterbrechungen des Betriebs zu minimieren.

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:

  • IAM-Authentifizierung (Identity and Access Management): 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 weitergegeben werden.

Auswirkungen auf die Leistung

TLS wirkt sich auf folgende Weise auf die Leistung aus:

  • Verbindungen herstellen: Ein Client und 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, verringern Sie den Overhead beim Herstellen einer Verbindung 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 Verbindungs-Time-outs führen. Dies kann einen Schneeballeffekt verursachen, da Memorystore for Valkey 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 umfasst CPU-intensive Vorgänge, die sich sowohl auf den Client als auch auf den Server auswirken. Dadurch kann die Kapazität Ihrer Instanz verringert und die Latenz der Instanz erhöht werden.

Empfehlungen

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

  • Die Aktivierung der TLS-Wiederaufnahme verringert den Overhead beim Herstellen von Verbindungen. Eine Verbindung zwischen Client und Server ist nur für die erste Verbindung erforderlich. Eine plötzliche Erweiterung der Instanzgröße des Clients kann jedoch zu einer kurzen Unterbrechung führen, die durch den ersten vollständigen Handshake jedes neuen Clienthosts verursacht wird.
  • Einige Clientbibliotheken bieten möglicherweise keine integrierten Steuerelemente zum Aktivieren von TLS. Sie können jedoch benutzerdefinierten Code verwenden, um diese Funktion in Ihre Instanzen zu integrieren.