Allgemeine Schritte und bewährte Methoden zur Fehlerbehebung

Verbindungsprobleme

Wenn Sie keine Verbindung zu Ihrem ElastiCache Cache herstellen können, sollten Sie eine der folgenden Möglichkeiten in Betracht ziehen:

1. Verwenden von TLS: Wenn beim Versuch, eine Verbindung zu Ihrem ElastiCache Endpunkt herzustellen, eine Verbindung nicht mehr hergestellt wird, verwenden Sie TLS möglicherweise nicht in Ihrem Client. Wenn Sie ElastiCache Serverless verwenden, ist die Verschlüsselung bei der Übertragung immer aktiviert. Stellen Sie sicher, dass Ihr Client TLS verwendet, um eine Verbindung zum Cache herzustellen. Weitere Informationen zum Herstellen einer Verbindung zu einem TLS-fähigen Cache finden Sie hier.

2. VPC: Auf ElastiCache Caches kann nur innerhalb einer VPC zugegriffen werden. Stellen Sie sicher, dass die EC2-Instance, von der aus Sie auf den Cache zugreifen, und der ElastiCache Cache in derselben VPC erstellt wurden. Alternativ müssen Sie das VPC-Peering zwischen der VPC, in der sich Ihre EC2-Instance befindet, und der VPC, in der Sie Ihren Cache erstellen, aktivieren.

3. Sicherheitsgruppen: ElastiCache verwendet Sicherheitsgruppen, um den Zugriff auf Ihren Cache zu kontrollieren. Berücksichtigen Sie dabei Folgendes:

   1. Stellen Sie sicher, dass die von Ihrem ElastiCache Cache verwendete Sicherheitsgruppe eingehenden Zugriff von Ihrer EC2-Instance aus darauf ermöglicht. Hier erfahren Sie, wie Sie Regeln für eingehenden Datenverkehr in Ihrer Sicherheitsgruppe korrekt einrichten.

   2. Stellen Sie sicher, dass die von Ihrem ElastiCache Cache verwendete Sicherheitsgruppe den Zugriff auf die Ports Ihres Caches ermöglicht (6379 und 6380 für serverlose Verbindungen und standardmäßig 6379 für selbst entworfene Ports). ElastiCache verwendet diese Ports, um Redis OSS-Befehle zu akzeptieren. Erfahren Sie hier mehr darüber, wie Sie den Portzugriff einrichten.

Fehler beim Redis OSS-Client

ElastiCache Serverless ist nur über Redis OSS-Clients zugänglich, die das Redis OSS-Clustermodus-Protokoll unterstützen. Auf selbst entworfene Cluster kann von Redis OSS-Clients in beiden Modi zugegriffen werden, abhängig von der Clusterkonfiguration.

Wenn bei Ihrem Client Redis OSS-Fehler auftreten, sollten Sie Folgendes beachten:

1. Clustermodus: Wenn bei Ihnen CROSSLOT-Fehler oder Fehler mit dem Befehl SELECT Redis OSS auftreten, versuchen Sie möglicherweise, mit einem Redis OSS-Client, der das Redis OSS-Cluster-Protokoll nicht unterstützt, auf einen Cache mit aktiviertem Clustermodus zuzugreifen. ElastiCache Serverless unterstützt nur Redis OSS-Clients, die das Redis OSS-Clusterprotokoll unterstützen. Wenn Sie Redis OSS im Modus „Cluster Mode Disabled“ (CMD) verwenden möchten, müssen Sie Ihren eigenen Cluster entwerfen.

2. CROSSLOT-Fehler: Wenn der ERR CROSSLOT Keys in request don't hash to the same slot Fehler auftritt, versuchen Sie möglicherweise, auf Schlüssel zuzugreifen, die nicht zu demselben Steckplatz in einem Cache im Clustermodus gehören. Zur Erinnerung: ElastiCache Serverless arbeitet immer im Clustermodus. Operationen mit mehreren Schlüsseln, Transaktionen oder Lua-Skripten mit mehreren Schlüsseln sind nur zulässig, wenn sich alle beteiligten Schlüssel im selben Hash-Slot befinden.

Weitere bewährte Methoden zur Konfiguration von Redis OSS-Clients finden Sie in diesem Blogbeitrag.

Fehlerbehebung bei hoher Latenz in Serverless ElastiCache

Wenn bei Ihrem Workload eine hohe Latenz auftritt, können Sie anhand der SuccessfulWriteRequestLatency Messwerte CloudWatch SuccessfulReadRequestLatency und überprüfen, ob die Latenz mit ElastiCache Serverless zusammenhängt. Diese Metriken messen die Latenz, die innerhalb von ElastiCache Serverless liegt. Die clientseitige Latenz und die Netzwerkausfallzeiten zwischen Ihrem Client und dem ElastiCache serverlosen Endpunkt sind nicht enthalten.

Fehlerbehebung bei der clientseitigen Latenz

