Un des plus important fournisseurs mondiaux de services financiers, innove avec InterSystems et relève les défis du milliard de transactions en toute sécurité.
Avantages
• Performance
• Évolutivité
• Mise en cache de données dynamiques
La banque d’investissement a conçu sa plateforme de trading au milieu des années 90. Mais au cours de la dernière décennie, le volume des échanges d’actions traité par la banque a explosé, en raison de la volatilité des marchés, des pratiques modernes de haute fréquence et d’une augmentation importante de sa clientèle. Confronté à une forte augmentation du volume de transactions, la plateforme montre alors ses limites et ses faiblesses.
Pour améliorer les performances, la première étape a été de repenser l’architecture de routage des ordres de bourse, au cœur de l’infrastructure de trading. Dans sa première version, l’application de routage était basée sur une base mémoire évoluée développée en interne, dotée d’un requêteur SQL simple pour interroger les données.
Techniquement, chaque instance exigeait un serveur dédié, qui stockait dans son cache mémoire un ensemble « d’images mémoire » – série de pointeurs vers les données résidentes dans toutes les autres instances de l’application. Cette architecture garantissait une grande performance, malheureusement devenue insuffisante au vu des évolutions de l’activité de la banque.
Le principal problème identifié n’était toutefois pas exactement la performance, mais l’instabilité du système lui-même. En effet, le système fonctionnait, jusqu’au moment où il ne fonctionnait plus vraiment… Cette situation étant générée par l’accroissement du nombre de transactions qui stressait fortement le système. Cette instabilité aléatoire était inacceptable pour la banque.
En effet, qu’un système crashe quelques minutes et génère une perte de revenus importante (risque chiffré en millions de dollars) est un problème sérieux, mais mesurable. Mais qu’un système soit non prévisible et perde des transactions de manière aléatoire ajoute au risque de perte de revenu, un risque très important pour la banque toute entière, qui plus est non mesurable.
Pour résoudre ces problèmes, la banque a d’abord porté les caches d’images mémoire de l’application de routage vers InterSystems Caché. Elle a adopté une architecture modulaire où la mise en cache des données, la persistance des données, les requêtes et la messagerie étaient séparées logiquement. InterSystems Caché est idéal dans un tel scénario car il peut fonctionner comme un cache mémoire tout en offrant une persistance complète. Grâce au ‘bindings’ C++ légers de Caché, la banque a multiplié les performances par cinq.
Performances record – Août 2011: Lors d’un pic d’échanges particulièrement important en août 2011, la plateforme de la banque a traité le chiffre record d’un milliard de transactions par jour.
A l’aide du protocole InterSystems ECP (Enterprise Cache Protocol) qui prend en charge les données dynamiques distribuées, la banque Crédit Suisse a remplacé les images mémoires interne par la couche ‘serveur d’application’ d’InterSystems Caché, permettant l’exécution des requêtes en temps réel sans ralentir le traitement des échanges.
La deuxième phase du projet consistait à améliorer les performances de l’application globale de gestion des ordres, avec laquelle les courtiers génèrent les ordres ensuite pris en charge par l’architecture globale d’acheminement des ordres.
Cette application de gestion des ordres est installée sur plus de 1200 postes clients dans le monde. Tous ces postes conservent un cache local de données et communiquent avec un cache de données commun via des serveurs « de niveau intermédiaire ». Le niveau intermédiaire communique à son tour avec l’application d’acheminement des ordres.
La banque a mis en œuvre InterSystems Caché sur les serveurs intermédiaires et utilise le protocole ECP pour mettre les données en cache localement sur les postes clients de gestion des ordres. Le résultat est à la fois une augmentation importante des performances et une réduction considérable du temps de récupération nécessaire en cas de panne.
Testé dans un premier temps pour atteindre 250 millions de transactions par jour, l’architecture a bientôt absorbé en production plus de 500 millions de transactions par jour ( soit une performance globale multipliée par 5 tout en divisant par deux le matériel nécessaire) avec une pointe à 1 milliard en août 2011.
Tout en éliminant le risque aléatoire grâce à une technologie très robuste et une traçabilité sans faille.
En s’appuyant sur InterSystems Caché, la banque bénéficie des performances et de la capacité dont elle a besoin pour relever les défis liés à la croissance actuelle et future de son activité.