Le service SQS (Simple Queue Service)

Introduction

SQS est le service de messaging d’AWS. Il s’agit d’un service qui se veut « simple », comme son nom l’indique. Il est basé sur la notion de file d’attente ou queue, dans laquelle on peut stocker et récupérer, de manière plus ou moins ordonnée, des messages. Tout fonctionne selon une dynamique fournisseur/consommateur de messages, où le premier produit des messages et les stocke dans des files d’attente et le dernier les consomme.

SQS est un service distribué, à tolérance des pannes, qui permet à des fournisseurs/consommateurs multiples d’interagir par l’intermédiaire des files d’attente. Les messages échangés sont caractérisés par un cycle de vie standard, avec une période de rétention et une date d’expiration, au-delà desquelles ils sont supprimés. L’interaction qui a lieu entre les fournisseurs et les consommateurs de messages est complètement découplée, dans le sens où ils ne se connaissent pas, ce qui évite la création d’adhérences entre les composants.

Fournisseurs et consommateurs de messages SQS

Le service SQS propose deux types de files d’attente : standard et FIFO (First In First Out). Bien que très similaires, ces deux types de files d’attente présentent...

Files d’attente SQS standard

Une des premières particularités des files d’attente standard est le fait qu’elles ne garantissent pas l’ordre selon lequel les messages sont stockés et, par conséquent, consommés. Bien que la loi du best effort s’y applique et que, par conséquent, l’ordre de l’arrivée des messages est dans la plupart des cas respecté, cela n’est pas garanti et il peut arriver que des messages soient traités en désordre. Ainsi, un consommateur de messages d’une file d’attente SQS standard ne peut pas présumer que l’ordre selon lequel il consomme les messages est bien celui dans lequel ils ont été initialement reçus.

De plus, l’unicité des messages dans la file n’est pas garantie non plus et, par conséquent, il peut arriver occasionnellement que plus d’une copie du même message soit délivrée à ses consommateurs. Ces deux particularités font que la fiabilité des files d’attente SQS est limitée, mais leur utilisation reste très intéressante dans des cas de figure moins contraignants, car elles proposent des rapports coûts/performances attractifs.

Ceci d’autant plus que les files d’attente standard peuvent supporter un nombre virtuellement illimité de transactions par seconde. Elles...

Files d’attente SQS FIFO

Ce type de file d’attente SQS a été spécialement conçu pour des cas d’utilisation dans lesquels garantir la consommation des messages dans l’ordre de leur arrivée est critique. Car les files d’attente SQS FIFO garantissent cet ordre. De plus, elles garantissent également l’unicité des messages, rendant ainsi impossible l’existence de doublons.

Les SQS FIFO se caractérisent par une fiabilité supérieure, comparées à leurs homologues standards. En revanche, contrairement à ces dernières, elles ne sont pas disponibles dans toutes les régions et sont limitées à maximum 300 transactions par seconde. Et si on rajoute le fait qu’elles ne sont pas supportées par tous les services AWS et que, s’agissant du service Lambda, leur support est seulement limité à un concept connu sous le nom de DLQ (Dead Letters Queues), qu’on va analyser dans un instant, alors il nous apparaît clairement que leur utilisation dans notre contexte spécifique n’est pas spécialement utile.

Le tableau ci-dessous permet de se repérer quant aux cas d’utilisation des deux types de files d’attente proposées par l’infrastructure AWS :

La production/consommation des messages SQS

La manipulation d’une file d’attente SQS standard, qui inclut des opérations comme la création, la production/consommation/suppression des messages, etc., peut se faire très simplement avec AWS CLI, comme suit :

