Évolutivité massive avec la plateforme de gestion de données InterSystems IRIS

Télécharger le guide technologique

Face aux quantités énormes et toujours croissantes de données générées dans le monde, les architectes logiciels doivent accorder une attention particulière à l'évolutivité de leurs solutions. Ils doivent concevoir des systèmes capables, le cas échéant, de gérer plusieurs milliers d'utilisateurs simultanés. Bien qu'elle ne soit pas facile, la conception de l'évolutivité massive est aujourd'hui une nécessité absolue pour la plupart des organisations. Qu'ils prennent en charge l'analyse en temps réel, l'apprentissage automatique, les grands modèles de langage, la génération augmentée par récupération (RAG) ou les applications en réseau, les systèmes de données doivent gérer des volumes, une vitesse et une complexité croissants.

Les architectes logiciels peuvent concevoir des systèmes évolutifs de plusieurs manières. Elles peuvent s'adapter verticalement en utilisant des machines plus grandes dotées de dizaines de cœurs. Ils peuvent utiliser des techniques de distribution de données (réplication) pour s'adapter horizontalement à un nombre croissant d'utilisateurs. Et ils peuvent faire évoluer le volume de données horizontalement en partitionnant leurs données. Dans la pratique, les architectes logiciels emploieront plusieurs de ces techniques simultanément, en arbitrant entre les coûts du matériel, la complexité du code et la facilité de déploiement pour répondre à leurs besoins particuliers.

Ce guide se concentre sur les mécanismes de la mise à l'échelle verticale et horizontale des volumes d'utilisateurs et de données, en tenant compte des performances, des coûts et de l'architecture. Il présente plusieurs options de distribution et de partitionnement des données et/ou du volume d'utilisateurs, en indiquant les scénarios dans lesquels chaque option serait particulièrement utile. Ce guide explique comment InterSystems, un leader mondial dans la technologie des données créatives, et InterSystems IRIS® peuvent simplifier la configuration, l'approvisionnement et l'exploitation des systèmes distribués grâce à la mise à l'échelle.

La manière la plus simple de procéder à une mise à l'échelle est de procéder à une mise à l'échelle "verticale", c'est-à-dire de "monter en puissance" et de se déployer sur une machine plus grande, avec davantage de cœurs de CPU et de mémoire. La plupart des plates-formes de données modernes prennent en charge le traitement parallèle des applications critiques (comme SQL) et comprennent une technologie permettant d'optimiser l'utilisation des processeurs dans les machines multicœurs. La mise à l'échelle verticale permet d'étendre une infrastructure existante sans modifier l'architecture informatique. Elle offre la simplicité, une latence plus faible (déployée sur une seule machine, avec des exigences limitées en matière de réseau) et une compatibilité plus facile avec les systèmes existants.

Cependant, il existe des limites pratiques à ce qui peut être réalisé par la seule mise à l'échelle verticale. D'une part, même la plus grande machine disponible peut ne pas être en mesure de gérer les énormes volumes de données et les charges de travail exigées par les applications modernes, et elle finira par se heurter à des limites strictes en termes d'évolutivité. En outre, le coût du "gros fer" peut être prohibitif. De nombreuses entreprises estiment qu'il est plus rentable d'acheter, par exemple, quatre serveurs à 16 cœurs qu'une machine à 64 cœurs.

La planification de la capacité pour les architectures à un seul serveur peut être difficile, en particulier pour les solutions qui sont susceptibles d'avoir des charges de travail très variables. La capacité à gérer les pics de charge peut entraîner une sous-utilisation inutile en dehors des heures de travail. En revanche, un nombre insuffisant de cœurs peut entraîner un ralentissement des performances pendant les périodes de forte utilisation. En outre, l'augmentation de la capacité d'une architecture de serveur unique implique l'achat d'une nouvelle machine complète. Il est impossible d'ajouter des capacités "à la volée". Et un seul serveur est un point de défaillance unique pour tout un système.

En bref, bien qu'il soit important que les logiciels exploitent tout le potentiel du matériel sur lequel ils sont déployés, la mise à l'échelle verticale seule ne suffit pas pour répondre à toutes les charges de travail, à l'exception des charges relativement statiques.

