Säule der Leistung und Effizienz von Amazon ElastiCache Well-Architected Lens

Die Säule der Leistungseffizienz konzentriert sich auf die effiziente Nutzung von IT- und Computing-Ressourcen. Zu den wichtigsten Themen gehören die Auswahl der richtigen Ressourcentypen und -größen je nach Workload-Anforderungen, die Überwachung der Leistung und das Treffen fundierter Entscheidungen, um die Effizienz aufrechtzuerhalten, wenn sich die Geschäftsanforderungen weiterentwickeln.

PE 1: Wie überwachen Sie die Leistung Ihres ElastiCache Amazon-Clusters?

Einführung auf Fragenebene: Wenn Sie die vorhandenen Überwachungsmetriken verstehen, können Sie die aktuelle Auslastung ermitteln. Eine ordnungsgemäße Überwachung kann dazu beitragen, potenzielle Engpässe zu identifizieren, die sich auf die Leistung Ihres Clusters auswirken.

Vorteil auf Fragenebene: Wenn Sie die Metriken Ihres Clusters kennen, können Sie Optimierungsmethoden entwickeln, die zu einer geringeren Latenz und einem höheren Durchsatz führen können.

• [Erforderlich] Basisleistungstests mit einer Teilmenge Ihres Workloads.

  • Sie sollten die Leistung des tatsächlichen Workloads mithilfe von Mechanismen wie Lasttests überwachen.

  • Überwachen Sie die CloudWatch Metriken, während Sie diese Tests durchführen, um sich ein Bild von den verfügbaren Metriken zu machen und eine Leistungsbasis festzulegen.

• [Am besten] Benennen Sie für ElastiCache (Redis OSS) -Workloads rechenintensive Befehle um, z. B. um die Fähigkeit von Benutzern einzuschränkenKEYS, blockierende Befehle auf Produktionsclustern auszuführen.

  • ElastiCache (Redis OSS) -Workloads, auf denen Engine 6.x ausgeführt wird, können die rollenbasierte Zugriffskontrolle nutzen, um bestimmte Befehle einzuschränken. Der Zugriff auf die Befehle kann gesteuert werden, indem Benutzer und Benutzergruppen mit der AWS Konsole oder CLI erstellt und die Benutzergruppen einem ElastiCache for Redis OSS-Cluster zugeordnet werden. Wenn RBAC in Redis OSS 6 aktiviert ist, können wir „- @dangerous" verwenden. Dadurch werden teure Befehle wie KEYS, MONITOR, SORT usw. für diesen Benutzer nicht zugelassen.

  • Benennen Sie für Engine-Version 5.x Befehle mithilfe des rename-commands Parameters in der OSS-Cluster-Parametergruppe von Amazon ElastiCache for Redis um.

• [Besser] Analysieren Sie langsame Abfragen und suchen Sie nach Optimierungsmöglichkeiten.

  • Für ElastiCache (Redis OSS-) Workloads erfahren Sie mehr über Ihre Abfragen, indem Sie das Slow Log analysieren. Sie können beispielsweise den Befehl redis-cli slowlog get 10 verwenden, um die letzten 10 Befehle anzuzeigen, welche die Latenzschwellenwerte überschritten haben (standardmäßig 10 Sekunden).

  • Bestimmte Abfragen können mithilfe komplexer ElastiCache (Redis OSS) Datenstrukturen effizienter ausgeführt werden. Für Bereichsabfragen im numerischen Stil kann eine Anwendung beispielsweise einfache numerische Indizes mit sortierten Sätzen implementieren. Die Verwaltung dieser Indizes kann die Anzahl der am Datensatz durchgeführten Scans reduzieren und Daten mit höherer Leistungseffizienz zurückgeben.

  • redis-benchmarkBietet für ElastiCache (Redis OSS-) Workloads eine einfache Oberfläche zum Testen der Leistung verschiedener Befehle mithilfe benutzerdefinierter Eingaben wie Anzahl der Clients und Datengröße.

  • Da Memcached nur einfache Befehle auf Schlüsselebene unterstützt, sollten Sie erwägen, zusätzliche Schlüssel als Indizes zu erstellen, um zu vermeiden, dass der Schlüsselbereich wiederholt wird, um Client-Abfragen zu bearbeiten.