Wenn Sie eine erhöhte Latenz auf der Clientseite, aber keinen entsprechenden Anstieg CloudWatch SuccessfulReadRequestLatency der SuccessfulWriteRequestLatency Messwerte für die serverseitige Latenz feststellen, sollten Sie Folgendes beachten:

• Stellen Sie sicher, dass die Sicherheitsgruppe den Zugriff auf die Ports 6379 und 6380 zulässt: ElastiCache Serverless verwendet den 6379-Port für den primären Endpunkt und den 6380-Port für den Leser-Endpunkt. Einige Clients stellen für jede neue Verbindung eine Verbindung zu beiden Ports her, auch wenn Ihre Anwendung die Funktion „Aus Replikat lesen“ nicht verwendet. Wenn Ihre Sicherheitsgruppe keinen eingehenden Zugriff auf beide Ports zulässt, kann der Verbindungsaufbau länger dauern. Erfahren Sie hier mehr darüber, wie Sie den Portzugriff einrichten.

Fehlerbehebung bei serverseitiger Latenz

Einige Schwankungen und gelegentliche Spitzenwerte sollten keinen Anlass zur Sorge geben. Wenn die Average Statistik jedoch einen starken Anstieg zeigt und anhält, sollten Sie im AWS Health Dashboard und in Ihrem Personal Health Dashboard nach weiteren Informationen suchen. Falls erforderlich, erwägen Sie, einen Support-Fall mit zu eröffnen. AWS Support

Ziehen Sie die folgenden bewährten Methoden und Strategien zur Reduzierung der Latenz in Betracht:

• Read from Replica aktivieren: Wenn Ihre Anwendung dies zulässt, empfehlen wir, die Funktion „Read from Replica“ in Ihrem Redis OSS-Client zu aktivieren, um Lesevorgänge zu skalieren und eine geringere Latenz zu erreichen. Wenn diese Option aktiviert ist, versucht ElastiCache Serverless, Ihre Leseanfragen an Replikat-Cache-Knoten weiterzuleiten, die sich in derselben Availability Zone (AZ) wie Ihr Client befinden, wodurch AZ-übergreifende Netzwerklatenz vermieden wird. Beachten Sie, dass die Aktivierung der Funktion „Aus Replikat lesen“ in Ihrem Client bedeutet, dass Ihre Anwendung eine eventuelle Datenkonsistenz akzeptiert. Ihre Anwendung empfängt möglicherweise für einige Zeit ältere Daten, wenn Sie versuchen, sie zu lesen, nachdem Sie in einen Schlüssel geschrieben haben.

• Stellen Sie sicher, dass Ihre Anwendung in denselben AZs wie Ihr Cache bereitgestellt wird: Möglicherweise stellen Sie eine höhere clientseitige Latenz fest, wenn Ihre Anwendung nicht in denselben AZs wie Ihr Cache bereitgestellt wird. Wenn Sie einen serverlosen Cache erstellen, können Sie die Subnetze angeben, von denen aus Ihre Anwendung auf den Cache zugreift, und ElastiCache Serverless erstellt VPC-Endpunkte in diesen Subnetzen. Stellen Sie sicher, dass Ihre Anwendung in denselben AZs bereitgestellt wird. Andernfalls kann es bei Ihrer Anwendung beim Zugriff auf den Cache zu einem AZ-übergreifenden Hop kommen, was zu einer höheren clientseitigen Latenz führt.

• Verbindungen wiederverwenden: ElastiCache Serverlose Anfragen werden über eine TLS-fähige TCP-Verbindung unter Verwendung des RESP-Protokolls gestellt. Das Initiieren der Verbindung (einschließlich der Authentifizierung der Verbindung, falls konfiguriert) nimmt Zeit in Anspruch, sodass die Latenz der ersten Anfrage höher als üblich ist. Anfragen über eine bereits initialisierte Verbindung sorgen für eine gleichbleibend niedrige ElastiCache Latenz. Aus diesem Grund sollten Sie die Verwendung von Verbindungspooling oder die Wiederverwendung vorhandener Redis OSS-Verbindungen in Betracht ziehen.

• Skalierungsgeschwindigkeit: ElastiCache Serverless skaliert automatisch, wenn Ihre Anforderungsrate steigt. Ein plötzlicher starker Anstieg der Anforderungsrate, der schneller ist als die Geschwindigkeit, mit der ElastiCache Serverless skaliert, kann für einige Zeit zu einer erhöhten Latenz führen. ElastiCache Serverless kann die unterstützte Anforderungsrate in der Regel schnell erhöhen. Es dauert bis zu 10 bis 12 Minuten, bis sich die Anforderungsrate verdoppelt.

• Inspizieren Sie Befehle mit langer Laufzeit: Einige Redis OSS-Befehle, einschließlich Lua-Skripten oder Befehle für große Datenstrukturen, können lange laufen. ElastiCache Veröffentlicht Metriken auf Befehlsebene, um diese Befehle zu identifizieren. Mit ElastiCache Serverless können Sie die BasedECPUs Metriken verwenden.

