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

Télécharger le guide

Face aux volumes de données immenses — et en croissance continue — générés dans le monde, les architectes logiciels doivent accorder une attention particulière à l’évolutivité de leurs solutions. Ils doivent concevoir des systèmes capables, lorsque c’est nécessaire, de gérer des milliers d’utilisateurs simultanés. Même si l’exercice est complexe, viser une évolutivité massive est aujourd’hui une nécessité pour la plupart des organisations.
Qu’il s’agisse d’analytique en temps réel, de machine learning, de grands modèles de langage (LLM), de retrieval-augmented generation (RAG) ou d’applications interconnectées, les systèmes de données doivent absorber des volumes, des vitesses et une complexité en hausse.

Les architectes logiciels peuvent concevoir des systèmes évolutifs de plusieurs façons. Ils peuvent augmenter la capacité verticalement, en s’appuyant sur des machines plus puissantes avec des dizaines de cœurs. Ils peuvent recourir à des techniques de distribution des données (réplication) pour passer à l’échelle horizontalement lorsque le nombre d’utilisateurs augmente. Et ils peuvent faire évoluer les volumes de données horizontalement en partitionnant les données. En pratique, ils combinent souvent plusieurs de ces approches, en arbitrant entre coûts matériels, complexité du code et facilité de déploiement, selon leurs besoins.

Ce guide se concentre sur les mécanismes de montée en charge verticale et horizontale — à la fois pour le nombre d’utilisateurs et pour les volumes de données — en tenant compte des performances, des coûts et de l’architecture. Il présente plusieurs options pour distribuer et partitionner les données et/ou la charge utilisateurs, avec des exemples de contextes où chaque option est particulièrement utile. Enfin, il explique comment InterSystems, leader mondial des technologies de données, et InterSystems IRIS® peuvent simplifier la configuration, le provisionnement et l’exploitation de systèmes distribués à l’échelle.

La façon la plus simple de passer à l’échelle consiste à monter en charge verticalement (scale up) : déployer sur une machine plus puissante, avec davantage de cœurs CPU et de mémoire. La plupart des plateformes de données modernes prennent en charge l’exécution parallèle de fonctions critiques (comme SQL) et intègrent des mécanismes pour optimiser l’utilisation des CPU sur des machines multi-cœurs.
La montée en charge verticale renforce l’infrastructure existante sans changer l’architecture de calcul. Elle présente plusieurs avantages : simplicité, latence plus faible (tout est sur une seule machine, avec peu de dépendance au réseau) et compatibilité plus facile avec les systèmes existants.

Cependant, la montée en charge verticale a des limites pratiques. D’abord, même les plus grosses machines disponibles peuvent ne pas suffire face aux volumes de données et aux charges de travail des applications modernes, et elles finissent par atteindre un plafond d’évolution. Ensuite, ces machines « big iron » peuvent coûter très cher. Beaucoup d’organisations trouvent plus économique d’acheter, par exemple, quatre serveurs 16 cœurs plutôt qu’une seule machine 64 cœurs.

Le dimensionnement d’une architecture sur un serveur unique est aussi délicat, surtout quand les charges varient fortement. Prévoir une capacité capable d’absorber les pics peut conduire à une sous-utilisation coûteuse en heures creuses. À l’inverse, un nombre de cœurs insuffisant peut faire chuter les performances lors des périodes de forte activité. Par ailleurs, augmenter la capacité d’une architecture mono-serveur implique souvent d’acheter une nouvelle machine complète : impossible d’ajouter de la capacité “à la volée”. Enfin, un serveur unique constitue un point de défaillance unique pour tout le système.

En résumé, même s’il est essentiel d’exploiter pleinement le matériel sur lequel un logiciel est déployé, la montée en charge verticale ne suffit pas — sauf pour des charges relativement stables.

Pour toutes ces raisons, la plupart des organisations qui visent une forte évolutivité s’appuient sur des systèmes interconnectés (scale out) et font monter en charge « horizontalement » les traitements et/ou les volumes de données, en répartissant le travail sur plusieurs serveurs. En général, chaque serveur du réseau est une machine abordable, mais on peut aussi utiliser des serveurs plus puissants, si besoin, afin de cumuler montée en charge horizontale et verticale (voir « Montée en charge hybride vertical/horizontal » plus loin).

La montée en charge horizontale apporte plusieurs bénéfices devenus quasiment incontournables pour les applications data à grande échelle. Ces systèmes élastiques peuvent grandir ou réduire leur capacité de façon dynamique et économique pour s’adapter à une demande variable, en dimensionnant à la volée du matériel standard ou des ressources cloud. Elle renforce aussi la résilience : dans un système multi-nœuds, l’ensemble ne tombe pas en panne parce qu’un nœud est indisponible. C’est un pilier des architectures cloud-native et distribuées, qui permet à la fois un passage à l’échelle massif et une tolérance aux pannes.

