Fanout von Amazon SNS SNS-Ereignissen in AWS Event Fork-Pipelines - Amazon Simple Notification Service
So funktionieren AWS Event Fork-PipelinesBereitstellung von AWS Event Fork-Pipelines

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fanout von Amazon SNS SNS-Ereignissen in AWS Event Fork-Pipelines

Für die Archivierung und Analyse von Ereignissen empfiehlt Amazon SNS jetzt, die native Integration mit Amazon Data Firehose zu verwenden. Sie können Firehose-Lieferstreams für SNS-Themen abonnieren, sodass Sie Benachrichtigungen an Archivierungs- und Analyseendpunkte wie Amazon Simple Storage Service (Amazon S3) -Buckets, Amazon Redshift Redshift-Tabellen, Amazon OpenSearch Service (OpenSearch Service) und mehr senden können. Die Verwendung von Amazon SNS mit Firehose Delivery Streams ist eine vollständig verwaltete und codelose Lösung, für die Sie keine Funktionen verwenden müssen. AWS Lambda Weitere Informationen finden Sie unter Lieferstreams von Fanout nach Firehose.

Sie können Amazon SNS zum Entwickeln ereignisgesteuerter Anwendungen verwenden, die Abonnenten-Services für die automatische Ausführung von Aufgaben als Antwort auf von Herausgeber-Services ausgelöste Ereignisse verwenden. Dieses Architekturmuster kann eine bessere Wiederverwendbarkeit, Interoperabilität und Skalierbarkeit von Services unterstützen. Es kann jedoch arbeitsaufwändig sein, die Verarbeitung von Ereignissen auf Pipelines aufzuteilen, die gemeinsame Anforderungen an die Ereignisbehandlung erfüllen, wie Speicherung, Backup, Suche, Analytik und Replay von Events.

Um die Entwicklung Ihrer ereignisgesteuerten Anwendungen zu beschleunigen, können Sie Event-Handling-Pipelines — unterstützt von AWS Event Fork Pipelines — für Amazon SNS SNS-Themen abonnieren. AWS Event Fork Pipelines ist eine Suite verschachtelter Open-Source-Anwendungen, die auf dem AWS Serverless Application Model (AWS SAM) basieren und die Sie direkt aus der AWS Event Fork Pipelines Suite (wählen Sie Apps anzeigen, die benutzerdefinierte IAM-Rollen oder Ressourcenrichtlinien erstellen) in Ihrem Konto bereitstellen können. AWS

Einen Anwendungsfall für AWS Event Fork Pipelines finden Sie unter. Bereitstellen und Testen der Beispielanwendung Amazon SNS Event Fork Pipelines

Themen

So funktionieren AWS Event Fork-Pipelines

AWS Event Fork Pipelines ist ein serverloses Entwurfsmuster. Es handelt sich jedoch auch um eine Suite verschachtelter serverloser Anwendungen, die auf AWS SAM basieren (die Sie direkt vom AWS Serverless Application Repository (AWS SAR) auf Ihrem Computer bereitstellen können, um Ihre AWS-Konto ereignisgesteuerten Plattformen zu erweitern). Sie können diese verschachtelten Anwendungen einzeln bereitstellen wie von Ihrer Architektur gefordert.

Das folgende Diagramm zeigt eine AWS Event Fork Pipelines-Anwendung, die durch drei verschachtelte Anwendungen ergänzt wird. Sie können jede der Pipelines aus der AWS Event Fork Pipelines Suite unabhängig voneinander auf der AWS SAR bereitstellen, wie es Ihre Architektur erfordert.

Die AWS Event Fork Pipelines Architektur, die zeigt, wie Ereignisse aus einem Amazon SNS SNS-Thema über drei verschiedene Pipelines gefiltert und verarbeitet werden: Event Storage and Backup, Event Search and Analytics und Event Replay. Diese Pipelines werden als vertikal gestapelte Boxen dargestellt, von denen jede unabhängig voneinander Ereignisse aus demselben Amazon SNS SNS-Thema parallel verarbeitet.

Jede Pipeline hat dasselbe Amazon SNS-Thema abonniert, um Ereignisse parallel verarbeiten zu können, wenn diese Ereignisse zum Thema veröffentlicht werden. Jede Pipeline ist unabhängig und Sie können eine eigene Abonnementfilterrichtlinie festlegen. So ist es möglich, dass eine Pipeline nur eine Teilmenge der Ereignisse verarbeitet - die von Interesse (anstelle aller zum Thema veröffentlichter Ereignisse).

Anmerkung

Da Sie die drei AWS Event Fork-Pipelines neben Ihren regulären Event-Verarbeitungspipelines platzieren (möglicherweise haben Sie Ihr Amazon SNS SNS-Thema bereits abonniert), müssen Sie keinen Teil Ihres aktuellen Nachrichtenherausgebers ändern, um die AWS Event Fork-Pipelines in Ihren bestehenden Workloads zu nutzen.

Die Pipeline für die Speicherung und Sicherung von Ereignissen

