Best Practices für Memorystore for Valkey

Auf dieser Seite finden Sie eine Anleitung zur optimalen Verwendung von Memorystore for Valkey. Auf dieser Seite werden auch potenzielle Probleme aufgezeigt, die vermieden werden sollten.

Best Practices für die Speicherverwaltung

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

Konzepte zur Speicherverwaltung

  • Arbeitsspeichernutzung: Die Menge an Arbeitsspeicher, die Ihre Instanz verwendet. Sie haben eine feste Speicherkapazität. Sie können Messwerte verwenden, um zu überwachen, wie viel Speicher Sie verwenden.

  • Entfernungsrichtlinie: Memorystore for Valkey verwendet die Entfernungsrichtlinie volatile-lru. Sie können Valkey-Befehle wie EXPIRE verwenden, um die Verdrängung von Schlüsseln festzulegen.

Arbeitsspeichernutzung für eine Instanz überwachen

Wenn Sie die Arbeitsspeichernutzung einer Memorystore for Valkey-Instanz überwachen möchten, empfehlen wir, den Messwert /instance/memory/maximum_utilization aufzurufen. Wenn die Arbeitsspeichernutzung der Instanz sich 80% nähert und Sie erwarten, dass die Datennutzung zunimmt, sollten Sie die Größe der Instanz erhöhen, um Platz für neue Daten zu schaffen.

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

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

Shards im aktivierten Clustermodus skalieren

Wenn Sie die Anzahl der Shards in einer Instanz skalieren, empfehlen wir, die Skalierung in Zeiten mit geringer Schreibaktivität durchzuführen. Die Skalierung in Zeiten hoher Nutzung kann aufgrund des Speicher-Overheads, der durch Replikation oder Slot-Migration verursacht wird, zu einer hohen Arbeitsspeicherauslastung Ihrer Instanz führen.

Wenn Ihr Valkey-Anwendungsfall Schlüsselentfernungen verwendet, 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 Zielanzahl von Shards sollte mindestens das 1,5-Fache des von Daten verwendeten Arbeitsspeichers zulassen. Mit anderen Worten: Sie sollten genügend Shards für das 1, 5-Fache der Datenmenge in Ihrer Instanz bereitstellen. Mit dem Messwert /instance/memory/total_used_memory können Sie sehen, wie viele Daten in Ihrer Instanz gespeichert sind.

Best Practices für die CPU-Nutzung

Wenn ein unerwarteter Zonenausfall auftritt, führt dies zu reduzierten CPU-Ressourcen für Ihre Instanz, da die Kapazität von Knoten in der nicht verfügbaren Zone verloren geht. Wir empfehlen die Verwendung von hochverfügbaren Instanzen. Wenn Sie mehrere Replikate pro Shard (im Gegensatz zu einem Replikat pro Shard) verwenden, stehen Ihnen 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 von verlorener Kapazität zu verarbeiten, wenn ein unerwarteter zonaler Ausfall auftritt. Sie sollten die CPU-Auslastung für Primärinstanzen 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 /instance/cpu/maximum_utilization-CPU-Nutzungsziele:

  • Bei Instanzen mit einem Replikat pro Knoten sollten Sie einen /instance/cpu/maximum_utilization-Wert von 0,5 Sekunden für die primäre Instanz und 0,5 Sekunden für das Replikat anstreben.
  • Bei Instanzen mit zwei oder mehr Replikaten pro Knoten sollten Sie einen /instance/cpu/maximum_utilization-Wert von 0,9 Sekunden für die primäre Instanz und 0,5 Sekunden für jedes Replikat anstreben.

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

Wenn Ihre Instanz eine hohe CPU-Auslastung aufweist oder die Ressourcen der Instanz erschöpft sind (z. B. durch zu viele Verbindungen), kann es zu Fehlern bei 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 folgenden Leistungsproblemen führen:

  • Hohe Latenz und Client-Zeitüberschreitungen
  • Arbeitsspeichermangel, der durch Befehle verursacht wird, die die Arbeitsspeichernutzung erhöhen
  • Datenverlust während der Knotenreplikation und -synchronisierung, weil der Valkey-Hauptthread blockiert ist
  • Nicht ausgeführte Systemdiagnosen, Beobachtbarkeit und Replikation

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

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

