Diffuser des notifications avec SNS et SQS

Introduction

L'équipe de préparation des commandes a besoin de chaque notification, tandis que l'analyse a besoin uniquement des nouvelles commandes. Vous publierez une seule fois vers deux files, configurerez leurs permissions de livraison et filtrerez les notifications destinées à l'analyse.

Terminez d'abord Envoyer et consommer des tâches avec SQS et Protégez un compartiment avec une politique de ressource. Cette VM indépendante fournit une CLI configurée et des données de référence indépendantes. Les files sont des destinations de notifications ; cette unité n'a pas besoin de consommateur Lambda.

Lien avec les certifications

Ce laboratoire propose une pratique des sujets d’examen suivants.

Cloud Practitioner (CLF-C02) · Tâche 3.8: Diffusion SNS, filtres d’abonnement et autorisations de livraison.
Solutions Architect – Associate (SAA-C03) · Tâche 2.1: Diffusion SNS, filtres d’abonnement et autorisations de livraison.
Developer – Associate (DVA-C02) · Tâche 1.1: Diffusion SNS, filtres d’abonnement et autorisations de livraison.
DevOps Engineer – Professional (DOP-C02) · Tâche 5.1: Pratique des fondamentaux : Diffusion SNS, filtres d’abonnement et autorisations de livraison.
Solutions Architect – Professional (SAP-C02) · Tâche 2.4: Pratique des fondamentaux : Diffusion SNS, filtres d’abonnement et autorisations de livraison.

Créer le sujet et autoriser la livraison aux files

Dans cette étape, créez un sujet et deux files vides avec la permission permettant uniquement à ce sujet de livrer des messages.

Amazon Simple Notification Service (SNS) distribue une publication via les abonnements d'un sujet, ou topic. Utilisez AWS View à côté de Terminal pour comparer les connexions du sujet, les corps des messages dans les files et les filtres ; conservez les données de référence.

cd /home/labex/project

Créez le sujet SNS du producteur. La substitution de commande, $(...), enregistre l'ARN renvoyé dans une variable du shell pour les commandes suivantes :

TOPIC_ARN=$(aws sns create-topic --name labex-q04-orders --query TopicArn --output text)

Créez des destinations indépendantes et enregistrez leurs URL de file :

FULFILLMENT_URL=$(aws sqs create-queue --queue-name labex-q04-fulfillment --query QueueUrl --output text)
ANALYTICS_URL=$(aws sqs create-queue --queue-name labex-q04-analytics --query QueueUrl --output text)

Les abonnements utilisent les ARN des files comme destinations. Sélectionnez les deux identifiants :

FULFILLMENT_ARN=$(aws sqs get-queue-attributes --queue-url "$FULFILLMENT_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
ANALYTICS_ARN=$(aws sqs get-queue-attributes --queue-url "$ANALYTICS_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)

Une politique de file accorde au service SNS sqs:SendMessage sur cette file exacte, avec aws:SourceArn limité à votre sujet. La seule configuration d'un abonnement n'accorde pas la permission de livraison. Écrivez une politique JSON ordinaire par file ; le shell insère les variables d'ARN :

cat > fulfillment-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "sns.amazonaws.com"},
    "Action": "sqs:SendMessage",
    "Resource": "$FULFILLMENT_ARN",
    "Condition": {"ArnEquals": {"aws:SourceArn": "$TOPIC_ARN"}}
  }]
}
EOF
cat > analytics-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "sns.amazonaws.com"},
    "Action": "sqs:SendMessage",
    "Resource": "$ANALYTICS_ARN",
    "Condition": {"ArnEquals": {"aws:SourceArn": "$TOPIC_ARN"}}
  }]
}
EOF

L'attribut SQS Policy contient une chaîne JSON. --rawfile lit un fichier de politique dans cette chaîne, puis la CLI applique le fichier d'attributs ordinaire :

jq -n --rawfile policy fulfillment-policy.json '{Policy:$policy}' > fulfillment-attributes.json
jq -n --rawfile policy analytics-policy.json '{Policy:$policy}' > analytics-attributes.json
aws sqs set-queue-attributes --queue-url "$FULFILLMENT_URL" --attributes file://fulfillment-attributes.json
aws sqs set-queue-attributes --queue-url "$ANALYTICS_URL" --attributes file://analytics-attributes.json

Lisez les permissions configurées :

