Pourquoi mon cluster ElastiCache autogéré inclut-il une métrique « Allocation de réseau dépassée » ?

Brève description

Lorsque la charge de travail d'application dépasse les capacités réseau du nœud ElastiCache sous-jacent, une régulation du trafic peut se produire. Pour suivre la régulation du trafic, utilisez les métriques suivantes :

• NetworkBandwidthInAllowanceExceeded et NetworkBandwidthOutAllowanceExceeded
• NetworkPacketsPerSecondAllowanceExceeded
• NetworkConntrackAllowanceExceeded

Résolution

NetworkBandwidthInAllowanceExceeded et NetworkBandwidthOutAllowanceExceeded

Les métriques NetworkBandwidthInAllowanceExceeded et NetworkBandwidthOutAllowanceExceeded suivent le nombre de paquets réseau régulés par ElastiCache lorsque le débit dépasse la limite de bande passante agrégée.

Lorsque vous examinez NetworkBandwidthInAllowanceExceeded et NetworkBandwidthOutAllowanceExceeded, vous devez également vérifier les métriques NetworkBytesIn et NetworkBytesOut dans Amazon CloudWatch. Lorsque les métriques d'utilisation de la bande passante CloudWatch NetworkBytesIn et NetworkBytesOut sont inférieures aux limites au niveau du nœud, les métriques de performance du réseau peuvent indiquer qu'ElastiCache a dépassé une limite. Pour plus d'informations, consultez la section Surveiller la bande passante de l'instance.

Remarque : De petites rafales de trafic peuvent entraîner une modification du trafic, même si votre bande passante moyenne se situe dans vos limites. Si des pics occasionnels sont observés dans ces métriques d'allocation de bande passante sans aucun effet sur l'application, aucune autre action n'est requise. Valkey et Redis OSS utilisant le protocole TCP, celui-ci retransmet les paquets abandonnés.

Si ces métriques d'allocation de bande passante sont systématiquement élevées et que votre application constate des problèmes de latence, examinez les horodatages des problèmes de latence. Si les horodatages d’erreurs correspondent aux heures des pics de métriques, augmentez la taille de votre cluster. Pour plus d'informations, consultez la section Mise à l’échelle de clusters conçus par vos soins.

Vérifiez également le type de nœud de cache pour le cluster. Si la charge de travail de l'application augmente systématiquement l'utilisation du réseau au-delà de la bande passante de base, il est possible que vous obteniez une régulation du trafic. Pour plus d'informations, consultez la section Bande passante d'instance disponible.

Remarque : Pour chaque octet qu'ElastiCache écrit sur le nœud primaire, ElastiCache réplique les mêmes informations sur tous les autres réplicas. Lorsque le cluster essaie de traiter le backlog de réplication, les clusters comportant de petits types de nœuds, des réplicas multiples et des demandes d'écriture intensives peuvent rencontrer des problèmes. Ce backlog peut entraîner des valeurs NetworkBandwidthOutAllowanceExceeded élevées sur les nœuds primaires.

Pour déterminer la cause d'un pic de métriques côté application, recherchez les commandes qui utilisent plusieurs touches. Cela inclut les exemples suivants :

• MGET
• RENCONTRÉ
• HGETALL

Si vous utilisez plusieurs clés de grande taille, telles que des objets JSON volumineux ou des valeurs de hachage, vous risquez de dépasser les limites de bande passante de votre type de nœud. ElastiCache supprime alors le trafic excédentaire ou l'ajoute à une file d'attente en fonction de la charge actuelle.

NetworkPacketsPerSecondAllowanceExceeded

Si cette métrique est une valeur différente de 0, cela signifie que l'utilisation du réseau sur les nœuds de cache sous-jacents a dépassé la limite de paquets par seconde (PPS). Cette limite est spécifique au type de nœud que vous utilisez. ElastiCache supprime ou met en file d'attente les paquets excédentaires qui dépassent la limite de nœuds.

Pour les applications qui génèrent un nombre élevé de requêtes par seconde (QPS) ou de petites requêtes, le nœud peut dépasser les limites PPS. Pour déterminer le taux d'exécution des commandes, utilisez les métriques CloudWatch pour chaque type de données Commande. Pour plus d'informations, consultez la section Métriques pour Valkey et Redis OSS.

Pour résoudre ce problème, vous pouvez temporairement augmenter verticalement le cluster à un type de nœud de plus grande taille. Si les opérations nécessitent beaucoup de lecture, vous pouvez ajouter d'autres réplicas en lecture au cluster ou à la partition pour répartir la charge. Pour les clusters activés en mode cluster (CME), si les opérations comprennent de lourdes tâches d’écriture, ajoutez d'autres partitions pour augmenter horizontalement le cluster.

Remarque : Pour les clusters désactivés en mode cluster (CMD), vous devez déplacer votre cluster vers un nœud de plus grande taille pour dimensionner les opérations d'écriture.

NetworkConntrackAllowanceExceeded

Si cette métrique est une valeur différente de 0, ElastiCache a dépassé le nombre maximal de connexions suivies dans tous les groupes de sécurité du nœud. Une fois la limite de connexion atteinte, les nouvelles connexions échouent jusqu'à ce qu'ElastiCache ferme les connexions existantes. Pour plus d'informations, consultez la section Suivi des connexions aux groupes de sécurité Amazon Elastic Compute Cloud (Amazon EC2).

Lorsque les charges de travail créent un grand nombre de connexions réseau et que vous ne fermez pas correctement les connexions, celles-ci restent ouvertes côté serveur. Ces connexions restent inactives et entraînent l'épuisement de conntrack. ElastiCache ne peut alors pas accepter de nouvelles connexions tant qu'ElastiCache n'a pas fermé les connexions existantes.

Pour résoudre ce problème dans ElastiCache, utilisez le paramètre délai d’expiration pour vérifier et modifier le délai d'inactivité de la connexion. Configurez le paramètre afin que le serveur ElastiCache ferme les connexions après une période d'inactivité.

Pour résoudre ce problème côté application, utilisez les paramètres du pool de connexions pour réutiliser les connexions existantes et réduire le taux de nouvelles connexions (NewConnections). Pour plus d’informations, consultez la section Bonnes pratiques : Clients Redis et Amazon ElastiCache for Redis.

Remarque : Le paramètre délai d’expiration côté serveur et les paramètres du Groupe de connexions côté client gèrent l'établissement de la connexion et nécessitent des tests de charge depuis l'application. Testez la charge de votre application afin de déterminer la configuration optimale pour les paramètres de délai d’expiration et de groupe de connexions.

Informations connexes

Surveillance de l'utilisation avec Métriques CloudWatch

Mise à l’échelle d'ElastiCache

Réseau

Paramètres Redis OSS 2.6.13

Les métriques de performance du réseau au niveau de l'instance Amazon EC2 révèlent de nouvelles informations