Best Practices für Skalierungsschwellenwerte

Szenarien für Skalierungsschwellenwerte fallen in die folgenden Kategorien:

  • Skalierung für die Arbeitsspeicherauslastung
  • Skalierung für CPU-Auslastung
  • Skalierung zur Vermeidung von Hotspots

Wenn Ihre Arbeitslast auf dem Entfernen von Schlüsseln basiert, empfiehlt Google, die CPU- oder Arbeitsspeicherauslastung nicht zu verringern. Bei diesen Arbeitslasten erreicht die Arbeitsspeicherauslastung häufig ihre maximale Kapazität, bevor automatisch Entfernungen erfolgen. Die resultierenden Speicherspitzen blockieren Vorgänge zur Verkleinerung.

In den folgenden Abschnitten werden gängige Szenarien und Messwertschwellenwerte beschrieben, die eine Skalierung rechtfertigen könnten.

Skalierung der Arbeitsspeicherauslastung

Wenn Sie feststellen möchten, wann Sie basierend auf der Arbeitsspeichernutzung skalieren müssen, beobachten Sie die Messwerte /instance/memory/average_utilization und /instance/memory/maximum_utilization. Weitere Informationen zu diesen Messwerten finden Sie unter Unterstützte Monitoring-Messwerte.

Wenn Ihre Instanz eine der folgenden Bedingungen erfüllt, sollten Sie einen horizontalen Skalierungsvorgang auslösen:

  • Die durchschnittliche Arbeitsspeicherauslastung Ihrer Instanz überschreitet den empfohlenen Grenzwert von 70%.
  • Die maximale Arbeitsspeicherauslastung überschreitet 80% und die durchschnittliche Arbeitsspeicherauslastung überschreitet 50%.

Wenn Ihre Instanz eine der folgenden Bedingungen erfüllt, sollten Sie einen Vorgang zum Herunterskalieren auslösen:

  • Die durchschnittliche Arbeitsspeicherauslastung Ihrer Instanz fällt unter den empfohlenen Schwellenwert von 50%.
  • Die maximale Arbeitsspeicherauslastung sinkt unter 60% und die durchschnittliche Arbeitsspeicherauslastung sinkt unter 40%.

Skalierung der CPU-Auslastung

Wenn Sie die Messwerte /instance/cpu/average_utilization und /instance/cpu/maximum_utilization im Blick behalten, können Sie feststellen, wann eine Skalierung anhand der CPU-Auslastung erforderlich ist.

Wenn Ihre Instanz eine der folgenden Bedingungen erfüllt, sollten Sie einen horizontalen Skalierungsvorgang auslösen:

  • Die durchschnittliche CPU-Auslastung Ihrer Instanz überschreitet den empfohlenen Schwellenwert von 70%.
  • Die maximale CPU-Auslastung überschreitet 80% und die durchschnittliche CPU-Auslastung überschreitet 50%.

Wenn Ihre Instanz eine der folgenden Bedingungen erfüllt, sollten Sie einen Vorgang zum Herunterskalieren auslösen:

  • Die durchschnittliche CPU-Auslastung Ihrer Instanz fällt unter den empfohlenen Schwellenwert von 50%.
  • Die maximale CPU-Auslastung sinkt unter 60% und die durchschnittliche CPU-Auslastung unter 40%.

Skalierung zur Vermeidung von Hotspots

Memorystore for Valkey bietet durchschnittliche und maximale Varianten desselben Messwerts, mit denen Sie Hotspots für diese Messwertfamilie identifizieren können. Der Höchstwert steht für den Instanzknoten mit der höchsten Last, während der Durchschnittswert die Last für die gesamte Instanz darstellt. Wenn der Höchstwert deutlich über dem Durchschnittswert liegt, deutet dies darauf hin, dass ein bestimmter Knoten unverhältnismäßig stark ausgelastet ist (ein Hotspot). Zur Behebung dieses Problems empfehlen wir, die Instanz horizontal zu skalieren. Weitere Informationen finden Sie unter Instanzkapazität skalieren.

