Résolution des problèmes de latence dans Amazon DynamoDB

Si votre charge de travail semble présenter une latence élevée, vous pouvez analyser la CloudWatch SuccessfulRequestLatency métrique et vérifier la latence moyenne pour voir si elle est liée à DynamoDB. Une certaine variabilité dans le SuccessfulRequestLatency est normale, et les pics occasionnels (en particulier dans la statistique Maximum) ne devraient pas être problématiques. Toutefois, si la statistique Average indique une forte augmentation et persiste, vous devez vérifier le tableau de bord de santé du service AWS et votre Tableau de bord d'état personnel pour plus d'informations. Parmi les causes possibles, citons la taille de l'élément de votre table (un élément de 1 Ko et un élément de 400 Ko varient en termes de latence) ou la taille de la requête (10 éléments contre 100).

Si nécessaire, envisagez d'ouvrir un dossier de support auprès de AWS Support et continuez à évaluer toutes les options de repli disponibles pour votre application (par exemple, l'évacuation d'une région si vous disposez d'une architecture multirégion) en fonction de vos runbooks. Vous devez enregistrer les identifiants de demande pour les demandes lentes de fourniture de ces identifiants AWS Support lorsque vous ouvrez un dossier d'assistance.

La métrique SuccessfulRequestLatency mesure uniquement la latence interne au service DynamoDB. L'activité côté client et les temps de connexion au réseau ne sont pas inclus. Pour en savoir plus sur la latence globale des appels de votre client vers le service DynamoDB, vous pouvez activer la journalisation des métriques de latence dans votre SDK AWS.

Note

Pour la plupart des opérations singleton (opérations qui s'appliquent à un seul élément en spécifiant entièrement la valeur de la clé primaire), DynamoDB fournit Average SuccessfulRequestLatency avec une milliseconde à un chiffre. Cette valeur n'inclut pas la surcharge de transport pour le code de l'appelant accédant au point de terminaison DynamoDB. Pour les opérations de données comportant plusieurs éléments, la latence varie en fonction de facteurs tels que la taille du jeu de résultats, la complexité des structures de données renvoyées et les expressions de condition et de filtre appliquées. Pour les opérations multi-éléments répétées sur le même ensemble de données avec les mêmes paramètres, DynamoDB fournit Average SuccessfulRequestLatency avec une cohérence élevée.

Envisagez l'une ou plusieurs des stratégies suivantes pour réduire la latence :

• Ajustez le délai des demandes et le comportement des nouvelles tentatives : le chemin entre votre client et DynamoDB passe par de nombreux composants, chacun étant conçu dans une optique de redondance. Pensez à l'étendue de la résilience du réseau, aux délais des paquets TCP et à l'architecture distribuée de DynamoDB elle-même. Les comportements par défaut du SDK sont conçus pour trouver le bon équilibre pour la plupart des applications. Si la meilleure latence possible est votre priorité absolue, vous devez envisager de régler le délai de demande par défaut et les paramètres de nouvelles tentatives pour votre SDK, afin de suivre de près la latence typique d'une demande réussie mesurée par votre client. Une demande qui prend beaucoup plus de temps que d'habitude a moins de chances d'aboutir. Vous pouvez faire une interruption immédiate et envoyer une nouvelle demande ; il est probable qu'elle emprunte un chemin différent et aboutisse rapidement. Gardez à l'esprit qu'un comportement trop agressif dans ces environnements peut présenter des inconvénients. Vous trouverez une discussion utile sur ce sujet dans la section Réglage des paramètres de demande HTTP du SDK Java AWS pour les applications Amazon DynamoDB sensibles à la latence.

• Réduisez la distance entre le client et le point de terminaison DynamoDB : si vous avez des utilisateurs répartis dans le monde entier, pensez à utiliser Tables globales : réplication multirégion avec DynamoDB. Les tables globales vous permettent de spécifier les régions AWS dans lesquelles vous voulez que la table soit disponible. La lecture de données à partir d'une réplique locale de tables globales peut réduire considérablement la latence pour vos utilisateurs. Pensez également à utiliser un point de terminaison de passerelle DynamoDB pour conserver le trafic de vos clients au sein de votre VPC.

• Utilisez la mise en cache : si votre trafic est intense en lectures, pensez à utiliser un service de mise en cache tel que Accélération en mémoire avec DynamoDB Accelerator (DAX). DAX est un service de cache en mémoire entièrement géré et hautement disponible pour DynamoDB, qui offre des performances jusqu'à 10 fois supérieures, de l'ordre de quelques millisecondes au lieu de quelques microsecondes, même lorsque le nombre de demandes s'élève à plusieurs millions par seconde.

• Réutilisez les connexions : les demandes DynamoDB sont effectuées via une session authentifiée dont la valeur par défaut est HTTPS. L'établissement de la connexion prend du temps, de sorte que la latence de la première demande est plus élevée que d'habitude. Les demandes effectuées via une connexion déjà initialisée garantissent la faible latence constante de DynamoDB. Pour cette raison, vous souhaiterez peut-être effectuer une demande GetItem de « maintien en vie » toutes les 30 secondes si aucune autre demande n'est faite, afin d'éviter la latence liée à l'établissement d'une nouvelle connexion.

• Utilisez des lectures éventuellement cohérentes : si votre application ne nécessite pas de lectures fortement cohérentes, pensez à utiliser les lectures éventuellement cohérentes par défaut. Les lectures éventuellement cohérentes sont moins coûteuses et sont également moins susceptibles de connaître des augmentations transitoires de la latence. Pour plus d'informations, consultez Cohérence en lecture.