Quand performance, scalabilité et robustesse bousculent vos habitudes de développement

OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable
Quand performance, scalabilité et robustesse bousculent vos habitudes de développement Retour d’expérience - Céline Gilet - 21 mars 2019 1

2 Faisons connaissance ๏ Tribu Software Craftsmanship à OCTO Technology ๏ Développeuse depuis + de 10 ans ๏ Conseil & accompagnement sur les pratiques de qualité logicielle ๏ Formation (Test Driven Development, Clean Code, Legacy Code..) Céline Gilet @celinegilet Céline Gilet

THERE IS A BETTER WAY Présentation du contexte projet 01
3

4 Présentation du contexte projet ๏ Le futur système de comptabilité d’un des grands acteurs du secteur bancaire ๏ Design d’une architecture capable de répondre aux enjeux croissants de volumétrie ๏ Intégration, calcul et export sur des centaines de millions de données par jour ๏ Performance, scalabilité et robustesse comme ligne directrice ๏ Plateau de développement agile de 30 personnes sur 10 mois < Différents profils : architectes, business analysts, coachs, développeurs, ops < Trois domaines fonctionnels à adresser : compensation, valorisation, axes de restitution < Mise à l’épreuve de l’architecture sur la réalisation de fonctionnalités clés Le défi à relever : performance, scalabilité et robustesse

5 Présentation du contexte projet Le schéma d’intégration au sein du SI Outils de restitution E.C E.C E.C E.C E.C E.C E.C Système d’Interprétation Événements comptables Mouvements Financiers E.C Entité comptable Monitoring Supervision Système Comptable COMPENSATION VALORISATION AXES DE RESTITUTION Et pleins d’autres…. Référentiels Paramétrage

THERE IS A BETTER WAY Déclinaison de 2 concepts côté
architecture : Composants & Pipelines 02 6

7 Composants & Pipelines ๏ Un rôle clair - pouvoir expliquer le job du composant en 1 phrase ๏ Une déclinaison logique et cohérente de ses fonctionnalités ๏ Une mise à disposition de ses services sous plusieurs formes ๏ Une responsabilité à vision fonctionnelle ou technique ๏ Un modèle de passage à l’échelle (scalabilité / auto-scalabilité) Le composant comme unité clé de l’architecture COMPOSANT Périmètre Caractéristiques ๏ Testable facilement et rapidement ๏ Autonome et indépendant au niveau “build” et “deploy” ๏ Ouvert aux changements et évolutions (frameworks, stockage...) ๏ Garant des performances sur des échelles de volumétries cibles ๏ Tolérant aux pannes et mécanismes de rejeu (robustesse)

8 Composants & Pipelines Un exemple : le composant technique de gestion des frontières FRONTIÈRE Objectif : récupérer les données brutes des fichiers de mouvements financiers pour les mettre à disposition du métier Fonctionnalités et traitements du composant Fichier de mouvements financiers Mouvements financiers dispos pour le métier Décompression Traduction Sauvegarde Parsing de données

9 Composants & Pipelines Un exemple : le composant fonctionnel d’intégration des données financières Objectif : réaliser les opérations d’intégration des mouvements financiers pour permettre le déclenchement des briques suivantes (soldes, restitution) Fonctionnalités et traitements du composant Mouvements financiers • Rejetés • Suspendus • Entrés en compta Contrôle de validité Mise en rejet Opérations de defaulting Enrichissement Sauvegarde Mise en suspens Mouvements financiers dispos pour le métier INTÉGRATION

10 Composants & Pipelines Assemblage et orchestration des composants ๏ Un composant est un maillon de la chaîne ๏ Pour réaliser un traitement métier de bout en bout, il faut assembler les composants pour créer un pipeline ๏ Un pipeline se définit par : < Un déclencheur < Des données en entrée < Une séquence de composants à appeler < Un résultat produit ๏ Deux typologies de pipelines : Flux et Batch ๏ Émergence d’un nouveau composant d’orchestration : pas de communication directe entre composants métier ORCHESTRATION Oracle Mouvements Financiers INTÉGRATION FRONTIÈRE Cluster Cassandra VALORISATION COMPENSATION EXPORT Fichiers produits

11 Composants & Pipelines Stockage des données d’un pipeline ๏ Chaque composant dialogue avec UNE seule base de données < Composants métiers => Cassandra < Composant orchestration => Oracle ๏ L’écriture d’une table est gérée par UN seul composant ๏ La lecture d’une table est possible par plusieurs composants ๏ Un quadrigramme par composant pour identifier facilement quel composant est responsable de l’écriture d’une table < Composant INTÉGRATION => INTG < Table INTG_FINANCIAL_POSTING ORCHESTRATION Oracle Mouvements Financiers INTÉGRATION FRONTIÈRE Cluster Cassandra VALORISATION COMPENSATION EXPORT Fichiers produits

