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 Arbeitsspeicherverwaltung

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

Konzepte zur Arbeitsspeicherverwaltung

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

  • Entfernungsrichtlinie: Memorystore for Valkey verwendet die volatile-lru Entfernungs richtlinie. Mit Valkey-Befehlen wie dem Befehl EXPIRE können Sie Entfernungen für Schlüssel festlegen.

Arbeitsspeichernutzung für eine Instanz überwachen

Wenn Sie die Arbeitsspeichernutzung für eine Memorystore for Valkey-Instanz überwachen möchten, empfehlen wir Ihnen, den Messwert /instance/memory/maximum_utilization aufzurufen. Wenn die Arbeitsspeichernutzung der Instanz 80% erreicht und Sie mit einer Zunahme der Datennutzung rechnen, sollten Sie die Größe der Instanz erhöhen, 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 aktiviert“ skalieren

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 Entfernung von Schlüsseln 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 Zielanzahl der Shards 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 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-Nutzung

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-Nutzung 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-Nutzung 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-Nutzung /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 zwei oder mehr 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 Ihre Instanz weniger als fünf Replikate hat, können Sie auch die Anzahl der Replikate auf maximal fünf erhöhen.

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 finden Sie Beispiele für ressourcenintensive Valkey-Befehle und ressourceneffiziente Alternativen.

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

Überlastung von Verbindungen 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 Time-out hat, versuchen Sie es mit exponentiellem Backoff und Jitter noch einmal. So wird verhindert, dass mehrere Clients den Server gleichzeitig überlasten.

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 durch Weiterleitungen verursachte Leistungsaufwand vermieden.

Clientzuordnung

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

  • Beim Initialisieren des Clients muss die anfängliche Zuordnung von Slots zu Knoten erstellt werden.

  • 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 Time-outs verursachen.

  • 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 gerüstet zu sein und sich über Änderungen zu informieren, die nicht zu Weiterleitungen 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 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 führen zu einer größeren 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, wird häufig der Fehler gemacht, dass die Client anwendung mehrere Anfragen zur Wiederherstellung der Verbindung und zur Erkennung stellt, ohne exponentielles Backoff bei Wiederholungen zu verwenden. Dadurch kann der Valkey-Server für längere Zeit nicht reagieren und eine sehr hohe CPU-Auslastung verursachen.

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 Anfragen zur Knotenerkennung 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 neuesten 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 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 die besten Ergebnisse beim Sichern Ihrer Instanz mit RDB-Snapshots oder beim Hinzufügen von Replikaten zu Ihrer Instanz zu erzielen, verwenden Sie die folgenden Best Practices:

Arbeitsspeicherverwaltung

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 Knotenkapazität fest, sodass 20% für den Overhead reserviert sind. Dieser Arbeitsspeicher-Overhead hilft Ihnen zusätzlich zur Überwachung von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden können. Wenn Sie Replikate hinzufügen, sollten Sie außerdem den Schreibtraffic so weit wie möglich reduzieren. 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 hinsichtlich der Wiederherstellung aus einem veralteten Snapshot haben, 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 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 Arbeitsspeicherverwaltung.

Wann sollte eine Instanz mit einer einzelnen Zone verwendet werden?

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

Kosten und Leistung

Wenn die Minimierung der Kosten und die maximale Leistung für Ihre Kunden in derselben Region Ihre Hauptziele sind, empfehlen wir Ihnen, eine Instanz mit einer einzelnen Zone auszuwählen.

Auswirkungen von Ausfällen minimieren

Wenn Sie eine Instanz mit einer einzelnen Zone auswählen, sind zonale Ausfälle weniger wahrscheinlich. 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 bei einer Instanz mit einer einzelnen Zone ein zonaler Ausfall auftritt, 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 so gering wie möglich zu halten.

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 Netzwerk-Stack von Google vertrauen. Diese Verschlüsselung ist zwar transparent und standardmäßig aktiviert, aber nicht Ende-zu-Ende. TLS hingegen verwendet 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 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 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 umfassen CPU-intensive Vorgänge, die sich sowohl auf den Client als auch auf den Server auswirken. Dadurch kann die Kapazität Ihrer Instanz reduziert und die Latenz der Instanz erhöht werden.

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 möchten, 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 Erhöhung der Instanzgröße des Clients kann jedoch zu einer kurzen Unterbrechung führen, die durch den anfänglichen 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.