L'architecture qui accompagnera notre première beta

Deux semaines de plus, et Scylla continue d’avancer. Petit point aujourd’hui sur notre architecture actuelle, qui va accompagner notre première Beta !

Rétrospective et Contexte

Scylla a longtemps été fait d’un seul bloc, une API qui devait gérer les calls gRPC, la logique métier, les interactions avec la base de données, etc.

Mais l’ajout des agents, qui était la dernière étape avant cette Beta, nous a fait nous poser beaucoup de questions sur notre architecture. En effet, la connexion entre un ou plusieurs agents et l’API impliquait beaucoup plus de code que nous ne l’imaginions ; le pool d’agents (channels mpsc, connexion gRPC) et la gestion de cette dernière (heartbeats, crash, …) représentaient une quantité de code et une complexité non négligeables, qui plus est sans vraiment de lien avec le rôle d’une API.

Problématique

Une réponse presque évidente se profilait : séparer cette logique “d’orchestration” des agents dans une crate à part entière, sauf que cela ne ferait que déplacer le problème : comment l’API communiquerait-elle avec ce service externe ?

Il nous fallait donc séparer le code correctement mais aussi trouver un moyen fiable et indépendant de gérer la communication entre tous ces services.

Notre solution

Comme vous pouvez le voir sur ce diagramme, notre architecture s’articule autour de deux éléments principaux : le core et le broker.

Concrètement, nous avons isolé un core : une crate qui regroupe la logique métier, en quelque sorte un contrat d’interaction avec la base de données, et qui est importée par l’ensemble des autres services (API, recorder, etc.). Le reste du code se construit autour, chaque service importe ce noyau commun plutôt que de réimplémenter ses propres règles.

Pour autant, les services n’ont aucun lien direct, et c’est volontaire ; nous voulons une structure scalable en O(1), pas O(n).

C’est ici que le broker joue un rôle majeur. Si nous décidons d’ajouter un service, il n’aura qu’à s’y connecter, écouter les évènements qui l’intéressent et publier ceux dont les autres services ont besoin. On peut de cette manière générer des séries d’évènements en cascade entre les services sans complexité supplémentaire.

Enfin, en ce qui concerne l’utilisation du core, les agents font exception. Leur rôle étant d’exécuter des pipelines, cela représenterait un vecteur d’attaque, il était donc impératif de leur empêcher l’accès à la base de données. Nous avons donc introduit un service tampon, le recorder, dont le rôle est d’écouter les agents et de persister leurs données en base à leur place. Cette indirection nous permet de garder un point d’entrée maîtrisé vers la db, tout en laissant aux agents la liberté d’évoluer indépendamment.

Et après ?

Même si cette nouvelle architecture nous a permis de répondre à de vraies problématiques, nous sommes conscients de ses limites et des nouveaux défis qu’elle soulève, notamment en termes de sécurité. Ce n’est qu’une étape et nous travaillons activement dessus pour la prochaine Beta !

Stay tuned!

• Suivez-nous sur LinkedIn
• Rejoignez notre serveur Discord