12 Composants & Pipelines Relationnel vs Non-Relationnel Base de données relationnelles ๏ Avantages < Technologie mature (SQL) < Transactions ACID < Requêtes complexes avec jointures multiples ๏ Inconvénients < Modèle de scaling vertical < Volumétrie moyenne < Performance limitée Apache Cassandra ๏ Avantages < Modèle de scaling horizontal < Base de données distribuée < Performance prédictible < Haute disponibilité < Scalabilité linéaire < Forte volumétrie “Big Data” ๏ Inconvénients < Langage dédié : CQL < Pas de transactions natives < Pas de jointures

13 Composants & Pipelines Pourquoi Cassandra pour les composants métiers ? Cassandra impose une modélisation & un stockage spécifique pour pouvoir prétendre à la performance et à la scalabilité linéaire Cassandra n’est pas là pour remplacer les bases de données relationnelles Les besoins sont différents et les 2 approches peuvent cohabiter Modélisation ๏ Partir des cas d’utilisation métier pour avoir les patterns d’accès aux données ๏ Design per query : disposer des requêtes de lecture pour pouvoir écrire de façon à avoir de la performance Stockage ๏ L’unité de traitement clé : les partitions ๏ Distribution des partitions parmi les noeuds du cluster ๏ Cible : 1 requête, 1 partition, 1 noeud

THERE IS A BETTER WAY Zoom sur le développement d’un
composant Clean Architecture 03 14

15 Clean Architecture Dans quel but ? ๏ La valeur d’un composant réside dans ses cas d’utilisation et ses services métiers ๏ Isoler et protéger cette valeur des changements et évolutions techniques ๏ Décorréler le modèle métier du modèle de stockage ๏ Le domaine métier d’un composant n’ évolue pas au même rythme que les éléments techniques (frameworks, base de données, infra…) ๏ Pas de dispersion de la logique métier dans plusieurs couches ๏ Des tests ciblés sur une problématique précise : rapidité, fiabilité et robustesse ๏ Une prise en compte des aspects techniques à posteriori ๏ Un découpage par responsabilité pour favoriser les évolutions et accélérer le cycle des déploiements

16 Clean Architecture Schéma d’un composant INFRASTRUCTURE USE CASES DOMAIN COMPOSANT POINTS D'ENTRÉE FOURNISSEURS DE DONNÉES APIs JMS EVENTS GUI TESTS Bases de données Système de fichiers CONFIGURATION

THERE IS A BETTER WAY Stratégie de tests d’un composant
04 17

18 Stratégie de tests d’un composant Les 2 volets MÉTIER PERFORMANCE Fonctionnalités métier INFRASTRUCTURE USE CASES DOMAIN • Clean Architecture • Piloté par les tests (TDD)

19 Stratégie de tests d’un composant Le volet métier MÉTIER Fonctionnalités métier INFRASTRUCTURE USE CASES DOMAIN • Clean Architecture • Piloté par les tests (TDD) Méthodologie ๏ Appropriation du contexte métier à travers des exemples et des sessions d’Event Storming ๏ Valider au plus tôt le bon fonctionnement des use-cases : “value first” ๏ Respect de la pyramide des tests ๏ Automatisation du calcul de la pyramide des tests et du respect de la clean archi dans la phase de qualimétrie des builds Unitaire Intégration Fonctionnel Coût Temps d’exécution Précision / Fiabilité Rapidité Quantité de tests • Example Mapping (BDD) • Event Storming (DDD)

20 Stratégie de tests d’un composant Le volet performance PERFORMANCE Fonctionnalités métier INFRASTRUCTURE USE CASES DOMAIN • Clean Architecture • Piloté par les tests (TDD) Méthodologie ๏ Des uses-cases valides fonctionnellement mais qui potentiellement n’ont pas des temps de réponse acceptable et linéaire ๏ Discussion avec le métier pour trouver un axe de parallélisation / répartition des calculs ๏ Passage éventuel des use-cases sous Apache Flink (Framework de traitements distribués) Temps de réponse sur des volumétries cibles Linéarité des temps de réponse

THERE IS A BETTER WAY La performance d’un composant 05
21