• [Ressourcen]:

  • Überwachung der Nutzung mit Metrics CloudWatch

  • Überwachung der Nutzung mit CloudWatch Metrics

  • CloudWatch Amazon-Alarme verwenden

  • Redis-spezifische Parameter

  • SLOWLOG

  • Redis OSS-Benchmark

PE 2: Wie verteilen Sie die Arbeit auf Ihre ElastiCache Clusterknoten?

Einführung auf Fragenebene: Die Art und Weise, wie Ihre Anwendung eine Verbindung zu ElastiCache Amazon-Knoten herstellt, kann sich auf die Leistung und Skalierbarkeit des Clusters auswirken.

Vorteil auf Fragenebene: Durch die richtige Nutzung der verfügbaren Knoten im Cluster wird sichergestellt, dass die Arbeit auf die verfügbaren Ressourcen verteilt wird. Die folgenden Methoden tragen ebenfalls dazu bei, ungenutzte Ressourcen zu vermeiden.

• [Erforderlich] Sorgen Sie dafür, dass sich die Clients mit dem richtigen ElastiCache Endpunkt verbinden.

  • Amazon ElastiCache for Redis OSS implementiert je nach verwendetem Cluster-Modus unterschiedliche Endpunkte. Wenn der Cluster-Modus aktiviert ist, ElastiCache wird ein Konfigurationsendpunkt bereitgestellt. ElastiCache Stellt bei deaktiviertem Clustermodus einen primären Endpunkt bereit, der normalerweise für Schreibvorgänge verwendet wird, und einen Leser-Endpunkt für die Verteilung von Lesevorgängen zwischen Replikaten. Die korrekte Implementierung dieser Endpunkte führt zu einer besseren Leistung und einfacheren Skalierungsvorgängen. Vermeiden Sie es, eine Verbindung zu einzelnen Knotenendpunkten herzustellen, es sei denn, dies ist ausdrücklich erforderlich.

  • ElastiCache Stellt für Memcached-Cluster mit mehreren Knoten einen Konfigurationsendpunkt bereit, der Auto Discovery aktiviert. Es wird empfohlen, einen Hashing-Algorithmus zu verwenden, um die Arbeit gleichmäßig auf die Cache-Knoten zu verteilen. Viele Memcached-Clientbibliotheken implementieren konsistentes Hashing. Überprüfen Sie die Dokumentation der von Ihnen verwendeten Bibliothek darauf, ob sie konsistentes Hashing unterstützt und wie es implementiert wird. Weitere Informationen zur Implementierung dieser Funktionen finden Sie hier.

• [Besser] Nutzen Sie den aktivierten Clustermodus ElastiCache (Redis OSS), um die Skalierbarkeit zu verbessern.

  • ElastiCache Cluster (Redis OSS) (Cluster-Modus aktiviert) unterstützen Online-Skalierungsoperationen (ausgehen/einsteigen und hoch/runter), um Daten dynamisch auf mehrere Shards zu verteilen. Durch die Verwendung des Konfigurationsendpunkts wird sichergestellt, dass sich Ihre clusterfähigen Clients an Änderungen in der Cluster-Topologie anpassen können.

  • Sie können den Cluster auch neu verteilen, indem Sie Hashslots zwischen verfügbaren Shards in Ihrem ElastiCache (Redis OSS) Cluster (Clustermodus aktiviert) verschieben. Dies trägt dazu bei, die Arbeit effizienter auf die verfügbaren Shards zu verteilen.

