AWS Queue : Délai de visibilité

• Le délai de visibilité dans AWS Queue fait référence à la durée pendant laquelle un message est invisible pour les autres consommateurs après qu'un consommateur l'a récupéré de la file d'attente.
• Cela empêche plusieurs consommateurs de traiter le même message simultanément.
• Lorsqu'un consommateur reçoit un message, il dispose d'un laps de temps spécifique pour le traiter.
• Le délai de visibilité commence dès que le message est reçu par un consommateur.
• Pendant cette période, le message est invisible pour les autres consommateurs.
• Si le consommateur traite le message avec succès, il doit supprimer le message de la file d'attente.
• La suppression du message garantit qu'il ne sera plus traité.
• Si le consommateur ne parvient pas à traiter le message dans le délai de visibilité, le message redevient visible.
• Une fois le délai expiré, un autre consommateur peut récupérer le message et tenter de le traiter.
• Le délai de visibilité est configurable au niveau de la file d'attente ou au niveau du message.
• Le délai de visibilité au niveau de la file d'attente s'applique à tous les messages de la file d'attente, sauf s'il est remplacé au niveau du message.
• Un délai de visibilité au niveau du message peut être défini lors de l'envoi d'un message à la file d'attente.
• Il permet à chaque message d'avoir des valeurs de délai de visibilité différentes.
• Le délai de visibilité par défaut est de 30 secondes.
• Le délai de visibilité peut être défini de 0 seconde à 12 heures.
• La définition d'un délai de visibilité approprié est cruciale pour un traitement fiable des messages.
• Si le délai est trop court, les messages peuvent être traités plusieurs fois.
• Si le délai est trop long, les messages peuvent être retardés en cas de défaillance du consommateur.

Comment ça marche

• Le consommateur A récupère un message de la file d'attente.
• Le délai de visibilité commence.
• Le message est invisible pour les autres consommateurs pendant cette période.
• Si le consommateur A traite le message avec succès et le supprime avant le délai, le processus est terminé.
• Si le consommateur A ne parvient pas à traiter le message avant l'expiration du délai, le message redevient visible.
• Le consommateur B peut alors récupérer le même message.
• Ce mécanisme garantit qu'un message est traité même si un consommateur échoue.
• Le système garantit une livraison "au moins une fois".
• Le message peut être traité plus d'une fois en cas d'échec.
• Les développeurs doivent concevoir leurs applications pour qu'elles soient idempotentes.
• L'idempotence signifie que le traitement du même message plusieurs fois a le même effet que le traitement une seule fois.

Configuration

• Le délai de visibilité peut être configuré via l'AWS Management Console.
• Il peut également être configuré à l'aide des SDK AWS ou de l'interface de ligne de commande.
• Pour configurer au niveau de la file d'attente, accédez aux paramètres de la file d'attente SQS dans l'AWS Management Console.
• Modifiez l'attribut "Délai de visibilité".
• Pour configurer au niveau du message, définissez le paramètre VisibilityTimeout lors de l'envoi du message.
• Cela remplace le paramètre au niveau de la file d'attente pour ce message spécifique.

Cas d'utilisation

• Traitement des tâches dont la durée de traitement maximale est connue.
• S'assurer que les messages ne sont pas traités plusieurs fois lorsque des défaillances de consommateurs sont possibles.
• Mise en œuvre d'un mécanisme de relance pour le traitement des messages en échec.
• Équilibrer la nécessité de relancer rapidement les messages en échec avec le risque de traitement en double.

Bonnes pratiques

• Choisissez un délai de visibilité suffisamment long pour que la plupart des messages soient traités.
• Surveillez les temps de traitement des messages pour ajuster le délai de visibilité si nécessaire.
• Mettez en œuvre l'idempotence dans la logique de traitement des messages.
• Utilisez des files d'attente de lettres mortes pour gérer les messages qui ne peuvent pas être traités après plusieurs tentatives.
• Envisagez d'utiliser des délais de visibilité au niveau du message pour les messages ayant des exigences de temps de traitement variables.

Problèmes potentiels

• Messages en cours de traitement plusieurs fois si le délai de visibilité est trop court.
• Messages retardés si un consommateur échoue et que le délai de visibilité est trop long.
• Augmentation des coûts due au traitement en double.
• Complexité de la logique applicative pour gérer l'idempotence.
• Difficulté à déterminer la valeur optimale du délai de visibilité.

Impact d'une configuration incorrecte

