Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Étapes de dépannage courantes et meilleures pratiques avec ElastiCache
Les rubriques suivantes fournissent des conseils de résolution des erreurs et des problèmes que vous pourriez rencontrer lors de l'utilisation ElastiCache. Si vous trouvez un problème qui n'est pas répertorié ici, vous pouvez utiliser le bouton de commentaires de cette page pour le signaler.
Pour obtenir des conseils de dépannage supplémentaires et des réponses aux questions d'assistance les plus courantes, consultez le centre de AWS connaissances
Rubriques
Problèmes de connexion
Si vous ne parvenez pas à vous connecter à votre ElastiCache cache, envisagez l'une des solutions suivantes :
Utilisation TLS : si votre connexion est bloquée lorsque vous essayez de vous connecter à votre ElastiCache terminal, il se peut que vous ne l'utilisiez pas TLS dans votre client. Si vous utilisez ElastiCache Serverless, le chiffrement en transit est toujours activé. Assurez-vous que votre client utilise TLS pour se connecter au cache. En savoir plus sur la connexion à un cache TLS activé.
VPC: ElastiCache les caches ne sont accessibles que depuis unVPC. Assurez-vous que l'EC2instance à partir de laquelle vous accédez au cache et le ElastiCache cache sont créés dans la même instanceVPC. Vous devez également activer le VPCpeering entre l'VPCendroit où réside votre EC2 instance et l'VPCendroit où vous créez votre cache.
Groupes de sécurité : ElastiCache utilise des groupes de sécurité pour contrôler l'accès à votre cache. Éléments à prendre en compte :
Assurez-vous que le groupe de sécurité utilisé par votre ElastiCache cache autorise l'accès entrant à celui-ci depuis votre EC2 instance. Cliquez ici pour savoir comment configurer correctement les règles de trafic entrant dans votre groupe de sécurité.
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 Valkey ou RedisOSS. Pour en savoir plus sur la configuration de l'accès aux ports, cliquez ici.
Si la connexion continue d'être difficile, consultez Problèmes de connexion persistants les autres étapes.
Erreurs du client Valkey ou Redis OSS
ElastiCache Le mode Serverless n'est accessible qu'à l'aide de clients prenant en charge le protocole en mode OSS cluster Valkey ou Redis. Les clusters conçus par nos soins sont accessibles depuis les clients dans l'un ou l'autre mode, en fonction de la configuration du cluster.
Si vous rencontrez des erreurs dans votre client, tenez compte des points suivants :
Mode cluster : si vous rencontrez CROSSLOT des erreurs ou des erreurs avec la SELECT
commande, vous essayez peut-être d'accéder à un cache activé en mode cluster avec un OSS client Valkey ou Redis qui ne prend pas en charge le protocole Cluster. ElastiCache Serverless ne prend en charge que les clients qui prennent en charge le protocole de cluster Valkey ou RedisOSS. Si vous souhaitez utiliser Valkey ou Redis OSS en « Mode cluster désactivé » (CMD), vous devez concevoir votre propre cluster. CROSSLOTerreurs : si vous rencontrez l'
ERR CROSSLOT Keys in request don't hash to the same sloterreur, 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 concernant la configuration des OSS clients Valkey ou Redis, 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 OSS client Valkey ou Redis 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 inter-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 au même endroit AZs que votre cache : vous pouvez observer une latence plus élevée côté client si votre application n'est pas déployée au même AZs endroit 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 VPC points de terminaison dans ces sous-réseaux. Assurez-vous que votre application est déployée dans le même environnementAZs. 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 TCP connexion TLS activée utilisant le RESP protocole. 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 Valkey ou 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 Valkey ou Redis, notamment OSS 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
BasedECPUsmé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 Valkey et RedisOSS, 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 ECPUs €/seconde (90 000 ECPUs €/seconde lors de l'utilisation de Read from Replica) sur un seul emplacement, dans une charge de travail qui exécute des commandes/simples. 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 API appels sont traités par les différents composants du service est appelée régulation. 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 OSS clients Valkey ou Redis 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 : le mode ElastiCache sans serveur évolue automatiquement à mesure que vous ingérez de nouvelles données ou que vous augmentez le taux de demandes. Si votre application évolue plus rapidement que la vitesse à laquelle le mode ElastiCache sans serveur évolue, vos demandes peuvent être limitées tandis ElastiCache que le mode sans serveur é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 : ElastiCache avec Valkey ou RedisOSS, 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 débit de demandes pour un seul emplacement dépasse 30 000 ECPUs €/seconde, dans une charge de travail qui exécute des commandes simples/. SET GET
Lire depuis une réplique : si votre application le permet, pensez à utiliser la fonction « Lire depuis une réplique ». La plupart des OSS clients Valkey ou Redis 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 la lecture depuis les 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 ECPUs €/seconde sur un seul emplacement, pour les charges de travail utilisant de simples SET commandes/. GET
Rubriques connexes