• [Besser] Implementieren Sie eine Strategie zur Identifizierung und Korrektur von Tastaturbefehlen in Ihrem Workload.

  • Bedenken Sie die Auswirkungen mehrdimensionaler Redis OSS-Datenstrukturen wie Listen, Streams, Sets usw. Diese Datenstrukturen werden in einzelnen Redis OSS-Schlüsseln gespeichert, die sich auf einem einzigen Knoten befinden. Ein sehr großer multidimensionaler Schlüssel nimmt potenziell mehr Netzwerkkapazität und Speicher in Anspruch als andere Datentypen und kann eine unverhältnismäßige Nutzung dieses Knotens bewirken. Wenn möglich, sollten Sie Ihren Workload so gestalten, dass der Datenzugriff auf viele einzelne Schlüssel verteilt wird.

  • Tastaturbefehle im Workload können die Leistung des verwendeten Knotens beeinträchtigen. Bei ElastiCache (Redis OSS-) Workloads können Sie Hotkeys erkennen, redis-cli --hotkeys wenn eine LFU-Richtlinie zur maximalen Speicherbelegung vorhanden ist.

  • Erwägen Sie, Tastaturbefehle auf mehreren Knoten zu replizieren, um den Zugriff auf sie gleichmäßiger zu verteilen. Bei diesem Ansatz muss der Client auf mehrere Primärknoten schreiben (der Redis-OSS-Knoten selbst bietet diese Funktionalität nicht) und zusätzlich zum ursprünglichen Schlüsselnamen eine Liste mit Schlüsselnamen verwalten, aus denen gelesen werden kann.

  • E ElastiCache (Redis OSS) Version 6 unterstützt servergestütztes clientseitiges Caching. Auf diese Weise können Anwendungen auf Änderungen an einem Schlüssel warten, bevor sie über das Netzwerk zurückrufen. ElastiCache

• [Ressourcen]:

  • Konfigurieren Sie ElastiCache (Redis OSS) für eine höhere Verfügbarkeit

  • Ermitteln von Verbindungsendpunkten

  • Bewährte Methoden für den Lastausgleich

  • Online-Resharding und Shard-Rebalancing für Redis OSS (Clustermodus aktiviert)

  • Clientseitiges Caching in Redis OSS

PE 3: Wie verfolgen und protokollieren Sie bei Caching-Workloads die Effektivität und Leistung Ihres Caches?

Einführung auf Fragenebene: Caching ist ein häufig auftretender Workload, ElastiCache und es ist wichtig, dass Sie wissen, wie Sie die Effektivität und Leistung Ihres Caches verwalten können.

Vorteil auf Fragenebene: Ihre Anwendung kann Anzeichen einer stagnierenden Leistung aufweisen. Ihre Fähigkeit, Cache-spezifische Metriken als Grundlage für Ihre Entscheidung zur Steigerung der App-Leistung zu verwenden, ist für Ihren Cache-Workload von entscheidender Bedeutung.

• [Erforderlich] Messen und verfolgen Sie die Cache-Trefferquote im Zeitverlauf. Die Effizienz Ihres Caches wird durch seine „Cache-Trefferquote“ bestimmt. Die Cache-Trefferquote wird durch die Summe der Schlüsseltreffer geteilt durch die Gesamtzahl der Treffer und Fehlversuche definiert. Je näher die Quote an 1 liegt, desto effektiver ist Ihr Cache. Eine niedrige Cache-Trefferquote wird durch die Menge der Cache-Fehlversuche verursacht. Cache-Fehlversuche treten auf, wenn der angeforderte Schlüssel nicht im Cache gefunden wird. Ein Schlüssel befindet sich nicht im Cache, weil er entweder bereinigt oder gelöscht wurde, abgelaufen ist oder nie existiert hat. Machen Sie sich klar, warum sich Schlüssel nicht im Cache befinden, und entwickeln Sie geeignete Strategien, um sie im Cache vorliegen zu haben.

  [Ressourcen]:

  • Metriken für Redis OSS

