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 liés aux erreurs internes du serveur dans Amazon DynamoDB
Dans DynamoDB, les erreurs internes du serveur (erreurs 500) indiquent que le service n’est pas en mesure de traiter la demande. Ces erreurs peuvent survenir pour diverses raisons, telles que des problèmes passagers de réseau dans la flotte, des problèmes d’infrastructure, des problèmes liés aux nœuds de stockage, etc.
Il est possible que vous rencontriez des erreurs internes du serveur pendant le cycle de vie de la table DynamoDB. Cela est attendu en raison de la nature distribuée du service et ne devrait généralement pas être une source de préoccupation. DynamoDB répare et résout automatiquement tout problème passager lié au service en temps réel, sans aucune intervention de votre part. Toutefois, si vous observez un nombre constamment élevé d’erreurs internes du serveur lors des demandes adressées à la table (comme le montre la métrique SystemErrors), vous devriez poursuivre votre examen.
Rubriques
Examen des erreurs internes du serveur
Si vous rencontrez des erreurs internes du serveur dans la table DynamoDB, envisagez les options suivantes :
Consultez le tableau de bord AWS Health.
Pour identifier le problème, la première étape consiste à consulter le tableau de bord de l’intégrité des services AWS
et le tableau de bord de l’état du compte AWS. Ces tableaux de bord fournissent des informations précieuses sur les problèmes rencontrés à l’échelle du service, les tables concernées, les problèmes constants et leur cause racine une fois le problème résolu. L’examen des informations contenues dans ces tableaux de bord vous permettra de mieux comprendre le statut actuel des Services AWS que vous utilisez et les éventuels problèmes affectant votre compte. Ces informations peuvent vous aider à déterminer les prochaines étapes pour résoudre le problème et minimiser les perturbations de vos opérations.
Contactez le Support.
Si vous observez des erreurs prolongées et persistantes dans vos demandes, cela peut indiquer un problème avec le service. En règle générale, si vous constatez un taux d’échec global de 1 % ou plus au cours des 15 dernières minutes, c’est le moment idéal pour faire remonter le problème à l’équipe d’AWS Support. Consultez le contrat de niveau de service DynamoDB
pour en savoir plus. Lorsque vous ouvrez un cas auprès de l’équipe d’AWS Support, fournissez les informations suivantes pour accélérer le processus de résolution des problèmes :
-
DDB concerné ; tables ou index secondaires
-
Période pendant laquelle les erreurs ont été observées
-
ID de demande DynamoDB, tels que
4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG, disponibles dans les journaux des applications.
L’inclusion de ces informations dans le cas de support aidera l’équipe AWS à comprendre le problème et à le résoudre plus rapidement. Si vous n’avez pas les ID de demande, vous devez tout de même journaliser le cas avec les autres informations disponibles.
-
Minimisation de l’impact des erreurs internes du serveur
Si des erreurs internes du serveur se produisent lors de l’utilisation de DynamoDB, minimisez leur impact sur votre application. Prenez en compte les bonnes pratiques suivantes :
-
Utilisez les backoffs et les nouvelles tentatives : les comportements par défaut du kit SDK de DynamoDB sont conçus pour trouver le bon équilibre pour la plupart des applications en termes de backoff et de stratégie de nouvelle tentative. Vous pouvez toutefois ajuster ces paramètres en fonction de la tolérance de votre application à la durée d’indisponibilité et de ses exigences de performance. En savoir plus sur les backoffs et les nouvelles tentatives pour comprendre comment optimiser ces paramètres de nouvelle tentative.
-
Utilisez des lectures cohérentes à terme : si votre application ne nécessite pas de lectures fortement cohérentes, envisagez d’utiliser des lectures cohérentes à terme. Ces lectures sont moins coûteuses et moins susceptibles de rencontrer des problèmes passagers en raison d’erreurs internes du serveur, car elles seraient effectuées à partir de n’importe quel nœud de stockage disponible. Pour en savoir plus, consultez Cohérence en lecture DynamoDB.
Amélioration de la conscience opérationnelle
Le maintien de la haute disponibilité et de la fiabilité de vos applications est crucial dans le paysage numérique actuel. L’un des principaux aspects de cette approche est la surveillance proactive des erreurs internes du serveur (ISE) dans les tables DynamoDB et les index secondaires globaux (GSI). En créant des alarmes CloudWatch pour surveiller ces erreurs, vous pouvez acquérir une meilleure conscience opérationnelle et être alerté des problèmes potentiels avant qu’ils n’affectent vos utilisateurs finaux. Cette approche est conforme au pilier Excellence opérationnelle du cadre AWS Well-Architected, garantissant ainsi que votre charge de travail DynamoDB est optimisée en termes de performances, de sécurité et de fiabilité.
Création d’alarmes CloudWatch
Vous devez configurer des alarmes CloudWatch sur vos tables DynamoDB pour recevoir des notifications en cas de nombre constamment élevé d’erreurs internes du serveur au lieu d’observer les métriques manuellement. Cela est lié au pilier Excellence opérationnelle du cadre Well-Architected pour toutes les charges de travail sur AWS. Consultez Utilisation du cadre DynamoDB Well-Architected pour optimiser votre charge de travail DynamoDB pour en savoir plus sur la bonne conception d’architecture des tables DynamoDB.
Ces alarmes utilisent des mathématiques de métriques personnalisées pour calculer le pourcentage de demandes ayant échoué pour une fenêtre de 5 minutes. La bonne pratique recommandée consiste à configurer l’alarme pour qu’elle entre dans l’état ALARM lorsque 3 points de données consécutifs dépassent le seuil de 1 %, ce qui signifie qu’au total 1 % des demandes échouent dans un délai de 15 minutes.
L’exemple ci-dessous est un modèle CloudFormation qui peut vous aider à créer des alarmes CloudWatch sur votre table et des GSI sur la table.
AWSTemplateFormatVersion: "2010-09-09" Description: Sample template for monitoring DynamoDB Parameters: DynamoDBProvisionedTableName: Description: Name of DynamoDB Provisioned Table to create Type: String MinLength: 3 MaxLength: 255 ConstraintDescription : https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#limits-naming-rules DynamoDBSNSEmail: Description : Email Address subscribed to newly created SNS Topic Type: String AllowedPattern: "^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$" MinLength: 1 MaxLength: 255 Resources: DynamoDBMonitoringSNSTopic: Type: AWS::SNS::Topic Properties: DisplayName: DynamoDB Monitoring SNS Topic Subscription: - Endpoint: !Ref DynamoDBSNSEmail Protocol: email TopicName: dynamodb-monitoring DynamoDBTableSystemErrorAlarm: Type: 'AWS::CloudWatch::Alarm' Properties: AlarmName: 'DynamoDBTableSystemErrorAlarm' AlarmDescription: 'Alarm when system errors exceed 1% of total number of requests for 15 minutes' AlarmActions: - !Ref DynamoDBMonitoringSNSTopic Metrics: - Id: 'e1' Expression: 'm1/(m1+m2+m3)' Label: SystemErrorsOverTotalRequests - Id: 'm1' MetricStat: Metric: Namespace: 'AWS/DynamoDB' MetricName: 'SystemErrors' Dimensions: - Name: 'TableName' Value: !Ref DynamoDBProvisionedTableName Period: 300 Stat: 'SampleCount' Unit: 'Count' ReturnData: False - Id: 'm2' MetricStat: Metric: Namespace: 'AWS/DynamoDB' MetricName: 'ConsumedReadCapacityUnits' Dimensions: - Name: 'TableName' Value: !Ref DynamoDBProvisionedTableName Period: 300 Stat: 'SampleCount' Unit: 'Count' ReturnData: False - Id: 'm3' MetricStat: Metric: Namespace: 'AWS/DynamoDB' MetricName: 'ConsumedWriteCapacityUnits' Dimensions: - Name: 'TableName' Value: !Ref DynamoDBProvisionedTableName Period: 300 Stat: 'SampleCount' Unit: 'Count' ReturnData: False EvaluationPeriods: 3 Threshold: 1.0 ComparisonOperator: 'GreaterThanThreshold' DynamoDBGSISystemErrorAlarm: Type: 'AWS::CloudWatch::Alarm' Properties: AlarmName: 'DynamoDBGSISystemErrorAlarm' AlarmDescription: 'Alarm when GSI system errors exceed 2% of total number of requests for 15 minutes' AlarmActions: - !Ref DynamoDBMonitoringSNSTopic Metrics: - Id: 'e1' Expression: 'm1/(m1+m2+m3)' Label: GSISystemErrorsOverTotalRequests - Id: 'm1' MetricStat: Metric: Namespace: 'AWS/DynamoDB' MetricName: 'SystemErrors' Dimensions: - Name: 'TableName' Value: !Ref DynamoDBProvisionedTableName - Name: 'GlobalSecondaryIndexName' Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ] Period: 300 Stat: 'SampleCount' Unit: 'Count' ReturnData: False - Id: 'm2' MetricStat: Metric: Namespace: 'AWS/DynamoDB' MetricName: 'ConsumedReadCapacityUnits' Dimensions: - Name: 'TableName' Value: !Ref DynamoDBProvisionedTableName - Name: 'GlobalSecondaryIndexName' Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ] Period: 300 Stat: 'SampleCount' Unit: 'Count' ReturnData: False - Id: 'm3' MetricStat: Metric: Namespace: 'AWS/DynamoDB' MetricName: 'ConsumedWriteCapacityUnits' Dimensions: - Name: 'TableName' Value: !Ref DynamoDBProvisionedTableName - Name: 'GlobalSecondaryIndexName' Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ] Period: 300 Stat: 'SampleCount' Unit: 'Count' ReturnData: False EvaluationPeriods: 3 Threshold: 1.0 ComparisonOperator: 'GreaterThanThreshold'
