View a markdown version of this page

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

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 et la latence médiane à l'aide de métriques en centiles (p50) pour voir si elles sont liées à DynamoDB. Une certaine variabilité dans la SuccessfulRequestLatency signalée est normale. Les pics occasionnels (en particulier dans la statistique Maximum et les percentiles élevés) ne devraient pas être problématiques. Toutefois, si la Average statistique ou la valeur p50 (médiane) montre une forte augmentation et persiste, vous devriez consulter le Tableau de bord de l'état des AWS services et votre Tableau de bord de santé personnel pour plus d'informations. Parmi les causes possibles, citons la taille de l’élément de la table (un élément de 1 Ko et un élément de 400 Ko varient en matière de latence) ou la taille de la requête (10 éléments contre 100).

Les métriques de percentiles (p99, p90, etc.) peuvent vous aider à mieux comprendre la distribution de la latence. Par exemple :

  • p50 (médiane) indique la latence typique de la charge de travail.

  • p90 indique que 90 % des demandes sont plus rapides que cette valeur.

  • p99 permet d’identifier les pires cas de latence affectant 1 % des demandes.

Des valeurs de p99 élevées avec des valeurs de p50 normales peuvent indiquer des problèmes sporadiques affectant une petite partie des demandes, tandis que des valeurs de p50 constamment élevées peuvent suggérer une certaine dégradation des performances.

Note

Pour analyser des valeurs de centile personnalisées (telles que p99,9), vous pouvez saisir manuellement le percentile souhaité (par exemple, p99,9) dans le champ de statistiques métriques. CloudWatch Cela vous permet d’évaluer les distributions de latence au-delà des percentiles par défaut répertoriés dans la liste déroulante.

Une certaine variation des mesures de latence, en particulier dans les percentiles les plus élevés, est attendue et peut être observée en raison d'opérations en DynamoDB-driven arrière-plan qui contribuent à maintenir une disponibilité et une durabilité élevées pour vos données stockées dans des tables DynamoDB ou de problèmes d'infrastructure transitoires.

Si nécessaire, envisagez d'ouvrir un dossier de support auprès AWS Support de votre application et continuez à évaluer les options de repli disponibles pour votre application (comme l'évacuation d'une région si votre architecture est multirégionale) en fonction de vos runbooks. AWS Support Lorsque vous ouvrez un dossier d'assistance, vous devez enregistrer les ID de demande pour les demandes lentes visant à fournir ces identifiants.

La métrique SuccessfulRequestLatency mesure uniquement la latence interne au service DynamoDB. L’activité côté client et les temps de parcours du 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 l'enregistrement des métriques de latence dans votre AWS SDK.

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 :

  • Réutilisez les connexions : les demandes DynamoDB sont effectuées par l’intermédiaire d’une session authentifiée via HTTPS par défaut. L’établissement de la connexion nécessite plusieurs allers-retours et prend du temps, de sorte que la latence de la première demande est plus élevée que celle des demandes suivantes qui réutilisent la connexion. Les demandes effectuées via une connexion déjà initialisée garantissent la faible latence constante de DynamoDB. Pour éviter la surcharge de latence liée à l’établissement de nouvelles connexions, vous pouvez mettre en œuvre un mécanisme « keep-alive » en envoyant une demande GetItem toutes les 30 secondes si aucune autre demande n’est faite.

  • 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 cohérentes à terme ont un coût moins élevé et peuvent provenir de plusieurs zones de disponibilité. Cela permet de sélectionner une zone de disponibilité colocalisée avec le demandeur, ce qui réduit le temps de latence. Pour de plus amples informations, veuillez consulter Cohérence en lecture DynamoDB.

  • Mettez en œuvre la couverture des demandes : pour des exigences de latence très faible de p99, envisagez de mettre en œuvre une couverture des demandes. Avec la couverture des demandes, si la demande initiale ne reçoit pas de réponse assez rapidement, envoyez une deuxième demande équivalente et laissez-les courir, la première réponse l’emporte. Cela améliore la latence de queue au prix de quelques demandes supplémentaires. Vous pouvez décider du temps d’attente avant l’envoi de la deuxième demande. La couverture est plus facile pour les lectures. Pour les écritures, utilisez un ordre basé sur l’horodatage pour garantir que les demandes couvertes sont traitées comme ayant eu lieu au moment de la première tentative, afin d’éviter les mises à jour hors ordre. Cette approche a été décrite dans Timestamp writes for write hedging in Amazon DynamoDB.

  • Ajustez le délai d’attente des demandes et le comportement des nouvelles tentatives : le chemin entre le client et DynamoDB passe par de nombreux composants, chacun étant conçu dans une optique de redondance. Tenez compte des aspects suivants :

    • Résilience du réseau

    • Délais d’expiration des paquets TCP

    • Architecture distribuée de DynamoDB

    Les comportements par défaut du kit SDK sont optimisés pour la plupart des applications. Toutefois, vous pouvez mettre en œuvre une stratégie d’interruption immédiate et ajuster les paramètres de délai d’expiration. Les demandes qui prennent beaucoup plus de temps que d’habitude ont moins de chances d’aboutir en fin de compte. En procédant à une interruption immédiate et à une nouvelle tentative, vous pouvez rapidement réussir en empruntant un chemin différent. Cela équivaut à la couverture des demandes, mais met fin à la première demande au lieu de l’autoriser à se poursuivre.

    Évitez de définir des valeurs de délai d’expiration trop basses. Des délais d’expiration trop bas peuvent entraîner des problèmes de disponibilité induits par le client. Par exemple, un délai d’expiration de socket de 50 millisecondes peut provoquer des erreurs de connexion lors des pics de latence du réseau, par exemple à l’approche des limites de bande passante d’instance Amazon EC2 pour le trafic à flux unique. Évaluez soigneusement les avantages de délais d’expiration plus bas par rapport aux risques potentiels pour la disponibilité des applications, et préférez la couverture à des délais d’expiration courts.

    Pour une discussion utile sur ce sujet, consultez la section Réglage des paramètres de requête HTTP du SDK AWS Java 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 multi-active, multirégion. Avec les tables globales, vous pouvez répliquer votre tableau dans des AWS régions spécifiques dans lesquelles vous souhaitez que le tableau soit disponible. Vous pouvez placer une copie des données plus près de l’utilisateur final afin de réduire la latence du réseau lors des opérations de lecture et d’écriture. Pour plus d'informations sur l'utilisation efficace des tables globales DynamoDB, consultez la section Utilisation des tables globales Amazon DynamoDB dans Prescriptive Guidance. AWS

  • Utilisez la mise en cache : si le trafic nécessite beaucoup de lecture, envisagez d’utiliser un des services de mise en cache suivants :