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.
Plan de données : Snaplex et redondance des pipelines
Le Snaplex est un cluster d'un ou plusieurs nœuds d'exécution de pipeline. Un Snaplex peut résider dans SnapLogic Integration Cloud ou sur site. Le Snaplex est conçu pour prendre en charge la mise à l'échelle automatique en cas d'augmentation de la charge du pipeline. En outre, le tableau de bord de contrôle surveille la santé de tous les nœuds Snaplex. De cette manière, les défaillances des nœuds Snaplex peuvent être détectées rapidement afin que les pipelines futurs ne soient pas programmés sur le nœud défectueux. Pour les Snaplex basés sur cloud, également connus sous le nom de Cloudplexes, les pannes de nœuds sont détectées automatiquement et les nœuds de remplacement sont mis à disposition de manière transparente. Pour les Snaplex sur site, également appelés Groundplexes, les utilisateurs administrateurs sont informés du nœud défectueux 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.
Plan de contrôle : Fiabilité du service
Le " plan de contrôle " de SnapLogic réside dans l'intégration SnapLogic Cloud, qui est hébergée dans AWS. En découplant 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 pour des raisons d'évolutivité et de fiabilité. Tous les serveurs frontaux basés sur REST sont hébergés derrière le service ELB (Elastic Load Balancing) d'AWS. En cas de défaillance d'un service du plan de contrôle, il y aura toujours un pool de services répliqués disponibles pour répondre aux demandes des clients et aux demandes internes. Voici un exemple où 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'intégration définie par logiciel
En divisant l'architecture élastique iPaaS de SnapLogic en plan de données et plan de contrôle, nous pouvons employer des stratégies de fiabilité efficaces, mais différentes, entre ces deux classes. Dans le plan de données, nous aidons à la fois à identifier et à corriger les défaillances des serveurs Snaplex, mais nous permettons également aux utilisateurs de mettre en œuvre des pipelines hautement fiables en fonction de leurs besoins. Dans le plan de contrôle, nous utilisons une combinaison de réplication de serveurs, d'équilibrage de charge et de ZooKeeper pour assurer une exécution fiable du système. Notre approche unique nous permet de modulariser la fiabilité et d'utiliser des stratégies de test ciblées. La fiabilité n'est pas une caractéristique du produit, mais une caractéristique de conception intrinsèque à chaque aspect de l'intégration SnapLogic Cloud.
