Architekturverbesserungen für eine verzögerungsfreie Echtzeit-Datenpipeline

<p>Ein Bericht über die Beziehung zwischen Kafka Consumer Group und der Anzahl der Partitionen, die daraus entstehenden Schwierigkeiten beim Auto Scaling und die Einführung einer neuen Architektur zu deren Lösung.<br /> <br /> - Einführung in den Airbridge-Service und die Workload<br /> - Probleme der bestehenden Architektur<br /> - Vorschlag für eine neue Architektur<br /> - Option 1: ein Driver-Executor-Modell wie bei Spark Streaming<br /> - Option 2: ein entkoppeltes Modell aus Kafka Consumer und Application Server<br /> - Warum Option 2 gewählt wurde<br /> - Die Architektur des entkoppelten Modells aus Kafka Consumer und Application Server<br /> - Überlegungen zur neuen Architektur<br /> - Erlebte Schwierigkeiten<br /> - Ergebnisse nach der Einführung der neuen Architektur<br /> - Was künftig noch ausprobiert werden sollte</p>

[lamanus]

<p>Wow … ich nutze auch ECS, aber in diesem Ausmaß habe ich mir darüber noch keine Gedanken gemacht. Wirklich gut.</p>

[lamanus]

<p>Beim Einsatz von envoy war die Anfrage, den Traffic zwischen den AZs zu reduzieren, offenbar im Status „holding“.<br /> <br /> https://github.com/aws/aws-app-mesh-roadmap/issues/94</p>;