Amélioration d’architecture pour un pipeline de données temps réel sans lag

<p>Voici un retour d’expérience sur la relation entre les Kafka consumer groups et le nombre de partitions, les difficultés d’auto scaling qui en découlent, et l’adoption d’une nouvelle architecture pour les résoudre.<br /> <br /> - Présentation du service Airbridge et de la charge de travail<br /> - Problèmes de l’architecture existante<br /> - Proposition d’une nouvelle architecture<br /> - Option 1 : modèle driver/executor comme Spark Streaming<br /> - Option 2 : modèle découplé entre Kafka consumer et serveur d’application<br /> - Pourquoi l’option 2 a été choisie<br /> - Architecture du modèle découplé entre Kafka consumer et serveur d’application<br /> - Points à considérer dans la nouvelle architecture<br /> - Difficultés rencontrées<br /> - Résultats après l’adoption de la nouvelle architecture<br /> - Ce qu’il reste à essayer par la suite</p>

[lamanus]

<p>Waouh... j’utilise aussi ECS, mais je n’avais jamais réfléchi à ce point-là, c’est vraiment bien.</p>

[lamanus]

<p>En utilisant envoy, il semble que la demande visant à réduire le trafic inter-AZ était en attente.<br /> <br /> https://github.com/aws/aws-app-mesh-roadmap/issues/94</p>;