La fiabilité du fonctionnement du système est une exigence pour toute intégration sérieuse plateforme en tant que service (iPaaS). Souvent, la fiabilité ou la tolérance aux pannes est mentionnée comme une caractéristique, mais il est difficile de se faire une idée de ce que cela signifie en termes pratiques. Pour un projet d‘intégration de données, la fiabilité peut être un défi car il doit connecter des services externes disparates, qui tombent en panne d‘eux-mêmes. Dans un article de blog précédent, nous avons expliqué comment les pipelines SnapLogic Integration Cloud peuvent être construits pour gérer les défaillances des points de terminaison grâce à notre mécanisme de livraison garantie. Dans ce billet, nous allons examiner certaines des techniques que nous utilisons pour garantir l‘exécution fiable des services que nous contrôlons.
L‘architecture SnapLogic se divise en deux catégories : le plan de données et le plan de contrôle. Le plan de données est encapsulé dans un Snaplex et le plan de contrôle est un ensemble de serveurs distribués répliqués. Cette séparation est utile à la fois pour l‘isolation des données et pour la fiabilité, car nous pouvons facilement utiliser différentes approches de tolérance aux pannes dans les deux plans.
Plane de données : Redondance des Snaplex et des pipelines
Un Snaplex est un cluster composé d'un ou plusieurs nœuds d'exécution de pipelines. Un Snaplex peut être hébergé soit dans le SnapLogic Integration Cloud sur site. Le Snaplex est conçu pour prendre en charge l'auto-scaling en cas d'augmentation de la charge des pipelines. De plus, le tableau de bord de surveillance contrôle l'état de santé de tous les nœuds du Snaplex. De cette manière, les pannes des nœuds Snaplex peuvent être détectées rapidement afin que les futurs pipelines ne soient pas planifiés sur le nœud défaillant. Pour les Snaplex cloud, également appelésCloudplex, les pannes de nœuds sont détectées automatiquement et des nœuds de remplacement sont mis à disposition de manière transparente. Pour les Snaplex sur site, également appelésGroundplex, les utilisateurs administrateurs sont informés du nœud défaillant afin qu'un remplacement puisse être effectué.
Si un nœud Snaplex tombe en panne pendant l‘exécution d‘un pipeline, le pipeline sera marqué comme ayant échoué. Les développeurs peuvent choisir de réessayer les pipelines défaillants ou, dans certains cas, tels que les pipelines programmés de manière récurrente, l‘exécution défaillante peut être ignorée. Diviser les pipelines de longue durée en plusieurs pipelines plus courts peut limiter l‘exposition à la défaillance d‘un nœud. Pour les intégrations hautement critiques, il est possible de construire et d‘exécuter simultanément des pipelines répliqués. De cette manière, une seule réplique défaillante n‘interrompra pas l‘intégration. Il est également possible de construire un pipeline pour mettre en scène les données dans le système de fichiers SnapLogic (SLFS) ou dans un autre magasin de données tel qu‘AWS S3. La mise en scène des données peut atténuer le besoin de réacquérir des données à partir d‘une source de données, par exemple, si une source de données est lente, comme AWS Glacier. En outre, certaines sources de données ont des coûts de transfert plus élevés ou des limites de transfert qui rendraient prohibitif le fait de demander des données plusieurs fois en cas de défaillance du point d‘extrémité en amont dans un pipeline.
Plain de contrôle : fiabilité des services
Le« plan de contrôle» de SnapLogic réside dans le SnapLogic Integration Cloud, hébergé sur AWS. En dissociant le contrôle du traitement des données, nous proposons des approches différenciées en matière de fiabilité. Tous les services du plan de contrôle sont répliqués à la fois pour garantir l'évolutivité et la fiabilité. Tous les serveurs frontaux basés sur REST sont placés derrière le service AWS ELB (Elastic Load Balancing). En cas de défaillance d'un service du plan de contrôle, un ensemble de services répliqués sera toujours disponible pour répondre aux requêtes des clients et aux demandes internes. Voici un exemple illustrant comment la redondance contribue à la fois à la fiabilité et à l'évolutivité.
Nous utilisons ZooKeeper pour mettre en œuvre notre service de planification fiable. Un aspect important de l‘iPaaS SnapLogic est la possibilité de créer des intégrations planifiées. Il est important que ces tâches programmées soient lancées à un moment précis ou aux intervalles requis. Nous mettons en œuvre le service de planification sous la forme d‘un ensemble de serveurs. Tous les serveurs peuvent accepter des demandes CRUD entrantes sur les tâches, mais un seul serveur est élu comme leader. Nous utilisons à cet effet un algorithme d‘élection du leader basé sur ZooKeeper. De cette manière, si le leader échoue, un nouveau leader sera élu immédiatement et reprendra la programmation des tâches à temps. Nous veillons à ce qu‘aucune tâche programmée ne soit manquée. En plus d‘utiliser ZooKeeper pour l‘élection du leader, nous l‘utilisons également pour permettre aux ordonnanceurs suiveurs d‘informer le leader des mises à jour de tâches.
Nous utilisons également une série de technologies de stockage de données répliquées pour assurer le contrôle et la fiabilité des métadonnées. Nous utilisons actuellement des clusters MongoDB pour les métadonnées et des buckets AWS S3 cryptés pour mettre en œuvre SLFS. Nous n‘exposons pas directement S3, mais fournissons plutôt une vue hiérarchique virtuelle des données. Cela nous permet de suivre et d‘autoriser correctement l‘accès aux données SLFS.
Pour MongoDB, nous avons développé une stratégie fiable de lecture-modification-écriture pour gérer les mises à jour de métadonnées de manière non bloquante à l‘aide de findAndModfy. Notre approche permet d‘obtenir des mises à jour non conflictuelles très efficaces, mais elle est sûre en cas de conflit d‘écriture. Dans un prochain article, nous fournirons une description technique de son fonctionnement.
Les avantages de l'
d'intégration définie par logiciel
En divisant l'architecture élastique iPaaS de SnapLogic en un plan de données et un plan de contrôle, nous pouvons mettre en œuvre des stratégies de fiabilité efficaces, mais distinctes, pour ces deux niveaux. Au niveau du plan de données, nous aidons à identifier et à corriger les défaillances des serveurs Snaplex, tout en permettant aux utilisateurs de mettre en place des pipelines hautement fiables selon leurs besoins. Au niveau du plan de contrôle, nous combinons la réplication des serveurs, l'équilibrage de charge et ZooKeeper pour garantir une exécution fiable du système. Notre approche, qui ne repose pas sur une solution unique, nous permet de modulariser la fiabilité et de mettre en œuvre des stratégies de test ciblées. La fiabilité n'est pas une fonctionnalité du produit, mais une caractéristique intrinsèque de la conception de tous les aspects du SnapLogic Integration Cloud.