• [Erforderlich] Messen und erfassen Sie die Leistung Ihres Anwendungs-Caches in Verbindung mit den Werten für Latenz und CPU-Auslastung, um zu ermitteln, ob Sie Anpassungen an Ihren time-to-live oder anderen Anwendungskomponenten vornehmen müssen. ElastiCache bietet eine Reihe von CloudWatch Metriken für aggregierte Latenzen für jede Datenstruktur. Diese Latenzmetriken werden anhand der Commandstats-Statistik des Befehls ElastiCache (Redis OSS) INFO berechnet und beinhalten nicht die Netzwerk- und I/O-Zeit. Dies ist nur die Zeit, die ElastiCache (Redis OSS) für die Verarbeitung der Operationen benötigt.

  [Ressourcen]:

  • Metriken für Redis OSS

  • Überwachung von Best Practices mit Amazon ElastiCache for Redis OSS mithilfe von Amazon CloudWatch

• [Am besten] Wählen Sie die richtige Caching-Strategie für Ihre Anforderungen aus. Eine niedrige Cache-Trefferquote wird durch die Menge der Cache-Fehlversuche verursacht. Wenn Ihr Workload so konzipiert ist, dass es nur wenige Cache-Fehlversuche gibt (z. B. Kommunikation in Echtzeit), sollten Sie Ihre Caching-Strategien überprüfen und die für Ihren Workload am besten geeigneten Lösungen anwenden, z. B. Abfrage-Instrumente zur Messung von Speicher und Leistung. Die tatsächlichen Strategien, die Sie zum Auffüllen und Verwalten Ihres Cache implementieren müssen, hängt von den Daten, die Ihre Clients zwischenspeichern müssen, und den Zugriffsmustern auf diese Daten ab. Es ist beispielsweise unwahrscheinlich, dass Sie dieselbe Strategie sowohl für personalisierte Empfehlungen in einer Streaming-Anwendung als auch für aktuelle Nachrichten verwenden.

  [Ressourcen]:

  • Caching-Strategien

  • Bewährte Methoden für das Caching

  • Skalierbare Leistung mit Amazon ElastiCache Whitepaper

PE 4: Wie optimiert Ihr Workload den Einsatz von Netzwerkressourcen und Verbindungen?

Einführung auf Fragenebene: ElastiCache (Redis OSS) und ElastiCache (Memcached) werden von vielen Anwendungsclients unterstützt, und die Implementierungen können variieren. Sie müssen das vorhandene Netzwerk- und Verbindungsmanagement verstehen, um mögliche Auswirkungen auf die Leistung zu analysieren.

Vorteil auf Fragenebene: Die effiziente Nutzung von Netzwerkressourcen kann die Leistungseffizienz Ihres Clusters verbessern. Die folgenden Empfehlungen können die Netzwerkanforderungen reduzieren und die Latenz und den Durchsatz des Clusters verbessern.

• [Erforderlich] Verwalten Sie proaktiv Verbindungen zu Ihrem Cluster. ElastiCache

  • Verbindungspooling in der Anwendung reduziert den Overhead im Cluster, der durch das Öffnen und Schließen von Verbindungen entsteht. Überwachen Sie das Verbindungsverhalten in Amazon CloudWatch mithilfe von CurrConnections undNewConnections.

  • Vermeiden Sie Verbindungslecks, indem Sie die Client-Verbindungen gegebenenfalls ordnungsgemäß schließen. Zu den Strategien zur Verbindungsverwaltung gehören das ordnungsgemäße Schließen von Verbindungen, die nicht verwendet werden, und das Festlegen von Verbindungs-Timeouts.

  • Für Memcached-Workloads gibt es eine konfigurierbare Speichermenge, die für die Verarbeitung von Verbindungen reserviert ist und als memcached_connections_overhead bezeichnet wird.

