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 percentiles (p50) pour voir si elles sont liées à DynamoDB. Une certaine variabilité des données signalées SuccessfulRequestLatency est normale, et les pics occasionnels (en particulier en ce qui concerne les Maximum statistiques et les percentiles élevés) ne devraient pas être préoccupants. Toutefois, si la Average statistique ou p50 (médiane) indique une forte augmentation et persiste, vous devriez consulter le AWS Service Health Dashboard et votre Personal Health Dashboard 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 éléments).

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

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

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

  • p99 permet d'identifier le pire des cas de latence affectant 1 % des demandes.

Des valeurs p99 élevées avec des valeurs p50 normales peuvent indiquer des problèmes sporadiques affectant une petite partie des demandes, tandis que des valeurs 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 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.

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 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 secours disponibles pour votre application (comme l'évacuation d'une région si vous avez une architecture multirégionale) en fonction de vos runbooks. Vous devez enregistrer les demandes lentes IDs pour les IDs fournir AWS Support lorsque vous ouvrez un dossier d'assistance.

La SuccessfulRequestLatency métrique mesure uniquement la latence interne au service DynamoDB ; l'activité côté client et les temps de trajet 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éutilisation des connexions : les requêtes DynamoDB sont effectuées via une session authentifiée via HTTPS par défaut. L'établissement de la connexion nécessite plusieurs allers-retours et prend du temps. La latence de la première demande est donc 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 le temps de latence lié à l'établissement de nouvelles connexions, vous pouvez implémenter un mécanisme de « maintien en vie » en envoyant une GetItem demande 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. À terme, les lectures cohérentes sont moins coûteuses et peuvent provenir de plusieurs zones de disponibilité, ce qui 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 de lecture DynamoDB.

  • Mettre en œuvre la couverture des demandes : pour des exigences de latence p99 très faibles, 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-la courir, la première réponse l'emporte. Cela améliore la latence de queue au prix de quelques requêtes supplémentaires. Vous pouvez décider du temps d'attente avant d'envoyer la deuxième demande. Le hedging est plus facile à lire. Pour les écritures, utilisez un ordre basé sur l'horodatage pour garantir que les demandes couvertes sont traitées comme s'étant produites au moment de la première tentative, empêchant ainsi les mises à jour. out-of-order Cette approche a été décrite dans Timestamp writing for write hedging in Amazon DynamoDB.

  • Ajustez le délai d'expiration 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 un souci 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 SDK sont optimisés pour la plupart des applications. Cependant, vous pouvez mettre en œuvre une stratégie d'échec rapide 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 échouant rapidement et en réessayant, vous pouvez rapidement réussir sur une autre voie. Cela est similaire à 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 faibles. Des délais d'attente trop courts peuvent entraîner des problèmes de disponibilité induits par le client. Par exemple, un délai d'expiration du socket de 50 millisecondes peut provoquer des erreurs de connexion lors des pics de latence du réseau, par exemple lorsque l'on approche des limites de bande passante des EC2 instances Amazon pour le trafic à flux unique. Évaluez soigneusement les avantages d'une réduction des délais par rapport aux risques potentiels pour la disponibilité des applications, et préférez la couverture aux courts délais d'attente.

    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 multirégion avec DynamoDB. Avec les tables globales, vous pouvez répliquer votre table AWS dans les régions spécifiées dans lesquelles vous souhaitez 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 pendant les 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 les directives prescriptives. AWS

  • Utiliser la mise en cache : si votre trafic est dense en lecture, pensez à utiliser l'un des services de mise en cache suivants :