Diagnostic de l'étranglement - Amazon DynamoDB
Comprendre les exceptions de limitationCadre de diagnostic

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.

Diagnostic de l'étranglement

Lorsque votre application est confrontée à une limitation, DynamoDB fournit des informations détaillées sur les exceptions et des CloudWatch mesures ciblées pour vous aider à diagnostiquer ces événements.

Cette section présente une approche systématique pour comprendre les événements de régulation dans vos applications DynamoDB. Il explique comment interpréter les exceptions de régulation, les corréler avec des CloudWatch métriques pour obtenir des informations plus approfondies et comprendre les modifications susceptibles de réduire la régulation dans vos applications DynamoDB.

Comprendre les exceptions de limitation

Lorsque DynamoDB limite une demande, il renvoie des exceptions spécifiques avec des informations de diagnostic détaillées. Par exemple, en Java, ceux-ci incluent ProvisionedThroughputExceededExceptionRequestLimitExceeded, ouThrottlingException.

Chaque exception inclut ThrottlingReasons une collection de personnes ThrottlingReason contenant deux champs clés pour vous aider à identifier et à comprendre la régulation :

  • Une raison : un champ concaténé suivant le format <ResourceType><OperationType><LimitType>

  • Un ARN de ressource : le nom de ressource Amazon (ARN) de la table ou de l'index concerné

