Benachrichtigungen mit SNS und SQS verteilen

Einführung

Die Auftragsabwicklung benötigt jede Bestellbenachrichtigung, während die Analyse nur neue Bestellungen benötigt. Du veröffentlichst einmal für zwei Warteschlangen, konfigurierst ihre Zustellberechtigungen und filterst Analysebenachrichtigungen.

Schließe zuerst Aufträge mit SQS senden und verarbeiten und Einen Bucket mit einer Ressourcenrichtlinie schützen ab. Diese unabhängige VM stellt eine konfigurierte CLI und unbeteiligte Referenzdaten bereit. Die Warteschlangen sind Benachrichtigungsziele; diese Einheit benötigt keinen Lambda-Verbraucher.

Bezug zu Zertifizierungen

Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.

Cloud Practitioner (CLF-C02) · Aufgabe 3.8: SNS-Fanout, Abonnementfilter und Zustellberechtigungen.
Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: SNS-Fanout, Abonnementfilter und Zustellberechtigungen.
Developer – Associate (DVA-C02) · Aufgabe 1.1: SNS-Fanout, Abonnementfilter und Zustellberechtigungen.
DevOps Engineer – Professional (DOP-C02) · Aufgabe 5.1: Grundlagenübung: SNS-Fanout, Abonnementfilter und Zustellberechtigungen.
Solutions Architect – Professional (SAP-C02) · Aufgabe 2.4: Grundlagenübung: SNS-Fanout, Abonnementfilter und Zustellberechtigungen.

Das Topic erstellen und Warteschlangenzustellung erlauben

Erstelle in diesem Schritt ein Topic und zwei leere Warteschlangen mit der Berechtigung, nur Zustellungen dieses Topics zu empfangen.

Amazon Simple Notification Service (SNS) verteilt eine Veröffentlichung über Topic-Abonnements. Verwende AWS View neben Terminal, um Topic-Verbindungen, Warteschlangeninhalte und Filter zu vergleichen; erhalte die Referenzdaten.

cd /home/labex/project

Erstelle das SNS-Topic des Produzenten. Die Befehlsersetzung $(...) speichert die zurückgegebene ARN in einer Shellvariable für die folgenden Befehle:

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

Erstelle unabhängige Ziele und speichere ihre Warteschlangen-URLs:

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)

Abonnements verwenden Warteschlangen-ARNs als Ziele. Wähle beide Kennungen aus:

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)

Eine Warteschlangenrichtlinie gewährt dem SNS-Dienst sqs:SendMessage für genau diese Warteschlange, wobei aws:SourceArn auf dein Topic begrenzt ist. Die Abonnementkonfiguration allein gewährt keine Zustellberechtigung. Schreibe eine gewöhnliche JSON-Richtlinie pro Warteschlange; die Shell setzt die ARN-Variablen ein:

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

Das SQS-Attribut Policy enthält eine JSON-Zeichenfolge. --rawfile liest eine Richtliniendatei in diese Zeichenfolge ein, und anschließend setzt die CLI die Attribute mithilfe der gewöhnlichen Attributdatei:

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

Lies die konfigurierten Berechtigungen aus:

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

Beide Richtlinien nennen ihre eigene Warteschlange und dasselbe Bestelltopic. AWS View zeigt ein Topic, zwei leere Warteschlangen und noch keine Abonnements.

Beide Warteschlangen abonnieren und die Analyse filtern

Verbinde in diesem Schritt jede Warteschlange mit dem Topic und wähle aus, welche Benachrichtigungen die Analyse empfängt.

SNS-Verteilung und Abonnementfilter

Das Analyseabonnement wählt das Nachrichtenattribut kind=created aus; jede Warteschlange erhält ihre eigene Kopie.

Ein Abonnement verbindet ein Protokoll und einen Endpunkt mit einem SNS-Topic. Für sqs ist der Endpunkt die Warteschlangen-ARN. Speichere die Abonnement-ARNs, damit du jede Verbindung konfigurieren und später entfernen kannst:

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)

Eine Filterrichtlinie wählt Benachrichtigungen für ein Abonnement aus. Der standardmäßige Filterbereich sind Nachrichtenattribute. Die Analyse akzeptiert nur ein String-Attribut kind mit dem Wert created; die Auftragsabwicklung hat keinen Filter:

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

Untersuche beide Abonnements und die Analyseattribute:

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

Erwarte zwei SQS-Endpunkte und den Analysefilter. Die unveränderte Nachrichtenzustellung (Raw Message Delivery) ist standardmäßig deaktiviert. Deshalb enthalten Warteschlangeninhalte einen SNS-Benachrichtigungsumschlag mit Topic, Nachrichten-ID, ursprünglicher Nachrichtenzeichenfolge und Attributen. Die Warteschlangen bleiben bis zur Veröffentlichung leer.

Verteilung, Filterung und die Zustellgrenze nachweisen

Veröffentliche in diesem Schritt zwei Benachrichtigungen und untersuche tatsächliche unabhängige Zustellungen.

