Série Scalabilité - Partie 2

Introduction

Avant de plonger dans l'architecture async de mAIstrow, prenons un moment pour regarder ce qui existe. Kafka, Pulsar, Redpanda, Ray... ces noms reviennent dès qu'on parle de systèmes distribués. OpenAI ou Google gèrent des millions d'utilisateurs, mais ils ne racontent pas comment. Moi, je veux être transparent, apprendre des solutions existantes, et décider -- en connaissance de cause -- si je dois m'en inspirer ou rester fidèle à ma vision : une IA distribuée, souveraine et écologique, bâtie sur Rust.

Parce que, soyons honnêtes : et si mAIstrow devait gérer des dizaines de milliers d'utilisateurs ? Ce n'est pas une question de "peut-on" -- c'est une question de "comment".

Pourquoi explorer les frameworks distribués ?

Quand j'ai travaillé sur Plan 9, j'ai compris une chose fondamentale : innover, c'est aussi comprendre ce qui existe. On ne réinvente pas la roue -- on la regarde, on la mesure, on la compare, puis on décide si on la fabrique mieux.

Mon système à 3 corps (serveur, engine IA, interface) est léger, local et conçu pour la souveraineté. Mais si mAIstrow devait un jour devenir une plateforme publique avec des milliers d'utilisateurs, il faudrait comprendre comment les géants font. Pas pour copier, mais pour apprendre, et décider si on doit adapter ou dépasser.

C'est pourquoi j'explore ici Kafka, Pulsar, Redpanda et Ray -- non pas pour abandonner Rust, mais pour affiner mon choix et garder la main sur ce que je construis.

Apache Kafka : le géant du streaming

Kafka est un monolithe de performance. Il remplacerait mon serveur Rust par un cluster de brokers et mes requêtes/réponses par des topics :

• L'interface envoie une requête à un topic requests.
• Les engines IA, en tant que groupes de consommateurs, la lisent, la traitent, et publient la réponse sur responses.
• Kafka gère la répartition automatique via des partitions, et la résilience par réplication.

C'est puissant. C'est ce qui alimente Netflix, LinkedIn ou Uber. Mais c'est aussi une usine à gaz.

Mon système actuel est centralisé, léger et local. Un seul serveur Rust/Go, un round-robin simple, SQLite pour la persistance. Kafka, lui, exige un cluster de brokers, Zookeeper (ou un équivalent) pour la coordination, et une infrastructure complète.

Et pourtant, Kafka m'inspire. Ses partitions montrent comment répartir les charges sans dépendre d'un serveur unique. Ses groupes de consommateurs incarnent la résilience par nature.

Mais mon système reste plus souverain, plus simple et plus flexible grâce à mes traits Rust. Kafka est un outil de masse. Moi, je veux un outil de maîtrise.

Les défis du scaling Kafka en production

Le scaling de Kafka en production n'est pas sans difficultés :

• Saturation réseau : quand le nombre de brokers augmente, la réplication et la synchronisation peuvent saturer le réseau interne du cluster.
• Complexité opérationnelle : équilibrage des partitions, monitoring, mises à jour, gestion des configurations.
• Limites de partitionnement : trop peu de partitions freine la montée en charge ; trop de partitions surcharge les métadonnées et la coordination.
• Compromis CAP : comme tout système distribué, Kafka doit arbitrer entre cohérence, disponibilité et tolérance au partitionnement.

Apache Pulsar : une alternative moderne et modulaire

Pulsar se distingue par son architecture en couches :

• Les brokers (stateless) gèrent le streaming.
• Les bookies (Apache BookKeeper) gèrent le stockage, séparément.

Cette séparation permet de scaler le stockage indépendamment du calcul. On peut ajouter des brokers pour le débit ou des bookies pour la capacité, sans rebalancing massif ni interruption.

Pulsar est plus modulaire que Kafka, gère le multi-tenancy nativement, et supporte la géo-réplication intégrée. C'est tentant.

Mais encore une fois : trop lourd pour mes cas d'usage. Mon système est fait pour tourner sur un Raspberry Pi, un vieux laptop ou une VM chez un ami. Pulsar, même en version "light", nécessite un cluster.

Pulsar serait un bon candidat si je voulais isoler des flux pour des écoles, des laboratoires ou des projets éducatifs. Mais pour mAIstrow, je préfère garder le contrôle total.

Redpanda : le lightweight compatible Kafka

Redpanda est un rêve pour les amateurs de légèreté :

