Iggy.rs - construire du message streaming en Rust

Origines

• En avril 2023, la décision a été prise d’apprendre Rust.
• Sur la base d’une expérience des systèmes distribués et de la messagerie, le développement d’une plateforme de message streaming a été lancé.
• L’objectif était de comprendre le fonctionnement interne des systèmes de messagerie et les compromis faits par les développeurs.
• Naissance d’Iggy.rs, avec l’ambition de créer une plateforme de message streaming mettant l’accent sur la vitesse et la légèreté.

Projet

• Au départ, Iggy utilisait le protocole QUIC pour fournir des fonctions de base d’échange de messages.
• Grâce à un prototypage continu et à des améliorations successives, un serveur prenant en charge les écritures/lectures parallèles et des flux indépendants a été mis en place.
• La prise en charge des protocoles TCP et HTTP a été ajoutée, et les performances ont été améliorées via l’optimisation des mécanismes de synchronisation des données.
• Les benchmarks ont confirmé un débit élevé et une faible latence, ce qui a conduit à en faire un projet de long terme.

Équipe

• Iggy est porté par une équipe d’environ 10 membres contribuant à différentes parties du projet.
• Ils participent à divers sous-projets, notamment le serveur core, les SDK, l’interface web et la CLI.
• Des développeurs aux expériences variées, partageant une passion pour la programmation, y contribuent de manière volontaire.
• La participation de contributeurs externes venus du monde entier a renforcé la confiance dans le projet.

Fonctionnalités

• Serveur de message streaming haute performance, durable et basé sur des logs.
• Débit élevé, faible latence et utilisation prévisible des ressources grâce à Rust, un langage compilé.
• Prise en charge de multiples streams, topics, partitions et de divers protocoles de transport.
• API RESTful, SDK clients dans plusieurs langages et travail direct avec des données binaires.
• Fonctions serveur configurables, stockage côté serveur des offsets des consommateurs et prise en charge de plusieurs méthodes de polling des messages.
• Groupes de consommateurs pour garantir l’ordre des messages et l’extension horizontale, avec expiration des messages et déduplication.
• Prise en charge de TLS pour tous les protocoles de transport, chiffrement optionnel des données et support des en-têtes de message.
• CLI intégrée et application de benchmarking pour administrer le serveur de streaming, avec déploiement sous forme de binaire unique.

Feuille de route

• Après son apparition sur la page GitHub Trending, des discussions ont eu lieu avec les utilisateurs autour de l’ajout de nouvelles fonctionnalités.
• L’objectif est d’améliorer les performances et la fiabilité grâce au clustering, à l’I/O bas niveau et à une architecture un thread par cœur.
• Des expérimentations sont prévues autour du mécanisme de consensus Raft, de l’amélioration des opérations d’I/O avec io_uring et de l’utilisation du runtime monoio.

Avenir

• L’objectif est de devenir une plateforme de message streaming généraliste et de repousser les limites des systèmes d’exploitation et du matériel.
• Le projet prévoit de proposer une plateforme intégrée facile à utiliser, avec prise en charge de plusieurs langages de programmation, d’une CLI et d’une interface web.
• Il vise à évoluer grâce aux retours et aux idées de la communauté.

Avis de GN⁺

• Iggy.rs est une plateforme de message streaming basée sur Rust, qui vise des performances élevées et une faible latence.
• En tant que projet open source, il continue de croître grâce à la participation et aux contributions volontaires de développeurs du monde entier.
• Son ambition de dépasser les limites de performance des systèmes distribués grâce à des technologies innovantes comme le clustering, l’optimisation des I/O bas niveau et une architecture un thread par cœur est particulièrement intéressante, ce qui en fait un projet très utile pour toute personne intéressée par ce domaine.

[GN⁺]

Avis sur Hacker News

• C’est ce genre d’histoires qui m’a donné envie de venir dans le logiciel au départ.
  Même avec des motivations différentes, travailler ensemble vers un même objectif, sans que la rémunération financière soit le seul but, me paraît idéal.
  J’espère que le projet réussira, et une comparaison avec d’autres alternatives aiderait à mieux comprendre où il se situe.
  • C’est exactement comme ça que ça a commencé, et on essaiera un jour d’inclure aussi des benchmarks et des comparaisons avec d’autres outils.
• L’idée est bonne, et l’article de blog aussi.
  L’auteur donne l’impression d’être humble, honnête et d’avoir le profil d’un chef de projet constructif.
  • L’équipe est vraiment excellente.
    Tout le monde a décidé de rejoindre cet effort aussi avec l’idée de s’amuser.