• [Besser] Komprimieren Sie große Objekte, um den Speicherplatz zu reduzieren und den Netzwerkdurchsatz zu verbessern.

  • Datenkomprimierung kann den erforderlichen Netzwerkdurchsatz (GBit/s) reduzieren, erhöht jedoch den Arbeitsaufwand für die Anwendung zum Komprimieren und Dekomprimieren von Daten.

  • Durch die Komprimierung wird auch der Speicherverbrauch von Schlüsseln reduziert.

  • Berücksichtigen Sie auf der Grundlage Ihrer Anwendungsanforderungen die Kompromisse zwischen Komprimierungsverhältnis und Komprimierungsgeschwindigkeit.

• [Ressourcen]:

  • Amazon ElastiCache für Redis OSS — Globaler Datenspeicher

  • Memcached-spezifische Parameter

  • Amazon ElastiCache for Redis OSS 5.0.3 verbessert die I/O-Verarbeitung, um die Leistung zu steigern

  • Metriken für Redis OSS

  • Amazon ElastiCache for Redis OSS für höhere Verfügbarkeit konfigurieren

PE 5: Wie verwalten Sie die Löschung und/oder Bereinigung von Schlüsseln?

Einführung auf Fragenebene: Workloads haben unterschiedliche Anforderungen und ein anderes erwartetes Verhalten, wenn sich ein Clusterknoten den Grenzwerten für den Speicherverbrauch nähert. Amazon ElastiCache for Redis OSS hat unterschiedliche Richtlinien für den Umgang mit diesen Situationen.

Vorteil auf Fragenebene: Die richtige Verwaltung des verfügbaren Speichers und das Verständnis der Löschungsrichtlinien tragen dazu bei, dass das Clusterverhalten bei Überschreitung der Speicherlimits von Instances besser erkannt wird.

• [Erforderlich] Instrumentieren Sie den Datenzugriff, um zu beurteilen, welche Richtlinie angewendet werden soll. Identifizieren Sie eine geeignete Richtlinie für maximalen Arbeitsspeicher, um zu kontrollieren, ob und wie Bereinigungen im Cluster durchgeführt werden.

  • Eine Bereinigung erfolgt, wenn der maximale Arbeitsspeicher des Clusters verbraucht ist und eine Richtlinie vorhanden ist, welche die Bereinigung zulässt. Das Verhalten des Clusters in dieser Situation hängt von der angegebenen Bereinigungsrichtlinie ab. Diese Richtlinie kann mithilfe der Parametergruppe maxmemory-policy auf dem Cluster ElastiCache (Redis OSS) verwaltet werden.

  • Die Standardrichtlinie volatile-lru gibt Speicherplatz frei, indem Schlüssel mit einer festgelegten Ablaufzeit (TTL-Wert) bereinigt werden. Die Richtlinien „Least frequently used“ (LFU, am wenigsten häufig verwendet) und „Least recently used“ (LRU, am wenigsten zuletzt verwendet) entfernen Schlüssel je nach Nutzung.

  • Für Memcached-Workloads gibt es eine standardmäßige LRU-Richtlinie, welche die Bereinigungen auf jedem Knoten steuert. Die Anzahl der Räumungen in Ihrem ElastiCache Amazon-Cluster kann mithilfe der Räumungsmetrik auf Amazon überwacht werden. CloudWatch

• [Besser] Standardisieren Sie das Löschverhalten, um die Auswirkungen auf die Leistung Ihres Clusters zu kontrollieren und unerwartete Leistungsengpässe zu vermeiden.

  • Bei ElastiCache (Redis OSS-) Workloads ist das explizite Entfernen von Schlüsseln aus dem Cluster wie folgtDEL: UNLINK Es entfernt die angegebenen Schlüssel. Der Befehl führt jedoch die eigentliche Speicherrückgewinnung in einem anderen Thread durch, sodass er nicht blockiert, während dies mit DEL der Fall ist. Die eigentliche Entfernung erfolgt später asynchron.

  • Für ElastiCache (Redis OSS) 6.x-Workloads kann das Verhalten des DEL Befehls in der Parametergruppe mithilfe von Parameter geändert werden. lazyfree-lazy-user-del

