Chronopost prend le virage Big Data avec Cassandra

Un choix difficile

Mais pour Chronopost, le choix de la bonne technologie n’a pas été simple au regard des centaines de bases de données sur le marché et de l’absence de standard unique. « Notre base de données devait constituer un espace sécurisé pour stocker des données qui jusqu’alors n’étaient pas présentes dans notre système. Elle devait être rapide et douée de capacité de dimensionnement, proposer un niveau élevé de résilience avec des capacités de réplication native, et enfin être simple à utiliser et à opérer », soutient-il.

Après une étude minutieuse, la société a finalement listé trois prétendants : HBase, Cassandra et MongoDB. Après des tests, Apache Cassandra s’est avéré la base préférée de Chronopost.

Le bon choix au bon moment

« J’imagine que nous avons considéré Cassandra au bon moment, la 1.2 était stable et la 2.0 en test », poursuit-il. « Les versions précédentes étaient différentes et n’auraient pas répondu à nos besoins. Les choses bougent très vite dans le NoSQL. »

Cassandra sert ainsi à gérer les données dans un environnement « scalable », là où l’information se crée à un rythme très rapide, par des centaines ou des millions d’utilisateurs et depuis plusieurs terminaux. Cassandra est prête pour des usages tels que ceux de l’Internet des objets, les plateformes de messaging dans les  télécoms, la personnalisation des sites de e-commerce ou encore les moteurs de recommandations  et les systèmes de détection de fraudes. La base de données permet de collecter et d’analyser toutes les données lors de leur création.

« Cassandra correspondait parfaitement à nos besoins : une architecture pair-à-pair, une intégration simple à Hadoop / Spark, facile à opérer (un process unique sur chaque machine). De plus, la base embarque Cassandra Query Language (CQL), qui facilite la transition depuis un SGBDR car il s’agit en fait d’un sous-ensemble de SQL », commente Alexander Dejanovski.

Choisir Cassandra plutôt que Microsoft SQL Server ou Oracle Database est une question d’échelle. Toutes les transactions ont de la valeur et une société n’a pas envie d’en perdre. Par exemple, dans un projet lié à l’Internet des objets, toutes les transactions ou informations générées par chaque objet doivent être collectées. On parle de données « Time-series » (séquences de données chronologiques, NDLR) et cela cartographie mieux les usages de chaque utilisateur du service et du terminal.

« Le meilleur cas d’usage de Cassandra est justement  le time-series. En tant que société de livraison express, nous avons essentiellement affaire à ce type de données (le cycle de vie de chaque colis) », affirme-t-il. Nous sommes une entreprise temps-réel, donnant en continu des indications sur les colis. Nous proposons aux clients un service rapide donc les données doivent suivre et transiter rapidement via nos systèmes pour répondre aux besoins. »

Des défis à résoudre

Cassandra a permis à Chronopost de résoudre certains problèmes. Par exemple, explique l’ingénieur, la base fournit un driver JDBC (Java Database Connectivity) pour faciliter l’intégration au socle EAI de l’entreprise, sans trop d’effort. « Le protocole est identique, le schéma à peine différent – et surtout nous n’avons pas à re-écrire l’application, mais uniquement à en modifier certains éléments qui interagissent avec la base. »

Plus surprenant, Chronopost a finalement finalisé le projet avec un schéma de donnée plus simple qu’avec son SGBDR. « Nous avons été soufflé par la rapidité de Cassandra. A la fin du PoC, notre application était 4 à 5 plus rapide qu’avec notre SGBDR. La latence est tombée de 100-120 millisecondes à 10-30 millisecondes par message, avec des écritures rapides qui nous ont permis d’absorber des charges plus facilement qu’avant. Et tout cela s’exécute sur du hardware peu couteux, de commodité », ajoute encore Alexander Dejanovski.

Avoir sous la main une base de données rapide nous a permis de développer de nouveaux services, assure-t-il. « Techniquement, nous aurions pu les mettre en place avec un SGBDR, mais nous étions limités en puissance, tout en gardant à l’esprit que le dimensionnement vertical est difficile (temps d’interruption, migration) et couteux. Les bases de données sont des goulots d’étranglements et le point unique de défaillance de chaque système IT. Nous sommes heureux que Cassandra ait pu changer cela. »

Se tourner vers l’avenir

Mais d’autres plans se dessinent pour Cassandra. Selon l’ingénieur, Chronopost a déjà mis en place en production un cluster Cassandra, réparti sur plusieurs datacenters et développe actuellement un cluster pour la recherche et l’analyse de données, avec Spark au-dessus de la base NoSQL.

« Nous avons appris à développer des applications sur Cassandra et avons de nombreux projets autour de la base. Côté développement, cela nous pousse à considérer quelque chose qui correspond mieux aux microservices », ajoute-t-il.

Chronopost travaille désormais avec ses équipes opérationnelles et d’administration à optimiser les capacités de résilience de Cassandra et à automatiser certains aspects, comme la sauvegarde ; « ce qui, dans un monde distribué, est beaucoup plus difficile que dans un monde monolithique », commente-t-il.

L’autre défi consistera à passer de la BI traditionnelle à de l’analytique Big Data, et à demander aux développeurs, plus habitués à SQL, à écrire des scripts Scala pour Spark.

Traduit et adapté par la rédaction