Moteurs de calcul de risques serverless avec AWS Step Functions et AWS Fargate

Cet article est réalisé par Soufiane Matine, Senior Expert Architect, et Thierry Wilmot, responsable de l’équipe calculateurs chez Société Générale, en collaboration avec Roberto Migli, Solutions Architect pour le segment Financial Services de AWS.

L’un des nombreux avantages de l’utilisation du cloud AWS est l’accès à des ressources à la demande en quelques secondes. C’est pourquoi de nombreux clients utilisent la puissance et la flexibilité du cloud pour résoudre des cas d’usage qui nécessitent une puissance de calcul élevée pendant une période potentiellement courte. Cet article vous présente un exemple concret en illustrant la façon dont l’une des principales institutions bancaires d’Europe, la Société Générale, utilise AWS pour résoudre le besoin d’une capacité de calcul flexible, scalable, et avec des coûts réduits.

A propos de la DSI des directions centrales de la Société Générale

La DSI des directions centrales de Société Générale sert l’informatique des unités métiers dans les domaines Finance, Risques, Conformité, Ressources Humaines, Communication, Immobilier, Achats ainsi que leurs filières étendues à l’ensemble du groupe.

Dans le cadre du programme de transformation de cette direction centrale et 5 ans après la conception en interne du premier calculateur de risque de crédit, l’équipe Calculateur passe un nouveau cap en décembre 2020 en se dotant du premier calculateur basé sur les services AWS.

Plus qu’une nouvelle version, c’est une nouvelle génération de calculateurs que la direction avait souhaitée au lancement de cette initiative, afin de faire bénéficier à terme au plus grand nombre, de l’expérience acquise au fil des années par l’équipe Calculateur, en introduisant un nouveau type de service, au juste coût, orienté vers le client final. Les premières maquettes de service ont vu le jour après quelque mois de tests, durant lesquels l’équipe a testé des capacités de calcul jusqu’au 1800 noeuds et 10Go de volume échangé par run pour répondre aux besoins de la Société Générale. Pour aboutir fin 2020, à une offre complète, neutre au niveau métier, industrialisée, ouverte à plusieurs langages et interopérable avec les solutions Big data.

Cette offre à destination des Tech Leads et Développeurs, se décline par un ensemble de services automatisés de déploiement et de kit de démarrage, pour des usages orientés traitement massif ou temps réel. Elle décuple la puissance de calcul pur, pour adresser les nouveaux besoins de simulation de la Société Générale. Elle élève le niveau de résilience, sur plusieurs sites, au niveau des meilleurs standards du marché. Elle permet la réduction des temps de développement (-20%) et minimise les coûts d’exploitation (jusqu’à 7 fois) grâce à la facturation à l’usage. Une aide à la conception de nouveau calculateur étant aussi incluse dans l’offre proposée.

En 2021, deux équipes vont bénéficier de cette toute nouvelle capacité. Les équipes de la Société Générale prévoient également la migration complète des calculateurs risque de crédit et la déclinaison de l’offre sur de nouveau usages métiers (Compliance & ALM).

Enfin, dans une perspective à deux ans, les équipes de la Société Générale réfléchissent à une offre encore plus générique, où les algorithmes de calculs seraient des données d’entrée comme les autres, permettant de nouveaux usages sans développements spécifiques.

Après un an de développement, nous sommes capables de fournir à nos clients une grille de calcul pour les besoins temps réel (fréquence élevée d’appel sur une faible volumétrie) et pour des besoins plus complexes, nécessitant une puissance brute plus conséquente sur des volumétries plus importantes.
Nous prévoyons une montée en puissance de cette nouvelle solution dans les prochains mois, pour servir nos enjeux de simulation dans le domaine du risque de crédit dans un premier temps, puis plus largement de la finance, de la liquidité & de la solvabilité.

Contexte métier et technologique

En premier lieu, il fallait adresser l’augmentation des capacités de simulation pour mieux accompagner les métiers du risque à identifier précisément les impacts en risque de crédit des événements économiques (ex : Covid-19, Brexit, Matière première…)

Ces opérations nécessitent un nombre élevé de processeurs car le calcul peut être effectué en parallèle. Avec une puissance de calcul suffisante, une exécution peut prendre 30 minutes. Une fois l’exécution terminée, les résultats peuvent être stockés et aucune ressource informatique supplémentaire n’est nécessaire. La mise à l’échelle de ce type d’opérations on-premises n’est pas optimale, car les clients doivent acheter des instances pour avoir la capacité de répondre aux besoins en pic. Les événements récents ont démontré qu’il est très difficile de planifier les besoins en ressources informatiques, à la hausse ou à la baisse.
Un second objectif visait à offrir un accès simple, utilisable par le plus grand nombre a ces nouvelles capacités de calcul et à diminuer le temps de développement en offrant aux développeurs et tech leads un ensemble d’applications en marque blanche.
Le troisième objectif était d’offrir plus de puissance à coût identique.

