3- Dépassement des limites de compte - Amazon DynamoDB
La limite du compte a dépassé les mesures d’atténuationTechniques courantes de diagnostic et de surveillanceProcédures de résolution

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.

3- Dépassement des limites de compte

Les tables à la demande ne disposent pas de niveaux de capacité provisionnée à gérer, mais DynamoDB applique des limites de débit au niveau du compte afin d’empêcher une exécution incontrôlée et d’assurer une utilisation équitable des ressources pour tous les clients. Ces limites de compte par table jouent le rôle de garanties ajustables et sont définies pour chaque combinaison de compte et de région. Lorsque votre taux de consommation en lecture ou en écriture dépasse ces limites, DynamoDB renvoie le type de raison de limitation AccountLimitExceeded dans l’exception de limitation. Les limites de compte par défaut par table s’appliquent automatiquement lorsqu’aucun paramètre de débit maximal personnalisé n’a été configuré pour les tables. Vous pouvez choisir de configurer des paramètres de débit maximal pour un meilleur contrôle des coûts et une meilleure prévisibilité, ou de demander des augmentations de quotas via la console Quotas dans Amazon DynamoDB si les exigences de votre application dépassent les limites par défaut.

La limite du compte a dépassé les mesures d’atténuation

Cette section fournit des conseils de résolution pour les scénarios de limitation par rapport aux limites du compte. Avant d’utiliser ce guide, assurez-vous d’avoir identifié les raisons spécifiques de la limitation liées à la gestion des exceptions par votre application et d’avoir déterminé l’Amazon Resource Name (ARN) de la ressource concernée. Pour en savoir plus sur la façon de déterminer les raisons de la limitation et d’identifier des ressources limitées, consultez Cadre de diagnostic des limitations DynamoDB.

Avant de vous lancer dans des scénarios de limitation spécifiques, déterminez si une action est réellement nécessaire :

  • Évaluez l’impact sur les performances : vérifiez si votre application répond toujours à ses exigences de performances malgré la limitation. De nombreuses applications fonctionnent sans problème lorsqu’elles s’approchent des limites du compte ou qu’elles les atteignent, notamment lors des opérations groupées ou des migrations de données.

  • Passez en revue les modèles récurrents de limitation : si la limitation est temporaire et que votre application gère les nouvelles tentatives de manière efficace, les limites actuelles peuvent suffire à votre charge de travail.

Si votre application fonctionne de manière acceptable même lorsque les limites du compte sont parfois atteintes, vous pouvez choisir de simplement suivre de plus près la situation plutôt que de mettre en œuvre des modifications immédiates.

Si vous déterminez que la limitation est à l’origine de problèmes de performances ou de fiabilité inacceptables, sélectionnez une raison de limitation spécifique ci-dessous pour déterminer les options d’atténuation recommandées :

TableReadAccountLimitExceeded

Quand cela se produit

La consommation en lecture de votre table a dépassé le quota de débit de lecture par table au niveau du compte pour votre région. Vous pouvez surveiller les CloudWatch métriques Techniques courantes de diagnostic et de surveillance pour analyser votre événement de régulation.

Étapes à suivre pour résoudre le problème

Procédez comme suit pour résoudre ce problème de limitation :

  • Demandez une augmentation des quotas :

    Demandez une augmentation de la limite de débit de lecture par table (code de quota CBE56 L-CF0). Pour connaître les étapes détaillées de soumission de cette demande, consultez Demande d’augmentation du quota par table.

TableWriteAccountLimitExceeded

Quand cela se produit

La consommation en écriture de votre table a dépassé le quota de débit d’écriture par table au niveau du compte pour votre région. Vous pouvez surveiller les CloudWatch métriques Techniques courantes de diagnostic et de surveillance pour analyser votre événement de régulation.

Étapes à suivre pour résoudre le problème

Procédez comme suit pour résoudre ce problème de limitation :

  • Demande d'augmentation du quota : demandez une augmentation de la limite de débit d'écriture par table (code de quota L-AB614373). Pour connaître les étapes détaillées de soumission de cette demande, consultez Demande d’augmentation du quota par table.

IndexReadAccountLimitExceeded

Quand cela se produit

Les opérations de lecture dirigées vers un index secondaire global (GSI) consomment plus de débit que ce que le quota de lecture par table de votre compte ne le permet dans votre région AWS actuelle. Le quota de débit de lecture par table au niveau du compte s'applique collectivement à une table et à toutes ses composantes combinées. GSIs Vous pouvez surveiller les CloudWatch métriques Techniques courantes de diagnostic et de surveillance pour analyser votre événement de régulation.

Étapes à suivre pour résoudre le problème

Choisissez la solution appropriée en fonction de la répartition de la capacité de votre compte :

IndexWriteAccountLimitExceeded

Quand cela se produit

Les opérations d'écriture dans votre table de base génèrent des mises à jour correspondantes d'un GSI qui dépassent collectivement le quota de débit d'écriture par table au niveau du compte pour votre région. AWS Chaque écriture dans un élément de table de base contenant des attributs indexés par un GSI déclenche une opération d’écriture correspondante dans ce GSI. Ces opérations d’écriture combinées sont prises en compte dans votre quota de débit d’écriture par table. Vous pouvez surveiller les CloudWatch métriques Techniques courantes de diagnostic et de surveillance afin d'analyser les modèles et le calendrier de ces événements de régulation et d'identifier les opérations à l'origine de l'activité d'écriture GSI excessive.

Étapes à suivre pour résoudre le problème

