Les échanges interbancaires français vont basculer sur Cassandra

STET Core, un système de type batch

Actuellement, STET-core fonctionne en mode batch. Les banques envoient leurs fichiers de transactions -des fichiers de 100 000 opérations - que STET traite en les chargeant dans une base de données relationnelle. « Les émetteurs de paiements, les banques, regroupent les transactions dans de gros fichiers qui sont envoyés en clearing. Nous sommes donc dans un modèle de traitement batch en asynchrone », explique Eric Gabillet, Directeur de l'engineering de STET. « Nous avons de grosses capacités de calcul, mais sans garanties sur le délai de traitement puisqu'on traite fichier par fichier. »

 Ce mode de fonctionnement présente l'avantage de la fiabilité puisque STET ne peut ni perdre ni doublonner l'une des 22 milliards de transactions qu'il traite chaque année (selon le concept d'Exactly-Once Transaction Counting). En revanche, ce mode batch introduit inévitablement des délais de traitement. Actuellement, un virement ou un paiement par carte est traité dans un délai de l'ordre de 1 à 2 jours. Un délai trop long pour l'Europe qui veut imposer l'Instant Payment, un paiement immédiat. L'ERPB (Euro Retail Payments Board) a défini la règle : Avec un "Instant Payment", l'argent devra être sur le compte du destinataire en moins de 10 secondes. Cette contrainte forte a poussé STET à lancer une refonte majeure de sa plateforme.

STET Core 2 devra passer au temps réel

Core 2 va devoir fonctionner en temps réel et ne plus traiter des blocs de transactions, mais transmettre les flux transaction par transaction. « Nous allons migrer tous nos flux SEPA, nos flux Carte, les flux legacy, et bien sûr l'Instant Payment. Tous ces flux devront être traités par notre moteur de traitement unitaire temps réel. C'est une refonte totale de notre système », confie Eric Gabillet. Il ajoute : « Pour les paiements instantanés, le processus de compensation sera totalement différent. Le traitement, les compensations et le règlement ont lieu transaction par transaction, et en temps réel de bout en bout. »

La plateforme technique STET va évoluer pour aller vers une plateforme unifiée qui sera hébergée dans 3 datacenters en mode multi-actif. « Nous devons augmenter notre capacité, car nous avons des ambitions européennes et la volonté d'accueillir de plus en plus de flux. En parallèle, nous devons garder un historique de tous les événements que nous traitons car nous sommes fortement audités à la fois par nos clients, par le régulateur et par les organismes liés à la sécurité. Nous devons être capables de rejouer des transactions en cas de corruption des données ou en cas de bug. Nous devons avoir une disponibilité maximum en 24/7. » En outre, STET doit être capable de calculer la position de l'ensemble des banques connectées au système en temps réel. Un défi lorsqu'on doit traiter entre 20 000 et 30 000 opérations chaque seconde.

Une plateforme 100% Big Data

Pour répondre à de telles contraintes techniques, les équipes informatiques de STET ont fait table rase du passé et ont opté pour des solutions radicalement nouvelles. L'architecture de Core 2 s'appuiera sur Apache Kafka pour collecter en temps réel les événements. Et Apache Spark assurera les traitements à réaliser sur les flux en temps réel, notamment le calcul des positions. Enfin, la base de données NoSQL Cassandra constituera le socle de cette architecture. « Nous avons mené des tests et Kafka s'est avéré comme une excellente brique. Nous l'avons poussé dans ses limites et nous n'avons jamais connu de problème de performances et de robustesse. Cassandra, et plus précisément Datastax Entreprise, est une solution Open Source. Cela signifie que tester et apprendre la solution ne coûte pas très cher. »

 L'architecture shared-nothing (on parle aussi d’architecture masterless) de Cassandra a été un atout clé pour les ingénieurs de STET dont la disponibilité est la priorité numéro 1. En outre, Cassandra présente l'avantage de n'avoir qu'une faible latence en mode écriture. « Nous devons réaliser autant d'écritures que de lectures dans nos bases. Etant donné le nombre important de messages à traiter, les temps d'écriture, le point faible des bases de données traditionnelles, étaient vraiment critiques pour nous. Cassandra est une base qui est performante mais qui est aussi scalable linéairement. La performance reste proportionnelle aux ressources provisionnées. »

Les développements sont menés par les équipes internes en langage Scala. Ces mêmes équipes assurent l'exploitation de la plateforme de production. En tant qu'acteur critique, STET s'est tourné vers Datastax, éditeur de Cassandra, afin de bénéficier d'un support professionnel de sa base de données. « Cela nous permet d'être prêts pour notre mise en conformité PCI-DSS », explique Eric Gabillet. « Nous disposons avec eux d'un consulting d'un très haut niveau, avec un accès direct aux "top commiters" de la solution. »

 De même, STET travaille avec Confluent, l'éditeur de Kafka. L'infrastructure serveur de Core 2 s'appuie essentiellement sur Red Hat, sachant que STET a choisi Ansible pour provisionner ses VM. Certaines ressources sont provisionnées sur AWS, d'autres sur Docker et enfin des VM de production sur Red Hat. Eric Gabillet ajoute : « Nous voulons aller vers le concept d'Infrastructure as Code avec un Cloud hybride. Les développements et les tests sont menés sur Amazon Web Services tandis que la production sera assurée dans notre Cloud privé. Nous faisons en sorte d'avoir les mêmes environnements et les mêmes capacités de test sur AWS et en production. »

STET Core 2 doit entrer en production en novembre 2017 afin de supporter les "Instant Payments" pour le marché belge dans en premier temps, puis sur le marché français dans le courant de l'année 2018. La Belgique sera le baptême du feu pour Core 2 car le délai maximum des "Instant Payments" a été fixé à 5 secondes seulement. Un défi pour les équipes d'Eric Gabillet.