Qu’est-ce qu’Amazon SQS ?
Amazon SQS (Simple Queue Service) est un service de file d’attente de messages qui permet aux composants d’application de communiquer entre eux en échangeant des messages. Ceci est largement utilisé pour créer des systèmes pilotés par les événements ou découpler des services sur AWS.
Fonctionnalités d’Amazon SQS
- Persistance des messages: les messages sont stockés dans des files d’attente jusqu’à ce qu’ils soient remis ou supprimés par les terminaux d’envoi ou de réception.
- Livraison garantie des messages: Les messages sont livrés au moins une fois et dans le même ordre qu’ils sont envoyés.
- Redistribution des messages: Si un message n’est pas acquitté, il sera renvoyé jusqu’à trois fois avant d’être supprimé de la file d’attente.
- Délai de visibilité: Les messages peuvent être configurés pour expirer et être supprimés après un certain temps, même s’ils n’ont pas encore été livrés.
Avantages d’Amazon SQS
Amazon SQS est un outil hautement fiable et évolutif service de file d’attente de messages qui vous permet de connecter vos applications de manière fiable. Il offre les avantages suivants :
- Faible coût de possession: Amazon SQS est rentable grâce à son modèle de tarification à l’utilisation et à la possibilité d’utiliser n’importe quel service AWS.
- Haut débit: Il peut gérer plus de 1 million de messages par seconde avec une latence inférieure à 1 ms.
- Tolérance aux pannes: Le service est conçu pour être hautement disponible et durable, sans point de défaillance unique.
- Sécurité: Amazon SQS utilise TLS et la signature des messages lors de l’envoi de messages entre clients, ainsi que des mécanismes d’authentification pour les clients accédant au service.
Comment traiter les messages dans une commande FIFO avec SQS
Attendez, les files d’attente ne sont-elles pas censées être premier entré, premier sorti par conception ? Bon, oui, mais avec SQS, ça se complique un peu. AWS prétend qu’ils font de leur mieux pour traiter les messages dans l’ordre, mais, de temps en temps, il peut y avoir des cas de messages traités hors tour.
SQS a une architecture distribuée avec beaucoup de redondance. Cela signifie qu’il existe plusieurs banques de messages. Lors de l’exécution, les messages sont récupérés au hasard dans l’un des magasins.
Permettez-moi d’essayer de mieux expliquer cela avec une analogie. Supposons qu’un groupe de trois personnes soit allé acheter des billets au guichet d’une gare. Ils décident de se tenir dans trois files d’attente différentes, et celui qui obtient les billets en premier en avisera les autres afin qu’ils puissent sortir de la file d’attente – distribués et redondants. Supposons que les trois files d’attente aient le même nombre de personnes à cette instance. Par chance, un autre groupe de trois personnes entre dans la gare presque en même temps. Alors qu’ils se divisaient en trois files d’attente, une personne du deuxième groupe a réussi à dépasser le premier groupe et était en tête dans l’une des files d’attente. À son tour, la personne du deuxième groupe a obtenu les billets avant l’autre groupe, ce qui n’est pas souhaité mais peut arriver parfois.
Alors, quelle est la sortie ? Si un ordre FIFO strict est requis, AWS recommande d’utiliser une file d’attente FIFO. Un FIFO SQS, contrairement au SQS standard, garantit une commande stricte.
Par analogie, supposons que vous alliez dans une banque et qu’on vous remette immédiatement un jeton. Les détenteurs de jetons sont servis séquentiellement, excluant la possibilité que quelqu’un soit servi hors tour.
Comment sont traités les messages ?
Les files d’attente SQS standard garantissent un traitement « au moins une fois ». Cela signifie que les messages ne seront pas perdus et seront traités au moins une fois. Mais que veut dire « au moins une fois » ? Cela signifie-t-il que les messages peuvent être traités plusieurs fois ? Eh bien, la réponse est oui.
Examinons d’abord le cycle de vie d’un message. Voici les étapes :
- Un message est placé dans une file d’attente.
- Il est capté par le consommateur.
- Une fois traité, le consommateur le supprime de la file d’attente.
Note: Lors du post-traitement, le message n’est pas automatiquement supprimé – il doit être explicitement supprimé par le consommateur.
Entre les étapes #2 et #3, le message est « en vol ». Lorsqu’un message est en cours, un délai de visibilité entre en jeu qui supprime le message dans la file d’attente afin qu’il ne soit pas traité à nouveau. Le délai de visibilité peut être configuré, la valeur par défaut étant de 30 secondes. L’idée est qu’un message doit être traité puis supprimé de la file d’attente avant l’expiration du délai de visibilité pour éviter un traitement en double.
Cependant, il peut arriver qu’un message reste bloqué pendant le traitement, ce qui entraîne l’expiration du délai de visibilité et la reprise du message par le consommateur. De plus, il peut arriver que, pendant le processus de suppression, l’un des serveurs décroche et que le message vive sur ce serveur particulier. Lorsqu’il revient, le message est à nouveau traité. Il est donc absolument nécessaire de concevoir les applications pour qu’elles soient idempotentes lors de l’utilisation d’un SQS standard. C’est-à-dire que même si un message est traité plus d’une fois, il ne devrait pas avoir d’impact commercial.
Pour en revenir à notre exemple de gare, supposons qu’une fois qu’une personne d’un groupe reçoit les billets, elle enverra un SMS à toutes les autres personnes du groupe. Mais, lors de l’envoi du SMS, si le mobile de l’un des destinataires se déconnecte du réseau, cette personne ne recevra pas le message et achètera à nouveau les billets. Il s’agit d’un scénario courant dans lequel un message peut être traité plusieurs fois.
Les messages dans le FIFO SQS, en revanche, sont traités exactement une fois. Cela nous amène à un autre sujet important : comment les messages en double sont-ils gérés ? Le SQS standard ne se soucie pas si vous mettez des messages en double – l’application en aval est censée être idempotente.
La file d’attente FIFO, d’autre part, n’autorise pas les doublons. Il crée un identifiant de déduplication, qui est essentiellement une valeur de hachage basée sur la charge utile. Toutefois, si le même message doit être traité dans un court laps de temps : l’ID de déduplication par défaut ne fonctionnera pas et un ID de déduplication aléatoire personnalisé devra être créé et permettra à tous les messages entrants d’être traités même s’il s’agit exactement de identique à l’un des messages précédents.
Quel type de SQS devriez-vous utiliser ?
En règle générale, vous devriez toujours chercher à utiliser le SQS standard. Il est distribué, redondant et offre un débit illimité. Après tout, il est conçu pour évoluer et servir tous les types de charges de travail avec une facilité considérable. Cependant, si un ordre strict est de la plus haute importance pour l’application que vous construisez et que vous ne vous souciez pas beaucoup du débit, alors, évidemment, FIFO sera votre meilleur choix.