Bonjour,

L’alpha de Caliopen a été en maintenance pendant un trop long moment et il me faut expliquer les raisons de cette situation. Ce post est un peu technique, je vais cependant essayer de ne pas (trop) vous saouler.

Un choix de conception dans la gestion des index sur elasticsearch, composant logiciel permettant notamment les recherches, est à la racine de l’interruption de service. La volonté initiale était d’isoler strictement les données des utilisateurs dans un index dédié à chacun. Louable volonté dans le contexte d’un produit tel que Caliopen, axé sur la confidentialité : il serait malvenu qu’un utilisateur voie les messages et contacts d’autres utilisateurs partageant un même index…

Cependant cette implémentation technique a vite montré des limites, dès le lancement de l’alpha. La gestion du cluster elasticsearch posait de plus en plus de soucis au fur et à mesure des changements de version et de l’arrivée de nouveaux utilisateurs de Caliopen. Ce défaut de conception m’était connu depuis de nombreux mois, et j’avais envisagé un changement important pour adresser ce point (https://github.com/CaliOpen/Caliopen/pull/747). L’impact important et les risques de cette modification m’ont fait hésiter, ajourner le problème et finalement abandonner l’idée (quelques ajustements sur la configuration du cluster ayant permis de retrouver un comportement moins chaotique sur l’alpha).

Lors du passage à la version 0.12.0, nous avions de gros traitements à faire sur les index afin d’uniformiser ce que nous appelons les identités d’un utilisateur (locales et distantes). Ces traitements ont largement sollicité le cluster elasticsearch et ont mis de nouveau en exergue le défaut de conception : il était impossible de réaliser les traitements en question, les nœuds du cluster tombant au fur et à mesure.

Le souci est le nombre d’index et leur petite taille, que nous demandions de gérer à un cluster ne comportant que 5 nœuds pour les données. Si nous avions déployé 90 nœuds alors nous n’aurions pas eu ce souci, mais 90 machines pour 2000 comptes utilisateurs n’est pas une solution économiquement viable pour une mise à l’échelle qui est dans les ambitions de Caliopen : savoir gérer plusieurs centaines de milliers d’utilisateurs sur certaines instances.

Comment adresser ce souci ?

Il faut faire moins d’index regroupant les données de plusieurs utilisateurs… Aïe je sens les trolls se préparer. Mais elasticsearch est un formidable outil d’indexation sachant très bien filtrer les informations, si on le lui demande correctement. L’isolation des données peut être, mais elle sera gérée autrement que par la manière dont celle-ci est stockée par elasticsearch.

Nous avons alors identifié 2 solutions techniques pour réaliser un tel filtrage :

1. Définir des alias d’index pour chaque utilisateur qui inclue un filtrage de type user_id = xxxxxxxx pointant sur l’index affecté a l’utilisateur.
2. Ou modifier toutes nos requêtes utilisant les fonctions de recherches pour filtrer explicitement.

La première solution est plus facile, mais a pour moi l’inconvénient de rendre la stricte isolation des données d’un utilisateur dépendante d’une bonne définition de l’alias. Si nous nous loupons dans la création d’un alias, d’autres données que celle de l’utilisateur pourraient devenir visibles dans l’interface. La seconde modification est plus lourde et c’est sur celle-ci que j’avais commencé à travailler en Décembre 2017.

Après quelques réflexions, et surtout beaucoup d’expérimentations pour vérifier que limiter le nombre d’index permettait réellement de retrouver un comportement correct du cluster elasticsearch, la seconde solution a repris vie et a été conduite jusqu’au bout pour être mise en œuvre réellement. Une version 0.12.1 a donc été déployée pour corriger en grande partie ce souci, d’autres problèmes ayant été identifiés (suggestion des emails dans la composition, logique de définition des index à la création d’un utilisateur), suivie très rapidement par une version 0.12.2 qui a été finalisée et mise en ligne pour vous permettre de retrouver un niveau fonctionnel complet.

Chamal