22 La performance d’un composant Une démarche en 3 phases EXPÉRIMENTER FORMALISER ANALYSER PHASE D’EXPLORATION / APPRENTISSAGE RÉCOLTER LES MÉTRIQUES LANCER LES SCÉNARIOS DE PERF ALERTER PHASE D’AUTOMATISATION / INDUSTRIALISATION HISTORISER RÉCOLTER LES MÉTRIQUES LANCER LE SCÉNARIO A OPTIMISER PHASE D’OPTIMISATION TESTER UNE PISTE A LA FOIS 1 2 3

23 La performance d’un composant La phase d’exploration / apprentissage ๏ Définir les scénarios (qualité vs quantité) ๏ Établir des échelles de volumétrie progressives ๏ Disposer de données représentatives métier (récupération de fichiers de production) ๏ Identifier les composants en dépendance (amont / aval) + les systèmes externes pour bouchonnage ๏ Prévoir un mécanisme d’injection de données pour le composant (référentiels, paramétrage…) EXPÉRIMENTER FORMALISER ANALYSER PHASE D’EXPLORATION / APPRENTISSAGE 1 Formaliser une démarche et une stratégie de performance ๏ Figer une version applicative stable et durcie (périmètre fonctionnel validé) ๏ Disposer d’un environnement dédié à la performance en isolation complète (pas de conflits sur les données et fichiers manipulés) ๏ Pouvoir être indépendant vis à vis des problématiques d’infrastructure : Kubernetes, ELK… ๏ Pouvoir lancer le composant sur un poste de développeur (debug & boucle de feedback rapide) Expérimenter la démarche formalisée sur une FAIBLE volumétrie ๏ Déterminer les moyens de collecte des métriques applicatives : api, logs, requêtes en base... ๏ Prévoir des endpoints donnant l’état d’avancement d’un traitement en mode asynchrone ๏ Adapter la configuration des logs (level + logger dédié à la perf) ๏ Etre vigilant sur l’analyse des logs : présence d’erreurs et niveau de verbosité ๏ Contrôler la collecte des métriques système : CPU, Mémoire, I/O Analyser les résultats pour apprendre avant d’automatiser

Cette automatisation ne doit pas intervenir trop tôt : il faut connaître suffisamment le système pour pouvoir poser des assertions et mettre en place un mécanisme d’alerte efficace L’objectif est de lancer les scénarios régulièrement et sur une volumétrie représentative pour : ๏ Garantir la tenue des performances dans le temps ๏ Détecter au plus vite des régressions suite à des développements ๏ Confirmer les gains d’une campagne d’optimisation 24 La performance d’un composant La phase d’automatisation / industrialisation RÉCOLTER LES MÉTRIQUES LANCER LES SCÉNARIOS DE PERF ALERTER PHASE D’AUTOMATISATION / INDUSTRIALISATION HISTORISER 2

25 La performance d’un composant La phase d’optimisation RÉCOLTER LES MÉTRIQUES LANCER LE SCÉNARIO A OPTIMISER PHASE D’OPTIMISATION TESTER UNE PISTE A LA FOIS 3 ๏ Un cycle d’optimisation est constitué de plusieurs itérations ๏ Chaque itération doit permettre de confirmer ou infirmer UNE seule piste d’optimisation ๏ Besoin d’avoir une volumétrie ni trop petite ni trop grande pour avoir des temps de réponse représentatifs et une boucle de feedback acceptable (de 3 à 4 minutes) ๏ La difficulté consiste à identifier et trouver des pistes d’optimisation : nécessité d’un outil permettant de faire du profiling

26 La performance d’un composant Le profiling à l’aide Scénario à optimiser ๏ La chaîne d’intégration de fichiers de mouvements financiers ๏ Volumétrie de 1 million de mouvements financiers ๏ Composant (integration.jar) qui tourne dans un container docker ๏ Contexte multi-thread ๏ Sous-utilisation des capacités CPU ๏ Identifier les points de contentions / blocages Adoption de YourKit ๏ Intégration facile au composant (process java : springboot / flink) ๏ Profiling possible sur des containers docker à distance ๏ Profiling des threads ๏ Capture et suivi d'événements (IO, socket, écriture cassandra..) ๏ Ecriture possible de sondes personnalisées ๏ Prise de snapshots pour historiser le profiling de campagnes de tirs 2 outils de profiling

27 La performance d’un composant Après plusieurs itérations d’optimisation Exemples de pistes d’amélioration ๏ Passer les sauvegardes Cassandra en mode asynchrone ๏ Supprimer l’utilisation de spring-data-cassandra pour utiliser directement le driver cassandra ๏ Mise en place d’un cache applicatif sur la récupération des données de référentiel ๏ Révision du mécanisme de parsing avec FlatPack ๏ Révision de la génération des identifiants en contexte multi-threading 1h53 3h 10h 17h Optimisation de Cassandra en écriture Optimisation sur les requêtes en lecture Optimisation applicative Intégration de 150 millions de mouvements financiers