Das folgende Diagramm zeigt die Pipeline für die Speicherung und Sicherung von Ereignissen. Sie können für diese Pipeline ein Abonnement Ihres Amazon SNS-Themas erstellen, um die Ereignisse in Ihrem System automatisch zu sichern.

Diese Pipeline besteht aus einer Amazon SQS SQS-Warteschlange, die die vom Amazon SNS SNS-Thema übermittelten Ereignisse zwischenspeichert, einer AWS Lambda Funktion, die automatisch nach diesen Ereignissen in der Warteschlange abfragt und sie in einen Amazon Data Firehose-Stream überträgt, und einem Amazon S3 S3-Bucket, der die vom Stream geladenen Ereignisse dauerhaft sichert.

Die Fork-Event-Storage-Backup -Pipeline, die für die Verarbeitung und Sicherung von Ereignissen aus einem Amazon SNS SNS-Thema konzipiert ist. Der Ablauf beginnt mit einem Amazon SNS SNS-Thema, von dem Ereignisse in eine Amazon SQS-Warteschlange weitergeleitet werden. Diese gefilterten Ereignisse werden dann von einer Lambda-Funktion verarbeitet, die sie an eine Amazon Kinesis Data Firehose weiterleitet. Der Firehose-Stream ist dafür verantwortlich, die Ereignisse zu puffern, zu transformieren und zu komprimieren, bevor sie in einen Amazon S3 S3-Backup-Bucket geladen werden. Schließlich kann Amazon Athena verwendet werden, um die gespeicherten Daten abzufragen. Das Diagramm verwendet eine Reihe von Symbolen und Pfeilen, um den Ablauf von einem Service zum nächsten zu veranschaulichen, wobei jede Komponente der Pipeline klar gekennzeichnet ist.

Um das Verhalten Ihres Firehose-Streams zu optimieren, können Sie ihn so konfigurieren, dass Ihre Ereignisse gepuffert, transformiert und komprimiert werden, bevor sie in den Bucket geladen werden. Während die Ereignisse geladen werden, können Sie Amazon Athena verwenden, um im Bucket SQL-Standardabfragen zu stellen. Sie können die Pipeline auch für die Wiederverwendung eines vorhandenen Amazon S3-Buckets konfigurieren oder einen neuen Bucket erstellen.

Die Pipeline für die Suche und Analyse von Ereignissen

Das folgende Diagramm zeigt die Pipeline für die Suche und Analyse von Ereignissen. Sie können für diese Pipeline ein Abonnement Ihres Amazon SNS-Themas erstellen, um die Ereignisse in Ihrem System in einer Suchdomäne zu indizieren und anschließend zu analysieren.

Diese Pipeline besteht aus einer Amazon SQS SQS-Warteschlange, die die vom Amazon SNS SNS-Thema übermittelten Ereignisse zwischenspeichert, einer AWS Lambda Funktion, die Ereignisse aus der Warteschlange abfragt und sie in einen Amazon Data Firehose-Stream überträgt, einer Amazon OpenSearch Service-Domain, die die vom Firehose-Stream geladenen Ereignisse indexiert, und einem Amazon S3 S3-Bucket, der die Ereignisse speichert, die nicht in der Such-Domain indexiert werden können.

Die Event-Such- und Analytics-Pipeline innerhalb einer Architektur. AWS Es beginnt auf der linken Seite mit dem Amazon SNS SNS-Thema, in dem alle Ereignisse empfangen werden. Diese Ereignisse werden dann durch eine gestrichelte Linie, die „ausgefächerte gefilterte Ereignisse“ darstellt, in eine Amazon SQS SQS-Warteschlange geleitet. Ereignisse aus der Warteschlange werden von einer Lambda-Funktion verarbeitet, die sie dann an einen Amazon Kinesis Data Firehose-Stream weiterleitet. Die Data Firehose leitet die Ereignisse an zwei Ziele weiter: Eine Route führt zu einem Amazon Elasticsearch Service zur Indizierung, und die andere Route sendet Ereignisse, die nicht verarbeitet werden können oder nur unvollständige Buchstaben enthalten, an einen Amazon S3 S3-Dead-Letter-Bucket. Ganz rechts wird die Ausgabe des Elasticsearch Service zur Analyse und Visualisierung in ein Kibana-Dashboard eingespeist. Der gesamte Datenfluss ist horizontal angeordnet und jede Komponente ist durch Linien miteinander verbunden, die die Richtung des Datenflusses angeben.

Um Ihren Firehose-Stream in Bezug auf die Pufferung, Transformierung und Komprimierung von Ereignissen zu optimieren, können Sie diese Pipeline konfigurieren.

Sie können auch konfigurieren, ob die Pipeline eine bestehende OpenSearch Domain in Ihrer wiederverwenden AWS-Konto oder eine neue für Sie erstellen soll. Während der Indizierung von Ereignissen in der Suchdomäne können Sie mit Kibana Analysen für Ihre Ereignisse ausführen und visuelle Dashboards in Echtzeit aktualisieren.

Die Pipeline für das Replay von Events