Indispensable à l’ère du Big Data, la montée en charge horizontale n’est toutefois pas sans défis. Elle exige une orchestration soignée, de l’équilibrage de charge et une distribution des données maîtrisée. Garantir la cohérence des données entre les nœuds tout en limitant la latence réseau peut être particulièrement complexe, surtout dans des systèmes temps réel. Les architectures distribuées sont en outre contraintes par le théorème CAP (Cohérence – Disponibilité – Tolérance au partitionnement). Des compromis sont inévitables et imposent de clarifier ce qui est prioritaire et ce qui l’est moins.

Enfin, les architectes le savent : deux charges de travail ne se ressemblent pas. Certaines applications modernes peuvent être utilisées simultanément par des centaines de milliers de personnes, générant un très grand nombre de petites transactions par seconde. D’autres n’ont que quelques utilisateurs, mais interrogent des pétaoctets de données. Ces deux types de charge sont exigeants, mais ils nécessitent des approches de montée en charge différentes. Nous considérons donc chaque scénario comme distinct.

Pour accélérer tout en passant à l’échelle, les bases de données s’appuient souvent sur la mise en cache : une couche temporaire très rapide pour les données fréquemment consultées, qui évite de relancer sans cesse les mêmes requêtes. Pour supporter un très grand nombre d’utilisateurs ou de transactions simultanés et passer à l’échelle côté “volume d’utilisateurs”, InterSystems a développé une implémentation spécifique : l’Enterprise Cache Protocol (ECP).

Dans un réseau de serveurs, l’un est configuré comme serveur de données, là où les données sont stockées de façon persistante. Les autres sont des serveurs applicatifs. Chaque serveur applicatif exécute une instance d’InterSystems IRIS et expose les données à l’application comme si elles étaient dans une base locale. Les données ne sont pas stockées durablement sur les serveurs applicatifs : ces serveurs apportent surtout du cache et de la puissance de calcul.

Les sessions utilisateurs sont réparties entre les serveurs applicatifs — généralement via un load balancer — et les requêtes sont servies depuis le cache local du serveur applicatif lorsque c’est possible. Les serveurs applicatifs ne récupèrent les données depuis le serveur de données que si nécessaire. ECP synchronise automatiquement les données entre les participants du cluster.

Comme le traitement est assuré par les serveurs applicatifs, le serveur de données peut se concentrer principalement sur la persistance des résultats des transactions. On peut ajouter ou retirer facilement des serveurs applicatifs du cluster en fonction de la charge. Par exemple, dans un contexte retail, il peut être pertinent d’ajouter des serveurs applicatifs pour absorber le pic de charge du Black Friday, puis de les arrêter une fois la période terminée. Les serveurs applicatifs sont particulièrement utiles pour les applications qui doivent exécuter un grand nombre de transactions, tout en n’impactant, à chaque transaction, qu’une petite partie de l’ensemble des données.

Lorsque des requêtes — le plus souvent analytiques — doivent accéder à de très grands volumes de données, le « jeu de données de travail » à mettre en cache pour exécuter ces requêtes efficacement peut dépasser la capacité mémoire d’une seule machine. Une technique efficace pour traiter ce type de volumes est le sharding : il consiste à partitionner physiquement de grandes tables de base de données sur plusieurs instances de serveurs.Du point de vue de l’application, l’accès se fait toujours via une table logique unique, sur une instance désignée comme shard master. Le shard master découpe les requêtes entrantes et les envoie aux serveurs shards, chacun détenant une partie distincte des données de la table et des index associés. Les serveurs shards traitent ces requêtes en parallèle, puis renvoient leurs résultats au shard master pour agrégation.

Les données sont réparties entre les serveurs shards selon une clé de sharding. Elle peut être gérée automatiquement par le système, ou définie par l’architecte logiciel à partir de certaines colonnes de la table. En choisissant soigneusement ces clés, il est possible de co-sharder des tables souvent jointes : les lignes qui doivent généralement être jointes sont alors stockées sur le même serveur shard. Cette co-localisation permet d’effectuer les jointures localement sur chaque shard, ce qui maximise la parallélisation et les performances. À mesure que les volumes augmentent, il est facile d’ajouter de nouveaux shards. Le sharding est totalement transparent pour l’application et pour les utilisateurs.

Toutes les tables n’ont pas besoin d’être shardées. Par exemple, dans des applications analytiques, les tables de faits (par exemple les commandes dans un contexte retail) sont généralement très volumineuses et seront shardées. Les tables de dimensions, beaucoup plus petites (produits, points de vente, etc.), ne le seront pas. Les tables non shardées sont stockées sur le shard master. Si une requête nécessite des jointures entre tables shardées et non shardées, ou si des données provenant de deux shards différents doivent être jointes, la technologie InterSystems s’appuie sur un mécanisme très efficace basé sur ECP pour répondre correctement et efficacement à la demande. Dans ce cas, seules les lignes nécessaires sont échangées entre shards — plutôt que de diffuser des tables entières sur le réseau, comme le font beaucoup d’autres technologies. Grâce au sharding, la technologie InterSystems améliore de façon transparente l’efficacité et les performances des requêtes Big Data, sans limiter les types de requêtes pouvant être exécutées.

