CMA CGM brise les limites d'Oracle avec le NoSQL et le Serverless

Instaurer une cohabitation pacifique entre Oracle et MongoDB

Ce premier projet NoSQL réussi avec MongoDB, n'a pas remis en cause le rôle-clé des bases de données Oracle dans le système d'information de l'armateur. Il a fallu organiser une cohabitation entre les bases relationnelles et NoSQL : « Notre pattern Single View a permis à CMA CGM de se libérer des contraintes techniques liées à l'utilisation du SGBD relationnel Oracle. Nous avons ce legacy Oracle avec une multitude de bases et des schémas de données que personne n'osait plus retoucher de peur de ce qui pourrait survenir. Au-dessus d’Oracle, nous réalisons du CDC (Change Data Capture) afin de capter toutes les modifications qui surviennent dans nos bases de données Oracle. » 

Des micro-batchs Spring tournent en permanence à fréquence élevée afin de détecter toute modification intervenue dans une table Oracle et réalise un « upsert » (updates et inserts) sur le cluster MongoDB. Ce cluster est exploité via une couche d’API REST, afin de délivrer des services de données pour les applications mobiles ou n’importe quel service frontend.

C'est fort de cette architecture duale que MongoDB a été sélectionné afin de sortir de l'enlisement un projet stratégique de CMA CGM, la gestion de son « pricing ». « Le projet Pricing fut un peu compliqué pour CMA CGM puisqu'il devait initialement entrer en production en... 2012. Il a été annulé maintes et maintes fois car une base de données relationnelle n'est pas adaptée : les données de pricing sont très hétérogènes, avec par exemple les Etats-Unis qui ne fonctionnent pas du tout de la même façon que l'Europe, si bien que les données de pricing US ont un format totalement différent du format européen, rien de commun à part le client lui-même. Nous avons été bloqués par cette hétérogénéité, bloqués par la volumétrie : nous ne nous en sortions pas avec des bases de données relationnelles », explique Nicolas Benhamou.

L'équipe projet était parvenue à répondre aux attentes des métiers mais sur un périmètre restreint, celui des lignes entre les Etats-Unis et la Chine, ce qui représentait déjà plusieurs To de données sur Oracle. « Nous avons dû attendre d'avoir notre projet E-Commerce sur MongoDB on-premise avant de songer à exploiter MongoDB pour notre solution de pricing. », continue le Solution Architect chez CMA CGM.

L'architecture mise en place par CMA CGM pour son application de Pricing

Les événements détectés au niveau des bases Oracle sont répercutés dans le cluster MongoDB Atlas via des micro-batchs Spring, appelant les Webhooks Stitch qui ont accès à la base Atlas. L'application de e-Commerce sollicite elle-aussi des webhooks Stitch afin d'accéder aux tarifs.

Afin de gagner du temps, l'équipe projet opte pour Atlas qui est la version managée dans le cloud de la base NoSQL MongoDB ainsi que pour son environnement d'exécution Serverless Stitch. « Atlas et Stitch nous ont épargné le besoin de mettre en place un backend. » Architectes et développeurs ont fait le choix d'exploiter ce que l'éditeur de Stitch appelle les webhooks, un Web Service REST qui permet d'exposer les fonctions d'accès aux données Stitch.

Il s'agit d'une alternative au développement via les SDK Android, IOS, JavaScript de la solution, lorsqu'on souhaite utiliser un autre langage. « Le projet ne nous a pas pris beaucoup de temps à partir du moment où nous avons pu disposer des bonnes solutions » commente l'architecte. « Pouvoir nous appuyer sur un modèle flexible nous a beaucoup aidés : Il y a dans toutes les entreprises des business analystes qui changent fréquemment d'avis, ce qui imposait de devoir intervenir sur les modèles de données en permanence. MongoDB nous permet d'être réactifs par rapport aux demandes des métiers, répondre aux demandes de changement rapidement. »

Une demande de modifications dans les propriétés d'un document de pricing qui aurait représenté une lourde tâche avec une base de données relationnelle est bien plus rapide à traiter avec une base NoSQL telle que MongoDB.

Quand l'équipe projet pousse Stitch à ses limites

Le tenant MongoDB Atlas dédié à l'application de pricing met en œuvre une base shardée (distribuée) qui héberge 370 millions de documents, soit 3 To de données. Les architectes ont fait le choix d'exploiter Stitch afin de charger les données dans ce cluster ainsi qu'effectuer les requêtes. Passés les problèmes de proxy, de sécurité avec l'authentification de Stitch par l’IDP de l'entreprise, l'équipe projet a dû passer outre les limitations « by design » de la solution.

Stitch est initialement conçu pour échanger des données avec des applications mobiles, ce qui représente de faibles volumétries de données face à un grand nombre potentiel de client mobile. L'usage de CMA CGM est inverse : pouvoir échanger énormément de données pour une transaction.

« Si on envoie une charge utile de 1 000 documents pour faire un "insert many", cela peut demander beaucoup de temps à être traité » explique Nicolas Benhamou. « Nous avons pu contourner cette limitation afin d’insérer et modifier des nombres conséquents de documents très rapidement. Il faut placer le curseur au bon endroit entre la taille du payload Stitch et la fréquence des appels. Envoyer 1000 documents d'un coup à Stitch pour faire un insert n'était pas efficace. Il faut mieux envoyer 5 documents à la fois en privilégiant le multithread. Nous pouvons monter jusqu'à 1000 threads à l'instant t et ça fonctionne pas trop mal. »

En outre, l'architecte souligne qu'Atlas et Stitch fonctionnant sur des tenants AWS différents, il faut bien veiller à ce que l'un et l'autre soient les plus proches possible afin de ne pas se retrouver freiné par des temps de latences trop importants. Hormis cette contrainte, il se félicite de la maintenabilité d'Atlas via Ansible. « Pour notre premier cluster on-premise, nous avons tout scripté en Ansible afin de pouvoir déployer un cluster d’un simple double clic. Les API Atlas étant les mêmes que celles de MongoDB, cela ne nous a pris que 2 heures pour scripter Atlas et disposer d'un cluster Atlas monitoré et scalable. Stitch a également des API qui permettent aussi un déploiement automatisé avec Ansible ou d’autres solutions telles que Puppet ou Chef. »

Caas et NoSQL favoris pour motoriser la stratégie IoT de CMA CGM

Pour cet expert, Stitch représente un moyen intéressant d'accéder aux données de MongoDB alors que la base NoSQL ne dispose pas d'API REST en natif. « Stitch nous permet de profiter de son driver MongoDB natif dans une fonction Stitch et de l’exposer sous forme d’une API dont on décide du design, y compris s’il faut se plier à une gouvernance d’API SOA de l’entreprise. » En outre, une API Gateway permet de virtualiser ces endpoints REST Stitch et en donner l’accès aux partenaires du transporteur.

Désormais, dans le cadre de sa stratégie IoT, l'armateur réfléchit au stockage et au traitement des données non-structurées provenant des conteneurs connectés. La piste du Caas (« Container as a Service ») est pour l'instant privilégiée, de même que MongoDB s'annonce comme la solution favorite pour être un composant clé de notre future application de traçabilité des conteneurs en temps réel de CMA CGM.