• [Ressourcen]:

  • Konfiguration von Engine-Parametern unter Verwendung von Parametergruppen

  • UNLINK

  • Cloud-Finanzmanagement mit AWS

PE 6: Wie modellieren und interagieren Sie mit Daten in ElastiCache?

Einführung auf Fragenebene: ElastiCache Ist stark von der Anwendung abhängig von den Datenstrukturen und dem verwendeten Datenmodell, muss aber auch der zugrunde liegende Datenspeicher (falls vorhanden) berücksichtigt werden. Machen Sie sich mit den verfügbaren ElastiCache (Redis OSS-) Datenstrukturen vertraut und stellen Sie sicher, dass Sie die für Ihre Bedürfnisse am besten geeigneten Datenstrukturen verwenden.

Vorteil auf Frageebene: Die Datenmodellierung ElastiCache besteht aus mehreren Ebenen, darunter Anwendungsfälle, Datentypen und Beziehungen zwischen Datenelementen. Darüber hinaus haben alle ElastiCache (Redis OSS) -Datentypen und Befehle ihre eigenen, gut dokumentierten Leistungssignaturen.

• [Am besten] Eine bewährte Methode besteht darin, das unbeabsichtigte Überschreiben von Daten zu reduzieren. Verwenden Sie eine Namenskonvention, die überlappende Schlüsselnamen minimiert. Bei der herkömmlichen Benennung Ihrer Datenstrukturen wird eine hierarchische Methode wie APPNAME:CONTEXT:ID bzw. ORDER-APP:CUSTOMER:123 verwendet.

  [Ressourcen]:

  • Benennung von Schlüsseln

• [Best] -Befehle ElastiCache (Redis OSS) haben eine Zeitkomplexität, die durch die Big-O-Notation definiert wird. Hier ist die Komplexität eines Befehls eine algorithmische/mathematische Darstellung seiner Wirkung. Bei der Einführung eines neuen Datentyps in Ihre Anwendung müssen Sie die Zeitkomplexität der zugehörigen Befehle sorgfältig überprüfen. Befehle mit einer Zeitkomplexität von O(1) sind zeitlich konstant und hängen nicht von der Größe der Eingabe ab. Befehle mit einer Zeitkomplexität von O(N) sind jedoch zeitlich linear und hängen von der Größe der Eingabe ab. Aufgrund des Single-Thread-Designs von ElastiCache (Redis OSS) führt ein großes Volumen an Vorgängen mit hoher Zeitkomplexität zu einer geringeren Leistung und zu potenziellen Zeitüberschreitungen.

  [Ressourcen]:

  • Befehle

• [Am besten] Verwenden Sie APIs, um grafische Einblicke in das Datenmodell in Ihrem Cluster zu erhalten.

  [Ressourcen]:

  • Redis OSS Commander

  • Redis OSS-Browser

  • Redsmin

PE 7: Wie protokollieren Sie langsam laufende Befehle in Ihrem ElastiCache Amazon-Cluster?

Einführung auf Fragenebene: Die Leistungsoptimierung bietet Vorteile durch die Erfassung, Aggregation und Benachrichtigung von Befehlen mit langer Laufzeit. Wenn Sie wissen, wie lange es dauert, bis Befehle ausgeführt werden, können Sie feststellen, welche Befehle zu einer schlechten Leistung führen und welche Befehle die Engine daran hindern, optimal zu arbeiten. Amazon ElastiCache for Redis OSS kann diese Informationen auch an Amazon CloudWatch oder Amazon Kinesis Data Firehose weiterleiten.