Pour toutes les raisons susmentionnées, la plupart des organisations qui recherchent une évolutivité massive se déploieront sur des systèmes en réseau, en "étendant" les charges de travail et/ou les volumes de données "horizontalement" en répartissant le travail sur plusieurs serveurs. En règle générale, chaque serveur du réseau sera une machine abordable, mais des serveurs plus grands peuvent également être utilisés, si nécessaire, pour tirer parti de l'évolutivité verticale (voir "Hybrid Vertical-Horizontal Scaling", ci-dessous).

L'évolutivité horizontale offre de multiples avantages qui sont presque inévitables dans les applications modernes de données volumineuses. Ces systèmes élastiques peuvent croître ou décroître de manière dynamique et économique pour répondre à une demande variable, avec du matériel de base et des ressources en nuage modulables en fonction des besoins. La mise à l'échelle horizontale ajoute de la résilience : un système à plusieurs nœuds ne tombe pas en panne lorsqu'un nœud tombe en panne. La mise à l'échelle horizontale est un élément fondamental des systèmes distribués et natifs dans le nuage, permettant une mise à l'échelle massive et une tolérance aux pannes.

Bien qu'essentielle à l'ère du Big Data, la mise à l'échelle horizontale n'est cependant pas sans poser de problèmes. Elle nécessite une orchestration minutieuse, un équilibrage des charges et une distribution des données. Le maintien de la cohérence des données entre les nœuds et la réduction des temps de latence du réseau peuvent poser des difficultés exceptionnelles, en particulier dans les systèmes en temps réel. L'architecture distribuée horizontale est limitée par le théorème CAP (Consistency-Availability-Partitioning). Les compromis sont inévitables et exigent un examen attentif des objectifs principaux par rapport aux objectifs secondaires.

Les architectes de logiciels reconnaîtront qu'il n'y a pas deux charges de travail identiques. Certaines applications modernes peuvent être utilisées simultanément par des centaines de milliers d'utilisateurs, qui effectuent un très grand nombre de petites transactions par seconde. D'autres n'ont qu'une poignée d'utilisateurs, mais interrogent des pétaoctets de données. Ces deux charges de travail sont très exigeantes, mais elles requièrent des approches différentes en matière d'évolutivité. Nous considérons chaque scénario comme distinct.

Pour accélérer la mise à l'échelle, les bases de données utilisent fréquemment la mise en cache, ajoutant une couche temporaire à grande vitesse pour les données fréquemment consultées et évitant les requêtes répétées de la base de données pour les mêmes données. Pour prendre en charge un grand nombre d'utilisateurs ou de transactions simultanées et pour s'adapter au volume d'utilisateurs, InterSystems a introduit sa propre implémentation unique appelée Enterprise Cache Protocol (ECP).

Au sein d'un réseau de serveurs, l'un d'entre eux sera configuré comme serveur de données où les données sont conservées. Les autres seront configurés comme des serveurs d'application. Chaque serveur d'application exécute une instance d'InterSystems IRIS et présente les données à l'application comme s'il s'agissait d'une base de données locale. Les données ne sont pas conservées sur les serveurs d'application. Au lieu de cela, ces serveurs fournissent le cache et la puissance de traitement de l'unité centrale.

Les sessions des utilisateurs sont réparties entre les serveurs d'application, généralement par l'intermédiaire d'un équilibreur de charge, et les requêtes sont satisfaites à partir du cache du serveur d'application local, si possible. Les serveurs d'application ne récupèrent les données du serveur de données qu'en cas de nécessité. ECP synchronise automatiquement les données entre tous les participants au cluster.

Le travail de calcul étant pris en charge par les serveurs d'application, le serveur de données peut se consacrer principalement à la persistance des résultats des transactions. Les serveurs d'application peuvent facilement être ajoutés ou retirés de la grappe en fonction des variations de la charge de travail. Par exemple, dans le cas d'un commerce de détail, vous pouvez ajouter des serveurs d'application pour faire face à la charge exceptionnelle des achats du vendredi noir et les désactiver une fois la période des fêtes terminée. Les serveurs d'application sont particulièrement utiles pour les applications où un grand nombre de transactions doivent être effectuées, mais où chaque transaction n'affecte qu'une partie relativement petite de l'ensemble des données.

