Comment puis-je résoudre les problèmes de latence élevée sur une table Amazon DynamoDB ?

Brève description

La latence de bout en bout implique une responsabilité partagée entre la latence côté service de DynamoDB et la latence côté client de l'utilisateur.

La métrique SuccessfulRequestLatency mesure uniquement le temps nécessaire à DynamoDB pour traiter intégralement la requête d'API. DynamoDB ne mesure pas le temps nécessaire à l'application pour se connecter au point de terminaison DynamoDB ou pour télécharger les résultats depuis le point de terminaison.

Résolution

Lorsque vous analysez la latence, il est recommandé de vérifier la latence moyenne et non les valeurs de latence maximale. Des pics de latence occasionnels sont normaux. Si la latence moyenne est élevée, il peut y avoir un problème sous-jacent.

Pour la plupart des opérations atomiques, telles que GetItem et PutItem, la latence moyenne est exprimée en millisecondes à un chiffre. La latence des opérations non atomiques, telles que Requête, Analyser, BatchGetItem et BatchWriteItem, dépend de nombreux facteurs. Ces facteurs incluent la taille du jeu de résultats, le nombre d'enregistrements insérés et la complexité des conditions et des filtres de requête.

Raisons courantes d'une latence élevée

Accès occasionnel

Pour éviter la latence, tous les hôtes frontend de DynamoDB gèrent des caches locaux. Lorsque le taux de requêtes est faible, les flottes frontend peuvent ne pas recevoir de requêtes pendant un certain temps et entraîner l'expiration de la durée de vie du cache (TTL). Si une requête arrive sur un hôte après l'expiration d'un cache, l'hôte doit obtenir des données à partir des composants internes de DynamoDB. L'hôte remplit le cache, puis il peut répondre. Le temps nécessaire pour obtenir et remplir les données peut entraîner une augmentation de la latence.

En cas de division d'une partition ou de changement de leadership, le cache peut devenir obsolète et entraîner une latence élevée lors des premiers appels. DynamoDB référence plusieurs caches pour récupérer les informations de partition, la validation de signature et d'autres informations relatives à chaque requête. Lorsque le taux de requêtes est faible, les caches ne restent pas à chaud et la latence est généralement plus élevée lors des premières requêtes.

Si les taux de requêtes sont élevés et que le trafic entrant est constant, chaque requête atteint régulièrement la flotte frontend et ne provoque aucun pic de latence. Pour éviter les problèmes liés à des accès occasionnels, demandez au client d'envoyer du trafic fictif vers la table DynamoDB.

Lectures à forte cohérence

Les opérations de lecture telles que GetItem, Requête et Analyser fournissent un paramètre ConsistentRead facultatif. Si vous définissez ConsisentRead sur vrai, DynamoDB renvoie une réponse contenant les données les plus récentes. Ces données reflètent les mises à jour de toutes les opérations d'écriture réussies précédentes, mais peuvent entraîner une latence plus élevée.

L'architecture DynamoDB comprend un nœud principal et deux nœuds de réplication dans une partition. DynamoDB utilise le nœud principal pour traiter les requêtes de lecture à forte cohérence, mais ne gère pas les réplicas en lecture. Dans la mesure où DynamoDB doit localiser le nœud principal puis rediriger la requête vers le service, vous pouvez constater une certaine latence.

Si votre application ne nécessite pas de lectures à forte cohérence, utilisez éventuellement des lectures cohérentes.

Moyens de réduire la latence

Réduire les paramètres de délai d'attente des requêtes

Réglez les paramètres du SDK client requestTimeOut et clientExecutionTimeout afin qu'ils expirent et échouent beaucoup plus rapidement, par exemple après 50 millisecondes. Ce délai plus court amène le client à abandonner les requêtes à latence élevée après une période donnée. Puis, le client envoie une deuxième requête qui se termine généralement beaucoup plus rapidement que la première. Pour plus d'informations, consultez la section Optimisation des paramètres de requête HTTP du kit SDK Java AWS pour applications Amazon DynamoDB sensibles à la latence.

Réduire la distance entre le client et le point de terminaison DynamoDB

Si vos utilisateurs sont dispersés dans le monde entier, utilisez des tables globales pour spécifier les régions AWS dans lesquelles vous souhaitez que la table soit disponible. Vous pouvez également utiliser les points de terminaison de passerelle DynamoDB pour éviter le trafic sur Internet.

Utiliser la mise en cache

Si la lecture de votre trafic est intensive, utilisez un service de mise en cache pour réduire la latence, tel qu'Amazon DynamoDB Accelerator (DAX).

Réutilisation de connexions

Lorsque vous établissez une nouvelle connexion, vous devez l'authentifier et la valider. De plus, avant de pouvoir traiter la requête, DynamoDB doit obtenir les métadonnées de la table depuis les systèmes internes. La flotte frontend de DynamoDB gère un cache utilisé pour stocker ces informations. Si les connexions sont réutilisées, le cache est utilisé pour traiter les requêtes.

Étant donné que les requêtes DynamoDB destinées aux utilisateurs d'AWS Key Management Service (AWS KMS) nécessitent un saut supplémentaire pour être authentifiées, vous pouvez constater une augmentation de la latence. Les clés AWS KMS sont actualisées toutes les 5 minutes. Si une connexion client n'est pas réutilisée, une nouvelle connexion TCP doit être établie pour chaque requête. Les connexions pour ces requêtes incluent des processus tels qu’une liaison TCP et un accusé de réception, et contribuent à la latence côté client.

L'authentification étant requise pour chaque nouvelle connexion, les caches ne sont pas utilisés et entraînent une latence côté serveur. Pour réutiliser les connexions, utilisez le paramètre TCP keep-alive. Utilisez également un modèle de conception qui garantit une seule instance de l'objet de connexion. Pour plus d'informations, consultez la page Client AWS non réutilisé dans une fonction Lambda sur le site Web d’Amazon CloudGuru.

Informations connexes

SuccessfulRequestLatency

Comprendre la latence d'Amazon DynamoDB

Bonnes pratiques en matière d'interrogation et d'analyse de données