Best Practices für Memorystore for Redis Cluster

Auf dieser Seite finden Sie eine Anleitung zur optimalen Verwendung von Memorystore for Redis Cluster. Auf dieser Seite werden auch mögliche Probleme aufgeführt, die Sie vermeiden sollten.

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

Best Practices für die Speicherverwaltung

In diesem Abschnitt werden Strategien für die Verwaltung des Arbeitsspeichers 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. Die Schreiblast kann je nach Redis-Anwendungsfall und Nutzungsmuster der Anwendung zwischen normal und sehr hoch liegen.

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

Cluster mit normaler Schreiblast überwachen

Sehen Sie sich den Messwert /cluster/memory/maximum_utilization an. Wenn /cluster/memory/maximum_utilization bei 100% oder darunter liegt, ist die Leistung Ihres Redis-Clusters bei normaler Schreiblast gut.

Wenn Ihre Arbeitsspeichernutzung jedoch 100% erreicht und Sie mit einem Anstieg der Datennutzung rechnen, sollten Sie die Clustergröße erhöhen, um Platz für neue Daten zu schaffen.

Cluster mit hoher Schreiblast überwachen

Sehen Sie sich den Messwert /cluster/memory/maximum_utilization an. Abhängig von der Schwere der hohen Schreiblast kann es bei Ihrem Cluster bei den folgenden Grenzwerten zu Leistungsproblemen kommen:

• Bei sehr hoher Schreiblast kann es zu Problemen kommen, wenn /cluster/memory/maximum_utilization 65% oder mehr erreicht.

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

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

Wenn Probleme auftreten oder Sie befürchten, dass Ihr Cluster eine hohe Schreiblast 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 mit wenig Schreibvorgängen tun. Die Skalierung in Zeiten hoher Schreiblast kann den Arbeitsspeicher Ihres Clusters aufgrund des durch die Replikation oder Slotmigration verursachten Speicheraufwands belasten.

Wenn in Ihrem Redis-Anwendungsfall Schlüssel entfernt werden, kann das Skalieren 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 Speicherplatz für Ihre Daten bietet. Die neue Anzahl der Ziel-Shards 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 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-Nutzung

Wenn ein unerwarteter Zonenausfall 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-Nutzung von Knoten so zu verwalten, dass Knoten genügend CPU-Overhead haben, um zusätzlichen Traffic aufgrund von verloren gegangener Kapazität bei einem unerwarteten zonenbezogenen Ausfall zu verarbeiten. Sie sollten die CPU-Auslastung für primäre und Replikate mit dem Messwert CPU-Sekunden des Hauptthreads /cluster/cpu/maximum_utilization überwachen.

Je nach Anzahl der Replikate, die Sie pro Knoten bereitstellen, empfehlen wir die folgenden /cluster/cpu/maximum_utilization-CPU-Auslastungsziele:

• Bei Clustern mit einem Replikat pro Knoten sollte der /cluster/cpu/maximum_utilization-Wert für den primären Knoten und das Replikat jeweils 0, 5 Sekunden betragen.
• Bei Clustern mit zwei oder mehr Replikaten pro Knoten sollte der /cluster/cpu/maximum_utilization-Wert für das primäre Replikat 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 Sie weniger als fünf Replikate für Ihren Cluster haben, können Sie 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 sein, dass sich der Cluster nicht richtig verhält und externe Messwerte fehlen.

Ressourcenintensive Redis-Befehle

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

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

In der folgenden Tabelle finden Sie Beispiele für ressourcenintensive Redis-Befehle und ressourcenschonende Alternativen.

Tipp: Diese Befehle sind nicht nur ressourcenintensiv, sondern auch kostspielig, da die Kosten mit der Gesamtgröße Ihrer Daten steigen.

Mit SLOWLOG können Sie herausfinden, welche Befehle mit langer Ausführungszeit Sie verwenden. Dieses Tool bietet Ihnen 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	Ressourcenschonende 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 Skripts blockieren	EVAL	Achten Sie darauf, dass Ihr Script nicht unbegrenzt ausgeführt wird.
	EVALSHA	Achten Sie darauf, dass Ihr Script nicht unbegrenzt ausgeführt wird.
Dateien und Links entfernen	DEL	UNLINK
Veröffentlichen und abonnieren	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Best Practices für die Skalierung von Grenzwerten