Le champ Motif suit un schéma cohérent qui vous aide à comprendre exactement ce qui se passe :

  • ResourceType(Qu'est-ce qui est limité) : ou Table Index

  • OperationType(Quel type d'opération) : Read ou Write

  • LimitType(Pourquoi l'étranglement s'est produit) :

    • KeyRangeThroughputExceeded: Cela se produit lorsqu'une partition spécifique qui sauvegarde votre table ou votre index a consommé une capacité de lecture ou d'écriture dépassant les limites de débit internes par partition.

    • ProvisionedThroughputExceeded: Cela se produit sur une table provisionnée ou un index secondaire global lorsque le taux de consommation en lecture ou en écriture a dépassé le montant provisionné.

    • AccountLimitExceeded: Cela se produit sur une table ou un index à la demande lorsque le taux de consommation en lecture ou en écriture a dépassé le taux de consommation maximal pour une table et ses index tel que défini au niveau du compte. Vous pouvez demander une augmentation de ce quota.

    • MaxOnDemandThroughputExceeded: Cela se produit sur une table ou un index à la demande lorsque le taux de consommation en lecture ou en écriture a dépassé le taux de consommation maximal indiqué par l'utilisateur configuré pour la table ou l'index. Vous pouvez vous-même augmenter cette valeur jusqu'à n'importe quelle valeur jusqu'à la limite du compte ou la définir sur -1 pour indiquer qu'aucune limite n'est spécifiée par l'utilisateur.

L'ARN de la ressource identifie exactement la table ou l'index qui est limité :

  • Pour les tables : arn:aws:dynamodb:[region]:[account-id]:table/[table-name]

  • Pour les index : arn:aws:dynamodb:[region]:[account-id]:table/[table-name]/index/[index-name]

Exemples de raisons d'étranglement complet :

  • TableReadProvisionedThroughputExceeded

  • IndexWriteAccountLimitExceeded

Cela permet d'identifier exactement quelle ressource est limitée, quel type d'opération en est la cause et pourquoi cette limitation s'est produite.

Exemples d'exceptions

Exemple 1 : capacité allouée dépassée sur un GSI

{
    "ThrottlingReasons": [
        {
            "reason": "IndexWriteProvisionedThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders/index/OrderDateIndex"
        }
    ],
    "awsErrorDetails": {
        "errorCode": "ProvisionedThroughputExceeded",
        "errorMessage": "The level of configured provisioned throughput for the index was exceeded",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}

Dans cet exemple, l'application reçoit un ProvisionedThroughputExceededException avec le motifIndexWriteProvisionedThroughputExceeded. Les écritures sur le OrderDateIndex sont limitées car la consommation d'écriture a dépassé la capacité d'écriture provisionnée configurée du GSI.

Exemple 2 : Dépassement du débit maximal à la demande

{
    "ThrottlingReasons": [
        {
            "reason": "TableReadMaxOnDemandThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-east-1:123456789012:table/UserSessions"
        }
    ],
    "awsErrorDetails": {
        "errorMessage": "Throughput exceeds the maximum OnDemandThroughput configured on table or index",
        "errorCode": "ThrottlingException",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}

Dans cet exemple, les lectures de la UserSessions table sont limitées car elles dépassent la limite de débit maximale à la demande configurée sur la table.

Cadre de diagnostic de la limitation DynamoDB

Lorsque votre application est confrontée à un ralentissement, procédez comme suit pour diagnostiquer et résoudre le problème.

Étape 1 - Analyser les ThrottlingReason détails

  1. Vérifiez le champ Motif pour identifier la raison précise de l'étranglement. La raison détaille le type de ressource limitée (table ou index), le type d'opération à l'origine de l'événement de limitation (lecture ou écriture) et le type de limite dépassé (partition, débit provisionné, limite de compte).

  2. Vérifiez le champ ResourceArn pour identifier la ressource (table ou GSI) qui est limitée.

  3. Utilisez ces informations combinées pour comprendre le contexte complet du problème de régulation.

    Par exemple, imaginez ce scénario dans lequel vous recevez l'ProvisionedThroughputExceededExceptionexception suivante pour une raison de limitation. TableWriteKeyRangeThroughputExceeded Le ResourceArn concerné est. arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders

    Cette combinaison vous indique que les opérations d'écriture dans votre CustomerOrders table sont limitées. La régulation se produit au niveau de la partition (et non au niveau de la table, qui s'afficherait sous la formeTableWriteProvisionedThroughputExceeded). La cause principale est que vous avez dépassé la capacité de débit maximale pour une valeur ou une plage de clés de partition spécifique, ce qui indique un problème de partition non résolu.

    Comprendre cette relation entre les éléments d'exception vous aide à mettre en œuvre la stratégie d'atténuation appropriée. Dans ce cas, il s'agit de remédier à la partition active plutôt que d'augmenter la capacité globale provisionnée de la table.

Étape 2 - Identifier et analyser les CloudWatch métriques associées

  1. Identifiez vos mesures : chaque raison de limitation dans DynamoDB correspond directement à des CloudWatch mesures spécifiques que vous pouvez surveiller pour suivre et analyser les événements de régulation. Vous pouvez systématiquement dériver les noms de CloudWatch métriques appropriés en fonction de la raison de la limitation.

  2. Associez la raison de votre limitation aux CloudWatch indicateurs correspondants à l'aide de ce tableau de référence :

    Raisons complètes de la régulation et référence des métriques CloudWatch
    Catégorie Raison de l'étranglement CloudWatch Indicateurs principaux
    Capacité allouée dépassée TableReadProvisionedThroughputExceeded ReadProvisionedThroughputThrottleEvents
    TableWriteProvisionedThroughputExceeded WriteProvisionedThroughputThrottleEvents
    IndexReadProvisionedThroughputExceeded ReadProvisionedThroughputThrottleEvents (GSI)
    IndexWriteProvisionedThroughputExceeded WriteProvisionedThroughputThrottleEvents (GSI)
    Limites de partition dépassées TableReadKeyRangeThroughputExceeded ReadKeyRangeThroughputThrottleEvents
    TableWriteKeyRangeThroughputExceeded WriteKeyRangeThroughputThrottleEvents
    IndexReadKeyRangeThroughputExceeded ReadKeyRangeThroughputThrottleEvents (GSI)
    IndexWriteKeyRangeThroughputExceeded WriteKeyRangeThroughputThrottleEvents (GSI)
    Dépassement du maximum sur demande TableReadMaxOnDemandThroughputExceeded ReadMaxOnDemandThroughputThrottleEvents
    TableWriteMaxOnDemandThroughputExceeded WriteMaxOnDemandThroughputThrottleEvents
    IndexReadMaxOnDemandThroughputExceeded ReadMaxOnDemandThroughputThrottleEvents (GSI)
    IndexWriteMaxOnDemandThroughputExceeded WriteMaxOnDemandThroughputThrottleEvents (GSI)
    Limites de compte dépassées TableReadAccountLimitExceeded ReadAccountLimitThrottleEvents
    TableWriteAccountLimitExceeded WriteAccountLimitThrottleEvents
    IndexReadAccountLimitExceeded ReadAccountLimitThrottleEvents (GSIs)
    IndexWriteAccountLimitExceeded WriteAccountLimitThrottleEvents (GSIs)

    Par exemple, si vous avez reçuIndexWriteProvisionedThroughputExceeded, au minimum, vous devez surveiller la WriteProvisionedThroughputThrottleEvents CloudWatch métrique pour l'indice spécifique identifié dans leResourceArn.

  3. Surveillez ces indicateurs CloudWatch pour comprendre la fréquence et le calendrier des événements de limitation, différencier la régulation en lecture et en écriture, identifier les modèles temporels en cas d'augmentation de la régulation et suivre les tendances d'utilisation de vos capacités.

    DynamoDB publie des mesures détaillées pour chaque table et chaque index secondaire global. Les métriques (ReadThrottleEventsWriteThrottleEvents, etThrottledRequests) regroupent tous les événements de régulation de votre table et de ses index.

Étape 3 - Identifiez vos clés limitées et vos taux d'accès élevés à l'aide de CloudWatch Contributor Insights (pour la régulation liée aux partitions)

Si vous avez identifié des problèmes liés aux partitions à l'étape 1 (tels que KeyRangeThroughputExceeded des erreurs), CloudWatch Contributor Insights for DynamoDB peut vous aider à diagnostiquer les clés spécifiques qui génèrent votre trafic et sont confrontées à des événements de limitation dans votre table ou votre index.

  1. Activez CloudWatch Contributor Insights pour votre tableau ou index limité en fonction de votre. ResourceARN

    Vous pouvez choisir le mode touches limitées pour vous concentrer exclusivement sur les touches les plus limitées. Ce mode est idéal pour la surveillance continue car il ne traite les événements qu'en cas d'étranglement. Sinon, le mode touches accessibles et limitées vous permet de rechercher des modèles dans les touches les plus consultées.

  2. Analysez les rapports pour identifier les modèles problématiques. Recherchez les clés présentant des taux d'accès ou de limitation disproportionnés, établissez une corrélation entre la régulation et les modèles de trafic. Vous pouvez créer des tableaux de bord intégrés combinant des graphiques Contributor Insights et des métriques DynamoDB CloudWatch .

Pour obtenir des informations détaillées sur l'activation et l'utilisation de CloudWatch Contributor Insights, consultez la section Utilisation de CloudWatch Contributor Insights pour DynamoDB.

Étape 4 - Déterminer la solution appropriée

Après avoir diagnostiqué la cause spécifique de l'étranglement, mettez en œuvre la solution recommandée en fonction de votre contexte spécifique. La solution appropriée dépend de plusieurs facteurs, notamment de votre scénario de limitation, du mode de capacité de la table, des décisions de conception de la table et des clés, des modèles d'accès et de l'efficacité des requêtes, de la configuration des index globaux et secondaires, ainsi que de l'architecture globale du système et des points d'intégration.

Pour des solutions détaillées répondant à vos scénarios de régulation spécifiques, consultez la Guide de résolution de limitation de DynamoDB section. Cette ressource fournit des stratégies de correction ciblées adaptées à votre raison d'étranglement particulière et à la configuration du mode capacité.

Étape 5 - Suivez vos progrès

  1. Suivez vos CloudWatch indicateurs qui correspondent à votre scénario de régulation.

  2. Vérifiez l'efficacité de vos stratégies d'atténuation en observant une diminution des événements d'étranglement.