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

Confrontés aux volumes considérables et sans cesse croissants de données générées dans le monde aujourd'hui, les architectes logiciels doivent accorder une attention particulière à l'évolutivité de leurs solutions. Ils doivent également concevoir des systèmes capables, si nécessaire, de gérer plusieurs milliers d'utilisateurs simultanés. Ce n'est pas facile, mais il est absolument indispensable de concevoir des systèmes hautement évolutifs.

Les architectes logiciels disposent de plusieurs options pour concevoir des systèmes évolutifs. Ils peuvent procéder à une évolutivité verticale en utilisant des machines plus puissantes dotées de dizaines de processeurs. Ils peuvent utiliser des techniques de distribution (réplication) des données pour procéder à une évolutivité horizontale afin d'accueillir un nombre croissant d'utilisateurs. Et ils peuvent faire évoluer le volume de données horizontalement grâce à une stratégie de partitionnement des données. Dans la pratique, les architectes logiciels emploient plusieurs de ces techniques, en trouvant un compromis entre les coûts liés au matériel, la complexité du code et la facilité de déploiement afin de répondre à leurs besoins spécifiques.

Cet article explique comment la plateforme de données InterSystems IRIS Data Platform prend en charge l'évolutivité verticale et horizontale des volumes de données et d'utilisateurs. Il présente plusieurs options de distribution et de partitionnement des données et/ou du volume d'utilisateurs, en donnant des exemples de scénarios où chaque option serait particulièrement utile. Enfin, cet article explique comment InterSystems IRIS contribue à simplifier la configuration et le provisionnement des systèmes distribués.

Évolutivité verticale

La manière la plus simple d'évoluer est peut-être de le faire “verticalement” – c'est-à-dire en déployant le système sur une machine plus puissante, dotée de plus de processeurs et de mémoire. InterSystems IRIS prend en charge le traitement parallèle de SQL et inclut une technologie permettant d'optimiser l'utilisation des processeurs dans les machines multi-cœurs.

Cependant, l'évolutivité verticale présente des limites pratiques. D'une part, même la plus grande machine disponible peut ne pas être capable de gérer les volumes de données et les charges de travail considérables requis par les applications modernes. D'autre part, les "supercalculateur" peuvent être extrêmement coûteux. De nombreuses organisations trouvent plus rentable d'acheter, par exemple, quatre serveurs à 16 cœurs plutôt qu'une machine à 64 cœurs.

La prévision de la capacité pour les architectures à serveur unique peut s'avérer difficile, en particulier La capacité de gérer les pics de charge peut entraîner une sous-utilisation coûteuse pendant les heures creuses. D'un autre côté, un nombre insuffisant de cœurs peut ralentir considérablement les performances pendant les périodes de forte utilisation. De plus, augmenter la capacité d'une architecture à serveur unique implique l'achat d'une nouvelle machine. Il est impossible de rajouter de la capacité en cours de fonctionnement.

En résumé, bien qu'il soit important que les logiciels exploitent tout le potentiel du matériel sur lequel ils sont déployés, l'évolutivité verticale seule ne suffit pas pour répondre à toutes les charges de travail, sauf les plus statiques.

Évolutivité horizontale

Pour toutes les raisons évoquées ci-dessus, la plupart des entreprises qui recherchent une évolutivité massive déploient leurs systèmes en réseau, en faisant évoluer les charges de travail et/ou les volumes de données "horizontalement", c'est-à-dire en répartissant le travail entre plusieurs serveurs. En général, chaque serveur du réseau est une machine abordable, mais des serveurs plus puissants peuvent être utilisés si nécessaire pour tirer parti également de l'évolutivité verticale.

Les architectes logiciels savent bien qu'il n'existe pas deux charges de travail identiques. Certaines applications modernes peuvent être utilisées simultanément par des centaines de milliers d'utilisateurs, ce qui génère un nombre très élevé de petites transactions par seconde. D'autres peuvent n'avoir qu'une poignée d'utilisateurs, mais interroger des pétaoctets de données. Ces deux types de charge de travail sont très exigeants, mais ils nécessitent des approches différentes en matière d' évolutivité. Nous allons d'abord examiner chaque scénario séparément.