Szenarien für Skalierungsschwellenwerte lassen sich in die folgenden Kategorien einteilen:

• Skalierung für die Arbeitsspeicherauslastung
• Skalierung für die CPU-Auslastung
• Skalieren, um Hotspots zu vermeiden

Wenn Ihre Arbeitslast auf dem Entfernen von Schlüsseln beruht, empfiehlt Google keine Skalierung für die CPU- oder Speicherauslastung. Bei diesen Arbeitslasten erreicht die Speicherauslastung häufig die maximale Kapazität, bevor es automatisch zu Räumungen kommt. Die resultierenden Speicherspitzen verhindern das Herunterskalieren.

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

Skalierung der Arbeitsspeicherauslastung

Wenn Sie feststellen möchten, wann eine Skalierung basierend auf der Arbeitsspeicherauslastung erfolgen soll, beobachten Sie die Messwerte /cluster/memory/average_utilization und /cluster/memory/maximum_utilization. Weitere Informationen zu diesen Messwerten finden Sie unter Unterstützte Monitoring-Messwerte.

Wenn Ihr Cluster eine der folgenden Bedingungen erfüllt, sollten Sie einen Scale-out-Vorgang auslösen:

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

Wenn Ihr Cluster eine der folgenden Bedingungen erfüllt, sollten Sie einen Scale-in-Vorgang auslösen:

• Die durchschnittliche Arbeitsspeicherauslastung Ihres Clusters sinkt unter den empfohlenen Schwellenwert von 50%.
• Die maximale Arbeitsspeicherauslastung sinkt unter 60% und die durchschnittliche Arbeitsspeicherauslastung unter 40%.

Skalierung der CPU-Auslastung

Um zu ermitteln, wann die Skalierung anhand der CPU-Auslastung erfolgen soll, beobachten Sie die Messwerte /cluster/cpu/average_utilization und /cluster/cpu/maximum_utilization.

Wenn Ihr Cluster eine der folgenden Bedingungen erfüllt, sollten Sie einen Scale-out-Vorgang auslösen:

• Die durchschnittliche CPU-Auslastung Ihres Clusters überschreitet den empfohlenen Grenzwert von 70%.
• Die maximale CPU-Auslastung überschreitet 80% und die durchschnittliche CPU-Auslastung überschreitet 50%.

Wenn Ihr Cluster eine der folgenden Bedingungen erfüllt, sollten Sie einen Scale-in-Vorgang auslösen:

• Die durchschnittliche CPU-Auslastung Ihres Clusters sinkt unter den empfohlenen Schwellenwert von 50%.
• Die maximale CPU-Auslastung sinkt unter 60% und die durchschnittliche CPU-Auslastung unter 40%.

Skalieren, um Hotspots zu vermeiden

Memorystore for Redis Cluster bietet durchschnittliche und maximale Variationen desselben Messwerts, mit denen Sie Hotspots für diese Messwertfamilie identifizieren können. Der Höchstwert steht für den am stärksten ausgelasteten Clusternknoten, der Durchschnittswert für die Auslastung des gesamten Clusters. Wenn der Höchstwert deutlich höher als der Durchschnittswert ist, deutet dies darauf hin, dass ein bestimmter Knoten überproportional belastet wird (Hotspot). Um dieses Problem zu beheben, empfehlen wir, den Cluster zu skalieren. Weitere Informationen finden Sie unter Instanzkapazität skalieren.

Wenn Sie eine erhebliche Abweichung zwischen den durchschnittlichen und maximalen Variationen feststellen, können Sie die Befehle INFO memory und INFO cpu für die Clusterknoten ausführen, um Echtzeitdaten direkt aus dem Cluster zu erfassen. Weitere Informationen zur Verwendung dieser Befehle finden Sie in der Redis-Dokumentation unter INFO.

Best Practices für Redis-Clients

Ihre Anwendung muss einen Cluster-kompatiblen 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 entsteht.

Clientzuordnung

Kunden 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 Zuordnung von Slots zu Knoten festlegen.

• Wenn eine MOVED-Weiterleitung vom Server 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 Quell- zum primären Zielknoten verschoben werden.

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

• Wenn vom Server ein READONLY-Fehler empfangen wird. Das kann passieren, wenn eine primäre Instanz zur Replikinstanz herabgestuft wird.

