AWS EventBridge-Rohre

In meiner letzten Sitzung auf der re:Invent ging es um AWS EventBridge Pipes. Ich fliege heute Abend wieder nach Hause, so dass ich noch etwas Zeit habe, einen Blog über diese neue Funktion zu schreiben, die Werner Vogels angekündigt hat.

Warum

Die Programmierung von Dienstintegrationen zwischen Ereignisproduzenten und -konsumenten durch Anwendungsentwicklungsteams kann aufgrund komplexer Details bei den beteiligten Ressourcen recht schwierig sein. Der erstellte Code kann Fehler enthalten oder ineffizient sein, wodurch die Gesamtanwendung immer komplexer wird und die Gesamtbetriebskosten der Anwendung steigen.

Was

Die neuen Pipes sind verwaltete Punkt-zu-Punkt-Integrationen zwischen Diensten. Die Quelle können Streams von SQS, DynamoDB, Kafka oder MQ sein. Die Palette der Ziele ist viel breiter und umfasst SNS, SQS, StepFunctions, Lambda, Kinesis, API Gateway, EventBridge und SageMaker. Die Konfiguration von Pipes ermöglicht es Ihnen, die Ereignisse zu filtern (nicht übereinstimmende Ereignisse werden verworfen) und können dann optional mit anderen Daten angereichert werden, indem eine Lambda-Funktion aufgerufen wird, die das Ergebnis an das Ziel der Pipe sendet. Die Pipe versucht, die Nachricht unter Verwendung der angegebenen Wiederholungsrichtlinien, Währungs- und Batching-Einstellungen an Ihr Ziel zuzustellen. Wenn die Nachricht nicht erfolgreich zugestellt werden konnte, können Sie das Ereignis an eine Dead-Letter-Queue (DLQ) weiterleiten, um die weitere Verarbeitung von Ereignissen nicht zu blockieren. Wird keine DLQ angegeben, verarbeitet die Pipe keine neuen Ereignisse mehr und Sie riskieren den Verlust von Ereignissen basierend auf dem "Ereignishorizont" Ihrer Quellressource. Bei SQS wird die DLQ in der Warteschlangen-Ressource angegeben, bei anderen Quellen können Sie eine in der Pipe-Ressource angeben. Die Filterfunktion ist sehr leistungsfähig und Sie müssen nicht für verworfene Ereignisse bezahlen. Die Integration wird vollständig verwaltet und es gibt keine Dataplane, auf die zugegriffen werden kann. Da vor Pipes Ereignisquellen-Zuordnungen die bevorzugte Methode für diese Integrationen waren, entspricht die Konfiguration von EventBridge Pipes weitgehend dem, was in diesen festgelegt werden konnte.

Was nicht

Pipes sind nicht für Situationen gedacht, in denen viele Produzenten auf viele Konsumenten zugreifen. In diesen Fällen würden Sie von den Quellen aus einen EventBridge-Bus anvisieren und Regeln verwenden, um die Nachrichten an die Ziele zu senden.Für DynamoDB beträgt die maximale Anzahl von Pollern 2. Wenn Sie also mehr Ressourcen für die Verarbeitung des DynamoDB-Streams benötigen, sollten Sie die Stream-Ereignisse zunächst an einen EventBridge-Bus weiterleiten und dann wieder Regeln für diesen Bus verwenden.EventBridge kann derzeit nicht als Quelle für Pipes verwendet werden. Ich denke, die Implementierung von Regeln ist hier gut genug.

Aktuelle Merkmale

• Stapelverarbeitung und Gleichzeitigkeit können festgelegt werden
• Ereignisse filtern
• bereichernde Ereignisse
• Warteschlange für tote Buchstaben
• Wiederholungen

Zukünftige Funktionen

• Kettenrohre
• Dead Letter Queues DLQ
• regions- oder kontoübergreifende Leitungen
• VPC-Endpunkt, der kein NAT durchläuft, wenn sich die Quelle in einer VPC befindet
• Unterstützung für AppFlow
• Unterstützung für CDK, SAM und AWS Application Composer
• Verbesserte Protokollierung

Fazit

Überall dort, wo Sie derzeit Event Source Mappings implementiert haben, sollten Sie nach Möglichkeit die EventBridge Pipe-Funktion verwenden, um die Betriebskosten Ihrer Anwendung zu senken. Es ist wahrscheinlich ratsam, zumindest auf die Unterstützung von CloudFormation zu warten, bevor Sie dies tun (ich konnte in der Dokumentation keine Unterstützung finden).