Technologies

Comment CA-GIP met en place des plateformes de données mutualisées

---

Lors du salon Cap IT, Julien Legrand, fast data squad leader chez CA-GIP, entité chargée de la production du groupe Crédit Agricole, a expliqué comment son équipe déploie des plateformes data mutualisées. Une démarche illustrée avec la présentation d'un socle conçu autour de solutions Confluent Kafka et MongoDB.

PublicitéCrédit Agricole Group Infrastructure Platform (CA-GIP) est l'entité qui gère la majorité des infrastructures du groupe bancaire Crédit Agricole. Son équipe data déploie progressivement des plateformes de données afin d'offrir des socles technologiques mutualisés pour ses métiers. À l'occasion du salon Cap IT, événement sur la transformation numérique de la banque et de l'assurance qui s'est tenu les 23 et 24 mars 2022, Julien Legrand, fast data squad leader chez CA-GIP, a partagé son retour d'expérience sur la mise en place de ce nouveau modèle. Il a pris en exemple une plateforme conçue autour des solutions Confluent Kafka et MongoDB.

« CA-GIP héberge plus de 80% de la production du groupe Crédit Agricole. Nos grands enjeux consistent à nous assurer de la qualité des services fournis, à accompagner les différentes entités du groupe dans leurs projets et à être un partenaire stratégique des métiers dans la transformation digitale », a rappelé Julien Legrand en introduction. Pour prendre en charge ces différentes missions, CA-GIP a opté pour une organisation sur deux niveaux. D'un côté, des clusters proches des métiers ; de l'autre, des socles techniques sur différents domaines, tels que la cyberdéfense, la digital workplace ou encore cloud, devops et data, le socle auquel est rattaché Julien Legrand. « Nous sommes chargés de construire des offres de services, pour fournir un catalogue à la disposition des architectes dans les clusters et les différentes entités métiers », a résumé ce dernier.

Industrialiser le déploiement de solutions complexes

L'équipe data, à laquelle appartient Julien Legrand, s'est construite de façon progressive depuis 2018. Elle est organisée selon un modèle agile, avec trois squads et sept équipes de développement, ainsi que des rôles transverses comme un data manager, un product owner, un architecte ou un release train engineer. Au total, l'équipe compte une quarantaine de personnes. « Nous sommes organisés par produits : chaque équipe de développement est responsable du build et du run de son offre », confie Julien Legrand. Parmi les produits figures des plateformes big data comme Cloudera, des technologies NoSQL comme MongoDB ou Cassandra ou encore des solutions de streaming d'événements comme Confluent Kafka. Ce modèle vise à concevoir des offres de services mutualisées, capables de répondre à différents clients. « Il s'agit d'industrialiser le déploiement d'une solution technique complexe, en y ajoutant un ensemble d'outils permettant de rendre autonome l'utilisateur final », explique Julien Legrand.

Pour cela, les équipes mettent en oeuvre des étapes progressives afin de bâtir et d'enrichir les socles. Tout démarre avec l'identification d'un besoin, qui conduit à l'élaboration d'une liste de solutions possibles, puis à un choix parmi celles-ci. Vient ensuite une phase de conception et d'industrialisation, notamment grâce à la plateforme d'automatisation Ansible. « Il s'agit de pouvoir livrer le plus vite possible des sandboxes aux clients, afin d'obtenir un retour. Nous cherchons à acquérir une certitude, pour savoir s'il faut aller plus loin », indique Julien Legrand. Si c'est le cas, l'équipe va ensuite déployer différents outils pour assurer la supervision et le monitoring, prévoir des mécanismes de résilience et bâtir un modèle de droits. Enfin, la dernière étape est la mise en production du socle technique, avec un certain nombre de prérequis pour qu'il s'intègre dans les environnements techniques du groupe : des contrats de service ; des « golden rules », ensembles de règles de configuration essentielles à respecter pour assurer les SLA ; une documentation suffisante et des API.

PublicitéPasser d'une offre de service à une plateforme data

Julien Legrand a ensuite présenté en exemple une offre de services basée sur MongoDB, un système de gestion de bases de données (SGBD) orienté documents. Cette offre se décline en deux versions, pour répondre à différents types de projets : dans un cas, le client accède à un replica set partagé, une option peu coûteuse et immédiatement disponible ; dans l'autre, il dispose d'un cluster dédié à son application, avec une licence entreprise. Les bénéfices de cette approche par offre sont de plusieurs ordres. D'abord, cela permet de développer une expertise au sein du squad qui construit l'offre, avec une montée en compétences et une capitalisation des connaissances d'un projet à l'autre. Cela fluidifie aussi la relation avec l'éditeur, dont les architectes solutions acquièrent ainsi une bonne connaissance de l'environnement CA-GIP. Un autre atout s'observe lors du déploiement, l'usage d'Ansible facilitant et accélérant la mise en place de clusters. De la même façon, la supervision et le monitoring sont optimisés. La centralisation des outils évite d'en fournir de nouveaux à chaque nouvelle solution, permettant aux clients de trouver de la cohérence entre les différents socles. « L'objectif est d'offrir au client tout ce dont il a besoin pour faire tourner son application », souligne Julien Legrand. Les socles ainsi conçus sont également plus exploitables. « Par exemple, sur le streaming, un squad peut facilement gérer plusieurs clusters Kafka », illustre le squad leader. Malgré tout, quelques enjeux persistent. « Il est parfois compliqué d'exploiter une application de façon homogène, en centralisant différents tableaux de bord », note Julien Legrand. De même, la mise en place de modèles de droits transverses, applicables d'un socle à l'autre, reste un sujet complexe. Enfin, en termes de planning il faut identifier les points d'accostage des clients auprès des différents squads.

Pour aller plus loin, l'équipe chargée du socle data cherche désormais à construire des plateformes de données. « Il ne s'agit plus seulement de fournir un cluster ou une offre de services, mais de permettre la consommation du socle dans un contexte plus global », explique Julien Legrand. Dans cette optique, le squad fast data a notamment conçu une plateforme autour des solutions Kafka et MongoDB. Celle-ci récupère au départ des données brutes à travers des topics-as-a-service, des brokers de données Kafka. Si besoin, de premiers traitements simples peuvent être effectués sur ces données avec ksqlDB. Ensuite, les données viennent alimenter un cluster MongoDB via Kafka Connect, qui peut également servir pour l'archivage ou la réplication. Le cluster MongoDB est en sharding afin d'augmenter les capacités de stockage et de pouvoir ainsi accueillir plusieurs téraoctets de données. Ce cluster contrôle l'essentiel des transformations, soit à travers des change streams pour les applications qui effectuent des changements immédiats sur les données (dont la plupart sont déployées sur Kubernative, la plateforme de conteneurs de CA-GIP), soit par des aggregation pipelines pour les traitements en mode batch. En bout de chaîne, les données peuvent venir alimenter d'autres bases analytiques, auxquelles se greffent des outils de data science et de MLOps comme Dataiku.

Un modèle à décliner dans d'autres domaines

« Avec cette plateforme, nous pouvons nous appuyer sur MongoDB pour la haute disponibilité, la réplication native et d'autres aspects clefs », souligne Julien Legrand. Son équipe envisage désormais de décliner de façon plus intensive des patterns similaires, de façon à répondre à différents besoins métiers. « Nous réfléchissons aussi sur le data mesh (NDLR Architecture de données décentralisée) afin d'avoir un ensemble de solutions pour adresser chaque domaine », confie Julien Legrand en conclusion.

Article rédigé par

Aurélie Chandeze, Rédactrice en chef adjointe de CIO
Suivez l'auteur sur Linked In,

Partager cet article