nicolas@BEL20:~$ aws sqs create-queue --queue-name send-money-queue 
{ 
    "QueueUrl": "https://sqs.eu-west-3.amazonaws.com/459436678662/
send-money-queue" 
} 
nicolas@BEL20:~$ aws sqs get-queue-attributes --queue-url 
https://sqs.eu-west-3.amazonaws.com/459436678662/send-money-queue 
nicolas@BEL20:~$ aws sqs get-queue-attributes --queue-url 
https://sqs.eu-west-3.amazonaws.com/459436678662/send-money-queue 
--attribute-name 
ApproximateNumberOfMessages 
{ 
    "Attributes": { 
        "ApproximateNumberOfMessages": "0" 
    } 
} 
nicolas@BEL20:~$ aws sqs get-queue-attributes --queue-url 
https://sqs.eu-west-3.amazonaws.com/459436678662/send-money-queue 
--attribute-name All 
{ 
    "Attributes": { 
        "QueueArn": "arn:aws:sqs:eu-west-3:459436678662:send-money-queue", 
        "ApproximateNumberOfMessages": "0", 
        "ApproximateNumberOfMessagesNotVisible": "0", 
        "ApproximateNumberOfMessagesDelayed": "0", 
        "CreatedTimestamp": "1597749946", ...

Le scénario de test

Lorsque nous nous sommes occupés du service API Gateway, au chapitre Le développement d’API Serverless, nous avions fourni une implémentation minimaliste des fonctions Lambda auxquelles les points d’entrée de notre API étaient connectés. Il est temps maintenant que nous complétions cette implémentation.

Ainsi, nous allons remplacer l’implémentation actuelle qui ne fait qu’une simple journalisation des messages, avec une autre qui publie, dans une file d’attente dédiée, chaque nouvel ordre de virement bancaire. Ceci afin que cet ordre puisse être récupéré par le service qui effectue le processus de transfert a proprement dit, service qui est en général un service externe à l’organisation. Et s’agissant d’une opération non déterministe, dont on ne peut pas présumer la durée, on ne peut pas non plus, par conséquent, ni anticiper ni attendre le résultat. D’où la nécessité d’un traitement asynchrone et complètement découplé, consistant à déposer les ordres de virements dans une file d’attente, pour qu’ils soient récupérés et traités en temps voulu.

Pour mémoire, notre scénario général est reproduit ci-dessous.

Le scénario général

Voilà maintenant le scénario qui sera implémenté lors de ce chapitre :

Le scénario courant

Et voici la mise à jour des étapes de notre scénario courant :

Exécution et test

Pour déployer ce nouveau projet, on utilise le même script deploy.sh. Un coup d’œil rapide à ce script nous montre quelques modifications mineures par rapport à sa version précédente.

#!/bin/bash 
RANDOM=$$ 
BUCKET_NAME=bucketname-$RANDOM 
STAGE_NAME=dev 
AWS_REGION=$(aws configure list | grep region | awk '{print $2}') 
aws s3 mb s3://$BUCKET_NAME 
echo $BUCKET_NAME > bucket-name.txt 
aws s3 cp openapi.yaml s3://$BUCKET_NAME/openapi.yaml 
sam deploy --s3-bucket $BUCKET_NAME --stack-name chapter6-stack 
--capabilities  
CAPABILITY_IAM --parameter-overrides BucketName=$BUCKET_NAME 
aws cloudformation wait stack-create-complete --stack-name chapter6-stack 
API_ID=$(aws apigateway get-rest-apis --query "items[?name==
'send-money-api'].id" --output text) 
aws apigateway create-deployment --rest-api-id $API_ID 
--stage-name $STAGE_NAME 
>/dev/null 2>&1 
echo "Your API with ID $API_ID is deployed and ready to be tested at 
https://$API_ID.execute-api.$AWS_REGION.amazonaws.com/$STAGE_NAME" 

nicolas@BEL20:~/AWSLambda/projects/aws-lambda/chapter6$ mvn clean install 
[INFO] Scanning for projects... 
[INFO] ------------------------------------------------------------------- 
[INFO] Reactor Build Order: 
[INFO]  
[INFO] Money Transfer :: The master POM module                       [pom] 
[INFO] Money Transfer :: The domain model module                     [jar] 
[INFO] Money Transfer :: The Lambda module                           [jar] 
[INFO]  
[INFO] -----------< fr.simplex-software.aws.lambda:chapter6 >------------- 
[INFO] Building Money Transfer :: The master POM module 1.0-SNAPSHOT [1/3] 
[INFO] -----------------------------[ pom ]-------------------------------- 
[INFO]  
[INFO] ---- maven-clean-plugin:3.1.0:clean...