Lorsque les requêtes - généralement des requêtes analytiques - doivent accéder à une grande quantité de données, l'"ensemble de données de travail" qui doit être mis en cache afin de prendre en charge efficacement la charge de travail de la requête peut dépasser la capacité de mémoire d'une seule machine. Une technique puissante pour faire face à ces grands ensembles de données est le sharding, qui partitionne physiquement les grandes tables de base de données sur plusieurs instances de serveur. Les applications continuent d'accéder à une table logique unique sur une instance désignée comme maître du nuage de points. Le maître des tessons décompose les requêtes entrantes et les envoie aux serveurs de tessons, chacun d'entre eux détenant une partie distincte des données de la table et des index associés. Les serveurs de stockage traitent les requêtes locales en parallèle et renvoient leurs résultats au serveur de stockage pour agrégation.

Les données sont réparties entre les serveurs de stockage en fonction d'une clé de stockage, qui peut être gérée automatiquement par le système ou définie par l'architecte logiciel sur la base de colonnes de table sélectionnées. Grâce à une sélection minutieuse des clés de stockage, les tables qui sont souvent jointes peuvent être partagées, de sorte que les lignes de ces tables qui seraient normalement jointes sont stockées sur le même serveur de stockage. Cette colocalisation permet aux tables d'être jointes localement sur chaque serveur de stockage, ce qui maximise la parallélisation et les performances. Au fur et à mesure que les volumes de données augmentent, il est possible d'ajouter facilement de nouveaux ensembles de données. Le sharding est totalement transparent pour l'application et les utilisateurs.

Il n'est pas nécessaire de sharder toutes les tables. Par exemple, dans les applications analytiques, les tables de faits (par exemple, les commandes dans un scénario de vente au détail) sont généralement très volumineuses et seront divisées. Les tableaux de dimensions beaucoup plus petites (par exemple, produits, points de vente, etc.) ne le seront pas. Les tables non partagées sont conservées sur le maître des tessons. Si une requête nécessite des jointures entre des tables sharded et non sharded, ou si des données provenant de deux shards différents doivent être jointes, la technologie d'InterSystems utilise un mécanisme ECP très efficace pour satisfaire correctement et efficacement la requête. Dans ce cas, seules les lignes dont on a besoin sont partagées entre les unités, au lieu de diffuser des tables entières sur le réseau, comme le feraient d'autres technologies. La technologie InterSystems améliore de manière transparente l'efficacité et la performance des charges de travail des requêtes Big Data grâce au sharding, sans limiter les types de requêtes qui peuvent être satisfaites.

Les architectures InterSystems permettent des jointures multi-tables complexes lors de requêtes sur des ensembles de données distribués et partitionnés - sans nécessiter de cosharding, de réplication de données ou de diffusion de tables entières à travers les réseaux.