C’est pourquoi en 2020 la «Computing Farm» a été migrée vers le Cloud AWS. L’équipe a identifié les exigences suivantes :

• Coûts réduits : la nouvelle ferme informatique doit avoir des coûts minimes de fonctionnement et d’exploitation,
• Minimisation du refactoring : la Société Générale a déjà développé des moteurs de calcul qui devraient pouvoir fonctionner dans la nouvelle architecture avec un effort de refactoring minimal,
• Temps d’exécution constant : les temps d’exécution de chaque opération de calcul doivent être constants et ne doivent pas augmenter lorsque plusieurs opérations de calcul sont demandées en parallèle,
• Sécurisé: chaque exécution doit être entièrement auditable,
• Scalabilité (presque) infinie : la limite des exécutions parallèles maximales doit être aussi élevée que possible,
• Conception flexible : la « Computing Farm» doit permettre de déployer de nouveaux moteurs de calcul dans une solution standard et reproductible.

Architecture de la solution

Le schéma ci-dessous présente l’architecture générale de la solution sur AWS :

L’application s’exécute dans un Amazon VPC privé sans accès direct à Internet. Nous nous appuyons sur VPC Endpoints pour tous les services utilisés sur le projet afin d’isoler complètement la solution au niveau du réseau.

Les utilisateurs finaux interagissent avec le système via une API REST, exposée via un API Gateway privée. Les utilisateurs internes devront télécharger l’ensemble des donnes nécessaires pour le calcul dans un bucket Amazon S3 privé. Ils invoqueront ensuite le moteur de calcul de leur choix via l’API privée. Il existe 2 types de moteurs de calcul: temps réel (synchrone) et batch (asynchrone). Les moteurs de calcul sont déclenchés par une fonction AWS Lambda.

Le traitement en temps réel s’exécute en quelques secondes et utilise Amazon ECS pour exécuter des conteneurs sur AWS Fargate. AWS Fargate supprime le besoin de provisionner et de gérer les serveurs : il vous permet de spécifier et de payer les ressources par application et améliore la sécurité grâce à l’isolation des applications dès la conception. Comme ces demandes peuvent être fréquentes, les conteneurs sont toujours actifs et sont associés à un Service Auto Scaling, qui peut ajouter et supprimer des conteneurs en fonction de la consommation du processeur.

Le type “batch” prend au contraire plus de temps pour être complété, et est donc géré via une file d’attente de travaux, où les utilisateurs finaux envoient la demande de calcul à l’API, et obtiennent en réponse un ID de job : grâce à cela, l’utilisateur peut interroger à nouveau l’application via l’API Gateway pour savoir quel est le statut de son travail. L’exécution du job est déléguée à AWS Step Functions, un orchestrateur de fonctions sans serveur qui facilite l’orchestration des fonctions AWS Lambda et de plusieurs services AWS.

Examinons de plus près le traitement de type batch. Avec AWS Step Functions, nous pouvons décrire le workflow et intégrer d’autres services AWS si nécessaire. Dans ce cas, nous utilisons les tâches Amazon ECS comme moteur d’exécution principal. Nous devons d’abord exécuter une analyse préliminaire sur les données en entrée, ce qui nous permet d’effectuer un pré-traitement et, surtout, de diviser l’entrée en parties plus petites qui peuvent être traitées indépendamment et en parallèle. Nous utilisons l’état Map pour exécuter chaque tâche en parallèle, avec un paramètre de concurrence configurable, comme l’illustre le diagramme d’AWS Step Functions ci-dessous :

Puisque nous utilisons des tâches Amazon ECS, nous transmettons les paramètres d’entrée à l’application en tant que variables d’environnement, qui sont définies dynamiquement par l’étape de préparation. À ce stade, chaque tâche s’exécutera dans une tâche AWS Fargate (nous pouvons en fait la configurer), et une fois toutes les opérations terminées, les résultats de chaque calcul sont rassemblés dans un état final dans un bucket S3 privé.