aws sqs get-queue-attributes --queue-url "$FULFILLMENT_URL" --attribute-names QueueArn Policy
aws sqs get-queue-attributes --queue-url "$ANALYTICS_URL" --attribute-names QueueArn Policy

Les deux politiques nomment leur propre file et le même sujet de commandes. AWS View affiche un sujet, deux files vides et aucun abonnement pour le moment.

Abonner les deux files et filtrer l'analyse

Dans cette étape, reliez chaque file au sujet et choisissez les notifications reçues par l'analyse.

Diffusion SNS et filtre d'abonnement

L'abonnement de l'analyse sélectionne l'attribut de message kind=created ; chaque file reçoit sa propre copie.

Un abonnement relie un protocole et un point de terminaison à un sujet SNS. Pour sqs, le point de terminaison est l'ARN de la file. Enregistrez les ARN des abonnements pour pouvoir configurer puis supprimer chaque connexion :

FULFILLMENT_SUB=$(aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$FULFILLMENT_ARN" --query SubscriptionArn --output text)
ANALYTICS_SUB=$(aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$ANALYTICS_ARN" --query SubscriptionArn --output text)

Une politique de filtrage sélectionne les notifications pour un abonnement. La portée de filtrage par défaut concerne les attributs de message. L'analyse accepte uniquement un attribut String kind avec la valeur created ; la préparation des commandes n'a pas de filtre :

aws sns set-subscription-attributes --subscription-arn "$ANALYTICS_SUB" --attribute-name FilterPolicy --attribute-value '{"kind":["created"]}'

Inspectez les deux abonnements et les attributs de celui de l'analyse :

aws sns list-subscriptions-by-topic --topic-arn "$TOPIC_ARN"
aws sns get-subscription-attributes --subscription-arn "$ANALYTICS_SUB"

Vous devez obtenir deux points de terminaison SQS et le filtre de l'analyse. La livraison de messages bruts est désactivée par défaut : les corps des messages dans les files contiendront donc une enveloppe de notification SNS avec le sujet, l'identifiant de message, la chaîne du message d'origine et les attributs. Les files restent vides jusqu'à la publication.

Prouver la diffusion, le filtrage et la frontière de livraison

Dans cette étape, publiez deux notifications et inspectez les véritables livraisons indépendantes.

Publiez un événement de création. Le message JSON est la charge utile métier ; l'attribut String distinct est ce que ce filtre d'abonnement évalue :

aws sns publish --topic-arn "$TOPIC_ARN" --message '{"id":"fanout-order","kind":"created"}' --message-attributes '{"kind":{"DataType":"String","StringValue":"created"}}'

Publiez un événement de mise à jour avec le même identifiant de commande :

aws sns publish --topic-arn "$TOPIC_ARN" --message '{"id":"fanout-order","kind":"updated"}' --message-attributes '{"kind":{"DataType":"String","StringValue":"updated"}}'

Observez AWS View : la préparation des commandes possède deux notifications, l'analyse uniquement la notification de création. Contrôlez les compteurs :

aws sqs get-queue-attributes --queue-url "$FULFILLMENT_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
aws sqs get-queue-attributes --queue-url "$ANALYTICS_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Recevez les messages pour inspection avec une visibilité de zéro. Cela remet immédiatement ces messages fictifs à disposition pour le nettoyage ultérieur au lieu de les maintenir en cours de livraison. L'exemple prouve l'existence de copies indépendantes, pas leur traitement ni leur acquittement. fromjson lit chaque chaîne d'enveloppe et la sélection finale des champs montre les champs de notification utilisés ici :

aws sqs receive-message \
  --queue-url "$FULFILLMENT_URL" \
  --max-number-of-messages 10 \
  --visibility-timeout 0 \
  --output json | jq '[.Messages[].Body | fromjson | {Type, TopicArn, MessageId, Message, MessageAttributes}]'
aws sqs receive-message \
  --queue-url "$ANALYTICS_URL" \
  --max-number-of-messages 10 \
  --visibility-timeout 0 \
  --output json | jq '[.Messages[].Body | fromjson | {Type, TopicArn, MessageId, Message, MessageAttributes}]'

Le corps est une enveloppe SNS : Type vaut Notification, TopicArn est votre sujet et Message contient la chaîne JSON d'origine. La notification de création possède le même MessageId SNS dans les deux files ; chaque file contient son propre message SQS. La préparation des commandes contient aussi l'événement de mise à jour, que l'analyse a filtré. Des consommateurs indépendants peuvent acquitter leurs copies séparément.

Testez maintenant pourquoi la permission du sujet compte. Remplacez temporairement aws:SourceArn de la préparation des commandes par un ARN de sujet fictif indépendant :

jq --arg wrong 'arn:aws:sns:us-east-1:123456789012:labex-q04-unrelated' '.Statement[0].Condition.ArnEquals["aws:SourceArn"]=$wrong' fulfillment-policy.json > wrong-source-policy.json
jq -n --rawfile policy wrong-source-policy.json '{Policy:$policy}' > wrong-source-attributes.json
aws sqs set-queue-attributes --queue-url "$FULFILLMENT_URL" --attributes file://wrong-source-attributes.json

Publiez une notification de mise à jour pour une autre commande fictive. SNS accepte la publication, mais la préparation des commandes n'est plus autorisée pour ce sujet ; l'analyse filtre l'attribut de mise à jour :

aws sns publish --topic-arn "$TOPIC_ARN" --message '{"id":"blocked-order","kind":"updated"}' --message-attributes '{"kind":{"DataType":"String","StringValue":"updated"}}'

Vérifiez que les compteurs des files restent à deux et un, sans enveloppe blocked-order dans AWS View :

aws sqs get-queue-attributes --queue-url "$FULFILLMENT_URL" --attribute-names ApproximateNumberOfMessages
aws sqs get-queue-attributes --queue-url "$ANALYTICS_URL" --attribute-names ApproximateNumberOfMessages

Une réponse de publication réussie prouve que SNS a accepté la notification ; la livraison à destination exige sa propre preuve. Rétablissez la politique d'origine exacte avant la vérification de l'étape :

aws sqs set-queue-attributes --queue-url "$FULFILLMENT_URL" --attributes file://fulfillment-attributes.json

Cet espace de travail teste la livraison immédiate aux files du même compte et les filtres d'attributs String. Les modifications des filtres SNS en production peuvent prendre jusqu'à 15 minutes pour se propager et les livraisons échouées suivent le mécanisme de nouvelles tentatives du service ; cette courte expérience de permission ne modélise pas les nouvelles tentatives en production.

Exemple AWS View : la préparation des commandes contient les notifications de création et de mise à jour ; l'analyse contient uniquement celle de création avec le même identifiant de message SNS.

Supprimer les connexions et les notifications jetables

Dans cette étape, supprimez les deux abonnements, le sujet et les files en conservant les données de référence indépendantes.

Désabonnez d'abord les deux points de terminaison :

aws sns unsubscribe --subscription-arn "$FULFILLMENT_SUB"
aws sns unsubscribe --subscription-arn "$ANALYTICS_SUB"

Supprimez le sujet et les files. Supprimer les files détruit les notifications fictives ; aucun traitement métier n'a été affirmé pour elles :

aws sns delete-topic --topic-arn "$TOPIC_ARN"
aws sqs delete-queue --queue-url "$FULFILLMENT_URL"
aws sqs delete-queue --queue-url "$ANALYTICS_URL"

Prouvez le nettoyage avec des requêtes natives réussies :

aws sns list-topics
aws sns list-subscriptions
aws sqs list-queues
aws dynamodb scan --table-name labex-q04-reference --query Items

Les listes de sujets et d'abonnements sont vides, les URL de files sont absentes et l'élément de référence indique toujours keep unchanged. Les erreurs d'authentification ou de réseau ne prouvent pas la suppression. AWS View affiche les mêmes ressources vides.

Supprimez vos fichiers ordinaires de configuration :

rm -f fulfillment-policy.json analytics-policy.json fulfillment-attributes.json analytics-attributes.json wrong-source-policy.json wrong-source-attributes.json

Exécutez la vérification du nettoyage avant de terminer l'environnement.

Résumé

Vous avez relié un sujet SNS à deux files SQS indépendantes, limité la livraison à un sujet source exact et filtré l'analyse avec un attribut de message. Les enveloppes réelles de notification ont prouvé l'événement publié partagé et les copies distinctes dans les files. Vous avez aussi distingué l'acceptation d'une publication par SNS de sa livraison aux destinations, puis supprimé vos ressources en conservant les données de référence.

Les consommateurs de files doivent toujours gérer les livraisons répétées. L'unité suivante applique une condition atomique DynamoDB pour empêcher les tâches répétées de produire des effets métier en double.