J’ai aujourd’hui le plaisir de vous annoncer la publication d’un nouveau rapport de performance assez différent de ce que nous avons proposé par le passé. Avant de commencer, je tiens à rappeler que les tests de benchmarks ne sont pas nouveaux chez Nuxeo. Ceux qui nous connaissent déjà savent peut-être que nous avons déjà réalisé plusieurs tests de performance sur des référentiels contenant 1 milliard d’objets et que nous testons en continu les performances de nos builds pour nous assurer de la flexibilité et de la robustesse de notre plateforme lors de chaque release. Et dans la lignée de notre approche “cuisine ouverte” et de notre héritage open source, toutes ces informations sont documentées et disponible au public sur benchmarks.nuxeo.com (nous contacter pour le mot de passe).

Mais alors, qu’est-ce qui rend ce test si différent des autres ?

Une approche radicalement différente

La première différence, et la plus évidente, concerne l’ampleur de notre test. Nous souhaitions dépasser les 10 milliards d’objets. Mais ce n’est que la partie émergée de l’iceberg.

Notre objectif avec ce projet était très différent des exercices théoriques habituels. Plusieurs clients nous ont contactés pour nous faire part de leur envie de faire évoluer leurs référentiels de contenu Nuxeo, dans le Cloud, pour leur permettre de dépasser cette barre des 10 milliards d’objets. Et ils se sont tournés vers nous pour obtenir des conseils et des bonnes pratiques afin d’exploiter et opérer de manière optimale la plateforme Nuxeo avec de tels volumes de contenu. Cela reflète l’évolution des contenus, tant dans leur nature que dans leur type, ainsi que leur importance croissante pour les entreprises aujourd’hui. Certaines accumulaient lentement des documents, images scannées et autres contenus classiques sur de longues périodes de temps (10, 15 ou même 20 ans) dans des solutions de gestion de contenu (ECM) traditionnelles. En redoublant d’efforts, elles parvenaient à faire évoluer ces systèmes pour y stocker jusqu’à 8/9 milliards d’objets. L’un de nos clients devrait même franchir la barre des 15 milliards d’objets dans les trois prochaines années.

Fun Fact: si vous créez 1000 documents par seconde, toutes les heures de chaque jour, il vous faudra à peu près 100 jours pour générer 10 milliars d’objets.

Ainsi, pour proposer des conseils et bonnes pratiques vraiment pertinents, nous ne pouvions pas nous contenter d’une approche trop théorique et contrôlée, et il ne suffisait pas de simuler l’ingestion de documents dans une base de données NoSQL. Tout d’abord, nous avons déployé une véritable instance de notre service Nuxeo Cloud, avec un object store Amazon S3, une base de données MongoDB Atlas (NoSQL, naturellement) et des index Elasticsearch. Ensuite, nous avons commencé à créer de vrais contenus (en grande quantité) avec les métadonnées associées. Au total, il s’agit donc de 11,3 milliards de fichiers binaires avec leurs métadonnées : une tâche qui nous a, à elle seule, pris plusieurs jours. Ces contenus étaient basés sur des exemples réels déjà vus chez nos clients et reflétaient les cas d’utilisation les plus extrêmes auxquels ils doivent faire face, en particulier dans le domaine des services financiers. On y trouve par exemple des photos d’identité, des relevés de compte, des documents de gestion, et même des correspondances avec les clients.

Et puisque notre objectif n’était pas de tester un simple service de stockage, mais bien un véritable déploiement de l’application Nuxeo, nous avons activé toutes les fonctionnalités habituelles, notamment en matière d’indexation et de sécurité. Nous avons également intégré des scénarios de test réels, avec des charges de travail mixtes, une réindexation complète ainsi que des actions en masse ou des uploads d’importants volumes de contenus.

Un projet en deux phases

Ce qui distingue également ce test de performance, c’est qu’il s’agit en fait d’un projet en deux phases :

Dans la première phase du projet, nous avons travaillé sur l’évolution de notre instance à référentiel unique, basée sur notre service Nuxeo Cloud : pour résumer, une seule base de données (sans sharding), un ensemble d’index et un object store. Le but de cette première phase était d’identifier les éventuelles baisses de performance lors de l’ingestion de données ou de leur utilisation. Nous souhaitions également identifier les composants clés et les métriques essentielles à surveiller afin de déterminer les moments où il devient nécessaire de faire évoluer les différents composants de l’architecture Nuxeo Cloud. Nous avons réalisé des tests à toutes les étapes, d’abord avec un milliard d’objets, puis, deux, puis trois. Nous sommes parvenus à mettre en place des architectures de référence pour des systèmes à référentiel unique sur AWS, capables de gérer respectivement 1, 2 et 3 milliards d’objets, et à répertorier les informations relatives au matériel, aux configurations et aux performances anticipées.

