OVH & SentiOne
sentione_icon1

+ de 120
nœuds physiques Elasticsearch

sentione_icon2

+ de 70 To
de données migrées

Performances SentiOne améliorées

6 fois plus
performant

Le contexte

SentiOne, reconnu par Deloitte comme l'une des entreprises technologiques à la croissance la plus rapide en Europe centrale, propose une plateforme d'intelligence artificielle (IA) conversationnelle unique. Celle-ci permet aux professionnels de suivre les discussions en ligne, d'interagir avec leurs visiteurs et d'automatiser le service client sur tous les canaux web.

Alors que la plupart des entreprises spécialisées dans l’IA qui fournissent des chatbots rencontrent des difficultés avec les ressources d’entraînement, SentiOne recourt à des discussions réelles sur Internet pour former son moteur NLU (Natural Language Understanding). À l’aide d’un vaste ensemble de données, collectées tout en développant un outil de social listening, SentiOne est capable d’entraîner des moteurs de deep learning d'une précision exceptionnelle.

« Grâce à nos années de collaboration avec OVHcloud, nous avons été en mesure de faire évoluer notre activité sereinement et de traiter des téraoctets de données, permettant ainsi à nos clients d’obtenir un produit de qualité.»


Michał Brzezicki, cofondateur et responsable technique chez SentiOne

La quantité de données à collecter et à analyser en temps réel augmentant constamment, l'entreprise a été confrontée à de nombreux défis en matière d’architecture et de logiciel. D'une part, les performances de son cluster Elasticsearch ont diminué alors que celui-ci est indispensable pour une expérience client fluide sur la plateforme. De plus, SentiOne a également remarqué que la répartition d’utilisation de certains clusters était inégale : tandis que certains étaient surchargés, d'autres restaient inutilisés.

Afin d’améliorer la vitesse de sa plateforme d'IA conversationnelle, SentiOne a entrepris un vaste plan de maintenance dans le but de migrer son matériel informatique et de mettre à jour son logiciel. Michał Brzezicki, cofondateur et responsable technique de SentiOne, nous explique comment son équipe est parvenue à réaliser ce projet complexe.

 

Le défi

L'équipe d'experts de SentiOne a découvert plusieurs raisons pouvant conduire à la dégradation du cluster Elasticsearch : un processeur manquant de puissance, des performances de stockage insuffisantes, des pannes matérielles, une configuration logicielle inadéquate ou des problèmes de connectivité.

Le réseau.
La technologie Elasticsearch s’accompagne de problèmes de connectivité. Par exemple, lorsque le réseau devient instable entre deux nœuds du cluster, l'ensemble est ralenti. Afin que les connexions entre les nœuds restent fiables et sécurisées, SentiOne a fait le choix d'utiliser le réseau privé vRack, une solution conçue par OVHcloud.

Les problèmes de réseau ont été presque définitivement résolus une fois cette solution activée. En effet, le vRack a permis à SentiOne de créer des connexions stables entre les nœuds, indépendamment du réseau public.

Pour mieux appréhender l’état de son architecture, l'équipe de SentiOne utilise Grafana et le plugin Sensu, afin de stocker toutes les données concernant l'état du système et d’Elasticsearch. Grâce aux interfaces publiques et au vRack, aucune anomalie n'a été enregistrée. L'équipe a donc conclu que les problèmes de performance ne provenaient pas du réseau.

Le processeur.
Tout en étudiant les causes potentielles des problèmes de performance, l'équipe s'est penchée sur l'utilisation du processeur et la gestion des threads. L'utilisation générale du CPU dans le cluster approchait les 80 %, ce qui a été jugé correct : cela indiquait une bonne utilisation des ressources en matière de coûts. Cependant, l'équipe a remarqué que le cluster était nettement plus lent lors du rééquilibrage.

Lors des ralentissements, l'utilisation du processeur était faible et limitée à un seul noyau. Une analyse plus approfondie a révélé que le CPU consacrait la majeure partie de son temps aux IOPS. Étant donné que l'équipe avait déjà exclu le réseau comme cause du ralentissement, elle a donc enquêté sur le stockage.

Le stockage.
La création d'un tableau de bord Grafana avec Sensu, pour mesurer le temps dédié aux IOPS, a permis à l'équipe de SentiOne de trouver des réponses. Le graphique obtenu montrait clairement combien de temps le processeur passait sur les IOPS sur une période donnée. La réponse : 100 % du temps !

Cela explique également le ralentissement du cluster lors du rééquilibrage. Si un nœud aléatoire était soumis à une forte quantité d’IOPS, copier ce shard ne faisait qu'empirer les choses.

La configuration du cluster Elasticsearch.

L'infrastructure de SentiOne était basée sur des nœuds « chauds et froids ». Les nœuds chauds hébergeaient des indices populaires et régulièrement consultés, tandis que les nœuds froids contenaient des données rarement utilisées. Si l’ajout d’autres réplicas d’indices chauds semblait une solution évidente pour équilibrer la charge, ce n’est finalement pas le cas. Les requêtes étaient assignées aléatoirement à des shards : si une requête conséquente était répétée (des groupes différents d’une même requête par exemple), tous les réplicas étaient surchargés par des calculs similaires ou identiques. De plus, la version d’Elasticsearch installée sur le cluster de SentiOne ne disposait pas de l’Adaptive Replica Selection (ARS). Il est devenu évident que l’ajout de nouveaux nœuds au cluster ne permettrait pas d’augmenter la performance, sauf en cas de mise à jour du logiciel par l’équipe.

Après avoir identifié les causes responsables de la dégradation des performances du cluster Elasticsearch, l’équipe informatique a été en capacité de planifier les changements logiciels, architecturaux et matériels permettant d’améliorer la réactivité de la plateforme.

 

