Introduction
Une tâche de commande invalide échoue chaque fois que le traitement l'exécute. Vous limiterez ses tentatives, la conserverez dans une file distincte pour investigation et confirmerez que les commandes valides aboutissent toujours.
Terminez d'abord Gérer le délai de visibilité et la nouvelle livraison et ses prérequis guidés. Cette VM indépendante fournit un traitement et une table de commandes vide ; les files, les messages et la connexion du consommateur sont votre travail.
Lien avec les certifications
Ce laboratoire propose une pratique des sujets d’examen suivants.
- Solutions Architect – Associate (SAA-C03) · Tâche 2.1: Traitement borné des messages et isolation des tâches en échec.
- Developer – Associate (DVA-C02) · Tâche 1.1: Traitement borné des messages et isolation des tâches en échec.
- DevOps Engineer – Professional (DOP-C02) · Tâche 5.1: Pratique des fondamentaux : Traitement borné des messages et isolation des tâches en échec.
- Solutions Architect – Professional (SAP-C02) · Tâche 2.4: Pratique des fondamentaux : Traitement borné des messages et isolation des tâches en échec.
Relier une file source à une file de lettres mortes
Dans cette étape, créez deux files Standard vides et configurez un réacheminement avec un nombre limité de tentatives sur la file source.
Une file de lettres mortes (DLQ) conserve les tâches qui dépassent la limite de réceptions d'une file source. Utilisez AWS View à côté de Terminal pour comparer les deux files, les tentatives réelles et les commandes stockées ; conservez les données de référence.
cd /home/labex/project
Créez la destination des tâches échouées et enregistrez son adresse de file :
DEAD_URL=$(aws sqs create-queue --queue-name labex-q03-dead --query QueueUrl --output text)
La politique de réacheminement référence l'ARN de la destination, son identifiant de ressource de service, plutôt que son URL de file. Sélectionnez cet ARN :
DEAD_ARN=$(aws sqs get-queue-attributes --queue-url "$DEAD_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
Écrivez une petite politique JSON. Le shell insère votre ARN de destination à la place de $DEAD_ARN ; maxReceiveCount permet deux tentatives de livraison avant qu'une réception supplémentaire déplace le message vers la DLQ.
cat > redrive-policy.json <<EOF
{
"deadLetterTargetArn": "$DEAD_ARN",
"maxReceiveCount": 2
}
EOF
Les attributs de file SQS représentent la politique de réacheminement comme une chaîne JSON dans un autre document JSON. --rawfile lit le fichier de politique sous forme de cette chaîne ; > écrit le fichier d'attributs.
jq -n --rawfile policy redrive-policy.json '{VisibilityTimeout:"30",RedrivePolicy:$policy}' > queue-attributes.json
Créez la file source avec ces attributs :
QUEUE_URL=$(aws sqs create-queue --queue-name labex-q03-jobs --attributes file://queue-attributes.json --query QueueUrl --output text)
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn VisibilityTimeout RedrivePolicy
Vous devez obtenir un délai de visibilité de 30, une politique pointant vers labex-q03-dead et une limite de réceptions de 2. Enregistrez l'ARN source pour la connexion du consommateur :
QUEUE_ARN=$(aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
AWS View affiche les deux files vides, aucune exécution du traitement et aucune commande. Une politique de réacheminement ne traite pas elle-même les messages ; la réception doit avoir lieu via un consommateur.
Connecter le consommateur et prouver le traitement valide
Dans cette étape, connectez un mappage de source d'événements Lambda et vérifiez le traitement réel d'une tâche valide.
Le mappage interroge la file et invoque le traitement ; un traitement réussi lui permet d'acquitter le message.
Un mappage de source d'événements relie la file source à un consommateur Lambda. Il interroge les messages, les transmet comme un événement SQS Records et supprime les messages traités avec succès. Le rôle d'exécution fourni possède uniquement les permissions de réception et de suppression sur la file source, d'écriture dans la table des commandes et de journalisation. Le traitement rejette les quantités hors de l'intervalle 1–10. Son code et ses permissions sont des ressources de démonstration ; votre tâche concerne la connexion de la file et l'isolation des échecs.
Créez un mappage avec une taille de lot de un pour que chaque tentative ait une seule tâche à inspecter :
MAPPING_ID=$(aws lambda create-event-source-mapping --function-name labex-q03-worker --event-source-arn "$QUEUE_ARN" --batch-size 1 --enabled --query UUID --output text)
Lisez la connexion :
aws lambda get-event-source-mapping --uuid "$MAPPING_ID" --query '{Source:EventSourceArn,Function:FunctionArn,Batch:BatchSize,State:State}'
Vous devez obtenir l'ARN source de labex-q03-jobs, la fonction labex-q03-worker, la taille de lot 1 et l'état Enabled. L'existence du mappage est une preuve de configuration ; une commande réellement stockée prouvera le traitement.
Envoyez une tâche valide :
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"good-order","quantity":2}'
Observez AWS View jusqu'à ce que le traitement renvoie un résultat et que la table des commandes affiche good-order. Le traitement est asynchrone ; laissez un court intervalle au consommateur au lieu de recevoir manuellement ce message. Lisez ensuite la commande :
aws dynamodb get-item --table-name labex-q03-orders --key '{"id":{"S":"good-order"}}' --consistent-read --query Item
Vous devez obtenir une quantité de 2 et un total de 600. Contrôlez les deux files :
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
aws sqs get-queue-attributes --queue-url "$DEAD_URL" --attribute-names ApproximateNumberOfMessages
Les deux files doivent être vides : le traitement a terminé l'écriture métier et le consommateur a acquitté la tâche réussie. Un message valide n'a pas sa place dans la DLQ.
Observer les tentatives limitées et l'isolation des échecs
Dans cette étape, envoyez une tâche invalide et observez les véritables tentatives échouées de traitement avant que le réacheminement natif la place dans la DLQ.
Avec la limite de deux réceptions de ce laboratoire, une réception ultérieure déplace la tâche échouée vers la DLQ au lieu d'invoquer le traitement une troisième fois.
Un message empoisonné, ou poison message, échoue à répétition à cause de ses données ou de la logique de traitement. Envoyez une quantité fictive invalide de zéro :
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"poison-order","quantity":0}'
AWS View affiche la tentative échouée du traitement. Le message reste en cours de livraison jusqu'à l'expiration de sa visibilité, puis le consommateur peut le recevoir de nouveau. Observez les tentatives et les compteurs des files jusqu'à ce que la DLQ contienne une tâche disponible. Avec cette fenêtre de 30 secondes et deux tentatives, prévoyez environ une minute plus le temps de traitement. Ne recevez pas et ne supprimez pas manuellement la tâche pendant que le consommateur fonctionne ; cela modifierait les nombres de réceptions et l'expérience.
Les deux tentatives échouées ont le même identifiant de message et les nombres de réceptions 1 et 2. Aucune commande stockée n'apparaît pour poison-order. Une fois la limite de réceptions atteinte, une réception native suivante retire le message de la file source au lieu d'invoquer la fonction une troisième fois.
Confirmez l'état des files avec la CLI :
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
aws sqs get-queue-attributes --queue-url "$DEAD_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
La source doit avoir zéro tâche disponible et zéro tâche en cours de livraison, avec une tâche disponible dans la DLQ. AWS View affiche son corps d'origine. Inspectez les journaux réels du traitement pour la quantité invalide et l'échec :
aws logs filter-log-events --log-group-name /aws/lambda/labex-q03-worker --query 'events[].message'
Lisez tous les éléments de commandes :
aws dynamodb scan --table-name labex-q03-orders --query Items
Seule good-order/2/600 reste. L'échec a été isolé sans détruire son message ni écrire une commande invalide. Un transfert vers une DLQ n'est ni une réparation ni un résultat métier réussi ; la récupération et la protection contre les doublons arrivent dans les unités suivantes et le défi de projet.
Supprimer la connexion et vos ressources
Dans cette étape, arrêtez votre connexion de consommateur avant de supprimer les files et les résultats.
Supprimez d'abord le mappage de source d'événements :
aws lambda delete-event-source-mapping --uuid "$MAPPING_ID" --query UUID --output text
Supprimez les deux files jetables. Cela détruit aussi la tâche empoisonnée fictive conservée dans la DLQ :
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws sqs delete-queue --queue-url "$DEAD_URL"
Supprimez la commande valide et les journaux d'exécution de ce laboratoire :
aws dynamodb delete-item --table-name labex-q03-orders --key '{"id":{"S":"good-order"}}'
aws logs delete-log-group --log-group-name /aws/lambda/labex-q03-worker
Contrôlez l'absence de vos ressources et la conservation de la référence avec des réponses API réussies :
aws lambda list-event-source-mappings --function-name labex-q03-worker --query EventSourceMappings
aws sqs list-queues
aws dynamodb scan --table-name labex-q03-orders --query Items
aws dynamodb scan --table-name labex-q03-reference --query Items
Les listes de mappages et de commandes sont vides, aucune URL de file ne reste et l'élément de référence indique toujours keep unchanged. Le traitement fourni et les structures des tables restent. AWS View affiche le même état des ressources. Une erreur d'authentification ou de réseau ne peut pas prouver la suppression.
Supprimez les fichiers locaux ordinaires de politique :
rm -f redrive-policy.json queue-attributes.json
Exécutez la vérification du nettoyage avant de terminer l'environnement.
Résumé
Vous avez relié une file source SQS à une DLQ avec une limite de réceptions, attaché un consommateur Lambda et vérifié une commande valide stockée. Vous avez observé une tâche invalide échouer deux fois et être transférée vers la DLQ sans écriture métier, puis supprimé votre mappage, vos files, votre résultat et les journaux en conservant les ressources fournies.