Wenn Sie eine erhebliche Abweichung zwischen den durchschnittlichen und maximalen Abweichungen feststellen, können Sie die Befehle INFO memory und INFO cpu für die Instanzknoten ausführen, um Echtzeitdaten direkt von der Instanz zu erfassen. Weitere Informationen zur Verwendung dieser Befehle finden Sie in der Valkey-Dokumentation unter INFO.

Best Practices für Valkey-Clients

Verbindungsüberlastung in Valkey vermeiden

Wir empfehlen Folgendes, um die Auswirkungen eines plötzlichen Anstiegs von Verbindungen zu minimieren:

  • Bestimmen Sie die für Sie am besten geeignete Größe des Clientverbindungspools. Eine gute Startgröße für jeden Client ist eine Verbindung pro Valkey-Knoten. Anschließend können Sie einen Benchmark-Test durchführen, um zu sehen, ob mehr Verbindungen hilfreich sind, ohne die maximal zulässige Anzahl von Verbindungen zu überschreiten.

  • Wenn die Verbindung des Clients zum Server aufgrund einer Zeitüberschreitung des Servers getrennt wird, versuchen Sie es mit exponentiellem Backoff mit 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. Zum Erstellen einer ausfallsicheren Anwendung 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-Nutzerzeitlimits konfigurieren: Legen Sie dieses Zeitlimit in Ihren Clients fest, um Verbindungen mit ausstehenden Anfragen zurückzusetzen, die 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 ein Leistungs-Overhead durch Weiterleitungen vermieden.

Clientzuordnung

In den folgenden Situationen müssen Clients 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 füllen.

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

  • Wenn ein CLUSTERDOWN-Fehler vom Server empfangen wird oder Verbindungen zu einem bestimmten Server dauerhaft Zeitüberschreitungen verursachen.

  • Wenn der Server einen READONLY-Fehler zurückgibt. Dies kann passieren, wenn eine primäre Instanz zu einem Replikat herabgestuft wird.

  • Außerdem sollten Clients die Topologie regelmäßig aktualisieren, um die Clients auf Änderungen vorzubereiten und über Änderungen informiert zu werden, die möglicherweise nicht zu Weiterleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikatknoten hinzugefügt werden. Beachten Sie, dass veraltete Verbindungen im Rahmen der Topologieaktualisierung ebenfalls geschlossen werden sollten, um die Notwendigkeit der Verarbeitung fehlgeschlagener Verbindungen während der Befehlsausführung zu reduzieren.

Client-Erkennung

Die Client-Erkennung erfolgt in der Regel durch Senden eines SLOTS-, NODES- oder CLUSTER SHARDS-Befehls an den Valkey-Server. Wir empfehlen die Verwendung des Befehls CLUSTER SHARDS. CLUSTER SHARDS ersetzt den Befehl SLOTS (verworfen) und bietet eine effizientere und erweiterbare Darstellung der Instanz.

Die Größe der Antwort für die Client-Erkennungsbefehle 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 Knotentopologie ermitteln, nicht unbegrenzt wächst.

Diese Aktualisierungen der Knotentopologie sind auf dem Valkey-Server ressourcenintensiv, aber auch wichtig für die Anwendungsverfügbarkeit. Daher ist es wichtig, dass jeder Client zu einem bestimmten Zeitpunkt nur eine einzige Discovery-Anfrage stellt (und das Ergebnis im Arbeitsspeicher zwischenspeichert) 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 Clientanwendung mehrere Wiederverbindungs- und Erkennungsanfragen stellt, ohne beim Wiederholungsversuch einen exponentiellen Backoff hinzuzufügen. Dies kann dazu führen, dass der Valkey-Server über einen längeren Zeitraum nicht mehr reagiert, was zu einer sehr hohen CPU-Auslastung führt.

