Dans l’article d’aujourd’hui, je vais vous montrer comment nous utilisons AWS SQS dans notre application Laravel et comment cela nous aide à gérer 1,6 milliard d’opérations chaque mois.
Dans l’image ci-dessous, vous pouvez voir notre facture type pour un mois d’utilisation d’AWS SQS :
Avant d’entrer dans les détails de la conception de notre système, je voudrais présenter la technologie SQS, pourquoi vous devriez envisager un système de messagerie et comment le comparer avec des services similaires.
Qu’est-ce qu’AWS SQS ?
Amazon Simple Queue Service est un système de file d’attente de messages entièrement géré pour permettre la communication entre des composants logiciels distribués ou des microservices.
Le découplage de certaines parties de votre système vous permet d’exécuter et de faire échouer vos composants logiciels indépendamment. Il vous permet également de créer des applications facilement évolutives.
Les files d’attente de messages agissent comme intermédiaires :
Qu’est-ce qu’un message ?
C’est une question importante à laquelle je souhaite répondre pour aider les développeurs qui abordent cette technologie pour la première fois.
Chaque système de file d’attente de messages accepte un texte comme contenu d’un message. La manière la plus courante de faire en sorte que différents systèmes échangent des données structurées consiste à utiliser des objets JSON.
JSON peut être facilement sérialisé sous forme de texte lors de l’insertion d’un nouveau message dans la file d’attente et désérialisé lorsqu’il est consommé de l’autre côté du système.
La voie Laravel
Laravel implémente son propre format lors de l’échange de messages avec les systèmes de file d’attente. Voici un exemple:
Le JSON est automatiquement créé par le système de file d’attente interne du framework lorsque vous distribuez un travail. Il est quelque peu caché aux yeux du développeur.
Le message JSON contient toutes les données nécessaires à Laravel pour comprendre quelle classe de travail doit être exécutée et dans quelles conditions (tentatives, maxTries, etc.).
Si votre application n’a pas de solution prépackagée comme celle fournie par Laravel, vous pouvez définir votre propre format. L’objectif est de fournir au consommateur de la file d’attente toutes les informations nécessaires pour traiter la tâche souhaitée.
Comment consommer les messages de la file d’attente
Vous devez implémenter un système qui interroge en permanence la file d’attente en attendant l’arrivée d’un message.
Laravel fournit un « travailleur » intégré que vous pouvez exécuter avec une simple commande :
Cette commande exécute un processus d’arrière-plan qui demande de nouveaux messages. Lorsqu’un message est récupéré, l’agent peut exécuter la classe de travail incluse dans le message.
Vous pouvez voir ce processus dans le \Illuminate\Queue\Worker.php classe:
while (true) {
// Before reserving any jobs, we will make sure this queue is not paused and
// if it is we will just pause this worker for a given amount of time and
// make sure we do not need to kill this worker process off completely.
if (! $this->daemonShouldRun($options, $connectionName, $queue)) {
$status = $this->pauseWorker($options, $lastRestart);
if (! is_null($status)) {
return $this->stop($status, $options);
}
continue;
}
...
// If the daemon should run (not in maintenance mode, etc.), then we can run
// fire off this job for processing. Otherwise, we will need to sleep the
// worker so no more jobs are processed until they should be processed.
if ($job) {
$jobsProcessed++;
$this->runJob($job, $connectionName, $options);
if ($options->rest > 0) {
$this->sleep($options->rest);
}
} else {
$this->sleep($options->sleep);
}
...
}Pourquoi devriez-vous utiliser AWS SQS ?
Étant donné que mon produit est un outil de développement, je discute avec d’autres développeurs presque chaque semaine de la conception interne de leur logiciel.
Dans la plupart des applications que j’ai eu l’occasion d’analyser, un système de messagerie a été introduit pour permettre l’exécution asynchrone des tâches.
Il en va de même pour l’inspecteur.
Je pense que c’est le cas d’utilisation le plus courant pour les systèmes de messagerie aujourd’hui. Les microservices ou les grands logiciels distribués, en général, sont des cas d’utilisation très spécialisés. Appartenant probablement davantage aux environnements d’entreprise.
Qu’est-ce qu’une tâche asynchrone ?
Imaginez que votre produit offre la possibilité d’importer des informations de compte en téléchargeant des fichiers volumineux. L’utilisateur sélectionne le fichier sur le PC local et clique sur « Importer.”
Cette opération peut prendre un certain temps avant de se terminer. Vous devez ouvrir le fichier, lire chaque ligne, le convertir au format approprié et stocker ces informations dans votre système.
Il pourrait être impossible de gérer ce processus au moment d’une requête HTTP.
Grâce à un système de file d’attente de messages, nous pouvons stocker le fichier sur nos serveurs et pousser un message vers le « importer” file d’attente avec le chemin où se trouve le fichier.
L’étape suivante consiste à créer un système d’arrière-plan qui attend ces messages pour gérer le processus d’importation. Les utilisateurs n’ont pas besoin d’attendre que l’importation soit terminée. En attendant, ils peuvent continuer à utiliser le produit ou le laisser en attente d’être notifié lorsque l’importation sera terminée :
Comment l’inspecteur utilise AWS SQS
Le défi le plus important d’Inspector est de pouvoir traiter de grandes quantités de trafic, garantissant également de bonnes performances.
Le point de terminaison où Inspector reçoit les données des applications surveillées gère environ 10 millions de requêtes HTTP par jour. Avec ce volume, le problème est que ces paquets de données ne peuvent pas être traités à la volée.
Au début de notre aventure, nous utilisions un Redis autogéré comme système de file d’attente de messages. Mais, avec des volumes croissants, nous avons préféré nous appuyer sur un service managé.
La stratégie consiste à utiliser AWS SQS pour pouvoir pousser ces tâches vers une file d’attente, qui sera consommée par un autre système distinct en arrière-plan (le pipeline de traitement) :
Les nœuds d’ingestion sont implémentés dans Node.js. Ils sont construits comme un script très simple et extrêmement évolutif. Les serveurs de travail qui consomment la file d’attente sont plutôt un composant système construit au-dessus du framework Laravel.
Nous aurions pu choisir n’importe quelle autre technologie pour gérer la file d’attente des messages. A ce stade de l’entreprise, SQS nous garantit une évolutivité sans aucune complexité puisqu’il s’agit d’un service entièrement managé.
D’autres solutions pourraient également nous faire économiser des coûts. Nous préférons garantir à nos clients que la plateforme fonctionne parfaitement et éviter le risque d’introduire des faiblesses qui pourraient provoquer des temps d’arrêt inattendus.
Conclusion
À ce stade, vous devriez avoir une meilleure idée de ce qu’est AWS SQS, comment utiliser AWS SQS pour faire évoluer votre application, pourquoi vous devriez utiliser AWS SQS, et plus encore. J’espère que vous avez retiré des informations précieuses de cet article. Si c’est le cas, n’hésitez pas à liker et partager.