• Si le délai de visibilité est trop faible, cela peut entraîner un traitement en double des messages.
• Cela peut entraîner des calculs incorrects, des commandes en double ou d'autres effets indésirables.
• Si le délai de visibilité est trop élevé, cela peut entraîner des retards dans le traitement des messages.
• Si un consommateur échoue, il faut plus de temps pour que le message redevienne disponible pour être retraité.

Surveillance

• Amazon CloudWatch peut être utilisé pour surveiller les files d'attente SQS.
• Des métriques telles que NumberOfMessagesReceived, NumberOfMessagesDeleted et ApproximateAgeOfOldestMessage peuvent être utiles.
• La surveillance de ces métriques peut aider à identifier les problèmes liés aux délais de visibilité.
• Par exemple, un ApproximateAgeOfOldestMessage élevé peut indiquer que le délai de visibilité est trop court.
• Cela peut entraîner le renvoi répété des messages dans la file d'attente.

Files d'attente de lettres mortes

• Les files d'attente de lettres mortes (DLQ) peuvent être utilisées conjointement avec les délais de visibilité.
• Une DLQ est une file d'attente où les messages sont envoyés s'ils ne peuvent pas être traités après un certain nombre de tentatives.
• L'attribut maxReceiveCount de la politique de redirection détermine le nombre de tentatives avant qu'un message ne soit envoyé à la DLQ.
• Lorsqu'un message est reçu plus de maxReceiveCount fois, il est déplacé vers la DLQ.
• Cela empêche les messages d'être traités de manière répétée et de causer potentiellement des problèmes.
• Les DLQ fournissent un mécanisme pour identifier et traiter les messages problématiques.

Sondage long

• L'interrogation longue peut améliorer l'efficacité de la récupération des messages des files d'attente SQS.
• Avec l'interrogation longue, un consommateur attend une durée spécifiée que les messages arrivent dans la file d'attente.
• Cela réduit le nombre de réponses vides et économise les ressources.
• L'attribut ReceiveMessageWaitTimeSeconds détermine la durée de l'interrogation longue.
• L'interrogation longue peut être utilisée conjointement avec les délais de visibilité pour optimiser le traitement des messages.
• Il réduit la latence associée à la récupération des messages de la file d'attente.

Relation avec les minuteurs de messages

• Les minuteurs de messages retardent la livraison d'un message à une file d'attente pour une durée spécifiée.
• L'attribut DelaySeconds détermine le délai.
• Les minuteurs de messages sont différents des délais de visibilité.
• Les minuteurs de messages contrôlent le moment où un message est initialement disponible pour le traitement.
• Les délais de visibilité contrôlent la durée pendant laquelle un message est invisible après avoir été reçu par un consommateur.
• Les minuteurs de messages et les délais de visibilité peuvent être utilisés pour gérer le traitement des messages de différentes manières.

Alternatives au délai de visibilité

• Mise en œuvre de mécanismes de verrouillage des messages dans l'application consommateur.
• Utilisation de transactions de base de données pour garantir que le traitement des messages est atomique.
• Utilisation de services de verrouillage distribués tels que ZooKeeper ou etcd.
• Ces alternatives peuvent offrir un contrôle plus précis sur le traitement des messages.
• Cependant, ils ajoutent également de la complexité à l'application.

Exemple de scénario

• Une application de commerce électronique utilise SQS pour traiter les mises à jour de commandes.
• Lorsqu'un client passe une commande, un message est envoyé à la file d'attente SQS.
• Un processus de travail récupère le message et met à jour l'état de la commande dans la base de données.
• Le délai de visibilité est défini sur 60 secondes.
• Si le processus de travail ne parvient pas à mettre à jour l'état de la commande dans les 60 secondes, le message redevient visible.
• Un autre processus de travail peut alors récupérer le message et tenter de mettre à jour l'état de la commande.
• Cela garantit que les mises à jour de commandes sont traitées même si un processus de travail échoue.
• Pour éviter les mises à jour de commandes en double, le processus de travail vérifie l'état actuel de la commande avant de la mettre à jour.
• Si l'état de la commande a déjà été mis à jour, le processus de travail ignore la mise à jour.
• Cela garantit que le processus de mise à jour de la commande est idempotent.

Configurations avancées

• Utilisation de l'action ChangeMessageVisibility pour prolonger le délai de visibilité d'un message.
• Cela peut être utile si un consommateur a besoin de plus de temps pour traiter un message.
• Mise en œuvre d'une interruption exponentielle pour réessayer le traitement des messages en échec.
• Cela peut aider à éviter de surcharger le système avec des tentatives.
• Utilisation d'attributs de message pour stocker des informations supplémentaires sur le message.
• Cela peut être utile pour acheminer les messages vers différents consommateurs ou pour fournir un contexte au consommateur.