Les architectures InterSystems permettent d’exécuter des jointures complexes sur plusieurs tables lors de requêtes sur des jeux de données distribués et partitionnés — sans imposer le co-sharding, la réplication des données ou la diffusion de tables entières sur le réseau.

Les solutions data modernes doivent souvent gérer simultanément un fort débit transactionnel (lié au volume d’utilisateurs) et de l’analytique sur de grands volumes de données. Exemple : une application de gestion privée qui propose, en temps réel, des tableaux de bord résumant les portefeuilles et le risque des clients, à partir des données de marché courantes.

La technologie InterSystems se distingue par sa capacité à combiner, en parallèle, des requêtes analytiques et des transactions d’ingestion. Elle rend possibles des applications HTAP — parfois appelées translytical — en permettant d’utiliser conjointement des serveurs applicatifs et le sharding. Des serveurs applicatifs peuvent être ajoutés à l’architecture (illustrée par la figure 2) pour répartir la charge sur le shard master. Ainsi, la charge de travail et les volumes de données peuvent évoluer de manière indépendante, selon les besoins de l’application.

Lorsque les applications exigent une évolutivité maximale — par exemple si un modèle prédictif doit scorer chaque enregistrement d’une grande table alors que de nouveaux enregistrements sont ingérés et interrogés en parallèle — chaque shard de données peut agir comme serveur de données dans un modèle ECP. Les serveurs applicatifs qui partagent la charge sur les shards de données sont alors appelés query shards. Combiné aux mécanismes transparents assurant une haute disponibilité d’un cluster InterSystems IRIS, cela donne aux architectes toutes les briques nécessaires pour répondre aux exigences spécifiques d’évolutivité et de fiabilité de leurs solutions.

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 montée en charge efficace exige une conception architecturale réfléchie : l’architecture influence les choix de scalabilité et, inversement, la scalabilité influence l’architecture.

• Le partitionnement des données, via des stratégies de sharding et de réplication, aide à gérer de grands volumes (voir « Montée en charge horizontale des volumes de données : sharding » ci-dessus).
• Les choix entre services sans état (stateless) et avec état (stateful) orientent la stratégie de montée en charge : les services stateless se prêtent plus facilement au passage à l’échelle horizontal.
• L’équilibrage de charge (load balancing) répartit le trafic entre les nœuds afin d’éviter qu’un seul ne sature.
• Les stratégies de tenancy déterminent comment différents utilisateurs partagent l’accès à une plateforme — et éventuellement à son infrastructure — tout en conservant 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 au partitionnement), guident les compromis à faire dans les systèmes distribués.

Les plateformes de données évolutives sont déterminantes pour réussir dans les secteurs où InterSystems accompagne ses clients. Le premier est la santé : InterSystems opère souvent à très grande échelle, en gérant des dossiers patients, de l’imagerie médicale et d’autres données diagnostiques, ainsi que des données issues de la surveillance en temps réel, au sein d’un grand nombre d’applications d’informatique médicale.

InterSystems intervient aussi sur d’autres usages data, notamment dans la finance (traitement des transactions, détection de fraude, reporting réglementaire) et dans la supply chain (suivi des expéditions, optimisation des livraisons, gestion des stocks).

InterSystems contribue à mettre en œuvre des solutions data dans l’ensemble de ces secteurs, en aidant les organisations à atteindre leurs objectifs de données, de performance et de fiabilité à grande échelle.

Le paysage des plateformes de données évolutives continue d’évoluer, avec l’émergence de nouvelles applications et de nouveaux systèmes :

• Les architectures cloud-native, comme Kubernetes et les modèles serverless, simplifient la montée en charge horizontale.
• La montée en charge pilotée par l’IA, via des algorithmes prédictifs, optimise l’allocation des ressources.
• L’edge computing rapproche le traitement des sources de données, ce qui réduit la latence.
• Les architectures data mesh et fédérées encouragent une gouvernance décentralisée des données et favorisent la mise à l’échelle.
• Les architectures de data fabric permettent de dépasser les silos et la fragmentation des données.

L’évolutivité massive n’est plus un “plus” : c’est une nécessité pour les applications data modernes. Elle est particulièrement indispensable pour les applications de traitement transactionnel et analytique hybride (HTAP), qui doivent gérer simultanément des charges de travail importantes et de grands volumes de données — parfois avec un grand nombre d’utilisateurs en parallèle.

La montée en charge verticale apporte simplicité et performance pour des systèmes plus modestes, tandis que la montée en charge horizontale offre l’élasticité et la résilience indispensables aux applications à grande échelle. Des architectures spécialisées permettent d’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 tout en s’adaptant à la croissance future.