Choisissez la solution appropriée en fonction de la répartition de la capacité de votre compte :

  • Demande d'augmentation du quota : demandez une augmentation de la limite de débit d'écriture par table (code de quota L-AB614373) afin de répondre à l'augmentation du trafic d'écriture GSI provenant des opérations de table de base. Le quota de débit d'écriture par table s'applique à l'ensemble de la table, y compris à l'ensemble de celle-ci. GSIs Pour connaître les étapes détaillées de soumission de cette demande, consultez Demande d’augmentation du quota par table.

  • Optimisation des projections GSI : passez en revue les projections et la conception GSI afin de réduire le volume d'écriture à. GSIs

Techniques courantes de diagnostic et de surveillance

Lorsque vous résolvez les problèmes liés au dépassement de la limite du compte, plusieurs CloudWatch indicateurs peuvent vous aider à déterminer si vous atteignez des limites par table ou à l'échelle du compte et à comprendre vos modèles de distribution de capacité.

CloudWatch Indicateurs essentiels

Surveillez ces métriques clés pour diagnostiquer la limitation par rapport aux limites du compte :

  • Événements de limitation par rapport aux limites du compte : ReadAccountLimitThrottleEvents et WriteAccountLimitThrottleEvents suivent les demandes qui sont limitées en raison des limites définies au niveau du compte. ReadThrottleEvents et WriteThrottleEvents suivent les demandes de lecture ou d’écriture qui dépassent la capacité provisionnée.

  • Consommation de capacité par ressource : ConsumedReadCapacityUnits et ConsumedWriteCapacityUnits pour chaque table et GSI indique l’utilisation individuelle des ressources.

  • Consommation à l'échelle du compte : utilisez des expressions mathématiques CloudWatch métriques pour additionner la capacité consommée dans toutes les tables et GSIs pour surveiller l'utilisation totale du compte.

Procédures de résolution

Demande d’augmentation du quota par table

Si vos applications doivent fonctionner au-delà des limites de débit par table actuelles, vous devez soumettre une demande d’augmentation de quota en suivant la procédure ci-dessous. Chaque table DynamoDB de AWS votre compte (ainsi que toutes les tables GSIs associées) est soumise à ces quotas de débit dans une région spécifique. Ces quotas représentent la capacité maximale de lecture ou d'écriture que chaque table individuelle et sa batterie GSIs peuvent consommer collectivement, et ils s'appliquent indépendamment à chaque table plutôt que sous forme d'agrégat pour toutes les tables de votre compte.

Vous pouvez choisir de définir des limites inférieures par table ou par GSI en configurant leurs paramètres de débit maximal à la demande.

  1. Identifiez le quota spécifique qui doit être augmenté :

    • Limite de débit de lecture par table (code de quota L-CF0CBE56) : 40 000 par défaut par table RCUs

    • Limite de débit d'écriture par table (code de quota L-AB614373) : 40 000 WCUs par défaut par table

  2. Utilisez la console AWS Service Quotas pour demander une augmentation de quota :

    • Accédez au service DynamoDB dans Service Quotas

    • Recherchez le quota approprié à l’aide du code correspondant

    • Demandez une augmentation en fonction de votre pic d’utilisation prévu

  3. Justifiez l’augmentation, en fournissant par exemple les informations suivantes :

    • Schémas d’utilisation actuels et exigences relatives aux pics de trafic

    • Argumentaire justifiant l’augmentation de la capacité

    • Chronologie indiquant quand l’augmentation de la capacité est nécessaire

Note

Le traitement des augmentations de quotas dure généralement entre 24 et 48 heures. Planifiez vos demandes en conséquence et envisagez des stratégies d’atténuation temporaires en attendant leur approbation.

Optimisation des projections et de la conception des GSI

Optimisez les projections et la conception des index secondaires globaux (GSI) afin de réduire la consommation de capacité et d’améliorer les performances.

Stratégies de projection sélective

Si vos requêtes ne doivent accéder qu’à quelques attributs, la projection de ces seuls attributs réduit la quantité de données écrites dans le GSI lorsque les éléments de la table de base changent. Pour plus de détails sur les types de projection, consultez Projections for Global Secondary Indexes.

  1. Analysez les modèles de requêtes : passez en revue les modèles de requête de votre application pour identifier les attributs réellement utilisés via le GSI.

  2. Utilisez des projections sélectives : concentrez-vous uniquement sur les attributs de projet qui sont réellement nécessaires dans les requêtes pour réduire le volume d’écriture.

  3. Envisagez de n’utiliser que les clés (KEYS_ONLY) : si vos requêtes ne nécessitent que les attributs de clés, utilisez la projection KEYS_ONLY pour minimiser le volume d’écriture.

  4. Trouvez un juste milieu entre lecture et écriture : la projection d’un nombre réduit d’attributs réduit la consommation de la capacité d’écriture, mais peut nécessiter des lectures supplémentaires de la table de base.

Implémentation de GSI fragmentés

Sparse GSIs contient uniquement les éléments dotés de l'attribut indexé, plutôt que tous les éléments de votre table de base. Cela réduit la densité des partitions et améliore les performances lorsque vous interrogez fréquemment des sous-jeux de données spécifiques.

  1. Conception GSIs qui inclut uniquement des éléments dotés de valeurs d'attributs spécifiques.

  2. Implémentez l’indexation conditionnelle en ne définissant l’attribut de clé de partition des GSI que sur les éléments qui doivent être indexés.

  3. Utilisez des clés composites en mode sparse GSIs (par exemple, status #timestamp) pour mieux répartir le trafic au sein du sous-ensemble d'éléments indexés.

Pour plus d’informations sur la mise en œuvre de ces stratégies, consultez Bonnes pratiques d’utilisation d’index secondaires dans DynamoDB.