Étapes de dépannage courantes et meilleures pratiques

Problèmes de connexion

Si vous ne parvenez pas à vous connecter à votre ElastiCache cache, considérez l'une des solutions suivantes :

1. Utilisation du protocole TLS : si votre connexion est bloquée lorsque vous essayez de vous connecter à votre ElastiCache point de terminaison, il se peut que vous n'utilisiez pas le protocole TLS dans votre client. Si vous utilisez ElastiCache Serverless, le chiffrement en transit est toujours activé. Assurez-vous que votre client utilise le protocole TLS pour se connecter au cache. Pour en savoir plus sur la connexion à un cache compatible TLS, cliquez ici.

2. VPC : les ElastiCache caches ne sont accessibles que depuis un VPC. Assurez-vous que l'instance EC2 à partir de laquelle vous accédez au cache et le ElastiCache cache sont créés dans le même VPC. Vous devez également activer le peering VPC entre le VPC où réside votre instance EC2 et le VPC dans lequel vous créez votre cache.

3. Groupes de sécurité : ElastiCache utilise des groupes de sécurité pour contrôler l'accès à votre cache. Éléments à prendre en compte :

   1. Assurez-vous que le groupe de sécurité utilisé par votre ElastiCache cache autorise l'accès entrant à celui-ci depuis votre instance EC2. Cliquez ici pour savoir comment configurer correctement les règles de trafic entrant dans votre groupe de sécurité.

   2. Assurez-vous que le groupe de sécurité utilisé par votre ElastiCache cache autorise l'accès aux ports de votre cache (6379 et 6380 pour le mode sans serveur, et 6379 par défaut pour les ports conçus par vous-même). ElastiCache utilise ces ports pour accepter les commandes Redis OSS. Pour en savoir plus sur la configuration de l'accès aux ports, cliquez ici.

Erreurs du client Redis OSS

ElastiCache Le mode Serverless est uniquement accessible via les clients Redis OSS qui prennent en charge le protocole en mode cluster Redis OSS. Les clusters conçus par nos soins sont accessibles à partir des clients Redis OSS dans l'un ou l'autre mode, en fonction de la configuration du cluster.

Si vous rencontrez des erreurs Redis OSS sur votre client, tenez compte des points suivants :

1. Mode cluster : Si vous rencontrez des erreurs CROSSLOT ou des erreurs avec la commande SELECT Redis OSS, vous essayez peut-être d'accéder à un cache activé en mode cluster avec un client Redis OSS qui ne prend pas en charge le protocole Redis OSS Cluster. ElastiCache Serverless prend uniquement en charge les clients Redis OSS qui prennent en charge le protocole de cluster Redis OSS. Si vous souhaitez utiliser Redis OSS en mode « Cluster Disabled » (CMD), vous devez concevoir votre propre cluster.

2. Erreurs CROSSLOT : si vous rencontrez cette ERR CROSSLOT Keys in request don't hash to the same slot erreur, vous tentez peut-être d'accéder à des clés qui n'appartiennent pas au même emplacement dans un cache en mode cluster. Pour rappel, ElastiCache Serverless fonctionne toujours en mode cluster. Les opérations multiclés, les transactions ou les scripts Lua impliquant plusieurs clés ne sont autorisés que si toutes les clés impliquées se trouvent dans le même emplacement de hachage.

Pour connaître les meilleures pratiques supplémentaires relatives à la configuration des clients Redis OSS, veuillez consulter ce billet de blog.

Résolution des problèmes de latence élevée en mode ElastiCache Serverless

Si votre charge de travail semble présenter une latence élevée, vous pouvez analyser les SuccessfulWriteRequestLatency métriques CloudWatch SuccessfulReadRequestLatency et pour vérifier si la latence est liée au mode ElastiCache Serverless. Ces mesures mesurent la latence interne à ElastiCache Serverless. La latence côté client et les temps de trajet réseau entre votre client et le point de terminaison ElastiCache sans serveur ne sont pas inclus.

Résolution des problèmes de latence côté client