Erkennungsendpunkt für die Knotenerkennung verwenden

Verwenden Sie den Memorystore for Valkey-Erkennungsendpunkt, um eine Knotenerkennung durchzuführen. Der Endpunkt der Erkennung ist hochverfügbar und wird über alle Knoten in der Instanz hinweg per Load Balancing verteilt. Außerdem versucht der Discovery-Endpunkt, die Anfragen zur Knotenerkennung an Knoten mit der aktuellsten Topologieansicht weiterzuleiten.

Für Instanzen mit deaktiviertem Clustermodus

Wenn Ihre Anwendung eine Verbindung zu einer Instanz mit deaktiviertem Clustermodus herstellt, muss sie 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 aus Replikaten zu lesen und den Traffic vom primären Knoten zu isolieren.

Da Instanzen mit deaktiviertem Clustermodus nur einen Shard haben, verwenden sie keine In-Memory-Topologie. Daher ist eine Topologieaktualisierung nicht möglich.

Während Failover- und Wartungsereignissen werden Verbindungen zur Instanz getrennt. Damit Ihre Anwendung nach diesen Ereignissen wieder erfolgreich eine Verbindung herstellt, implementieren Sie einen Wiederholungsmechanismus mit exponentiellem Backoff.

Sie können die Strategie „Vor dem Löschen erstellen“ verwenden, wenn Sie Wartungsarbeiten an Ihrer Instanz durchführen. Weitere Informationen zu dieser Strategie finden Sie unter Lebenszyklusstrategie „Create-before-destroy“.

Wenn Sie diese Strategie verwenden, erhalten Sie möglicherweise die folgende Fehlermeldung:

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

Beenden Sie die Verbindung zu Ihrer Instanz, um dieses Problem zu beheben. Erstellen Sie dann die Verbindung neu.

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

Damit Sie die besten Ergebnisse beim Sichern Ihrer Instanz mit RDB-Snapshots oder beim Hinzufügen von Replikaten zu Ihrer Instanz erzielen, sollten Sie die folgenden Best Practices beachten:

Speicherverwaltung

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

Damit die Knoten genügend Arbeitsspeicher haben, um den Snapshot abzuschließen, behalten Sie maxmemory bei 80 % der Knotenkapazität bei oder legen Sie diesen Wert fest, sodass 20% für den Overhead reserviert sind. Dieser Arbeitsspeicher-Overhead hilft Ihnen zusätzlich zum Monitoring von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Außerdem sollten Sie beim Hinzufügen von Replikaten den Schreibtraffic so weit wie möglich reduzieren. Weitere Informationen finden Sie unter Arbeitsspeichernutzung für eine Instanz überwachen.

Veraltete Snapshots

Das Wiederherstellen von Knoten aus einem veralteten Snapshot kann zu Leistungsproblemen für Ihre Anwendung führen, da sie versucht, eine erhebliche Menge veralteter Schlüssel oder andere Änderungen an Ihrer Datenbank, z. B. eine Schemaänderung, abzugleichen. Wenn Sie Bedenken hinsichtlich der Wiederherstellung aus einem veralteten Snapshot haben, 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 RDB-Snapshots die Leistung der Instanz 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 für Zeiten mit geringem Instanz-Traffic planen, wenn Sie mit weniger häufigen Snapshots einverstanden 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 erfordert, empfehlen wir, die Auswirkungen auf die Leistung sorgfältig zu bewerten 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 sollte eine Einzelzoneninstanz 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 Sie die Kosten minimieren und die Leistung für Ihre Clients in derselben Region maximieren möchten, 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, ist es weniger wahrscheinlich, dass sich zonale Ausfälle auf Ihre Instanz auswirken. Wenn Sie alle Knoten in einer einzelnen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein zonaler Ausfall Ihren Server betrifft, von 100% auf 33%. Die Wahrscheinlichkeit, dass die Zone, in der sich Ihre Instanz befindet, ausfällt, beträgt 33 %. Die Wahrscheinlichkeit, dass Knoten, die sich in der nicht verfügbaren Zone befinden, betroffen sind, beträgt dagegen 100 %.

