Pourquoi ma métrique de latence maximale d'Amazon DynamoDB est-elle élevée alors que la latence moyenne est normale ?

Solution

Lorsque vous analysez la métrique CloudWatch SuccessfulRequestLatency, c'est une bonne pratique de vérifier la latence moyenne. La latence maximale ne donne pas une idée de la latence globale de votre table DynamoDB. Au lieu de cela, elle montre le temps maximum pris par une seule demande au cours de cette période. Par exemple, si vous avez 100 demandes sur une table DynamoDB en même temps, même si 99 demandes prennent 10 ms et qu'une seule demande prend 100 ms, la métrique de latence maximale est de 100 ms.

DynamoDB est un système de distribution à grande échelle, avec des milliers de nœuds dans la flotte de backend. Ainsi, une table DynamoDB peut avoir plusieurs partitions dans le tablespace, et chaque partition possède plusieurs copies dans la flotte de backend. Lorsque vous effectuez un appel d'API à DynamoDB, le point de terminaison du service DynamoDB reçoit votre appel, puis l'achemine vers l'un des nœuds backend pour traitement. Lorsque l'appel est traité avec succès, DynamoDB achemine les résultats vers votre client.

Dans la plupart des cas, l'appel d'API est traité avec succès en une seule tentative, et vous observez une faible latence du côté client. Mais, parfois, la première tentative échoue si le nœud backend subit l'une des conditions suivantes :

• Une période chargée
• Basculement
• Fractionnement de partition
• Problèmes de connectivité

Dans ces cas-là, la première tentative échoue dans un délai d'attente côté serveur (5000 ms). Ensuite, le serveur réessaie automatiquement l'appel d'API sur un autre nœud, souvent plusieurs fois. Le serveur renvoie le résultat à votre client lorsque l'appel d'API est traité avec succès. Lorsque cela se produit, vous observez une latence élevée pour cette demande particulière. Ainsi, une métrique de latence maximale élevée n'est généralement pas une cause d'inquiétude. Si le service DynamoDB observe une latence élevée constante à partir d'un nœud, le service supprime automatiquement ce composant de la flotte de backend. Vous pouvez observer un niveau élevé de latence pour un certain pourcentage d'appels d'API lorsque la panne localisée mentionnée précédemment se produit du côté du service. Cela se traduit par un niveau élevé de SuccessfulRequestLatency maximum dans les métriques CloudWatch pour les tables DynamoDB correspondantes. Pour cette raison, les échecs localisés peuvent augmenter votre latence maximale, mais vous ne devez prendre aucune mesure pour contrôler cet échec.

Cependant, vous pouvez configurer votre application pour qu'elle réagisse rapidement en effectuant une interruption immédiate avec une nouvelle tentative de backoff exponentiel. Cela signifie que la nouvelle demande arrive au nouveau nœud et que vous obtenez des résultats plus rapides. Pour plus d'informations, consultez Réglage des paramètres de demande HTTP du kit AWS Java SDK pour les applications Amazon DynamoDB prenant en charge la latence.

Informations connexes

Comment résoudre les problèmes liés à la latence élevée sur une table Amazon DynamoDB ?

Journalisation des métriques de latence