Si vous remarquez une latence élevée du côté client, mais aucune augmentation correspondante, CloudWatch SuccessfulReadRequestLatency et si SuccessfulWriteRequestLatency des mesures mesurent la latence côté serveur, tenez compte des points suivants :

• Assurez-vous que le groupe de sécurité autorise l'accès aux ports 6379 et 6380 : ElastiCache Serverless utilise le port 6379 pour le point de terminaison principal et le port 6380 pour le point de terminaison du lecteur. Certains clients établissent une connectivité aux deux ports pour chaque nouvelle connexion, même si votre application n'utilise pas la fonctionnalité Read from Replica. Si votre groupe de sécurité n'autorise pas l'accès entrant aux deux ports, l'établissement de la connexion peut prendre plus de temps. Pour en savoir plus sur la configuration de l'accès aux ports, cliquez ici.

Résolution des problèmes de latence côté serveur

Une certaine variabilité et des pics occasionnels ne devraient pas être une source de préoccupation. Toutefois, si les Average statistiques indiquent une forte augmentation et persistent, vous devriez consulter le Personal Health Dashboard AWS Health Dashboard et votre Personal Health Dashboard pour plus d'informations. Si nécessaire, pensez à ouvrir un étui de support avec AWS Support.

Tenez compte des meilleures pratiques et stratégies suivantes pour réduire le temps de latence :

• Activer la lecture depuis une réplique : si votre application le permet, nous vous recommandons d'activer la fonctionnalité « Lire depuis une réplique » dans votre client Redis OSS afin de dimensionner les lectures et de réduire la latence. Lorsqu'il est activé, ElastiCache Serverless tente d'acheminer vos demandes de lecture vers des nœuds de cache répliqués situés dans la même zone de disponibilité (AZ) que votre client, évitant ainsi la latence du réseau entre zones de disponibilité (AZ). Notez que l'activation de la fonctionnalité Read from Replica dans votre client signifie que votre application accepte une éventuelle cohérence des données. Votre application peut recevoir des données plus anciennes pendant un certain temps si vous essayez de les lire après avoir écrit sur une clé.

• Assurez-vous que votre application est déployée dans les mêmes zones de disponibilité que votre cache : vous pouvez observer une latence plus élevée côté client si votre application n'est pas déployée dans les mêmes zones de disponibilité que votre cache. Lorsque vous créez un cache sans serveur, vous pouvez fournir les sous-réseaux à partir desquels votre application va accéder au cache, et ElastiCache Serverless crée des points de terminaison VPC dans ces sous-réseaux. Assurez-vous que votre application est déployée dans les mêmes AZ. Dans le cas contraire, votre application risque de subir un saut cross-AZ lors de l'accès au cache, ce qui augmentera la latence côté client.

• Réutilisation des connexions : les demandes ElastiCache sans serveur sont effectuées via une connexion TCP compatible TLS à l'aide du protocole RESP. L'établissement de la connexion (y compris l'authentification de la connexion, si elle est configurée) prend du temps, de sorte que la latence de la première demande est supérieure à la normale. Les requêtes via une connexion déjà initialisée offrent une ElastiCache faible latence constante. Pour cette raison, vous devez envisager d'utiliser le regroupement de connexions ou de réutiliser les connexions Redis OSS existantes.

• Vitesse de mise à l'échelle : ElastiCache Serverless évolue automatiquement à mesure que votre taux de demandes augmente. Une augmentation soudaine et importante du taux de requêtes, plus rapide que la vitesse à laquelle ElastiCache Serverless évolue, peut entraîner une latence élevée pendant un certain temps. ElastiCache Les applications sans serveur peuvent généralement augmenter rapidement le taux de demandes prises en charge, ce qui prend jusqu'à 10 à 12 minutes pour doubler le taux de demandes.

• Inspectez les commandes de longue durée : certaines commandes Redis OSS, notamment les scripts Lua ou les commandes sur de grandes structures de données, peuvent s'exécuter pendant une longue période. Pour identifier ces commandes, ElastiCache publie des métriques au niveau des commandes. Avec ElastiCache Serverless, vous pouvez utiliser les BasedECPUs métriques.

• Demandes limitées : lorsque les demandes sont limitées en mode ElastiCache Serverless, vous pouvez constater une augmentation de la latence côté client dans votre application. Lorsque les demandes sont limitées dans ElastiCache Serverless, vous devriez constater une augmentation de la ThrottledRequests ElastiCache métrique Serverless. Consultez la section ci-dessous pour résoudre les problèmes liés aux demandes limitées.

• Distribution uniforme des clés et des demandes : dans ElastiCache (Redis OSS), une répartition inégale des clés ou des demandes par emplacement peut entraîner un hot slot, ce qui peut entraîner une latence élevée. ElastiCache Serverless prend en charge jusqu'à 30 000 ECPU/seconde (90 000 ECPU/seconde lors de l'utilisation de Read from Replica) sur un seul emplacement, dans une charge de travail qui exécute de simples commandes SET/GET. Nous vous recommandons d'évaluer la distribution de vos clés et de vos demandes entre les emplacements et de garantir une distribution uniforme si votre taux de demandes dépasse cette limite.