Évolutivité horizontale du volume d'utilisateurs

Pour prendre en charge un nombre considérable d'utilisateurs (ou de transactions) simultanés, InterSystems IRIS s'appuie sur une technologie unique de mise en cache des données appelée Enterprise Cache Protocol (ECP).

Dans un réseau de serveurs, l'un d'entre eux sera configuré comme serveur de donnéesdans lequel les données seront conservées. Les autres seront configurés comme serveurs d'applications. Chaque serveur d'applications 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'applications. Ceux-ci sont là pour fournir de la mémoire cache et de la puissance de traitement du processeur.

Les sessions utilisateur sont réparties entre les serveurs d'application, généralement via un équilibreur de charge, et les requêtes sont traitées à 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 que si nécessaire. InterSystems IRIS synchronise automatiquement les données entre tous les participants du cluster.

Le travail de calcul étant pris en charge par les serveurs d'application, le serveur de données peut être principalement dédié au stockage permanent des résultats des transactions. Les serveurs d'application peuvent être facilement ajoutés au cluster ou supprimés de celui-ci en fonction de la charge de travail. Par exemple, dans le cas d'une utilisation dans le secteur de la vente au détail, vous pouvez ajouter quelques serveurs d'application pour faire face à la charge exceptionnelle du Black Friday, puis les désactiver une fois la période de soldes terminée.

Les serveurs d'applications 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 restreinte de l'ensemble des données. Les déploiements qui utilisent des serveurs d'applications avec ECP ont démontré leur capacité à prendre en charge plusieurs milliers d'utilisateurs simultanés dans divers secteurs.

Évolutivité horizontale du volume de données

Lorsque des requêtes (généralement analytiques) doivent accéder à une grande quantité de données, le "jeu de données de travail" qui doit être mis en cache afin de prendre en charge efficacement la charge de travail des requêtes peut dépasser la capacité mémoire d'une seule machine. InterSystems IRIS fournit une fonctionnalité appelée "partitionnement" qui partitionne physiquement les grandes tables de base de données sur plusieurs instances de serveur. Les applications accèdent toujours à une seule table logique sur une instance désignée comme master de partition. Le master de partition décompose les requêtes entrantes et les envoie aux serveurs de partition, chacun contenant une partie distincte des données de la table et des index associés. Les serveurs de partition traitent les requêtes locales à la partition de manière parallèle, puis renvoient leurs résultats au serveur de partition pour agrégation.

Les données sont partitionnées entre les serveurs de partition selon une clé de partition, qui peut être gérée automatiquement par le système ou définie par l'architecte logiciel en fonction des colonnes sélectionnées de la table. Grâce à une sélection rigoureuse des clés de partition, les tables qui sont souvent jointes peuvent être co-partitionnées, de sorte que les lignes de ces tables qui seraient normalement jointes sont stockées sur le même serveur de partition, ce qui permet à la jointure de se faire entièrement au niveau local sur chaque serveur de partition, maximisant ainsi la parallélisation et les performances.

À mesure que le volume de données augmente, des partitions supplémentaires peuvent être facilement ajoutées. Le partitionnement est totalement transparent pour l'application et les utilisateurs.

Toutes les tables ne doivent pas nécessairement être partitionnées. 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 partitionnées. La partitionnement ne concerne pas les tables beaucoup plus petites (par exemple, les produits, les points de vente, etc.). Les tables non partitionnées sont conservées sur le master de partition. Si une requête nécessite des jointures entre des tables partitionnées et non partitionnées tables, ou si des données provenant de deux partitions différentes doivent être jointes, InterSystems IRIS utilise un mécanisme ECP très efficace pour répondre correctement et efficacement à la requête. Dans ces cas, InterSystems IRIS ne partage entre les partitions que les lignes nécessaires, plutôt que de diffuser des tables entières sur le réseau, comme le feraient de nombreuses autres technologies. InterSystems IRIS améliore de manière transparente l'efficacité et les performances des charges de travail de requêtes relatives au Big Data grâce au partitionnement, sans limiter les types de requêtes qui peuvent être satisfaites.