• Commencer avec QUIC semble être un choix vraiment affûté et intelligent.
  Il offre un multistreaming utile, proche de SCTP, ce qui en fait un bon point de départ ; il existe déjà beaucoup de bonnes bibliothèques utilisables, et il a de grandes chances de s’améliorer et d’être optimisé à l’avenir : https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
  C’est un domaine où utiliser simplement un protocole de transport un peu meilleur que les solutions existantes peut apporter de gros gains ; j’ai hâte de voir ce que QUIC donnera dans les dix prochaines années.
  • On a commencé avec QUIC parce qu’on voulait essayer quelque chose de nouveau.
    Cela dit, le protocole TCP actuellement implémenté est légèrement plus rapide que QUIC, peut-être parce qu’il manque encore du tuning supplémentaire.
    À noter aussi que QUIC est lent sur macOS par rapport à Linux.
• Ça ressemble à un concurrent direct de JetStream ? Progresser autant en moins d’un an, c’est impressionnant.
  https://docs.nats.io/nats-concepts/jetstream
  • Il existe pas mal de solutions de streaming de messages, comme JetStream, Kafka, Redpanda, RabbitMQ Streams ou Fluvio.
• Je ne vois pas bien comment ça se compare à Kafka et à Fluvio, un concurrent de Kafka écrit en Rust.
  Est-ce que c’est plutôt proche d’une file de messages comme RabbitMQ ?
  https://www.fluvio.io/
  • Comme il s’agit d’un flux de messages, c’est plus proche de Kafka, Redpanda et du plugin RabbitMQ Streams.
    Fluvio est un vrai produit, avec une entreprise derrière, donc il est plus mature, mais nous avons nos propres idées pour faire d’Iggy une solution de streaming de messages compétitive.
  • Fluvio ne vise-t-il pas à remplacer à la fois Flink et Kafka ? Je viens juste de le découvrir et j’essaie de comprendre.
• Il y a quelques années, j’avais fait quelque chose de similaire en Go avec un ami.
  https://github.com/thibauts/styx
  • Ça a l’air assez similaire.
    Je me demande pourquoi vous n’avez pas continué à travailler dessus.
• J’aimerais l’essayer un jour. Mais il faudra sans doute que j’apprenne Rust d’abord.
  À part ça, j’aime bien l’esthétique du site.
  • Il existe plusieurs SDK, et le blog utilise le moteur Rust Zola.
  • L’article de blog mentionne des SDK pour d’autres langages de programmation, donc il semble qu’on puisse l’utiliser sans apprendre Rust.
• Cet article m’a donné envie de ressortir les débuts de Fluvio.
  Nous sommes une petite équipe qui entretient depuis des décennies des liens étroits avec des applications centrées sur les données dans plusieurs domaines, et nous misons sur le streaming de données basé sur Rust et WebAssembly plutôt que sur Java et la JVM.
  Voici l’article de juin 2021 dans lequel le CTO résumait la vision de Fluvio : https://news.ycombinator.com/item?id=38880743
  Comme les questions de comparaison reviennent sans cesse, je peux aussi partager des ressources côté Fluvio. C’est un long travail de documentation, mais je peux partager ce que nous avons pour l’instant. Iggy est aussi un très beau travail.
• C’est une idée et un projet vraiment excellents.
  Mais avant de l’essayer, je pense qu’il me faut comprendre deux choses : comment exécuter plus d’une instance serveur, et, lorsqu’il y en a plusieurs, comment se passent les interactions avec le système de fichiers entre serveurs.
  • L’article de blog dit que cela fonctionne en nœud unique. Il n’y a pas encore de support de cluster.
    Quand les clusters seront pris en charge, je pense que ça pourra concurrencer Kafka.
• Le choix de monoio me surprend.
  À ma connaissance, il nécessite le compilateur nightly, et je ne trouvais pas que ce soit un bon choix pour maintenir un projet.
  • Il nécessite bien nightly, mais il n’utilise que cinq fonctionnalités, dont l’une peut être retirée en ajoutant une crate externe.
    Les autres ne sont pas, pour la plupart, particulièrement radicales. Je n’ai pas examiné le code en profondeur, mais tout me paraît compréhensible. Par exemple, l’une d’elles est une API de la bibliothèque standard permettant de créer des conteneurs non initialisés, ce qui permet d’éviter des copies.
    Je n’ai pas comparé glommio, qui fonctionne sur stable, avec monoio, mais ce serait intéressant.
  • Monoio semble être le runtime le plus performant, et il est aussi facile à utiliser en pratique.
    C’est pour cela que nous avons choisi une approche bleeding edge. De toute façon, il nous faudra encore quelques mois pour implémenter io_uring et d’autres optimisations, et il est probable que nous réécrivions certaines parties centrales en passant à une structure avec un thread par cœur.