THERE IS A BETTER WAY La scalabilité d’un composant 06
28

29 La scalabilité d’un composant Kubernetes à l’aide 1 pod = 1 conteneur docker = 1 composant Besoins ๏ S’adapter au rythme des demandes et en particulier aux montées en charge ๏ Maintenir les fonctionnalités et les performances de traitement Comment ? ๏ Utilisation de la plateforme Kubernetes pour gérer le passage à l’échelle ๏ Fonctionne avec la technologie de conteneurisation Docker ๏ Manipulation et configuration de ressources Kubernetes

30 La scalabilité d’un composant Les choix possibles Définition d’un nombre fixe d’instances • Définition du nombre de réplicas dans la configuration du ReplicaSet • Les ReplicaSets s’assurent du respect du taux de réplication en re-créant ou supprimant des pods replicas : 3 Définition d’une fourchette min/max d’instances • Définition de l’auto-scaling dans la configuration du ReplicaSet : HorizontalPodAutoScaler minReplicas: 3 maxReplicas: 10 A la demande • Utilisation de l’API Kubernetes pour manipuler les ressources nécessaires (création / suppression) • Dépendance / Couplage à la plateforme Kubernetes dans les développements Prédictibilité des sollicitations du composant

THERE IS A BETTER WAY La robustesse d’un composant 07
31

32 La robustesse d’un composant Kubernetes & développement Partir du principe qu’un composant peut tomber à n’importe quel moment ORCHESTRATEUR COMPOSANT COMPOSANT Requête (Demande : 1234) Pas d’acquittement de la demande (1234) au bout d’un certain temps (timeout) Envoi de la demande : rejeu avec un nouvel identifiant (1235) Requête (Demande : 1235) Réponse (Demande : 1235) Détecter la perte et redémarrer une nouvelle instance du composant Relancer les traitements métiers arrêtés en plein milieu (dev d’un mécanisme de rejeu) 2 1 1 2

THERE IS A BETTER WAY Les pipelines comme colonne vertébrale
08 33

34 Les pipelines comme colonne vertébrale De la validation unitaire à la validation de pipeline ROBUSTESSE PERFORMANCE SCALABILITÉ ๏ Validation unitaire par composant des aspects de performance, scalabilité et robustesse ๏ Permet d’accélérer le travail au niveau pipeline avec le chaînage de plusieurs composants ORCHESTRATION Oracle Mouvements Financiers INTÉGRATION FRONTIÈRE Cluster Cassandra VALORISATION COMPENSATION EXPORT Fichiers produits

35 Les pipelines comme colonne vertébrale Notre contrat avec le métier ROBUSTESSE PERFORMANCE SCALABILITÉ ❏ Test end-to-end au vert ❏ Template d’analyse de perf • Description du contexte et des configurations infra (Kubernetes, Flink, Cassandra) • Temps de réponse par volumétrie des tirs de performance • Recommandation sur l’infrastructure cible ❏ Test end-to-end au vert ❏ Template d’analyse de scalabilité • Description du contexte et des configurations infra • Démarche de montée en charge • Linéarité des temps de réponse • Recommandation sur le choix du mode de passage à l’échelle ❏ Test end-to-end au vert ❏ Destruction aléatoire des composants du pipeline ❏ Template d’analyse de robustesse • Description du contexte et des configurations infra • Liste des pods détruits par les règles Chaos

36 Performance, Scalabilité, Robustesse Les points d’attention ๏ Adresser toujours ces problématiques autour de cas d’utilisation métier : n’en faîtes pas des sujets technico-technique ๏ Sagesse et patience : commencer petit et unitaire avant d’envisager l’automatisation et la volumétrie la plus grosse ๏ Un seul combat à la fois : performance puis scalabilité puis robustesse ๏ Des bonnes guidelines de design et d’architecture : rôle et responsabilité des composants, principes d’orchestration, standards de communication, stockage en mode append-only... ๏ Et des bonnes pratiques de développement : clean archi, utilisation des streams, idempotence des uses-cases pour le rejeu, mode stateless, twelve-factor app…

37 MERCI ! :) Des questions ? @celinegilet Céline Gilet

Quand performance, scalabilité et robustesse bo...

Quand performance, scalabilité et robustesse bousculent vos habitudes de développement

More Decks by Céline Gilet

Other Decks in Technology

Featured

Transcript