L'architecture InterSystems IRIS permet des jointures multi-tables complexes lors de l'interrogation d'ensembles de données distribués et partitionnés sans nécessiter de co-partitionnement, sans réplication des données et sans diffusion de tables entières sur les réseaux.

Évolutivité du volume des utilisateurs et des données

De nombreuses solutions modernes doivent prendre en charge simultanément un taux de transaction élevé (volume d'utilisateurs) et l'analyse de grands volumes de données. Prenons l' exemple: une application de gestion de patrimoine privé qui fournit des tableaux de bord résumant les portefeuilles et les risques des clients, en temps réel, à partir des données actuelles du marché.

InterSystems IRIS permet de telles applications de traitement hybride transactionnel et analytique (HTAP) en autorisant l'utilisation combinée de serveurs d'applications et de partitionnement. Des serveurs d'applications peuvent être ajoutés à l'architecture illustrée à la figure #2 afin de répartir la charge de travail sur le master de partition. Les charges de travail et les volumes de données peuvent être dimensionnés 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 table volumineuse alors que de nouveaux enregistrements sont ingérés et interrogés simultanément), chaque partition de données individuelle peut agir comme serveur de données dans un modèle ECP. Les serveurs d'application qui partagent les charges de travail sur les partitions de données sont appelés "partitions de requêtes". Ceci, combiné aux mécanismes transparents garantissant la haute disponibilité d'un cluster InterSystems IRIS, fournit aux architectes de solutions tout ce qu'il faut pour satisfaire les exigences uniques de leur solution en matière d'évolutivité et de fiabilité.

Les performances et l'efficacité comparatives de l'approche de partitionnement d'InterSystems IRIS ont été démontrées et documentées dans un test de référence validé par une grande société d'analyse technologique. Lors de tests réalisés à partir d'un cas d'utilisation réel dans le domaine des services financiers critiques, InterSystems IRIS s'est révélé plus rapide que plusieurs bases de données hautement spécialisées, tout en nécessitant moins de matériel et en accédant à davantage de données.

Déploiement flexible

InterSystems IRIS offre aux développeurs de logiciels une grande flexibilité pour la conception de solutions hautement efficaces et évolutives. Mais l'évolutivité peut s'accompagner d'une complexité accrue, notamment en raison de l'ajout de serveurs supplémentaires à l'architecture, qui assument alors diverses fonctions. Simplifiez le provisionnement et le déploiement des serveurs (physiques ou virtuels) dans une architecture distribuée avec InterSystems IRIS.

InterSystems permet d'utiliser des scripts simples pour configurer les conteneurs InterSystems IRIS en tant que serveur de données, serveur de partition, master de partition, serveur d'application, etc. Les conteneurs peuvent être facilement déployés dans des clouds publics ou privés. Ils sont également faciles à mettre hors service, ce qui permet de concevoir des architectures évolutives pouvant s'adapter à des besoins fluctuants.

Conclusion

Une évolutivité massive est indispensable pour les applications modernes, en particulier les applications hybrides de traitement transactionnel et analytique qui doivent gérer simultanément des charges de travail et des volumes de données très importants. La plateforme de données InterSystems IRIS offre aux architectes logiciels des options pour faire évoluer leurs applications de manière économique. Elle prend en charge l'évolutivité verticale, les serveurs d'applications pour l'évolutivité horizontale du volume d'utilisateurs et une approche très efficace du partitionnement pour l'évolutivité horizontale du volume de données, qui élimine le besoin de diffusions sur le réseau. Toutes ces technologies peuvent être utilisées indépendamment ou en combinaison pour adapter une architecture évolutive aux exigences spécifiques d'une application.

---

Plus d'articles sur le sujet:

• Évolutivité horizontale avec InterSystems IRIS
• Utilisation d'InterSystems IRIS en mode FaaS avec Kubeless
• Évolutivité des hôtes cloud et reconfiguration d'InterSystems IRIS
• Déploiement IRIS hautement disponible sur Kubernetes sans mise en miroir

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