• Außerdem sollten Clients die Topologie regelmäßig aktualisieren, um für Änderungen gerüstet zu sein und Änderungen zu erkennen, die nicht zu Weiterleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikatknoten hinzugefügt werden. Beachten Sie, dass alle alten Verbindungen im Rahmen der Aktualisierung der Topologie geschlossen werden sollten, um die Notwendigkeit zu verringern, fehlgeschlagene Verbindungen während der Befehlslaufzeit zu verarbeiten.

Clientermittlung

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

Die Größe der Antwort für die Cluster-Client-Erkennungsbefehle kann je nach Clustergröße und ‑topologie variieren. Größere Cluster mit mehr Knoten liefern eine größere Antwort. Daher ist es wichtig, dass die Anzahl der Clients, die die Cluster-Topologie ermitteln, nicht unbegrenzt wächst.

Diese Aktualisierungen der Topologie sind auf dem Redis-Server kostspielig, aber auch wichtig für die Verfügbarkeit der Anwendung. Daher ist es wichtig, dass jeder Client zu einem bestimmten Zeitpunkt nur eine 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 die Clustererkennung durchführen muss, ist ein häufiger Fehler, dass die Clientanwendung mehrere Wiederverbindungs- und Erkennungsanfragen stellt, ohne beim Wiederholen exponentielle Backoffs hinzuzufügen. Dadurch kann der Redis-Server für längere Zeit nicht mehr reagieren und es kann zu einer sehr hohen CPU-Auslastung kommen.

Überlastung von Redis durch Discovery vermeiden

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

• Implementieren Sie einen Clientverbindungspool mit einer endlichen 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 Timeouts getrennt wird, versuchen Sie es noch einmal mit exponentiellem Backoff mit Jitter. So lässt sich vermeiden, dass mehrere Clients den Server gleichzeitig überlasten.

• Verwenden Sie den Memorystore for Redis Cluster-Erkennungsendpunkt, um die Clustererkennung durchzuführen. Der Discovery-Endpunkt ist hochverfügbar und wird auf alle Knoten im Cluster verteilt. Außerdem versucht der Discovery-Endpunkt, die Cluster-Discovery-Anfragen 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-Clustern 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 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, werden inaktive Verbindungen, die nicht reagieren, innerhalb einer Minute zurückgesetzt.
• TCP-Nutzer-Timeouts konfigurieren: Legen Sie dieses Timeout in Ihren Clients fest, um Verbindungen zurückzusetzen, für die ausstehende Anfragen vorhanden sind und die nicht mehr reagieren. Wenn Sie das Zeitlimit beispielsweise auf 15 Sekunden festlegen, werden nicht reagierende Verbindungen mit ausstehenden Anfragen nach 15 Sekunden zurückgesetzt.

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

Wenn Sie Ihren Cluster mit RDB-Snapshots sichern oder Replikate zu Ihrem Cluster hinzufügen möchten, sollten Sie die folgenden Best Practices beachten:

Speicherverwaltung

Bei RDB-Snapshots wird ein Prozess-Fork und ein Copy-on-Write-Mechanismus verwendet, um einen Snapshot der Knotendaten zu erstellen. Je nach Muster der Schreibvorgänge für Knoten wächst der verwendete Speicher der Knoten, da Seiten, die von den Schreibvorgängen betroffen sind, kopiert werden. Der Speicherbedarf kann bis zum Doppelten der Größe der Daten im Knoten betragen.

Damit Knoten genügend Arbeitsspeicher für die Erstellung des Snapshots haben, sollte maxmemory bei 80% der Knotenkapazität liegen, sodass 20% für den Overhead reserviert sind. Dieser zusätzliche Speicherbedarf hilft Ihnen zusammen mit der Überwachung von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Wenn Sie Replikate hinzufügen, sollten Sie außerdem den Schreibtraffic so weit wie möglich reduzieren. Weitere Informationen finden Sie unter Cluster mit hoher Schreiblast überwachen.

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, können Sie die Arbeitsspeichernutzung Ihres Clusters auf eine der folgenden Arten reduzieren:

• 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, damit er mehr Arbeitsspeicher hat.

Wenn die Arbeitsspeichernutzung Ihres Clusters unter dem Schwellenwert von 80% liegt, fügen Sie das Replikat wieder hinzu.

Veraltete Snapshots

