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 subir une latence élevée, vous pouvez analyser la métrique SuccessfulRequestLatency CloudWatch et vérifier la latence moyenne et la latence médiane à l’aide de métriques de percentiles (p50) pour voir si cela est lié à 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 statistique Average ou p50 (médiane) indique une forte augmentation et persiste, vous devez consulter le tableau de bord de l’intégrité des services AWS et le tableau de bord de l’état 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 percentile personnalisées (telles que p99,9), vous pouvez saisir manuellement le percentile souhaité (par exemple, p99,9) dans le champ de statistique de métrique 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.

Certaines variations des métriques de latence, en particulier en ce qui concerne les percentiles les plus élevés, sont attendues et peuvent être le résultat d’opérations en arrière-plan pilotées par DynamoDB qui aident à maintenir une disponibilité et une durabilité élevées pour les données stockées dans des tables DynamoDB, ou de problèmes passagers d’infrastructure.

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 journaliser les ID de demande pour les demandes lentes pour la fourniture de ces ID à AWS Support lorsque vous ouvrez un cas de support.

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 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 :

  • 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 en savoir plus, consultez 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 Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications.

  • 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. Les tables globales vous permettent de répliquer votre table dans les régions AWS spécifiées dans lesquelles vous voulez qu’elle 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 Utilisation des tables globales Amazon DynamoDB dans Recommandations 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 :

    • DynamoDB Accelerator (DAX) : 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 à quelques microsecondes, même lorsque le nombre de demandes s’élève à plusieurs millions par seconde. Pour plus d’informations sur DAX, consultez Accélération en mémoire avec DynamoDB Accelerator (DAX) :

    • Amazon ElastiCache : service de cache en mémoire entièrement géré qui peut être intégré à DynamoDB pour améliorer les performances de lecture à l’aide du modèle de cache secondaire. Pour plus d’informations, consultez Integrating Amazon DynamoDB and Amazon ElastiCache by using read-through caching dans Recommandations AWS.