Résolution des problèmes de régulation dans Serverless ElastiCache

Dans les architectures orientées services et les systèmes distribués, la limitation de la vitesse à laquelle les appels d'API sont traités par les différents composants du service est appelée limitation. Cela atténue les pics, contrôle les incohérences dans le débit des composants et permet des restaurations plus prévisibles en cas d'événement opérationnel inattendu. ElastiCache Le mode Serverless est conçu pour ces types d'architectures, et la plupart des clients Redis OSS proposent des tentatives intégrées pour les demandes limitées. Un certain degré de limitation ne constitue pas nécessairement un problème pour votre application, mais la limitation persistante d'une partie sensible à la latence de votre flux de données peut avoir un impact négatif sur l'expérience utilisateur et réduire l'efficacité globale du système.

Lorsque les demandes sont limitées dans ElastiCache Serverless, vous devriez constater une augmentation de la ThrottledRequests ElastiCache métrique Serverless. Si vous constatez un nombre élevé de demandes limitées, tenez compte des points suivants :

• Vitesse de mise à l'échelle : ElastiCache Serverless évolue automatiquement à mesure que vous ingérez de plus en plus de données ou que vous augmentez le taux de demandes. Si votre application évolue plus rapidement que la vitesse à laquelle ElastiCache Serverless évolue, vos demandes peuvent être limitées tandis ElastiCache que Serverless évolue pour s'adapter à votre charge de travail. ElastiCache Le mode Serverless permet généralement d'augmenter rapidement la taille de stockage, en doublant la taille de stockage de votre cache en 10 à 12 minutes.

• Distribution uniforme des clés et des demandes : dans ElastiCache (Redis OSS), une répartition inégale des clés ou des demandes par emplacement peut entraîner un hot slot. Un hot slot peut entraîner une limitation du nombre de demandes si le taux de demandes adressées à un seul emplacement dépasse 30 000 ECPUS/seconde, dans une charge de travail qui exécute de simples commandes SET/GET.

• Lire depuis une réplique : si votre application le permet, pensez à utiliser la fonction « Lire depuis une réplique ». La plupart des clients Redis OSS peuvent être configurés pour « dimensionner les lectures » afin de diriger les lectures vers des nœuds de réplication. Cette fonctionnalité vous permet de dimensionner le trafic de lecture. En outre, ElastiCache Serverless achemine automatiquement les données lues à partir des demandes de réplication vers les nœuds situés dans la même zone de disponibilité que votre application, ce qui permet de réduire le temps de latence. Lorsque Read from Replica est activé, vous pouvez atteindre 90 000 ECPU/seconde sur un seul emplacement, pour les charges de travail utilisant de simples commandes SET/GET.

Rubriques connexes

• Étapes de dépannage supplémentaires

• ElastiCache meilleures pratiques et stratégies de mise en cache