Das Wiederherstellen von Knoten aus einem alten Snapshot kann zu Leistungsproblemen für Ihre Anwendung führen, da eine große Anzahl alter Schlüssel oder andere Änderungen an Ihrer Datenbank, z. B. eine Schemaänderung, abgeglichen werden müssen. Wenn Sie Bedenken haben, dass Sie einen alten Snapshot wiederherstellen, können Sie die RDB-Persistenzfunktion deaktivieren. Sobald Sie die Persistenz wieder aktivieren, wird beim nächsten geplanten Snapshot-Intervall ein Snapshot erstellt.

Auswirkungen von RDB-Snapshots auf die Leistung

Abhängig von Ihrem 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 für Zeiten mit geringem Cluster-Traffic planen, wenn Sie mit weniger häufigen Snapshots zufrieden sind.

Wenn Ihr Cluster beispielsweise zwischen 1:00 Uhr und 4:00 Uhr nur 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äufig Snapshots benötigt, 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 Arbeitsspeicherverwaltung.

Wann sollte ein Einzelzonencluster 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 Sie die Kosten minimieren und die Spitzenleistung für Ihre Clients in derselben Region maximieren möchten, empfehlen wir Ihnen, einen Einzelzonencluster auszuwählen.

Auswirkungen von Ausfällen minimieren

Wenn Sie einen einzonalen Cluster auswählen, sind zonale Ausfälle weniger wahrscheinlich. Wenn Sie alle Knoten in einer einzigen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein zonales Problem Ihren Server beeinträchtigt, von 100% auf 33%. Die Wahrscheinlichkeit, dass die Zone, in der sich Ihr Cluster befindet, ausfällt, beträgt 33 %. Die Wahrscheinlichkeit, dass Knoten in der nicht verfügbaren Zone betroffen sind, beträgt 100 %.

Schnelle Erholung

Wenn ein zonaler Ausfall für einen Cluster mit einer einzelnen Zone auftritt, vereinfacht 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 den Betrieb nur minimal zu unterbrechen.

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 erhalten Sie bei einer Änderung der Topologie möglicherweise unknownPartition-Fehler.

Transport Layer Security (TLS) aktivieren

In diesem Abschnitt werden die Sicherheitsvorteile und Leistungsbeeinträchtigungen der Verwendung von Transport Layer Security (TLS) sowie Empfehlungen für die Aktivierung beschrieben.

Sicherheitsvorteile

Die Verwendung von TLS bietet die folgenden Sicherheitsvorteile:

• IAM-Authentifizierung (Identity and Access Management): Diese Art der Authentifizierung wird von TLS verwendet, um vor Server-Spoofing-Angriffen wie Man-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 ist es jedoch erforderlich, sowohl den Host- als auch den Netzwerk-Stack von Google zu vertrauen. Diese Verschlüsselung ist zwar transparent und standardmäßig aktiviert, aber keine Ende-zu-Ende-Verschlüsselung. TLS hingegen verwendet die Verschlüsselung während der Übertragung auf der Anwendungsebene. Durch die Ende-zu-Ende-Verschlüsselung haben Sie 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 und weitergegeben werden.

Auswirkungen auf die Leistung

TLS wirkt sich auf folgende Weise 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, verringern Sie den Aufwand für die Herstellung 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 kann es zu Zeitüberschreitungen kommen, wenn viele Verbindungen zwischen dem Client und dem Server bestehen. Dies kann zu einem Schneeballeffekt führen, da Memorystore for Redis Cluster versucht, Zeitüberschreitungen bei Verbindungen zu beheben, was die Ressourcen erhöht, die zum Herstellen von Verbindungen verwendet werden.

• Daten verschlüsseln und entschlüsseln: Die Datenverschlüsselung und ‑entschlüsselung erfordern 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 TLS aktivieren möchten, sollten Sie Ihre Sicherheitsrichtlinien unter Berücksichtigung der Vor- und Nachteile von TLS prüfen. Wenn Sie TLS aktivieren, beachten Sie Folgendes:

• Durch Aktivieren der TLS-Wiederaufnahme wird der Aufwand für das Herstellen von Verbindungen reduziert. Eine Verbindung zwischen dem Client und dem Server ist nur für die erste Verbindung erforderlich. Eine plötzliche Vergrößerung der Clustergröße des Clients kann jedoch zu einer kurzen Unterbrechung führen, die durch den ersten vollständigen Handshake jedes neuen Client-Hosts 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 Cluster zu integrieren.