Un test de performance mené par Icon Solutions et MongoDB montre que l’IPF traite 6 000 paiements par seconde sans aucune perte de données en cas de défaillance
Un test de performance mené par Icon Solutions et MongoDB montre que l’IPF traite 6 000 paiements par seconde sans aucune perte de données en cas de défaillance
Un test de performance conjoint réalisé sur MongoDB Atlas démontre une évolutivité quasi linéaire, une latence de bout en bout inférieure à la seconde et une reprise après défaillance des nœuds d’application et de base de données sans perte d’une seule transaction.
LONDRES--(BUSINESS WIRE)--Icon Solutions et MongoDB ont publié aujourd’hui les résultats d’un test de performance conjoint montrant que l’Icon Payments Framework (IPF), fonctionnant sur MongoDB Atlas, a traité 6 000 transactions de paiement de bout en bout par seconde (environ 430 000 opérations de base de données par seconde) avec une latence moyenne de bout en bout de 0,51 seconde, et s’est remis de pannes tant au niveau des nœuds d’application que des nœuds de base de données sans aucune perte de données.
Les volumes de paiements de compte à compte évoluent rapidement vers des systèmes instantanés. Le trafic migre des systèmes de règlement net vers des systèmes instantanés, et les volumes de prélèvements automatiques devraient passer en partie au modèle request-to-pay avec règlement via des systèmes instantanés. Pour les banques, cela se traduit par des pics de trafic plus marqués, une part croissante de paiements soumis à des SLA de quelques secondes, et une tolérance zéro en matière d’indisponibilité. La capacité à traiter plusieurs milliers de paiements par seconde tout en garantissant résilience, disponibilité et faible latence est systématiquement sous-estimée par les établissements qui développent eux-mêmes leurs solutions, et la mise à niveau des plateformes héritées pour un traitement en continu représente un défi de taille.
L’IPF est un cadre de développement de solutions de paiement éprouvé à l’échelle internationale, auquel font confiance des banques de premier rang telles que Citi, NatWest et BNP Paribas. Reposant sur une architecture basée sur le cloud et orientée événements, il a été conçu dès le départ pour des environnements où l’évolutivité, la résilience et la disponibilité continue constituent des exigences fondamentales. Le test de performance a été conçu pour évaluer précisément ces aspects.
Le test de performance a utilisé un flux de paiement sortant SEPA Instant de référence, dans lequel chaque paiement passe par 12 étapes de traitement distinctes, notamment la vérification des doublons, la validation des messages et des règles du schéma, le filtrage des fraudes et des sanctions, la récupération des taux de change, la réservation et la comptabilisation des fonds, ainsi que la génération de messages du schéma, les systèmes périphériques de la banque étant représentés par des simulateurs. L’IPF et MongoDB Atlas ont été soumis à un test « en échelle » allant de 500 à 6 000 transactions de paiement cibles par seconde, afin de pouvoir observer le débit, la latence et la charge de la base de données à chaque étape, et non pas uniquement aux pics d’activité. Des scénarios de défaillance ont ensuite été exécutés sous une charge de transactions en temps réel.
Principaux résultats
- 6 000 paiements par seconde, de bout en bout. L’IPF a traité 6 000 transactions de paiement par seconde, chacune franchissant les 12 étapes de traitement. Ce débit opérationnel s’est appuyé sur environ 430 000 opérations de base de données par seconde réparties sur deux clusters MongoDB Atlas : environ 236 000 sur le journal des événements IPF et 196 000 sur le magasin de données opérationnelles IPF.
- Une latence largement inférieure aux SLA des paiements instantanés. La latence moyenne de bout en bout à 6 000 transactions par seconde était de 0,51 seconde, soit une fraction de la fenêtre de 10 secondes généralement autorisée par les systèmes de paiement instantané. La latence de persistance est restée inférieure à 30 millisecondes, même en période de pointe.
- Une évolutivité quasi linéaire et prévisible. De 500 à 6 000 transactions par seconde, l’application et la base de données ont évolué au même rythme : l’utilisation du processeur par segment et les taux d’insertion ont augmenté proportionnellement à chaque échelon, tandis que la latence est restée pratiquement stable jusqu’au sommet de la fourchette. La capacité peut donc être estimée avec certitude et la croissance planifiée en fonction de l’infrastructure, plutôt que comme un saut dans l’inconnu.
- Une marge de manœuvre suffisante. En période de charge maximale, l’utilisation du processeur des shards actifs sur MongoDB Atlas s’est maintenue autour de 50 %, les pods du service de paiement IPF ont fonctionné à environ 60 %, la file d’attente d’écriture de WiredTiger est restée à zéro et le décalage de réplication est resté faible tout au long du test.
- Récupération après une panne sans aucune perte de données. Sous une charge réelle de 3 500 transactions par seconde, IPF s’est remis d’une défaillance non contrôlée d’un nœud d’application en moins de 90 secondes et d’un arrêt planifié d’un nœud en environ 60 secondes. Dans les deux cas, chaque transaction a atteint un état final sans aucune perte de données et sans intervention manuelle : le rééquilibrage des shards d’IPF redistribue les transactions en cours vers les nœuds restants et reconstitue leur état à partir des événements persistés.
- Basculement de la base de données mesuré en secondes. Par ailleurs, un basculement d’un nœud principal de MongoDB Atlas, effectué à l’aide du test de basculement intégré à Atlas, que les clients peuvent exécuter eux-mêmes, s’est achevé en environ 5 secondes en moyenne, le traitement des paiements s’étant poursuivi sans interruption et sans perte de paiement ni redémarrage des applications.
- Les gains de la plateforme se traduisent directement par des performances accrues en matière de paiements. Le passage de MongoDB Atlas 8.0 à la version 8.3 a permis de réduire la latence de persistance d’environ 50 %, passant d’environ 40 millisecondes à environ 20 millisecondes à un débit de 4 000 transactions par seconde.
Pour les banques et les prestataires de services de paiement, l’importance de ces résultats est concrète : une capacité qu’il est possible de planifier plutôt que d’estimer, des pannes qui se résolvent sans intervention manuelle, et une voie vers une infrastructure de paiement moderne qui ne nécessite pas de tout développer en interne ni de moderniser une plateforme héritée. C’est l’architecture qui a rendu ces résultats possibles.
Ces résultats ont été obtenus grâce à une architecture distribuée et évolutive, plutôt qu’à du matériel surdimensionné. IPF fonctionnait sous la forme de 12 pods d’application sur Kubernetes, répartis sur trois zones de disponibilité au sein d’une même région cloud, en utilisant Akka pour un traitement simultané et tolérant aux pannes, les flux à contre-pression de l’IPF Connector Framework pour éviter que les systèmes en aval de lutte contre la fraude, de sanctions et de comptabilité ne soient submergés à mesure que la charge augmentait, et Kafka pour acheminer les données de traitement vers l’Operational Data Store. La persistance suit les modèles d’event sourcing et de CQRS, MongoDB Atlas prenant en charge à la fois l’IPF Event Journal (un cluster à cinq shards) et l’IPF Operational Data Store (un cluster à six shards). Chaque shard tournait sur un niveau de classe M80 avec 32 vCPU et 128 Go de RAM.
Il est possible d’augmenter la capacité en multipliant le partitionnement et en séparant les services : en distinguant les paiements groupés des paiements individuels, en répartissant les flux entre le lancement, l’exécution et la compensation des paiements, ou encore en procédant à une séparation géographique. Ce test de performance ouvre donc clairement la voie à un débit supérieur à 6 000 transactions par seconde pour les banques et les prestataires de services de paiement qui en ont besoin. Chaque service séparé est capable, à lui seul, de traiter plusieurs milliers de transactions par seconde.
« Les banques ont besoin d’une infrastructure de paiement capable de s’adapter à une économie instantanée », déclare Toine van Beusekom, directeur de la stratégie chez Icon Solutions. « Pourtant, prendre en charge des milliers de paiements par seconde tout en garantissant résilience, disponibilité, évolutivité et latence ultra-faible n’est pas chose aisée, en particulier pour les établissements qui s’appuient sur une architecture héritée ou qui développent tout eux-mêmes. Ce test de performance démontre que l’IPF offre une approche alternative conçue pour répondre aux exigences sans précédent d’un monde toujours connecté, permettant ainsi aux banques de faire évoluer les paiements en toute confiance. »
« À un rythme de 6 000 paiements par seconde, la couche de données traite près d’un demi-million d’opérations de base de données par seconde, avec une reprise après défaillance des nœuds en cinq secondes et aucune perte de données », déclare Boris Bialek, vice-président des secteurs d’activité et directeur technique mondial sur le terrain chez MongoDB. « Les paiements instantanés nécessitent une infrastructure de données dynamique et pilotée par les événements, et non pas simplement un système d’enregistrement statique, et ce test de performance montre ce que MongoDB est capable d’offrir en temps réel, avec une marge de manœuvre considérable. Évolutivité, résilience et performances opérationnelles au sein d’une seule et même plateforme gérée. Tel est le moteur des paiements modernes. »
Accédez au rapport de test de performance : Scale Without Sacrifice: How Icon Solutions and MongoDB Power Always-On Payments .
L’ensemble complet des données, comprenant l’échelle complète des indicateurs pour chaque étape allant de 500 à 6 000 transactions de paiement par seconde, ainsi que des détails supplémentaires sur la manière dont ces résultats ont été obtenus, est disponible sur demande auprès d’Icon Solutions ou de MongoDB.
À propos d’Icon Solutions
Icon Solutions est une entreprise de technologie financière qui conçoit et met en œuvre des systèmes de paiement de pointe depuis 2009. Son produit phare, l’Icon Payments Framework (IPF), est un cadre de développement de solutions de paiement éprouvé à l’échelle internationale, auquel font confiance des banques de premier plan telles que Citi, NatWest et BNP Paribas. L’IPF aide les banques à accélérer la transformation de leur infrastructure de paiement en leur permettant de créer, de tester et de déployer plus rapidement des solutions de traitement des paiements, tout en gardant le contrôle des délais et des coûts.
À propos de MongoDB
MongoDB, dont le siège social est situé à New York, a pour mission d’aider les innovateurs à créer, transformer et révolutionner les secteurs d’activité grâce à des logiciels. Sa plateforme de données unifiée et intelligente est conçue pour alimenter la prochaine génération d’applications, grâce à des fonctionnalités intégrées pour les données opérationnelles, la recherche, l’analyse en temps réel et la récupération alimentée par l’IA. Des millions de développeurs et plus de 67 000 clients issus de presque tous les secteurs d’activité, dont environ 75 % des entreprises du classement Fortune 100, font confiance à MongoDB pour leurs applications les plus importantes.
Le texte du communiqué issu d’une traduction ne doit d’aucune manière être considéré comme officiel. La seule version du communiqué qui fasse foi est celle du communiqué dans sa langue d’origine. La traduction devra toujours être confrontée au texte source, qui fera jurisprudence.
Contacts
Contacts médias
Icon Solutions : debbie@iseepr.co.uk MongoDB : info@mongodb.com