Veröffentliche ein Erstellungsereignis. Die JSON-Nachricht ist die geschäftliche Nutzlast; das separate String-Attribut wird von diesem Abonnementfilter ausgewertet:

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

Veröffentliche ein Aktualisierungsereignis mit derselben Bestell-ID:

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

Beobachte AWS View: Die Auftragsabwicklung hat zwei Benachrichtigungen, die Analyse nur die Erstellungsbenachrichtigung. Prüfe die Zähler:

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

Empfange die Nachrichten zur Untersuchung mit einer Sichtbarkeitsfrist von null. Dadurch werden diese fiktiven Nachrichten sofort für die spätere Bereinigung freigegeben, statt sie in Bearbeitung zu halten. Das Beispiel belegt unabhängige Kopien, keine Verarbeitung oder Bestätigung. fromjson liest jede Umschlagzeichenfolge, und die abschließende Feldauswahl zeigt die hier verwendeten Benachrichtigungsfelder:

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}]'

Der Inhalt ist ein SNS-Umschlag: Type ist Notification, TopicArn ist dein Topic, und Message enthält die ursprüngliche JSON-Zeichenfolge. Die Erstellungsbenachrichtigung hat in beiden Warteschlangen dieselbe SNS-MessageId; jede Warteschlange hält ihre eigene SQS-Nachricht vor. Die Auftragsabwicklung enthält zusätzlich das Aktualisierungsereignis, das die Analyse herausgefiltert hat. Unabhängige Verbraucher können ihre Kopien getrennt bestätigen.

Teste jetzt, warum die Topic-Berechtigung wichtig ist. Setze aws:SourceArn der Auftragsabwicklung vorübergehend auf eine unbeteiligte fiktive Topic-ARN:

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

Veröffentliche eine Aktualisierungsbenachrichtigung für eine andere fiktive Bestellung. SNS akzeptiert die Veröffentlichung, aber die Auftragsabwicklung ist für dieses Topic nicht mehr autorisiert; die Analyse filtert das Aktualisierungsattribut heraus:

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

Prüfe, dass die Warteschlangenzähler bei zwei und eins bleiben und kein blocked-order-Umschlag in AWS View erscheint:

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

Eine erfolgreiche Veröffentlichungsantwort belegt, dass SNS die Benachrichtigung angenommen hat; die Zustellung an das Ziel benötigt einen eigenen Nachweis. Stelle vor der Schrittprüfung genau die ursprüngliche Richtlinie wieder her:

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

Dieser Arbeitsbereich testet die unmittelbare Warteschlangenzustellung im selben Konto und String-Attributfilter. Die Übernahme von SNS-Filteränderungen in der Produktion kann bis zu 15 Minuten dauern, und für fehlgeschlagene Zustellungen gilt das Wiederholungsverhalten des Dienstes; dieses kurze Berechtigungsexperiment ist kein Modell für Wiederholungen in der Produktion.

Beispiel in AWS View: Die Auftragsabwicklung enthält Erstellungs- und Aktualisierungsbenachrichtigungen; die Analyse enthält nur die Erstellungsbenachrichtigung mit derselben SNS-Nachrichten-ID.

Verbindungen und temporäre Benachrichtigungen entfernen

Entferne in diesem Schritt beide Abonnements, das Topic und die Warteschlangen und erhalte dabei unbeteiligte Referenzdaten.

Melde zuerst beide Endpunkte ab:

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

Lösche das Topic und die Warteschlangen. Das Löschen der Warteschlangen verwirft die fiktiven Benachrichtigungen; für sie wurde keine Geschäftsverarbeitung behauptet:

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

Belege die Bereinigung mit erfolgreichen Abfragen direkt beim Dienst:

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

Topic- und Abonnementlisten sind leer, Warteschlangen-URLs fehlen, und das Referenzelement enthält weiterhin keep unchanged. Authentifizierungs- oder Netzwerkfehler belegen keine Löschung. AWS View zeigt dieselben leeren Ressourcen.

Entferne deine gewöhnlichen Konfigurationsdateien:

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

Führe die Bereinigungsprüfung aus, bevor du die Umgebung beendest.

Zusammenfassung

Du hast ein SNS-Topic mit zwei unabhängigen SQS-Warteschlangen verbunden, die Zustellung auf genau ein Quelltopic begrenzt und die Analyse anhand eines Nachrichtenattributs gefiltert. Tatsächliche Benachrichtigungsumschläge belegten das gemeinsame veröffentlichte Ereignis und separate Warteschlangenkopien. Du hast außerdem die Annahme einer Veröffentlichung durch SNS von der Zustellung an ihre Ziele unterschieden und anschließend deine Ressourcen entfernt, während die Referenzdaten erhalten blieben.

Warteschlangenverbraucher müssen weiterhin mit wiederholter Zustellung umgehen. Die nächste Einheit verwendet eine atomare DynamoDB-Bedingung, um zu verhindern, dass wiederholte Aufträge doppelte geschäftliche Auswirkungen erzeugen.