Les solutions de données modernes doivent souvent prendre en charge simultanément un taux de transaction élevé (volume d'utilisateurs) et l'analyse de grands volumes de données. Un exemple : une application de gestion de fortune privée qui fournit des tableaux de bord résumant les portefeuilles et les risques des clients, en temps réel, sur la base des données actuelles du marché.

La technologie d'InterSystems est inhabituelle en ce qu'elle permet de réaliser simultanément des requêtes analytiques et des transactions ingestives. Il permet de créer des applications de traitement transactionnel et analytique hybride (HTAP) - ou translytiques - en combinant l'utilisation de serveurs d'applications et de la mise en commun des données (sharding). Des serveurs d'application peuvent être ajoutés à l'architecture (voir figure 2) afin de répartir la charge de travail sur le maître de stockage. Les charges de travail et les volumes de données peuvent être mis à l'échelle indépendamment les uns des autres, en fonction des besoins de l'application.

Lorsque les applications exigent une évolutivité maximale (par exemple, si un modèle prédictif doit évaluer chaque enregistrement d'une grande table alors que de nouveaux enregistrements sont ingérés et interrogés en même temps), chaque bloc de données individuel peut jouer le rôle de serveur de données dans un modèle ECP. Les serveurs d'application qui partagent les charges de travail sur les ensembles de données sont appelés ensembles de requêtes. Ceci, combiné avec les mécanismes transparents pour assurer la haute disponibilité d'un cluster InterSystems IRIS, fournit aux architectes de solutions tout ce dont ils ont besoin pour satisfaire les exigences uniques d'évolutivité et de fiabilité de leur solution.

De nombreux systèmes modernes combinent les échelles verticale et horizontale. Par exemple, une base de données peut être exécutée sur des nœuds puissants à échelle verticale tout en distribuant les requêtes sur des serveurs d'application à échelle horizontale. Les modèles hybrides offrent souplesse et résilience, et peuvent être adaptés à des charges de travail et à des besoins spécifiques.

Une mise à l'échelle efficace nécessite une conception architecturale réfléchie, qui influence la mise à l'échelle et est influencée par elle :

• Le partitionnement des données, principalement les stratégies de partage et de réplication, aide à gérer les grands ensembles de données (voir "Mise à l'échelle horizontale par volume de données : partage", ci-dessus).
• Le choix entre les services sans état et les services avec état détermine les décisions de mise à l'échelle. Les services sans état sont plus faciles à faire évoluer horizontalement.
• L'équilibrage de la charge répartit le trafic de manière égale entre les nœuds, de sorte qu'aucun d'entre eux n'est submergé.
• Les stratégies de location déterminent comment des utilisateurs distincts partagent l'accès à une plateforme de données et éventuellement à son infrastructure, tout en maintenant une séparation logique des données de chaque utilisateur.
• Les modèles de cohérence, contraints par le théorème CAP (cohérence, disponibilité, tolérance de partition), guident les compromis dans les systèmes distribués.

Les plates-formes de données évolutives sont essentielles à la réussite dans les secteurs où InterSystems s'emploie à résoudre les problèmes de ses clients. La plus importante est celle des données de santé, où InterSystems travaille souvent à très grande échelle, gérant les dossiers des patients, l'imagerie médicale et d'autres données de diagnostic, ainsi que le suivi en temps réel, parmi un grand nombre d'applications informatiques médicales.

InterSystems est également actif dans d'autres applications de données, y compris la finance (traitement des transactions, détection des fraudes et rapports à des fins réglementaires) et la chaîne d'approvisionnement (suivi des expéditions, optimisation des livraisons et gestion des stocks).

InterSystems a joué un rôle dans la mise en place de solutions de données dans toutes ces industries, aidant les organisations à atteindre leurs objectifs en matière de données, de performance et de fiabilité à grande échelle.

Le paysage des plates-formes de données évolutives continue d'évoluer à mesure que de nouvelles applications et de nouveaux systèmes de données sont mis en place :

• Les architectures cloud-natives, comme Kubernetes et les modèles sans serveur, simplifient la mise à l'échelle horizontale.
• La mise à l'échelle pilotée par l'IA avec des algorithmes prédictifs optimise l'allocation des ressources.
• L'informatique en périphérie distribue le traitement au plus près des sources de données, ce qui réduit les temps de latence.
• Le maillage des données et les architectures fédérées favorisent la propriété décentralisée des données et l'évolutivité.
• Les architectures de données permettent de surmonter les silos et la fragmentation des données.

L'évolutivité massive n'est plus une option, c'est une nécessité pour les applications de données modernes. Cette mise à l'échelle est particulièrement nécessaire pour les applications de traitement transactionnel et analytique hybride (HTAP) qui doivent gérer simultanément de grandes charges de travail et de gros volumes de données, éventuellement avec un grand nombre d'utilisateurs simultanés.

La mise à l'échelle verticale offre simplicité et performance pour les petits systèmes, tandis que la mise à l'échelle horizontale apporte l'élasticité et la résilience essentielles pour les applications à grande échelle. Les architectures spécialisées peuvent adapter le fonctionnement du système à différentes combinaisons d'exigences et de priorités. En comprenant les forces et les limites de chaque approche, les organisations peuvent concevoir des architectures de données qui répondent aux besoins actuels et s'adaptent à la croissance future.