Das folgende Diagramm zeigt die Pipeline für das Replay von Events. Um die Ereignisse aufzuzeichnen, die von Ihrem System in den letzten 14 Tagen verarbeitet wurden (beispielsweise für den Fall, dass Ihre Plattform nach einem Fehler wiederhergestellt werden muss), können Sie für diese Pipeline ein Abonnement Ihres Amazon SNS-Themas erstellen und anschließend die Ereignisse neu verarbeiten.

Diese Pipeline besteht aus einer Amazon SQS SQS-Warteschlange, die die vom Amazon SNS SNS-Thema übermittelten Ereignisse zwischenspeichert, und einer AWS Lambda Funktion, die Ereignisse aus der Warteschlange abfragt und sie in Ihre reguläre Ereignisverarbeitungspipeline zurückleitet, die auch Ihr Thema abonniert hat.

Die Event Replay Pipeline in einem Flussdiagrammformat. Von links nach rechts beginnt es mit einem Amazon SNS SNS-Thema, das gefilterte Ereignisse auf zwei parallel Prozesse verteilt. Der obere Flow stellt Ihre reguläre Ereignisverarbeitungspipeline dar, die eine Amazon SQS SQS-Warteschlange umfasst, die Ereignisse verarbeitet. Der untere Flow, der als "“ bezeichnet wirdfork-event-replay-pipeline, umfasst eine Amazon SQS SQS-Wiedergabewarteschlange, in der Ereignisse vorübergehend gespeichert werden, bevor sie von einer Lambda-Wiedergabefunktion verarbeitet werden. Diese Lambda-Funktion ist in der Lage, Ereignisse erneut in Ihre reguläre Ereignisverarbeitungspipeline zu übertragen oder sie für die Wiedergabe vorzuhalten, je nachdem, ob die Wiedergabefunktion aktiviert oder deaktiviert ist. Das Diagramm zeigt auch, dass die Bediener die Kontrolle über die Aktivierung oder Deaktivierung der Funktion zur Ereigniswiedergabe haben.
Anmerkung

Standardmäßig ist die Funktion für das erneute Abspielen deaktiviert und schiebt Ihre Ereignisse nicht erneut in die reguläre Pipeline. Wenn Sie Ereignisse erneut verarbeiten müssen, müssen Sie die Amazon-SQS-Warteschlange für das erneute Abspielen als Ereignisquelle für die AWS Lambda -Funktion für das erneute Abspielen aktivieren.

Bereitstellung von AWS Event Fork-Pipelines

Die AWS Event Fork Pipelines Suite (wählen Sie Apps anzeigen, die benutzerdefinierte IAM-Rollen oder Ressourcenrichtlinien erstellen) ist als Gruppe von öffentlichen Anwendungen in der verfügbar AWS Serverless Application Repository, von wo aus Sie sie mithilfe der AWS Lambda Konsole manuell bereitstellen und testen können. Informationen zur Bereitstellung von Pipelines mithilfe der AWS Lambda Konsole finden Sie unter. AWS Event Fork-Pipelines für ein Amazon SNS SNS-Thema abonnieren

In einem Produktionsszenario empfehlen wir, AWS Event Fork-Pipelines in die SAM-Vorlage Ihrer gesamten Anwendung einzubetten. AWS Mit der Funktion für verschachtelte Anwendungen können Sie dies tun, indem Sie die Ressource AWS::Serverless::Application zu Ihrer AWS SAM-Vorlage hinzufügen und dabei auf die AWS SAR ApplicationId und die der verschachtelten Anwendung verweisen. SemanticVersion

Sie können beispielsweise die Event Storage and Backup Pipeline als verschachtelte Anwendung verwenden, indem Sie dem Resources Abschnitt Ihrer SAM-Vorlage den folgenden YAML-Snippet hinzufügen. AWS 

Backup:   
    Type: AWS::Serverless::Application
  Properties:
    Location:
      ApplicationId: arn:aws:serverlessrepo:us-east-2:123456789012:applications/fork-event-storage-backup-pipeline
      SemanticVersion: 1.0.0
    Parameters: 
      #The ARN of the Amazon SNS topic whose messages should be backed up to the Amazon S3 bucket.
      TopicArn: !Ref MySNSTopic

Wenn Sie Parameterwerte angeben, können Sie AWS CloudFormation systeminterne Funktionen verwenden, um auf andere Ressourcen in Ihrer Vorlage zu verweisen. Im obigen YAML-Snippet verweist der TopicArn Parameter beispielsweise auf die AWS::SNS::Topic Ressource, die an anderer Stelle in der Vorlage MySNSTopic definiert ist. AWS SAM Weitere Informationen finden Sie in der Referenz für intrinsische Funktion im AWS CloudFormation -Benutzerhandbuch.

Anmerkung

Die AWS Lambda Konsolenseite für Ihre AWS SAR-Anwendung enthält die Schaltfläche Als SAM-Ressource kopieren, mit der das für die Verschachtelung einer AWS SAR-Anwendung erforderliche YAML in die Zwischenablage kopiert wird.