À ce sujet, nous vantons depuis de nombreuses années les mérites et les avantages du NoSQL et de MongoDB. Pour l’expliquer, il convient de préciser qu’une seule instance de base de données NoSQL est capable de gérer jusqu’à 3 milliards d’objets (et plus encore sans sharding). Et pour ceux qui se demandent pourquoi nous avons arrêté le test à 3 milliards, il ne s’agit pas d’une limite impossible à dépasser pour un système reposant sur un référentiel unique. Mais tout simplement parce que nous avions le sentiment que c’était suffisant pour les clients avec un seul référentiel.

Tout ceci nous amène à la phase 2. Pour celle-ci, nous avons déployé un système à référentiels multiples qui, selon nous, représentait bien les besoins et exigences d’une grande entreprise internationale. Nous avons ainsi déployé trois référentiels distincts :

  • Un référentiel géographique actif (Ouest des États-Unis)
  • Un second référentiel géographique actif (Est des États-Unis)
  • Un référentiel d’archivage

Il s’agit d’une répartition assez efficace du point de vue des clients. Tout d’abord, parce qu’ils peuvent avoir besoin de créer des référentiels régionaux basés sur des exigences en matière de confidentialité ou de localisation des données ou encore de disponibilité. Ensuite, parce qu’ils peuvent vouloir séparer les données actives et les archives afin de les stocker dans des référentiels différents proposant différents niveaux de performances.

Chaque référentiel s’appuie sur sa propre instance de base de données (MongoDB Atlas). Il s’accompagne également d’un jeu d’index (Elasticsearch) et d’un object store (Amazon S3). Même si nous supportons Amazon Glacier et que cette solution peut constituer une option pertinente pour le stockage d’archives dans le Cloud, nous n’avons pas utilisé de services d’archivage profond dans le cadre de nos tests. Mais ce qu’il faut retenir ici, c’est que nous sommes en mesure de créer des référentiels locaux (dans n’importe quel centre de données Amazon, GCP ou Azure) pour les clients internationaux devant stocker leurs contenus dans des régions bien définies, et de leur proposer des solutions de stockage avec les métadonnées et les index de recherche correspondants. Les données ne sont pas partagées entre ces référentiels séparés, mais il est tout de même possible d’accéder en toute transparence à l’ensemble des contenus (en fonction des droits d’accès attribués) directement depuis l’interface Nuxeo.

Comme lors de la première phase, nous avions une idée bien précise des livrables souhaités. Ici, nous souhaitions proposer des résultats illustrant les performances de Nuxeo Cloud sur plus de 10 milliards d’objets. Et pour aller plus loin, nous avons également mené une série de tests en conditions réelles… sur 11 milliards d’objets. En plus de ces tests de performance, nous avons développé une architecture de référence en matière de sharding à destination de nos clients, accompagnée de conseils et de bonnes pratiques pour mettre en place un système à référentiels multiples.

Et nous en avons profité pour créer un nouvel outil venant supporter ces tests. L’idée n’était pas de proposer un test de performance figé, mais plutôt d’être capable de mesurer les performances de la plateforme en continu afin de garantir sa pérennité. Si vous avez envie de voir un système opérationnel gérant plus de 10 milliards d’objets dans le Cloud, nous vous ferons une démonstration avec plaisir.

Où puis-je trouver les résultats ?

Voici un petit aperçu : une capture de notre tableau de bord indiquant clairement notre état d’avancement : 11,34 milliards de documents.

11 milliars de documents

Mais ce tableau de bord contient bien d’autres informations. Au cours des prochaines semaines, Thierry Delprat, CTO de Nuxeo, publiera une série d’articles pour présenter en détail notre projet, partager les résultats de nos tests et nous faire partager son expérience vis-à-vis du projet. Et si vous n’avez pas envie d’attendre, nous vous avons préparé un rapport technique détaillé, déjà disponible en téléchargement.

Je vous souhaite une bonne lecture et vous invite à vous joindre à moi pour féliciter Thierry et son équipe pour cette réussite à la fois importante pour nous et riche en enseignements pour l’ensemble du secteur.