Transformer le code de la Société Générale pour qu’il s’exécute dans AWS Fargate était assez simple. Nous devions tout d’abord supprimer toute la logique complexe de distribution de la charge de travail – car elle est maintenant complètement remplacée par AWS Step Functions. Ensuite, nous devions être en mesure d’utiliser Amazon S3 au lieu du système de fichiers local pour accéder et écrire les résultats des calculs. Enfin, nous avons ajouté la possibilité d’utiliser des variables d’environnement pour configurer toutes les entrées / sorties de chaque exécution.

Cette configuration est entièrement sans serveur – pas de correctifs de système d’exploitation, pas d’instances à maintenir et à exécuter. De plus, les exécutions de calcul sont indépendantes les unes des autres, et en utilisant des balises de conteneurs et différentes fonctions d’étape, nous pouvons même exécuter en parallèle différentes versions des moteurs, tester plus rapidement et réduire les risques de régressions. Une multitude de métriques sont également mises à disposition à partir des services AWS, nous pouvons suivre les temps d’exécution, les échecs, le nombre de requêtes, etc.

Voici quelques conseils lors de l’utilisation de Step Functions avec Amazon ECS :

• La quantité de données qui peuvent être passées entre les états est gouvernée par des limites – l’utilisation des états de type Map avec Amazon ECS peut produire de grandes volumes de données en sortie. Assurez-vous d’utiliser ResultPath pour contrôler quelles informations doivent être transmises à travers la machine à état,
• Utilisez des variables d’environnement pour transmettre des données entre les états de la Step Function et les tasks Amazon ECS – si vous devez passer des configurations volumineuses, utilisez des fichiers S3 comme bus de données,
• Lors de l’exécution de nombreuses tâches en parallèle avec AWS Fargate, vous pouvez rencontrer des limites de services permettant le bon fonctionnement continu du service Amazon ECS – vous pouvez définir une stratégie de Retry pour permettre à la Step Function de réessayer automatiquement les taches en cas d’échec,
• Si vos tâches sont de longue durée, vous pouvez envisager d’utiliser Heartbeat pour que les tasks Amazon ECS envoient un signal pendant le traitement pour indiquer à Step Functions que la tâche est toujours active

Pour plus de flexibilité

L’architecture ci-dessus illustre l’une des configurations possibles d’un moteur de calcul des risques spécifique : comment rendre cette solution facilement reproductible et suffisamment flexible pour fonctionner avec différents moteurs, à l’échelle ? Nous décidons de tout opérer au travers de l’utilisation d’AWS Cloud Development Kit (CDK), un framework de développement logiciel open source pour modéliser et provisionner vos ressources d’application cloud à l’aide de langages de programmation familiers. Avec AWS CDK, il est possible de créer des constructions de plus haut niveau qui peuvent utiliser et configurer plusieurs services dans une stack, augmentant ainsi la réutilisation des composants par différentes équipes.

Par exemple, pour certains moteurs de calcul, nous devrons avoir recours aux instances EC2 – Spot chaque fois que possible. Nous avons implémenté une machine à état standard dans AWS CDK qui crée une flotte ponctuelle à la volée. La machine à état du générateur Spot Fleet est mise à disposition et abstraite sous la forme d’un module NPM qui peut être réutilisé entre les équipes et déployé sur différents comptes AWS – tout ce dont vous avez besoin est d’importer le module et de l’inclure dans la stack CDK, avec une ligne de code qui ressemble à ceci en Typescript :

new SpotfleetStateMachine(app, `stepfunction-spotfleet`, {
  vpc: coreStack.vpc,
  ecsCluster: ecsStack.batchProcessorEcsCluster,
  fleetCapacity: 30
});

Toute la sécurité, la configuration des fonctions Lambda, la stratégie de retry en cas d’erreur et les tests sont déjà intégrés dans le module et simplifiés pour l’utilisateur.

Dans cet article, nous avons partagé comment la Société Générale exploite différentes technologies AWS pour créer des moteurs de calcul hautement performants et configurables. À l’avenir, l’équipe prévoit de tester les instances basées sur processeurs ARM Graviton2 pour un meilleur rapport prix/performances et de tirer parti des services AWS natifs supplémentaires pour créer de futures plates-formes pour répondre à leur besoins métiers.

Soufiane Matine est Senior Expert Architect chez Société Générale depuis plus de 4 ans. Il s’est spécialisé dans la data, conteneurisation et le cloud. Il travaille aujourd’hui à accompagner les projets Société Générale dans leur transformation Cloud en tant que lead Cloud Architect.

Roberto Migli est Solutions Architect dans l’équipe AWS France, il assiste les clients du secteur financiers à adopter et tirer le meilleur partie les technologies du Cloud AWS