Comment résoudre les problèmes de latence élevée sur les clusters DynamoDB Accelerator (DAX) ?

Solution

Plusieurs raisons peuvent expliquer la latence de vos demandes. Reportez-vous à chacun des problèmes potentiels ci-dessous pour résoudre votre problème de latence.

Le cluster ou le nœud est soumis à une charge élevée

La latence est souvent causée par un cluster ou un nœud soumis à une charge élevée sur le cluster DAX. Cette latence peut être encore plus affectée si votre client est configuré sur une URL de nœud unique au lieu de l'URL du cluster. Dans ce cas, si le nœud rencontre un problème lors d'une charge élevée, les demandes du client souffrent d'une latence ou d'une limitation.

Pour remédier à la latence et à la limitation causées par une charge élevée sur des clusters ou des nœuds individuels, utilisez la mise à l'échelle horizontale ou la mise à l'échelle verticale.

Mauvaise configuration dans le client DAX

Si vous réduisez le paramètre withMinIdleConnectionSize, la latence au sein du cluster DAX est susceptible d'augmenter. Ce paramètre définit le nombre minimum de connexions inactives avec le cluster DAX. Pour chaque demande, le client utilisera une connexion inactive disponible. Si aucune connexion n'est disponible, le client en établit une nouvelle. Par exemple, si le paramètre est défini sur 20, il existe au moins 20 connexions inactives avec le cluster DAX.

Le client gère un pool de connexions. Lorsqu'une application lance un appel d'API à DynamoDB ou DAX, le client loue une connexion à partir du pool de connexions. Ensuite, le client effectue l'appel d'API et renvoie la connexion au pool. Toutefois, le pool de connexions a une limite supérieure. Si vous effectuez simultanément un grand nombre d'appels d'API à DAX, ils risquent de dépasser la limite du pool de connexions. Dans ce cas, certaines demandes doivent attendre la fin des autres demandes avant d'obtenir des baux auprès du pool de connexions. Cela entraîne la mise en file d'attente des demandes au niveau du pool de connexions. En conséquence, l'application connaît une augmentation de la latence aller-retour.

Par conséquent, pour réduire les pics de trafic périodiques dans votre application, ajustez les paramètres setMinIdleConnectionSize, getMinIdleConnectionSize et withMinIdleConnectionSize. Ces paramètres jouent un rôle clé dans la latence d'un cluster DAX. Configurez-les pour vos appels d'API afin que DAX utilise un nombre approprié de connexions inactives sans avoir à rétablir de nouvelles connexions.

Éléments manquants dans le cache

Si une demande de lecture manque un élément, DAX envoie la demande à DynamoDB. DynamoDB traite les demandes en utilisant des lectures éventuellement cohérentes, puis renvoie les éléments à DAX. DAX les stocke dans le cache des éléments, puis les renvoie à l'application. La latence dans la table DynamoDB sous-jacente peut entraîner une latence dans la demande.

Les erreurs de cache se produisent souvent pour deux raisons :

1.    Lectures très cohérentes : les lectures fortement cohérentes pour le même élément ne sont pas mises en cache par DAX. Cela entraîne un échec du cache, car les entrées contournent DAX et sont extraites de la table DynamoDB elle-même. Vous pouvez utiliser des lectures éventuellement cohérentes pour résoudre ce problème, mais notez que DynamoDB doit d'abord lire les données pour qu’elles soient mises en cache.

2.    Politique d'expulsion dans DAX : les données demandées qui ont déjà été supprimées du cache sont manquantes. DAX utilise trois valeurs différentes pour déterminer les expulsions du cache :

• Les clusters DAX utilisent un algorithme LRU (Least Recently Used) pour hiérarchiser les éléments. Les éléments ayant la priorité la plus faible sont supprimés lorsque le cache est plein.
• DAX utilise une valeur TTL (Time-to-Live) pour la période pendant laquelle les éléments sont disponibles dans le cache. Lorsque la valeur TTL d'un élément est dépassée, l'élément est expulsé.
  Remarque : Si vous utilisez la valeur TTL par défaut de cinq minutes, vérifiez si vous interrogez les données après la durée TTL.
• DAX utilise la fonctionnalité d'écriture directe pour supprimer les anciennes valeurs au fur et à mesure que de nouvelles valeurs sont écrites. Ainsi, les éléments du cache de DAX restent cohérents avec le magasin de données sous-jacent lors de l'utilisation d'un appel d'API.

Pour étendre la valeur TTL de vos éléments, consultez la section Configuration des paramètres TTL.
Remarque : Vous ne pouvez pas modifier un groupe de paramètres lorsqu'il est utilisé dans une instance DAX en cours d'exécution.

Des erreurs de cache peuvent également survenir lorsque des correctifs de maintenance sont appliqués à un cluster DAX. Utilisez plusieurs clusters de nœuds pour réduire ces temps d'arrêt.

Fenêtres de maintenance

La latence peut se produire pendant la fenêtre de maintenance hebdomadaire, surtout s'il y a des mises à niveau logicielles, des correctifs ou des changements de système sur les nœuds du cluster. Dans la plupart des cas, les demandes sont traitées avec succès par d'autres nœuds disponibles qui ne sont pas en cours de maintenance. Un cluster qui reçoit un nombre élevé de demandes lors d'une maintenance intensive peut connaître une défaillance.

Pour réduire les risques de latence ou de panne, configurez la fenêtre de maintenance en fonction de vos heures creuses. Cela permet au cluster de se mettre à niveau pendant une période de faible charge de demandes.

Latence dans la table DynamoDB

Avec les opérations d'écriture, les données sont d'abord écrites dans la table DynamoDB, puis dans le cluster DAX. L'opération n'est réussie que si les données sont correctement écrites à la fois dans la table et dans DAX. La latence dans la table DynamoDB sous-jacente peut entraîner une latence dans la demande. Pour réduire cette latence, consultez la section Comment puis-je résoudre un problème de latence élevée sur une table Amazon DynamoDB ?

Pour mieux configurer DynamoDB en fonction des exigences de latence de votre application, consultez la section Réglage des paramètres de requête HTTP du kit AWS Java SDK pour les applications Amazon DynamoDB sensibles à la latence.

Délai d'expiration de la demande

Le paramètre setIdleConnectionTimeout détermine le délai d'expiration des connexions inactives, et setConnectTimeout détermine le délai d'expiration des connexions au cluster DAX. Ces deux paramètres concernent les délais d'expiration des pools de connexions, qui peuvent affecter la latence de votre cluster.

Configurez le délai d'expiration des demandes pour les connexions avec le cluster DAX en ajustant le paramètre setRequestTimeout. Pour plus d'informations, consultez setRequestTimeout dans la documentation DAX.

Il est également recommandé d'utiliser des tentatives de backoff exponentiel, ce qui réduit les erreurs de demande et les coûts opérationnels.

Remarque : DAX ne prend pas en charge la latence du cluster dans CloudWatch Metrics.

---