Filtrage des messages SQS et intégration SNS + SQS

Dans une architecture de diffusion en étoile sans filtrage, chaque abonné SQS reçoit chaque message SNS. Si votre rubrique publie des événements de commande pour 10 catégories de produits différentes, mais qu'un abonné ne traite que les commandes d'électronique, il reçoit tout de même les messages concernant l'alimentation et les vêtements, qu'il doit ensuite ignorer. Cela gaspille des ressources de calcul, augmente les coûts et ajoute une charge inutile aux consommateurs. Les politiques de filtrage des abonnements SNS résolvent ce problème en permettant à SNS d'acheminer lui-même les messages uniquement vers les abonnés appropriés.

Une politique de filtrage est un objet JSON appliqué à un abonnement SQS ou Lambda. SNS évalue la politique par rapport aux attributs de message avant la distribution. Si les attributs du message correspondent à la politique de filtrage, le message est distribué ; sinon, SNS ignore silencieusement cet abonné. Les politiques de filtrage prennent en charge la correspondance de chaînes, les plages numériques, la correspondance par préfixe et l'opérateur exists pour vérifier la présence ou l'absence d'un attribut.

Par défaut, les politiques de filtrage s'appliquent aux attributs de message (métadonnées). Depuis 2023, SNS prend également en charge le filtrage fondé sur la charge utile (corps) en définissant la portée de la politique de filtrage sur MessageBody. Vous pouvez ainsi appliquer directement un filtrage fondé sur un chemin JSON au corps du message, sans demander aux éditeurs d'ajouter des attributs. Le filtrage du corps est plus flexible, mais exige que le corps du message soit un JSON valide. Vérifiez toujours quelle portée correspond au format de sortie de votre éditeur.

Les politiques de filtrage prennent en charge plusieurs opérateurs de correspondance, au-delà de la simple égalité de chaînes :

• Numérique : {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Préfixe : {"prefix": "order-"} correspond à toute chaîne commençant par ce préfixe
• Tout sauf : {"anything-but": ["CANCELLED"]} correspond à toute valeur sauf celles indiquées
• Présence : {"exists": true} correspond si l'attribut est présent ; false s'il est absent

Pour que le filtrage fonctionne, l'éditeur doit inclure des attributs de message lors de la publication dans SNS. Les attributs sont des paires clé-valeur associées à un type de données (String, Number, Binary). L'éditeur n'a pas besoin de savoir quels abonnés possèdent quelles politiques de filtrage : il enrichit simplement le message avec des attributs décrivant l'événement. SNS gère automatiquement le routage. Les éditeurs restent ainsi totalement découplés de la logique propre aux abonnés.

Une topologie de diffusion en étoile sophistiquée peut utiliser SNS pour acheminer des messages vers des files SQS présentant plusieurs niveaux de précision : une file reçoit toutes les commandes (sans filtre) à des fins d'audit, une autre reçoit uniquement les commandes HIGH_VALUE (amount >= 1000) pour l'analyse des fraudes, et une troisième reçoit uniquement les commandes ELECTRONICS pour l'entrepôt d'électronique. Chaque file SQS possède son propre consommateur Lambda. Ce modèle permet de faire évoluer chaque niveau de traitement indépendamment et d'ajouter de nouveaux consommateurs sans modifier les éléments existants ni l'éditeur.

SNS peut distribuer des messages vers des files SQS situées dans un autre compte AWS. La politique fondée sur les ressources de la file SQS doit autoriser le principal de service SNS à appeler sqs:SendMessage depuis l'ARN de la rubrique SNS du compte éditeur. Cela permet de centraliser la publication des événements (un compte publie, plusieurs équipes de comptes s'abonnent) sans partager d'informations d'identification. La diffusion en étoile entre comptes est un modèle courant dans les configurations AWS Organizations comportant plusieurs comptes.

Lorsque le volume d'événements augmente brutalement, les invocations directes de SNS vers Lambda font évoluer Lambda immédiatement, ce qui peut surcharger les bases de données ou les API en aval. L'ajout de SQS entre SNS et Lambda crée un tampon : SNS distribue les messages à SQS, puis Lambda interroge SQS avec une taille de lot contrôlée. Lambda peut ainsi traiter les messages à un rythme soutenable tandis que SQS absorbe les pics de trafic. La profondeur de la file sert de mécanisme de rétropression : vous pouvez la surveiller et déclencher une alerte lorsqu'elle dépasse un seuil indiquant un retard du consommateur.

SNS → Lambda (direct) : latence minimale, aucun tampon, Lambda évolue immédiatement. Idéal pour les alertes en temps réel ou les notifications urgentes pour lesquelles une latence inférieure à une seconde est importante. SNS → SQS → Lambda : ajoute la prise en charge d'une DLQ, un débit contrôlé, des nouvelles tentatives avec délai d'invisibilité et la surveillance de la profondeur de la file. Idéal pour le traitement des transactions, les mises à jour des stocks et tous les scénarios où les limites des systèmes en aval doivent être respectées. Pour les questions d'examen, choisissez la mise en mémoire tampon SQS dès que la durabilité et le contrôle du débit sont mentionnés.

Utilisez l’éditeur de politiques de filtrage de la console SNS pour tester si un exemple de message correspondrait à votre politique de filtrage avant de la déployer. Vous pouvez également utiliser le SNS Sandbox pour simuler la remise des messages et vérifier leur routage. Dans le code, validez les politiques de filtrage en publiant des messages de test avec des attributs connus et en vérifiant les métriques CloudWatch de chaque abonnement : la métrique NumberOfMessagesFiltered indique combien de messages ont été bloqués par le filtre, ce qui vous aide à ajuster vos politiques sans attendre des événements en production.

Une intégration complète entre SNS et SQS se présente ainsi : (1) l’application publie un événement dans un rubrique SNS Standard avec des attributs de message ; (2) SNS évalue la politique de filtrage de chaque abonnement et remet uniquement les messages correspondants à chaque file SQS ; (3) Lambda interroge chaque file SQS selon une taille de lot configurée et traite les messages ; (4) les messages ayant échoué atteignent la DLQ après maxReceiveCount ; (5) une alarme CloudWatch surveillant la profondeur de la DLQ alerte l’équipe. Ce modèle entièrement découplé et résilient constitue une architecture SAA-C03 de référence.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les politiques de filtrage SNS acheminent les messages en fonction de leurs attributs ou du contenu de leur corps au niveau de SNS, ce qui élimine le traitement inutile par les consommateurs en aval ; que le modèle SNS→SQS→Lambda ajoute une mise en tampon durable et un contrôle du débit entre la diffusion à plusieurs consommateurs et le traitement ; et que la remise SQS entre comptes permet de centraliser la publication et la souscription dans des environnements comportant plusieurs comptes grâce aux politiques de ressources des files. Nous allons maintenant découvrir les API REST, HTTP et WebSocket d’Amazon API Gateway.