• Gedrosselte Anfragen: Wenn Anfragen in ElastiCache Serverless gedrosselt werden, kann es zu einem Anstieg der clientseitigen Latenz in Ihrer Anwendung kommen. Wenn Anfragen in Serverless gedrosselt werden, sollten Sie einen ElastiCache Anstieg der Serverless-Metrik feststellen. ThrottledRequests ElastiCache Im folgenden Abschnitt finden Sie Informationen zur Behebung gedrosselter Anfragen.

• Gleichmäßige Verteilung von Schlüsseln und Anfragen: In ElastiCache (Redis OSS) kann eine ungleichmäßige Verteilung von Schlüsseln oder Anfragen pro Steckplatz zu einem Hot-Slot führen, was zu einer erhöhten Latenz führen kann. ElastiCache Serverless unterstützt bis zu 30.000 ECPUs/Sekunde (90.000 ECPUS/Sekunde bei Verwendung von Read from Replica) auf einem einzigen Steckplatz in einem Workload, der einfache SET/GET-Befehle ausführt. Wir empfehlen, Ihre Schlüssel- und Anforderungsverteilung auf die Slots zu überprüfen und für eine gleichmäßige Verteilung zu sorgen, falls Ihre Anforderungsrate diese Grenze überschreitet.

Behebung von Drosselungsproblemen in Serverless ElastiCache

In serviceorientierten Architekturen und verteilten Systemen wird die Begrenzung der Geschwindigkeit, mit der API-Aufrufe durch verschiedene Servicekomponenten verarbeitet werden, als Drosselung bezeichnet. Dadurch werden Leistungsspitzen geglättet, Abweichungen im Komponentendurchsatz vermieden und bei unerwarteten Betriebsereignissen besser vorhersehbare Wiederherstellungen ermöglicht. ElastiCache Serverless wurde für diese Art von Architekturen entwickelt, und die meisten Redis OSS-Clients verfügen über integrierte Wiederholungsversuche für gedrosselte Anfragen. Ein gewisses Maß an Drosselung ist nicht zwangsläufig ein Problem für Ihre Anwendung. Eine anhaltende Drosselung eines latenzsensitiven Teils des Datenworkflows kann sich jedoch negativ auf die Benutzererfahrung auswirken und die allgemeine Effizienz des Systems beeinträchtigen.

Wenn Anfragen in Serverless gedrosselt werden, sollten Sie einen Anstieg der ElastiCache Serverless-Metrik feststellen. ThrottledRequests ElastiCache Wenn Sie eine hohe Anzahl gedrosselter Anfragen feststellen, sollten Sie Folgendes beachten:

• Skalierungsgeschwindigkeit: ElastiCache Serverless wird automatisch skaliert, wenn Sie mehr Daten aufnehmen oder Ihre Anforderungsrate erhöhen. Wenn Ihre Anwendung schneller skaliert als die Geschwindigkeit, mit der Serverless skaliert, werden Ihre Anfragen möglicherweise gedrosselt, während ElastiCache Serverless an Ihre Arbeitslast angepasst wird. ElastiCache ElastiCache Serverless kann die Speichergröße in der Regel schnell erhöhen. Es dauert bis zu 10 bis 12 Minuten, bis sich die Speichergröße in Ihrem Cache verdoppelt hat.

• Gleichmäßige Verteilung von Schlüsseln und Anfragen: In ElastiCache (Redis OSS) kann eine ungleichmäßige Verteilung von Schlüsseln oder Anfragen pro Steckplatz zu einem Hot-Slot führen. Ein Hot-Slot kann zu einer Drosselung von Anfragen führen, wenn die Anforderungsrate für einen einzelnen Steckplatz 30.000 ECPUS/Sekunde übersteigt, und das bei einer Arbeitslast, die einfache SET/GET-Befehle ausführt.

• Aus Replikat lesen: Wenn Ihre Anwendung dies zulässt, sollten Sie in Erwägung ziehen, die Funktion „Aus Replikat lesen“ zu verwenden. Die meisten Redis OSS-Clients können so konfiguriert werden, dass sie Lesevorgänge“ skalieren „, sodass Lesevorgänge direkt an Replikatknoten weitergeleitet werden. Mit dieser Funktion können Sie den Lesetraffic skalieren. Darüber hinaus leitet ElastiCache Serverless automatisch Lesevorgänge von Replikatanfragen an Knoten weiter, die sich in derselben Availability Zone wie Ihre Anwendung befinden, was zu einer geringeren Latenz führt. Wenn Read from Replica aktiviert ist, können Sie für Workloads mit einfachen SET/GET-Befehlen bis zu 90.000 ECPUS/Sekunde auf einem einzigen Steckplatz erreichen.

Verwandte Themen

• Zusätzliche Schritte zur Fehlerbehebung

• ElastiCache Best Practices und Caching-Strategien