Délai de visibilité, DLQ et interrogation longue

Lorsqu’un consommateur reçoit un message de SQS, celui-ci est masqué pour tous les autres consommateurs pendant une période appelée délai de visibilité. Durant cette période, le consommateur traite le message, puis le supprime. Si le consommateur tombe en panne ou ne termine pas à temps, le délai de visibilité expire et le message redevient visible, ce qui permet à un autre consommateur de le prendre en charge. Il s’agit du mécanisme central qui garantit la livraison au moins une fois de SQS.

Le délai de visibilité par défaut est de 30 secondes. Il peut être défini entre 0 seconde et 12 heures. Définissez-le à une valeur dépassant confortablement votre durée maximale de traitement prévue : si le traitement peut durer jusqu’à 2 minutes, définissez le délai sur au moins 3 à 4 minutes. Vous pouvez également modifier le délai pour un reçu donné à l’aide de change-message-visibility, ce qui est utile lorsqu’un consommateur détecte qu’il a besoin de plus de temps pour terminer le traitement d’un message spécifique.

Un délai trop court fait réapparaître les messages avant que le consommateur ait terminé, ce qui entraîne un traitement en double. Un délai trop long empêche un autre consommateur de prendre en charge un message si le consommateur initial tombe en panne sans que cela soit détecté (par exemple, en cas de panne d’une instance EC2 sans nettoyage correct). Le délai optimal est légèrement supérieur à votre durée de traitement au 99e centile, tout en étant suffisamment court pour permettre une récupération rapide après une panne de consommateur. Surveillez la métrique CloudWatch ApproximateNumberOfMessagesNotVisible pour détecter les problèmes de délai.

Une file d’attente de lettres mortes (DLQ) est une file SQS distincte vers laquelle les messages sont envoyés après avoir échoué un nombre configurable de fois (la valeur maxReceiveCount). Lorsque le nombre de réceptions d’un message dépasse maxReceiveCount, SQS le déplace automatiquement vers la DLQ. Les DLQ empêchent les messages irrécupérables (messages qui échouent systématiquement) de bloquer indéfiniment la file. Les messages de la DLQ peuvent être inspectés, débogués et rejoués après correction du problème de traitement.

Une DLQ est simplement une file SQS classique (Standard pour une source Standard, FIFO pour une source FIFO). Vous configurez la Redrive Policy sur la file source afin d’indiquer quelle file constitue la DLQ et de définir le seuil maxReceiveCount. Assurez-vous que la période de rétention de la DLQ est plus longue que celle de la file source : les messages arrivent tardivement dans la DLQ et vous devez disposer de suffisamment de temps pour les examiner avant leur expiration.

Définissez une alarme CloudWatch sur la métrique ApproximateNumberOfMessagesVisible de la DLQ. Tout message arrivant dans la DLQ indique un échec de traitement qui nécessite votre attention. Configurez l’alarme pour déclencher immédiatement une notification SNS qui alerte l’ingénieur d’astreinte. Considérez chaque message de la DLQ comme un bogue à examiner : les messages de la DLQ ne doivent pas s’accumuler silencieusement. Après avoir corrigé le bogue, utilisez le redéploiement de la DLQ pour renvoyer les messages vers la file source afin de les traiter à nouveau.

Après avoir corrigé le bogue à l’origine des échecs de traitement, utilisez le redéploiement de la DLQ SQS pour déplacer les messages de la DLQ vers la file source afin de les traiter à nouveau. La console fournit une fonctionnalité intégrée de redéploiement. Vous pouvez filtrer les messages selon leurs attributs afin de ne rejouer que certains messages. Vous pouvez également écrire une fonction Lambda qui interroge la DLQ et transfère les messages vers la file source si vous avez besoin d’une logique de filtrage personnalisée.

Par défaut, SQS utilise l’interrogation courte : un appel receive-message échantillonne un sous-ensemble aléatoire de serveurs et renvoie immédiatement une réponse, même si aucun message n’est disponible. Cela entraîne de nombreuses réponses vides et gaspille des appels d’API. L’interrogation longue attend jusqu’à 20 secondes l’arrivée d’un message avant de renvoyer une réponse vide. Elle réduit considérablement les coûts (grâce à un nombre moindre d’appels d’API) et diminue la latence (le message est reçu dès son arrivée, jusqu’à 20 secondes avant le cycle d’interrogation suivant).

Activez l’interrogation longue au niveau de la file (ce qui s’applique à tous les appels de réception) ou pour chaque requête. Une configuration au niveau de la file avec ReceiveMessageWaitTimeSeconds défini sur 20 est recommandée pour la plupart des applications. Lorsque Lambda utilise SQS comme source d’événements, l’interrogation longue est activée automatiquement. Pour les consommateurs basés sur EC2, définissez WaitTimeSeconds dans l’appel receive-message.

Les messages SQS peuvent contenir des attributs de message : des paires clé-valeur de métadonnées distinctes du corps du message. Les attributs possèdent un type (chaîne, nombre ou binaire) et une valeur. Lorsque SQS est abonné à une rubrique SNS, vous pouvez utiliser des politiques de filtrage des abonnements SNS appliquées aux attributs des messages afin d’acheminer uniquement les messages pertinents vers chaque file. Sans filtrage, chaque abonné SQS reçoit chaque publication SNS, quel que soit son contenu.

Une file avec délai rend chaque nouveau message invisible pendant une période comprise entre 0 et 15 minutes après son envoi. Cela est utile pour les flux de travail dans lesquels un consommateur ne doit pas traiter immédiatement un message, par exemple lorsqu’il faut attendre la fin d’un processus dépendant. Vous pouvez également définir un délai par message à l’aide de DelaySeconds dans l’appel d’envoi, ce qui remplace le délai défini au niveau de la file. Remarque : les files avec délai ne sont pas disponibles pour les files FIFO.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que le délai d'invisibilité masque un message aux autres consommateurs pendant son traitement, ce qui permet une livraison au moins une fois avec une nouvelle livraison automatique si le consommateur échoue ; les files d'attente de lettres mortes recueillent les messages qui échouent à plusieurs reprises afin de faciliter le débogage et la relecture une fois le bogue corrigé ; et l'interrogation longue (avec un temps d'attente maximal de 20 secondes) réduit les coûts d'API et la latence par rapport à l'interrogation courte. Nous allons maintenant découvrir les rubriques SNS et l'architecture de diffusion en étoile.