• Compatible avec l'API Kafka (via rdkafka en Rust),
• Écrit en C++, très performant,
• Peut tourner en local, même sur un Raspberry Pi,
• Monobinaire, sans dépendance Java ni Zookeeper.

Imaginez : mon serveur Rust devient un broker Redpanda. Les topics requests et responses existent. L'interface et les engines utilisent rdkafka pour communiquer. C'est presque comme mon système actuel, mais avec une répartition automatique, une résilience intégrée et une scalabilité évidente.

Redpanda est le premier framework que je veux tester. Pas pour remplacer mon système, mais pour l'expérimenter. Un POC avec un broker local, un client Rust, et un trait Transport qui peut basculer entre WebSocket et Kafka/Redpanda.

Ray : le champion du calcul distribué

Ray est différent. Il ne gère pas le streaming -- il gère le calcul distribué.

Dans Ray :

• Un acteur central (le "head") orchestre les tâches.
• Les engines IA deviennent des acteurs Ray, capables de recevoir des messages, de calculer et de retourner des résultats.
• L'interface envoie des requêtes à l'acteur, qui les répartit.

Ray est conçu pour le machine learning, le training et l'inférence parallèle. Son architecture repose sur des primitives dédiées : des Tasks (fonctions stateless distribuables) et des Actors (objets stateful distribués), chacun pouvant spécifier ses besoins CPU/GPU.

Mais Ray est souvent Python et souvent cloud-oriented. Mon système, lui, est Rust, local et modulaire. C'est une option si je veux gérer des milliers d'utilisateurs avec des calculs lourds. Mais pour l'instant, je préfère rester sur mes traits, mes abstractions et ma maîtrise.

Ce que font OpenAI, Google, Anthropic

Les géants de l'IA gèrent des millions d'utilisateurs. Ils utilisent probablement des systèmes distribués propriétaires, mélangeant :

• Des brokers de messagerie (Kafka-like),
• Des frameworks de calcul (Ray-like),
• Des bases distribuées (Bigtable, Spanner),
• Des infrastructures cloud (AWS, GCP, Azure).

Mais ils n'en parlent pas. Pas parce qu'ils sont secrets -- mais parce que c'est leur avantage concurrentiel. Leur silence est une leçon.

Le modèle est clairement cloud-centric : chacun dépend d'un cloud propriétaire optimisé pour sa charge IA, ce qui ferme le jeu sur l'accès aux ressources et l'innovation ouverte.

Je veux être différent. Je veux que mAIstrow soit transparente. Que l'on sache comment elle fonctionne, pourquoi elle est conçue ainsi, et ce que j'ai appris en la construisant.

Pourquoi rester sur Rust ?

Alors, pourquoi ne pas basculer vers Kafka, Pulsar ou Ray ?

Parce que Rust est mon outil de maîtrise, pas seulement de performance.

• Performance : Rust est rapide, sûr et sans GC. Idéal pour des systèmes où chaque milliseconde compte.
• Contrôle total : je décide du protocole, de la persistance, de la répartition. Pas de "boîte noire".
• Flexibilité : mes traits me permettent de changer de transport (WebSocket vers Kafka vers Redpanda) sans réécrire tout le système.
• Sobriété : je ne veux pas de 100 dépendances. Je veux un système qui tient sur un vieux laptop.

Kafka, Pulsar, Redpanda, Ray -- ce sont des bêtes de scalabilité. Mais mAIstrow est une bête de souveraineté.

Prochaines étapes

1. Tester un POC avec Redpanda : utiliser rdkafka en Rust, créer des topics, intégrer un trait Transport qui bascule entre WebSocket et Kafka/Redpanda.
2. Explorer ray-rs : si je veux gérer des calculs parallèles lourds, essayer un prototype avec des acteurs Ray en Rust.
3. Rester modulaire : le système reste léger, local et souverain, mais il peut s'inspirer de ces outils sans devenir lourd.

Glossaire rapide

• Kafka : Broker de messagerie distribué, très utilisé pour le streaming.
• Pulsar : Alternative moderne à Kafka, avec séparation stockage/calcul.
• Redpanda : Compatible Kafka, léger, écrit en C++, idéal pour les POCs.
• Ray : Framework de calcul distribué, conçu pour le ML, souvent en Python.
• Rust traits : Mécanisme de polymorphisme, idéal pour abstraire les protocoles.
• POC : Proof of Concept -- un test rapide pour valider une idée.