Schnelle Erholung

Wenn ein zonaler Ausfall für eine Instanz mit einer einzelnen Zone 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 den Betrieb mit minimalen Unterbrechungen fortzusetzen.

Best Practices für die Kapazitätsplanung

Damit Sie Ressourcen erfolgreich bereitstellen und robuste Architekturen erstellen können, empfehlen wir die folgenden Best Practices für die Kapazitätsplanung:

  • An mehreren Standorten bereitstellen: Wenn Sie aufgrund vorübergehender Ressourceneinschränkungen keine Instanz in Ihrer bevorzugten Zone erstellen können, versuchen Sie, die Instanz entweder in einer anderen Zone innerhalb derselben Region oder in einer anderen Region zu erstellen.
  • Regionsübergreifenden Zugriff verwenden: Konfigurieren Sie Ihre Clients so, dass sie auf Ihre Instanzen in verschiedenen Regionen zugreifen können. Wenn Sie aufgrund lokaler Ressourcenbeschränkungen eine Instanz in einer anderen Region bereitstellen müssen, können Ihre Clients eine Verbindung zur Instanz herstellen.
  • Regionenübergreifende Replikation verwenden: Wenn Sie eine sekundäre Instanz in einer alternativen Region zu einer primären Lese- oder Schreibinstanz für die Notfallwiederherstellung hochstufen möchten, führen Sie einen Switchover durch.

Transport Layer Security (TLS) aktivieren

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

Sicherheitsvorteile

Die Verwendung von TLS bietet die folgenden Sicherheitsvorteile:

  • IAM-Authentifizierung (Identity and Access Management): TLS verwendet diese Art der Authentifizierung, um vor Server-Spoofing-Angriffen wie Person-in-the-Middle-Angriffen zu schützen.
  • Verschlüsselung während der Übertragung: Die integrierte Verschlüsselung vonGoogle Cloudschützt den Traffic im Google-Netzwerk auf Infrastrukturebene. Dazu müssen Sie jedoch sowohl dem Host- als auch dem Netzwerkstack 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, wird durch die Aktivierung von TLS das Risiko minimiert, dass Ihre Authentifizierungstokens offengelegt werden und verloren gehen.

Auswirkungen auf die Leistung

TLS wirkt sich folgendermaßen auf die Leistung aus:

  • Verbindungen herstellen: Ein Client und ein Server, die eine TLS-Sitzung hergestellt haben, können die Sitzung fortsetzen, ohne den ressourcenintensiven Prozess des Verbindungsaufbaus zwischen Client und Server zu wiederholen. Durch die Aktivierung der TLS-Wiederaufnahme reduzieren Sie den Aufwand für den Aufbau einer Verbindung zwischen dem Client und dem Server.

    Wenn Sie die TLS-Wiederaufnahme nicht einrichten, ist das Herstellen von Verbindungen ressourcenintensiv. Sowohl bei neuen als auch bei bestehenden Verbindungen können viele Verbindungen zwischen dem Client und dem Server zu Zeitüberschreitungen führen. Dies kann einen Schneeballeffekt verursachen, da Memorystore for Valkey versucht, Verbindungen mit Zeitüberschreitung wiederherzustellen. Dadurch werden mehr Ressourcen für den Verbindungsaufbau benötigt.

  • Daten verschlüsseln und entschlüsseln: Die Verschlüsselung und Entschlüsselung von Daten umfasst CPU-intensive Vorgänge, die sich sowohl auf den Client als auch auf den Server auswirken. Dies kann die Kapazität Ihrer Instanz verringern und die Latenz der Instanz erhöhen.

Empfehlungen

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

  • Durch die Aktivierung der TLS-Wiederaufnahme wird der Aufwand für den Verbindungsaufbau verringert. Eine Verbindung zwischen dem Client und dem 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 einzubinden.