Vorteil auf Fragenebene: Die Protokollierung an einem festen Standort und die Bereitstellung von Benachrichtigungsereignissen bei langsamen Befehlen können zu einer detaillierten Leistungsanalyse beitragen und zur Auslösung automatisierter Ereignisse verwendet werden.

• [Erforderlich] Amazon ElastiCache (Redis OSS) führt Engine Version 6.0 oder neuer aus, ordnungsgemäß konfigurierte Parametergruppe und SLOWLOG-Protokollierung sind auf dem Cluster aktiviert.

  • Die erforderlichen Parameter sind nur verfügbar, wenn die Engine-Versionskompatibilität auf Redis OSS Version 6.0 oder höher eingestellt ist.

  • Die SLOWLOG-Protokollierung erfolgt, wenn die Serverausführungszeit eines Befehls länger als ein bestimmter Wert dauert. Das Verhalten des Clusters hängt von den zugehörigen Parametergruppenparametern ab, d. h. slowlog-log-slower-than und slowlog-max-len.

  • Änderungen werden sofort wirksam.

• [Am besten] Nutzen Sie unsere Kinesis Data Firehose Firehose-Funktionen. CloudWatch

  • Nutzen Sie die Filter- und Alarmfunktionen von CloudWatch CloudWatch Logs Insights und Amazon Simple Notification Services, um die Leistung zu überwachen und Ereignisse zu benachrichtigen.

  • Verwenden Sie die Streaming-Funktionen von Kinesis Data Firehose, um SLOWLOG-Protokolle im permanenten Speicher zu archivieren oder um eine automatische Cluster-Parameteroptimierung auszulösen.

  • Stellen Sie fest, ob das JSON- oder Plain-TEXT-Format Ihren Anforderungen am besten entspricht.

  • Stellen Sie IAM-Berechtigungen für die Veröffentlichung in CloudWatch oder Kinesis Data Firehose bereit.

• [Besser] Konfigurieren Sie slowlog-log-slower-than auf einen anderen Wert als den Standardwert.

  • Dieser Parameter bestimmt, wie lange ein Befehl innerhalb der Redis OSS-Engine ausgeführt werden kann, bevor er als langsam laufender Befehl protokolliert wird. Der Standardwert ist 10 000 Mikrosekunden (10 Millisekunden). Der Standardwert ist für einige Workloads möglicherweise zu hoch.

  • Ermitteln Sie auf der Grundlage der Anwendungsanforderungen und der Testergebnisse einen Wert, der für Ihren Workload besser geeignet ist. Ein zu niedriger Wert kann jedoch zu übermäßigen Daten führen.

• [Besser] Übernehmen Sie für slowlog-max-len den Standardwert.

  • Dieser Parameter bestimmt die Obergrenze dafür, wie viele langsam laufende Befehle zu einem bestimmten Zeitpunkt im Redis OSS-Speicher erfasst werden. Mit dem Wert 0 wird die Erfassung effektiv deaktiviert. Je höher der Wert, desto mehr Einträge werden im Speicher gespeichert. Dadurch wird die Wahrscheinlichkeit verringert, dass wichtige Informationen bereinigt werden, bevor sie überprüft werden können. Der Standardwert lautet 128.

  • Der Standardwert ist für die meisten Workloads geeignet. Wenn Daten in einem erweiterten Zeitfenster von der Redis-CLI aus über den Befehl SLOWLOG analysiert werden müssen, sollten Sie erwägen, diesen Wert zu erhöhen. Dadurch können mehr Befehle im Redis OSS-Speicher verbleiben.

    Wenn Sie die SLOWLOG-Daten entweder an CloudWatch Logs oder Kinesis Data Firehose ausgeben, werden die Daten dauerhaft gespeichert und können außerhalb des ElastiCache Systems analysiert werden, wodurch die Notwendigkeit reduziert wird, eine große Anzahl langsam laufender Befehle im Redis OSS-Speicher zu speichern.

