En effet, conçu au milieu des années 90, la plateforme de trading de l'établissement montrait des faiblesses et une certaine instabilité, en étant confronté à une forte augmentation du volume d'échanges. Au cours de la dernière décennie, le volume d'échanges traité par la banque a explosé, en raison de la volatilité des marchés, des pratiques modernes et d'une augmentation importante de sa clientèle.

Amélioration des performances du système d'échanges
Pour améliorer les performances de son système d'échanges, la première étape entreprise par la banque a été de repenser l'architecture de routage des ordres, qui réside au cœur de son infrastructure d'opérations en bourse. Dans sa première incarnation, l'application d'acheminement des ordres était basée sur un cache de données en mémoire développé en interne, avec un simple analyseur SQL pour interroger les données. Chaque installation exigeait un serveur dédié, qui stockait dans son cache un ensemble « d'images mémoire », une série de pointeurs vers les données résidentes dans toutes les autres instances de l'application.

Pour résoudre ces problèmes, la banque a porté les caches d'images mémoire de l'application d'acheminement des ordres vers 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 logiquement séparées. Caché est idéal dans un tel scénario, car il peut fonctionner comme un cache en mémoire tout en offrant une persistance complète. À l'aide des associations C++ légères de Caché, la banque a pu multiplier les performances par cinq.

En outre, à l'aide du protocole ECP (Enterprise Cache Protocol), la fonction intégrée de Caché qui permet la prise en charge de données dynamiques distribuées, elle a pu remplacer les images mémoire internes par une couche de serveur d'application basée sur Caché. Cela permet l'exécution des requêtes en temps réel sans ralentir le traitement des échanges.

Améliorer les performances de l'application de gestion des ordres
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 traités par l'architecture globale d'acheminement des ordres. Des clients de gestion des ordres sont installés sur plus de 1 200 postes de travail dans le monde, qui conservent tous un cache local de données et qui communiquent avec un cache de données central sur 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 Caché sur les serveurs intermédiaires et utilise le protocole ECP pour mettre les données en cache localement sur les 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.

En appuyant son système d'opérations en bourse sur Caché d'InterSystems, Credit Suisse bénéficie des performances et de la capacité dont elle a besoin pour relever les défis liés à sa croissance actuelle et à venir. 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. Pour preuve, cette performance record en Août 2011, où lors d'un volume d'échanges particulièrement important, le système de gestion d'opérations en bourse basé sur Caché de Credit Suisse a traité le chiffre record d'un milliard d'échanges quotidiens.

Une expertise BigData qu'InterSystems démontrera lors de la conférence-exposition BigData Paris qui se déroulera les 20 et 21 mars 2012 à la Cité Internationale Universitaire de Paris - Plus d'informations : www.bigdataparis.com/fr

InterSystems