La solution

La meilleure option aurait été le remplacement du matériel et la mise à l’échelle horizontale des clusters. Disposant d’un budget important mais limité, SentiOne a commencé par assainir l’utilisation du cluster.

Avant que l'équipe ne soit prête à migrer vers une nouvelle infrastructure de serveurs dédiés, plusieurs autres actions ont dû être effectuées.

La fragmentation des données.
Tout d’abord, les ingénieurs de SentiOne ont analysé les requêtes des utilisateurs et leur impact sur les performances du cluster. Le lien entre le temps d’interrogation et le nombre de shards interrogés est facilement explicable : plus ces derniers sont nombreux, plus le processus général prend du temps.

Afin de réduire le temps d’interrogation, SentiOne a décidé de diviser les données en shards plus petits – moins de 30 Go. Une fois interrogées, les informations d'un seul shard pourraient théoriquement tenir dans le cache du système de fichiers en RAM.

Après avoir étudié les périodes d’interrogation du système par les utilisateurs, SentiOne a également modifié la façon dont les données étaient réparties en indices. L’entreprise a donc divisé celles-ci selon le comportement des clients, minimisant ainsi le nombre de fragments par requête et réduisant l'intervalle entre les indices hebdomadaires et mensuels.

La mise en pratique.
L'équipe de SentiOne a modifié les points sur lesquels le cluster Elasticsearch était interrogé, optimisé les appels et modifié l'interface des utilisateurs afin que ceux-ci n'aient pas l'impression que le système se bloque. Elle a également introduit des contrôles qui bloquent les requêtes trop lourdes, en se concentrant sur les temps d'exécution selon des délais variables. Auparavant, une seule requête lourde pouvait dégrader les performances de l'ensemble du cluster : ce contrôle de sécurité était donc une nécessité, même s'il doit limiter l’expérience de certains utilisateurs.

Les changements d’architecture.
Avec la nouvelle version du cluster, SentiOne a abandonné l'approche « chaud et froid » pour plusieurs raisons. Tout d'abord, il est difficile de distinguer clairement les indices chauds et froids. À quel moment peut-on le faire ? Ensuite, les nœuds froids utilisaient très peu d’IOPS avec des pics d'utilisation du processeur. Les nœuds chauds étaient surchargés par les IOPS, mais n’utilisaient pas certaines ressources du CPU. Ces éléments représentaient un gaspillage de ressources et, par conséquent, une perte d’argent. Enfin, trouver le bon équilibre entre les nœuds chauds et froids s'est avéré délicat, ce qui a entraîné une augmentation des dépenses inutiles.

SentiOne Elasticsearch

Un nouveau matériel.
L’ancienne architecture se composait de 3 nœuds maîtres, 82 nœuds chauds et 42 nœuds froids, tous équipés de la même solution de stockage : 2 unités Intel SSD DC S4500. L'objectif principal de la migration logicielle étant d'améliorer les performances de stockage, SentiOne a choisi des serveurs de la gamme Advance – les modèles Advance-2 avec disques NVMe – pour ses nœuds de données.

La technologie NVMe est une combinaison de SSD, de bus PCIe et du protocole NVMe, conçue pour combler l'écart de performance entre le calcul et le stockage.

La connexion entre les SSD peut influer de manière significative la latence observée par l'utilisateur au niveau de l'application, tandis que deux éléments, l’interface physique (PCIe) et le protocole (NVMe), déterminent la performance globale. Une liaison PCIe 3.0 x 4 offre un débit près de cinq fois supérieur à celui du SATA le plus rapide et près de trois fois supérieur à celui de la meilleure interface SAS. Le protocole NVMe offre jusqu'à 64 000 files d'attente, garantissant ainsi la capacité de l’interface à traiter le nombre élevé d’IOPS produit par les processeurs multicœurs.

Afin de déployer le nouveau cluster de 121 nœuds de données et 3 nœuds maîtres, SentiOne a passé deux mois à développer, tester et planifier sa solution. Même si la migration et la mise à niveau d'Elasticsearch n'ont pas été sans difficulté, et bien qu'elles aient entraîné une indisponibilité du cluster pendant six heures, elles ont néanmoins apporté les avantages escomptés.

 

Le résultat

La plateforme omnicanal de SentiOne administre des milliards de discussions sur des milliers de sources web. Pour fournir aux entreprises des informations sur leur public et l'automatisation du service client via l’intelligence artificielle, la solution collecte, traite et analyse d'énormes quantités de données. C’est pour cette raison qu’elle se doit d’être performante.

Le nouveau cluster, créé sur des serveurs dédiés Advance-2 équipés de disques NVMe, a changé la donne pour SentiOne. La migration matérielle a immédiatement rendu la plateforme plus performante : le cluster est désormais six fois plus rapide !

Durée moyenne des requêtes avec le cluster elasticsearch

La mise à jour de la version d'Elasticsearch – qui inclut l'activation de la fonctionnalité ARS – a permis au cluster de fonctionner de manière uniforme et de répartir les charges entre plusieurs nœuds, lorsque celles-ci sont plus élevées. L'équipe a calculé que pendant les opérations courantes, la charge approche les 50 % et ne dépasse pas les 80 % en cas d’instabilité. SentiOne dispose ainsi d’une marge suffisante pour les futures mises à échelle et les nouvelles fonctionnalités.

 

« D’un point de vue budgétaire, le processus de migration s'est avéré très avantageux. En effet, les coûts de fonctionnement du cluster ont été réduits d'environ 5 % et les performances se sont nettement améliorées. »


Michał Brzezicki, cofondateur et responsable technique chez SentiOne