• [Ressourcen]:

  • Wie aktiviere ich Redis OSS Slow Log in einem Cache-Cluster ElastiCache (Redis OSS)?

  • Protokollzustellung

  • Redis OSS-spezifische Parameter

  • https://aws.amazon.com/cloudwatch/Amazon CloudWatch

  • Amazon Kinesis Data Firehose

PE8: Wie hilft Auto Scaling dabei, die Leistung des ElastiCache Clusters zu steigern?

Einführung auf Fragenebene: Durch die Implementierung der Funktion von Redis OSS Auto Scaling können sich Ihre ElastiCache Komponenten im Laufe der Zeit anpassen, um die gewünschten Shards oder Replicas automatisch zu erhöhen oder zu verringern. Dies kann erreicht werden, indem entweder die Zielverfolgung oder die geplante Skalierungsrichtlinie implementiert wird.

Vorteil auf Fragenebene: Wenn Sie die Arbeitslastspitzen verstehen und entsprechend planen, können Sie eine verbesserte Caching-Leistung und einen unterbrechungsfreien Betrieb sicherstellen. ElastiCache (Redis OSS) Auto Scaling überwacht kontinuierlich Ihre CPU-/Speicherauslastung, um sicherzustellen, dass Ihr Cluster mit den gewünschten Leistungsniveaus arbeitet.

• [Erforderlich] Beim Starten eines Clusters für ElastiCache (Redis OSS):

  1. Stellen Sie sicher, dass der Clustermodus aktiviert ist.

  2. Stellen Sie sicher, dass die Instance zu einer Familie mit einem bestimmten Typ und einer bestimmten Größe gehört, die Auto Scaling unterstützt.

  3. Vergewissern Sie sich, dass der Cluster nicht in globalen Datenspeichern, Outposts oder lokalen Zonen ausgeführt wird

  [Ressourcen]:

  • Skalierung von Clustern in Redis OSS (Clustermodus aktiviert)

  • Verwenden von Auto Scaling mit Shards

  • Verwenden von Auto Scaling mit Replikaten

• [Am besten] Stellen Sie fest, ob Ihr Workload lese- oder schreibintensiv ist, um die Skalierungsrichtlinie zu definieren. Verwenden Sie nur eine Nachverfolgungsmetrik, um eine optimale Leistung zu erzielen. Es wird empfohlen, für jede Dimension mehrere Richtlinien zu vermeiden, da Auto-Scaling-Richtlinien aufskalieren, wenn das Ziel erreicht wird, aber erst dann abskalieren, wenn alle Ziel-Nachverfolgungsrichtlinien für die Abskalierung bereit sind.

  [Ressourcen]:

  • Auto-Scaling-Richtlinien

  • Definieren einer Skalierungsrichtlinie

• [Am besten] Wenn Sie die Leistung im Zeitverlauf überwachen, können Sie Workload-Änderungen erkennen, die bei punktueller Überwachung unbemerkt bleiben würden. Sie können die entsprechenden CloudWatch Metriken für die Clusterauslastung über einen Zeitraum von vier Wochen analysieren, um den Zielschwellenwert zu bestimmen. Wenn Sie sich immer noch nicht sicher sind, welchen Wert Sie wählen möchten, empfehlen wir, mit dem minimal unterstützten vordefinierten Metrikwert zu beginnen.

  [Ressourcen]:

  • Überwachung der Nutzung mit Metriken CloudWatch

• [Besser] Wir empfehlen, Ihre Anwendung mit den erwarteten minimalen und maximalen Workloads zu testen, um die genaue Anzahl der Shard/Replikate zu ermitteln, die der Cluster benötigt, um Skalierungsrichtlinien zu entwickeln und Verfügbarkeitsprobleme zu minimieren.

  [Ressourcen]:

  • Registrieren eines skalierbaren Ziels

  • Registrieren eines skalierbaren Ziels