Préface. Vous avez dit performances?

Transcription

1

2

3 Préface Vous avez dit performances? Avons-nous encore besoin de nous préoccuper des performances des applications informatiques? Les machines montent en puissance régulièrement, fidèles au rythme annoncé jadis par Gordon Moore. Quant aux débits des réseaux, selon la constatation faite par George Gilder, ils progressent environ trois fois plus vite que les processeurs. Avec un tel potentiel et une telle évolution, on pourrait penser que la technique serait en mesure de fournir bien plus que la puissance requise par les applications, à un coût très bas et sans cesse décroissant. Il ne serait donc plus raisonnable de perdre son temps (et donc de l argent) à optimiser les performances des applications. La solution économique consisterait à surdimensionner, pour un surcoût dérisoire, les ressources matérielles et réseaux. En contrepartie, les équipes de développement devraient se concentrer sur l architecture fonctionnelle, sur les approches favorisant la réutilisation des codes, la portabilité, la maintenabilité, la flexibilité. Malheureusement, la réalité vient assez souvent démentir ce modèle. Certaines applications enregistrent des temps de réponse décevants, ou voient ces temps de réponse se dégrader lourdement quand on essaie de monter en charge. On arrive ainsi, parfois, à ce paradoxe qu une application fort bien conçue sur le plan de l architecture fonctionnelle et de l architecture de services soit incapable de supporter une charge normale d exploitation, ou d atteindre le niveau de fiabilité requis par les métiers. Il y a, à cela, des raisons bien identifiées : les volumes de données et les besoins de recherche et d échange de ces données croissent au moins aussi vite que les capacités des outils mis en œuvre ; et l on commence à buter sur une première limite physique. En effet, si l on a réussi à contourner les contraintes imposées par plusieurs limites théoriques, comme par exemple la taille des transistors élémentaires (grâce à la multiplication des processeurs), on a aujourd hui beaucoup de peine à imaginer comment transporter un signal au-delà de la vitesse de la lumière... Certes, certaines applications ne rencontreront jamais de problèmes de performances, même en l absence de toute conception technique : compte tenu de la nature des ressources qu elles requièrent, elles ne consommeront jamais toute la puissance

4 VI Performance des architectures IT mise à leur disposition. Mais ce n est pas le cas de tous les types d application. Et les grandes applications critiques, largement réparties et accédant à de grandes masses de données, sont en général les plus sujettes aux problèmes de temps de réponse. La question des performances ne peut donc être évacuée de la conception technique des applications. Or, à condition de réfléchir à la réalité du fonctionnement technique, de s appuyer sur les bonnes pratiques et l expérience, et de concevoir des architectures techniques prenant en compte les contraintes d exploitation, il est tout à fait possible de maîtriser la question des performances. On trouvera ainsi, dans le présent ouvrage, un ensemble de recommandations et de bonnes pratiques permettant de traiter une part importante des problèmes de performances. En pratique, les équipes de développement peuvent prendre en compte la question des performances de deux façons différentes. Soit a posteriori, parce que les tests de charge ou de préproduction mettent en évidence un problème grave de performance sur une application quasi finalisée. Il faut alors, dans l urgence, essayer de masquer les problèmes les plus pénalisants. Les travaux effectués permettent souvent d améliorer les choses, mais pas de façon optimale, et en général au prix d une dégradation de la qualité technique de l application. Cela se paie souvent, par la suite, sous la forme d une dégradation de la fiabilité, d un surcoût des maintenances, d une réduction des capacités de réutilisation et d intégrabilité, et au total d une espérance de vie moindre. Soit, et c est l idéal, en concevant d emblée une application qui intègre les questions de performances. Cela suppose que les départements Études restent conscients du problème et disposent des compétences techniques capables d intervenir lors de la conception des applications. Cela suppose aussi que les méthodes de conduite de projets IT imposent une étape d évaluation des risques et contraintes techniques, débouchant si nécessaire sur une conception technique sérieuse. Dans cette perspective, il est important de permettre aux équipes des Études à la fois d intégrer les bonnes pratiques permettant d optimiser l architecture technique des applications, et de disposer d une bonne culture générale sur les infrastructures contribuant aux performances et à la fiabilité. C est à l atteinte de ce double objectif que le présent ouvrage se propose de contribuer. Jean-Marc Berlioux Senior Program Director Gartner France

5 Table des matières Préface Avant-propos V XVII Première partie La nécessité d un SI performant Chapitre 1 Problématiques de performance des SI Le système d information, vecteur de performance pour l entreprise Évolution des SI Les premiers calculateurs Les grands systèmes L apparition des bases de données Le SI à l heure de l e-business Les architectures de services Le Cloud, public ou privé Typologies des applications et criticité business DSI et gestion de la performance Les couches d architecture du SI La couche télécom La couche matérielle La couche logicielle Les architectures distribuées

6 VIII Performance des architectures IT Récapitulatif Chapitre 2 Les fondamentaux de la performance Le temps de réponse La capacité à monter en charge La disponibilité Définition générale Calcul de la disponibilité Le mythe des cinq neuf Disponibilité et business La robustesse Chapitre 3 L organisation de la performance Organisation des équipes de production Méthodologie de mise en œuvre de la performance Performance et maîtrise d ouvrage Performance et direction des études Performance et maîtrises d œuvre Performance et exploitation Maturité dans la performance Niveau 1 : le statut quo Niveau 2 : la mesure Niveau 3 : l optimisation des performances Niveau 4 : l optimisation du métier Niveau 5 : l optimisation des processus Chapitre 4 Contractualiser la performance La qualité des services Catalogue de services et orientation client L engagement autour des services Contenu d un SLA Mise en place d un SLA Gestion des incidents RTO

7 Table des matières IX RPO RTO et RPO Le plan de continuité Deuxième partie Performance et architecture d entreprise Chapitre 5 Les enjeux architecturaux de la performance Démarche proposée Construire une architecture Construire une architecture performante Étape 1 : modéliser l architecture du SI modernisé Les contraintes du SI Modèle d architecture logique Le risque majeur : le passage de frontière Étape 2 : choisir les patterns d architecture La redondance Mécanisme de chargement paresseux Simplicité Patterns SOA Étape 3 : détecter les anti-patterns de performance L exemple «Fil Rouge» Le syndrome de la cascade Le syndrome de la mitrailleuse à requêtes Le syndrome de la requête mammouth Le syndrome du goulet d étranglement Conclusion Chapitre 6 Performances des services d une SOA La performance d un web service : les points clefs Enjeux Éléments de solution La performance des services CRUD Enjeux Éléments de solution

8 X Performance des architectures IT 6.3 Une solution miracle? WS-* versus REST Enjeux Brève présentation de REST Analyse Conclusion La robustesse des services Enjeux de l intégrité des services Éléments de solution «intégrité» Chapitre 7 Robustesse et performance d un processus métier Rappel sur les processus métier Contenu du chapitre Robustesse d un processus métier Enjeux Solution n 1 : repartir de zéro Solution n 2 : isoler le processus Solution n 3 : processus avec préréservations Solution n 4 : prévoir des points de reprise du processus Conclusion sur la robustesse des processus Performance d un processus métier Enjeux Éléments de solution Conclusion : les architectures de déploiement Chapitre 8 Performance d une solution métier La performance d une solution Enjeux : le problème des listes longues Éléments de solution : gérer les listes longues en optimisant les requêtes à la base de données Éléments de solution : gérer les listes longues en utilisant un cache applicatif Élément de solution : accéder à des données stables Conclusion : la gestion de cache Robustesse d une solution Enjeux de la disponibilité d une solution

9 Table des matières XI Éléments de solution «disponibilité» Mise en œuvre d un plan batch Enjeux Éléments de solution Troisième partie Optimiser les infrastructures Chapitre 9 Les Datacenter Datacenter et performance Contraintes spécifiques Gestion de la disponibilité Les différents types de Datacenter Classification Impacts La gestion des risques Risques intrinsèques Risques extrinsèques Datacenter et PCA Classification des sites de repli Types de bascule Chapitre 10 Les réseaux Fondamentaux Une évolution continue Les propriétés des réseaux Les réseaux et la performance Idée fausse n 1 : la latence est nulle Idée fausse n 2 : la bande passante est illimitée Idée fausse n 3 : le réseau est fiable Idée fausse n 4 : le réseau est sécurisé Idée fausse n 5 : la topologie du réseau ne change pas Idée fausse n 6 : il n y a qu un seul administrateur Idée fausse n 7 : les coûts de transport sont nuls Idée fausse n 8 : le réseau est homogène

10 XII Performance des architectures IT Synthèse des recommandations Techniques de disponibilité avec les réseaux VIP et Health Check Bascule DNS Redondance de routeur virtuel Chapitre 11 Le stockage Disques durs et interfaces d accès Le standard S-ATA Le standard SCSI Le standard FC Conclusion sur les interfaces d accès Les systèmes RAID Les modes simples Les modes composites Conclusion sur les modes RAID Les stratégies d accès aux données Le Direct Access Storage (DAS) Le Storage Area Network (SAN) Le Network Access Storage (NAS) Conclusion sur les modes d accès Chapitre 12 Le clustering Qu est-ce que le clustering? Les différentes formes de clustering Les clusters actif/passif Les clusters de type actif/actif Conclusions sur les formes de clustering La répartition de charge Répartition de charge statique Répartition de charge dynamique Algorithmes de répartition Synthèse et conclusion sur la répartition de charge La tolérance aux pannes

11 Table des matières XIII 12.5 Les différentes formes de scalabilité La scalabilité verticale La scalabilité horizontale La scalabilité diagonale Conclusions sur les types de scalabilité Chapitre 13 Les bases de données Levier 1 : la qualité des requêtes Levier 2 : l utilisation des procédures stockées Levier 3 : le choix du bon niveau d isolation transactionnelle La lecture sale La lecture non répétable La lecture fantôme Les modes d isolation Levier 4 : l optimisation du stockage et des entrées-sorties L optimisation du rangement des données Supprimer des E/S Levier 5 : changement de paradigme Principes Avantages Inconvénients Quelques outils Chapitre 14 Les serveurs d application Les leviers de la performance Levier 1 : la durée de traitements Levier 2 : la gestion de la mémoire Levier 3 : le paramétrage des applications Le session failover Étude d un cluster sans session failover Étude d un cluster avec session failover

12 XIV Performance des architectures IT Quatrième partie Les bonnes pratiques Chapitre 15 Les tests de performance Qu est-ce qu un test de performance? Les différentes approches Vocabulaire des tests de performance Les types de tests de performance Méthodologie Phase 1 : la définition des objectifs Phase 2 : l étude de l application Phase 3 : la capture Phase 4 : le développement Phase 5 : la préparation et la conduite des tirs Phase 6 : l analyse Quelques outils Le tuning Le profiling Enseignements Quelques précautions à prendre Quelques outils de profiling Chapitre 16 La gestion de la production La démarche Le monitoring et la supervision La méthodologie Type 1 : le monitoring de disponibilité Type 2 : le monitoring des temps de réponse Type 3 : le monitoring des activités techniques Type 4 : le monitoring des activités métier Type 5 : le monitoring de l expérience utilisateur Les types de sondes Synthèse Le capacity planning

13 Table des matières XV Chapitre 17 La gestion de projet Cycle de vie d un projet de développement informatique Constats sur la négligence des problématiques de performance Actions de tuning et upgrade Optimisations Refactoring Réécriture Bilan Intégrer la performance dans la démarche projet Expression de besoins et performance Analyse et conception Développement et performance Intégration et performance Performance et production Bibliographie Index

14

15 Avant propos Software gets slower faster than hardware gets faster. (La performance des logiciels croit moins vite que celle du matériel.) Nicklaus Wirth De quelle performance parlons nous? Selon les dictionnaires généralistes, la définition du mot performance porte sur le résultat chiffré obtenu lors d une compétition. Il s agit donc, au sens premier du terme, d une affaire de concurrence qui évoque le positionnement des entreprises dans l économie mondialisée. Chacun sait aujourd hui que la mondialisation des échanges a rendu la concurrence plus âpre entre les entreprises de tous types. Pour rester compétitives, ces dernières doivent ainsi être capables de livrer de nouveaux produits de plus en plus vite, en réduisant au maximum les coûts de production. Le système d information est impacté par cette accélération ; dans le cadre de processus de plus en plus informatisés, il est au cœur de ces nouvelles exigences de productivité. Les métiers lui demandent d être extrêmement réactif, pour les aider à mettre sur le marché de nouvelles offres. On parle pour cela d agilité : ce terme désigne la capacité du SI à supporter des évolutions rapides. Ainsi, la performance des entreprises porte sur leur capacité à : Proposer des produits ou services innovants : on parle ici de la capacité d anticipation, du côté «visionnaire» des dirigeants de l entreprise. Optimiser leurs processus afin de réduire leurs coûts : c est-à-dire adopter une organisation optimale dans le travail des collaborateurs. Sous-traiter au maximum les tâches à faible valeur ajoutée : l entreprise privilégiera la sous-traitance pour tout ce qui ne constitue pas son cœur de métier ; de plus, elle reportera les tâches de saisie de données sur ses partenaires et clients (par exemple, dans le cadre de la banque en ligne, les clients passeront eux-mêmes leurs ordres de virement).

16 XVIII Performance des architectures IT Disposer d un système d information agile et fiable : de par la cohérence et la capacité de montée en charge de son architecture, le SI devra être un facilitateur de la performance de l entreprise. De nombreux ouvrages abordent ces différents aspects de la performance, en axant leur propos sur la gouvernance du système d information 1. Mais, peu l abordent sous son angle technologique. Nous souhaitons combler cette lacune en répondant à la problématique suivante : comment faire en sorte que le SI soit un facteur de performance de l entreprise, au travers d une architecture bien pensée, d une infrastructure fiable et d une organisation adaptée des équipes de production? L objectif de cet ouvrage n est pas de donner une vision définitive sur des sujets en perpétuelle évolution, mais de fournir des outils pour aborder méthodiquement les questions techniques délicates que soulève la performance de nos systèmes d informations. À qui s adresse ce livre? Cet ouvrage s adresse à tous ceux qui sont concernés de près ou de loin par la performance des applications et du SI : Directeurs informatiques. Responsables des études. Architectes. Chef de projets. Responsables de la production. Consultants. Première partie : les problématiques de performance des SI La première partie de cet ouvrage a pour objectif d introduire les problématiques de performance auxquelles sont confrontés aujourd hui le système d information et les équipes de la DSI. Elle commence par présenter le SI sous un angle historique et technique pour dégager les éléments critiques en termes de performance. Elle aborde ensuite les concepts fondamentaux de la performance que sont les temps de réponse, la capacité à monter en charge, la disponibilité, la robustesse. Enfin, elle présente les bonnes pratiques d organisation de la DSI vis-à-vis de la performance. Cette partie introductive est accessible à tous les profils. Seconde partie : définir l architecture d entreprise L objectif de cette partie est de présenter les enjeux architecturaux de la performance et de la robustesse des applications du système d information (SI). Elle traite essentiellement des problématiques liées aux communications entre les différents composants. Cette partie s adresse plus particulièrement aux architectes de solutions applicatives, issus du département des études. 1. Voir notamment Performance du système d information, Yves Caseau, Dunod, 2007.

17 Avant propos XIX Troisième partie : optimiser les infrastructures La troisième partie aborde la question de l infrastructure, véritable socle sur lequel fonctionnent les applications. Qu elle soit matérielle avec les réseaux et le stockage ou bien logicielle avec les bases de données et les serveurs d application, l infrastructure joue un rôle clé dans le niveau de performance des applications. Ces sujets sont traités ici sous l angle des performances et sous-celui des coûts. Cette partie aborde aussi la question du clustering au travers d un chapitre qui lui est dédié. Cette partie intéressera les architectes de solutions applicatives et les architectes de production. Quatrième partie : les bonnes pratiques Cette dernière partie a pour ambition de fournir au lecteur des recettes pratiques immédiatement utilisables sur les projets. Elles sont regroupées par thèmes avec les techniques de programmation, les tests de performance, la gestion de la production et les pratiques de gestion de projet. Cette partie décrit le cycle de vie d un projet. Elle concerne aussi bien les profils des études (architectes, chefs de projets) que ceux de l exploitation (architectes et techniciens de production). Remerciements Les auteurs tiennent tout d abord à remercier leurs épouses pour leur patience et leur soutien pendant les périodes de rédaction de cet ouvrage. Leur reconnaissance va aussi à Yahya El Mir et Julien Mériaudeau, respectivement Président et Directeur Général du groupe SQLI qui ont sponsorisé ce projet. Ils remercient également leur collègue Pirmin Lemberger qui a bien voulu relire l ouvrage et aider à le compléter par ses retours d expérience.

18

19 PREMIÈRE PARTIE La nécessité d un SI performant Le cabinet d étude Gartner a publié une étude qui révèle qu au cours des dernières années : 40 % des entreprises ne vérifiaient pas la disponibilité de leurs applications ; 64 % ne mesuraient pas les temps de réponse de leurs applications. Ces chiffres mettent en évidence que la performance est trop souvent négligée dans les pratiques des DSI. Il ressort aussi de cette étude que, contrairement aux idées reçues, les plantages imprévus sont majoritairement liés à des erreurs applicatives (40 %), et à des erreurs humaines (40 %) plutôt qu à des pannes matérielles (20 %). Ceci souligne l importance de la conception de l architecture du SI (cf. deuxième partie) et de l organisation de la performance (cf. quatrième partie). Néanmoins, avec l importance croissante qu occupe l informatique dans les entreprises, il apparaît que pour 70 % d entre elles les temps de pannes imprévues pour leurs applications critiques, sont inférieurs à 43 heures/an. La première partie de cet ouvrage a pour objectif d introduire les problématiques de performance auxquelles sont confrontés aujourd hui le système d information et les équipes de la DSI.

20 2 La nécessité d un SI performant Elle commence par présenter le SI sous un angle historique et technique pour dégager les éléments critiques en termes de performance. Elle aborde ensuite les concepts fondamentaux de la performance que sont les temps de réponse, la capacité à monter en charge, la disponibilité, la robustesse. Enfin, elle présente les bonnes pratiques d organisation de la DSI vis-à-vis de la performance.

21 1 Problématiques de performance des SI Objectif L objectif de ce chapitre est d introduire les problématiques de performance auxquelles est confronté le système d information. Il commence par faire un bref historique de l évolution des systèmes d information afin de montrer comment la performance est devenue un élément critique pour les entreprises. Puis, il passe en revue les problématiques de performance dans les différentes couches techniques du système d information (télécom, matérielle, logicielle, architectures SOA 1 ). 1.1 LE SYSTÈME D INFORMATION, VECTEUR DE PERFORMANCE POUR L ENTREPRISE L accroissement de la compétition entre les entreprises liée à la mondialisation s accompagne d une montée en puissance de l informatisation des processus. Cette montée en puissance est provoquée par le besoin d accélérer les traitements et les échanges ; la dématérialisation permet en effet des gains de temps substantiels : 1. SOA : Service Oriented Architecture.

22 4 Chapitre 1. Problématiques de performance des SI Transmission des informations à la vitesse de la lumière (par exemple, les échanges entre entreprises). Accélération des tâches humaines grâce à l assistance informatique (par exemple, des formulaires de demande de congés). Suppression de tâches récurrentes déportées sur des traitements automatiques (par exemple, la génération de tableaux de bords analytiques). De fait, l outil informatique est aujourd hui devenu indispensable dans tous les secteurs d activité (banque, services, transports, etc.). Il est devenu omniprésent à tel point qu on parle parfois d «informatique pervasive». Cette omniprésence rend la dépendance des entreprises à leur système d information de plus en plus critique. Ce dernier devient le garant : de la bonne conservation des référentiels de données, qui constituent le cœur des entreprises (par exemple, les contrats d une assurance, les spécifications sur des produits commercialisés) ; de la bonne exécution des traitements qui permettent à l entreprise de générer de la valeur (par exemple, un site de commerce électronique). Dès lors, le bon fonctionnement du SI devient stratégique, et un arrêt de ses services peut avoir de graves répercussions. Il va donc falloir disposer de solutions pour garantir la constance de l approvisionnement en «énergie informatique» au même titre qu en énergie électrique. De plus, il faudra que cette énergie informatique soit adaptable et supporte des fluctuations dans son usage : de même que l EDF doit savoir faire face aux jours de grand froid, le SI de la direction générale des impôts doit pouvoir supporter un pic d affluence dans la télé-déclaration pendant les jours qui précédent la date limite de déclaration. Enfin, les gestionnaires du SI doivent pouvoir suivre ses métriques de fonctionnement, de la même manière que les contrôleurs aériens suivent en temps réel les décollages et atterrissages des avions dans leur aéroport. Ces différentes notions permettent de faire émerger un cahier des charges du SI performant (figure 1.1). Ce dernier devra assurer : Une continuité de service, qui se traduira par un niveau de robustesse et de disponibilité constant dans le temps (cf. section 7.4). Des temps de réponses, c est-à-dire des temps d attente admissibles par les utilisateurs (cf. section 7.1). Une capacité à s adapter aux variations de charge induites par les utilisateurs, qui se traduira par des temps de réponse acceptables et une capacité à monter en charge. L anticipation des évolutions de la demande. On parle pour cela de capacity planning. La mise à disposition d un outillage de suivi de la performance. Cet outillage offrira des interfaces techniques qui permettront aux équipes de production

23 1.2 Évolution des SI 5 d assurer la supervision des applications ; il proposera aussi des interfaces destinées aux utilisateurs métiers, permettant de suivre les transactions d un point de vue fonctionnel (par exemple, nombre de commandes passées, de produits livrés). Cette seconde catégorie d outils de suivi est souvent appelée BAM, pour Business Activity Monitoring (cf. chapitre 16). Utilisateurs futurs Attente : capacity planning Administrateur production Attente : monitoring & supervision Attente : BAM Système d Information mainframe Suivi métiers Utilisateurs exceptionnels Utilisateur régulier Attente : capacité à monter en charge Attentes : robustesse, disponibilité, temps de réponse Progiciel Application web Référentiels Figure 1.1 Les attentes vis à vis du SI en termes de performance Les termes en gras ci-dessus seront définis plus en détail dans les chapitres suivants. 1.2 ÉVOLUTION DES SI Les premiers calculateurs Les premiers équipements informatiques, dans les années 1960 et 1970, étaient destinés à des centres de calculs. Ils étaient utilisés essentiellement pour réaliser des traitements par batch, pour lesquels on n attendait pas un résultat immédiat. Il ne s agissait donc pas d un usage synchrone. De plus, les utilisateurs étaient des opérateurs et non les utilisateurs finaux. Ces derniers attendaient un rapport des traitements effectués sous forme papier et n étaient en aucun cas intéressés par un suivi des activités traitées sous forme informatique.

24 6 Chapitre 1. Problématiques de performance des SI Par conséquent, la disponibilité de ces machines était peu critique, puisqu elles travaillaient indépendamment des utilisateurs finaux, souvent de nuit. La capacité à monter en charge face à un nombre croissant d utilisateurs n était pas non plus critique, la population d accédants étant restreinte à quelques opérateurs. On attendait donc de ces machines essentiellement une robustesse suffisante pour ne pas perdre d information et mener à bien les traitements. Des plantages intempestifs pouvaient être admis. Néanmoins, ils devaient être réduits au maximum car les calculateurs étaient rares et lents ; ainsi, les allocations de temps de calcul pouvaient revenir cher. Les opérateurs de ces calculateurs disposaient à l époque de peu d outils de suivi de la performance de leurs machines Les grands systèmes Avec les grands systèmes, le transactionnel (CICS, etc.) a ensuite progressivement fait son apparition «pendant la journée» : l architecture des applications interactives étant simple, la performance et la robustesse étaient essentiellement liées à la capacité du matériel, c est-à-dire à la capacité de l ordinateur central (le fameux mainframe) à offrir une robustesse de plus en plus grande. La performance était pour sa part liée essentiellement aux canaux de lecture-écriture sur les disques durs L apparition des bases de données À la fin des années 1980, les bases de données relationnelles ont commencé à se répandre dans les entreprises. Dès lors, l informatique a cessé d être seulement un avantage compétitif pour devenir un composant indispensable de l entreprise. Certaines données métier critiques ont quitté l ordinateur central pour s installer sur des ordinateurs départementaux ; la souplesse du SI s obtenant aux dépens de sa simplicité (apparition des silos d information). Le rôle critique assumé par les bases de données les a fait rapidement évoluer et s équiper d un outillage pour : garantir l intégrité des données (avec les systèmes transactionnels (commit/roll back), les systèmes de sauvegarde et réplication) ; disposer d une capacité à monter en charge en préservant leur disponibilité (avec les pools de connexion) ; optimiser les performances (avec les outils d optimisation de requêtes) ; suivre leur activité (avec les logs et les systèmes de monitoring). Au début des années 1990, les applications client/serveur sont apparues et ont mis le contenu de ces bases de données à la disposition des utilisateurs métiers via des interfaces graphiques évoluées. Dès lors, l accès à l informatique a cessé d être réservé aux informaticiens et la problématique de performance est devenue stratégique dans les entreprises. Ces dernières ont alors constitué des directions du système d information disposant d équipes de production dédiées au maintien en condition opérationnelle des systèmes.

25 1.2 Évolution des SI Le SI à l heure de l e business Comme on l a vu dans la section précédente, l informatique est devenue aujourd hui omniprésente dans tous les secteurs d activité. Un poste informatique est établi sur le bureau de chaque collaborateur en entreprise. De plus, avec l avènement de l ebusiness, les entreprises mettent aussi des interfaces à la disposition de leurs partenaires et clients. Le système d information est ainsi devenu hautement stratégique. Certaines entreprises de nouvelle génération comme Amazon, Google ou SalesForce sont même devenues incapables de poursuivre leur activité en cas de panne informatique. Nous verrons plus loin que ces acteurs disposent des systèmes d information parmi les plus avancés en termes de gestion de la performance Les architectures de services Les architectures orientées service ou SOA (Service Oriented Architecture) sont extrêmement prometteuses en termes d agilité pour les SI. L approche SOA consiste à demander aux applications de faire un effort de capacité d intégration afin de présenter leurs fonctionnalités sous une forme utilisable par d autre. Cette interface est appelée un «service». Le bénéfice de cette approche est la capacité de créer facilement d autres applications, appelées applications composites, par combinaisons de services existants, un peu comme un assemblage de «Lego». Cette combinaison pourra impliquer des services internes à l entreprise et des services mis à disposition par des partenaires (figure 1.2). Système information service note de frais service réservatio avion application dépla ement pro essionnel service réservation auto service réservatio hôtel Utilisateur se vice validation par hiérarchie Figure 1.2 Exemple de composition de services internes et externes Le principe est très séduisant lorsqu on imagine les opportunités qu il peut offrir, cependant il pose un certain nombre de problématiques liées aux architectures distribuées (sécurité, garantie d acheminement, intégrité transactionnelle, etc.). Parmi ces problématiques, la performance est particulièrement critique. En effet, si l un des

26 8 Chapitre 1. Problématiques de performance des SI services invoqués par l application composite souffre d un problème de montée en charge, il risque d impacter l ensemble de l architecture distribuée. Pour se prémunir contre ce risque, on choisit généralement de mettre en place des contrats de service engageant les sociétés qui exposent des services. Ainsi, on raisonne de la même manière que dans le cadre d une offre de service dans le monde physique (banque, cinéma, restaurant, etc.), en garantissant au client un niveau de prestation acceptable. Ce contrat de service décrira en particulier le niveau de disponibilité que peuvent atteindre les applications composites. Dans le cadre d architectures distribuées, faisant intervenir divers acteurs internes ou externes à l entreprise, il est particulièrement crucial de disposer d outils de suivi pour déterminer : à quel endroit se situe un dysfonctionnement (information technique) ; si les commandes ou transactions commerciales ont été menées à bien au sein de la chaîne de partenaires (information métier). SOA propose donc un cadre dans lequel la maîtrise de la performance est particulièrement critique. On y reviendra plus particulièrement dans la deuxième partie Le Cloud, public ou privé La terminologie Cloud Computing recouvre de nouvelles architectures dont la caractéristique principale est l élasticité. On entend par élasticité, la capacité à adapter les ressources informatiques selon la demande des utilisateurs. L exemple de la société Amazon, à l origine du concept de Cloud Computing, permet de bien comprendre cette notion d élasticité : Amazon dispose d une grande quantité de serveurs capables d absorber des pics de charge utilisateur, comme une explosion des ventes de livres peu avant Noël. Lorsque la demande sur son site de commerce électronique est moins forte, Amazon peut réaffecter ses ressources à d autres traitements, par exemple en les louant à des entreprises tierces. La propriété d élasticité repose sur les technologies de virtualisation 1, qui permettent de décorréler les ressources disponibles des machines physiques sous-jacentes. Ainsi, il est possible de réaffecter la puissance machine d une application vers une autre de manière simple et dynamique. La virtualisation est mise en œuvre dans les deux types de Cloud : public et privé. Les Clouds publics sont des infrastructures mises à disposition des entreprises par des grands acteurs du Web (Amazon, Google, Microsoft, etc.). La puissance machine est vendue sous forme de service : on paie à la consommation. Et les utilisateurs peuvent faire des demandes de ressources au travers d une interface Web : ces ressources sont mises à disposition en quelques minutes. 1. Les principales offres de Virtualisation sont les outils de VMware, Microsoft et l alternative Open Source Xen.

27 1.3 Typologies des applications et criticité business 9 Les Clouds privés reprennent les mêmes principes, mais sont gérés par l entreprise utilisatrice. Il s agit donc d offres de services internes. Il faut noter que plus le nombre de serveurs d une plateforme est important, plus elle dispose d une réserve de puissance à même de garantir l élasticité. Ainsi, parler de Cloud pour une plateforme de 20 machines ne fait pas sens. Le Cloud, public ou privé, introduit de nouveaux paradigmes de gestion de la performance. Si on opte pour le Cloud public, la problématique est largement déléguée à l opérateur de la plateforme, ce d autant plus que ces opérateurs proposent souvent des briques logicielles clefs en main (comme par exemple les bases de données Amazon SimpleDB, Google Datastore, Microsoft Azure SQL), dont ils maîtrisent la performance. De plus, les opérateurs de Cloud public ont inventé de nouvelles architectures, qui proposent des stratégies novatrices de gestion de la performance. On parle en particulier d architectures faiblement consistantes, de bases NoSQL, d algorithmes de calculs distribués Avec un Cloud privé, la problématique de performance est largement déléguée à l équipe d exploitation de la plateforme Cloud, qui doit donc développer de fortes compétences concernant la virtualisation et les clusters de base de données en particulier. 1.3 TYPOLOGIES DES APPLICATIONS ET CRITICITÉ BUSINESS On distingue généralement deux grandes familles d applications au sein d un système d information : Les applications métiers : elles correspondent au cœur d activité de l entreprise et sont indispensables à son fonctionnement quotidien. Elles jouent un rôle important dans le savoir-faire et la compétitivité de l entreprise. Du fait de leur criticité, ces applications sont souvent gérées et hébergées au sein de la DSI. Elles peuvent être bâties, selon les secteurs d activité, sur des développements spécifiques (par exemple, dans les secteurs de la banque et de l assurance) ou sur l intégration de progiciels (par exemple, chez les opérateurs télécoms). Les applications support (ou informatique de commodité) : il s agit là d une catégorie d applications utiles pour toutes les typologies d entreprises dans tous les secteurs d activité : on peut citer par exemple les progiciels de gestion intégrés, les applications de gestion des ressources humaines, les applications collaboratives comme la messagerie électronique, etc. Ces applications sont généralement issues de l intégration de progiciels du marché. Elles peuvent être déployées au sein du SI d entreprise ou externalisées chez des opérateurs SaaS (Software as a Service), comme Sales Force pour le CRM, ou Google pour la messagerie, etc. De par leur criticité, les applications métiers sont très exigeantes en termes de performance et de robustesse. En effet, une rupture de service peut avoir des

28 10 Chapitre 1. Problématiques de performance des SI conséquences directes et graves sur l activité de l entreprise. On peut citer l exemple extrême d un site de commerce électronique comme Amazon : une rupture de service mettrait fin aux bénéfices et même à l activité de son entreprise. Par ailleurs, une congestion liée à une mauvaise prise en compte de la montée en charge peut se révéler très néfaste en termes de qualité de service client et d image de marque de l entreprise. L informatique de commodité connaît une criticité plus variable. Certaines applications de support, comme la messagerie électronique, sont devenues fondamentales dans les entreprises au même titre que le téléphone ou l électricité. Ainsi, la messagerie est souvent l application la plus utilisée et donc l une des plus critiques du SI. A contrario, d autres applications de commodité, comme les demandes de congés, les commandes de matériel de bureau, etc. sont beaucoup moins exigeantes en termes de performance. Enfin, les pratiques et usages d une entreprise donnée peuvent avoir une influence sur la criticité d une application de support : par exemple, les calendriers partagés ou la messagerie instantanée sont utilisés de manière très variable selon les entreprises, et leur criticité est par conséquent relative. On peut ainsi introduire un barème sur la criticité des applications, selon la gravité de leur indisponibilité : Application vitale : généralement une application métier (exemples : application de vente centrale dans le modèle économique de l entreprise, application de routage des appels pour un opérateur télécom). Application critique : une application métier ou une commodité fondamentale exemples : application de banque en ligne, messagerie d entreprise. Application sensible : une application métier ou une commodité largement utilisée (exemples : un outil BackOffice en banque ou assurance, la GED de l entreprise, le site web de présentation de l entreprise). Application satellite : généralement une commodité (exemples : outil de demande de congé, statistique de fréquentation du site web). Le temps de rétablissement qui suit une panne applicative est très important : il peut avoir une influence sur la gravité de la panne. En effet, perdre un site de commerce électronique pendant trois minutes n a pas le même impact qu une panne de deux jours. On parle ainsi de RTO (Recovery Time Objective) pour qualifier le temps de rétablissement acceptable pour l activité de l entreprise. Le RTO est donc un élément structurant de l évaluation de la gravité d une panne. 1.4 DSI ET GESTION DE LA PERFORMANCE La plupart des entreprises actuelles disposent d une DSI chargée de la gestion de leur informatique. Les DSI sont généralement organisées en deux pôles principaux (figure 1.3) : La direction des études, chargée de la conception et de la construction des systèmes informatiques (en anglais le build). Elle a la responsabilité de concevoir des applications performantes : elle doit pour cela appliquer des bonnes pratiques

29 1.4 DSI et gestion de la performance 11 ou patterns d architecture. Ces pratiques seront décrites dans la deuxième partie de cet ouvrage. La direction de la production, chargée de l exploitation des systèmes (en anglais le run). Elle a la responsabilité de la surveillance de la performance des systèmes : elle doit pour cela déployer un outillage pour surveiller les infrastructures et gérer les montées en charge. Cet outillage sera décrit dans la troisième partie de cet ouvrage. L organisation des équipes de production suit généralement les recommandations du référentiel ITIL 1. Les tâches de ces équipes sont : Gestion des Demandes de Service : gestion de l ensemble des demandes de service établies par un demandeur pour un bénéficiaire souhaitant disposer d un service donné. Gestion des Niveaux de Service : maintien et amélioration de la qualité du Service IT via un cycle constant d accords internes, de contrats externes, de surveillance et de tableaux de bord portant sur le respect des niveaux de service. Gestion des incidents : rétablir le fonctionnement normal du service aussi vite que possible en minimisant la durée d interruption de service pour l entreprise, assurant ainsi les meilleurs niveaux de disponibilité et de services possibles. Gestion des problèmes : chercher à connaître les causes premières d un ou plusieurs incidents et ainsi coordonner les premières actions à réaliser pour améliorer et corriger la situation. Gestion des configurations : fournir un modèle logique de l infrastructure lié aux technologies de l information en identifiant, contrôlant, maintenant à jour et en vérifiant les versions de tous les éléments de configuration existants. Gestion des changements : contrôle des changements dans l infrastructure ou de n importe quel aspect des services, permettant des changements approuvés n entraînant qu un minimum de coupure. Gestion des mises en production : avoir une vue globale d un changement apporté à un service et s assurer que tous les aspects d une MEP 2 matérielle ou logicielle, aussi bien techniques que non techniques sont pris en considération. Ces tâches sont dispatchées auprès des équipes de production en transitant par un guichet unique : le «service desk». Par ailleurs, les DSI intègrent généralement des services transverses : gestion de la qualité, pôle architecture/urbanisation, responsables de la sécurité. Ces services sont prescripteurs de bonnes pratiques dans leur domaine d intervention, qui peuvent avoir un impact positif sur la performance du SI. Par exemple, des règles d archivage issues de la direction de la sécurité ou bien de bonnes pratiques de développement issues du département qualité peuvent avoir un effet bénéfique sur la performance. 1. ITIL : Information Technology Infrastructure Library. 2. Mise En Production.

30 12 Chapitre 1. Problématiques de performance des SI DSI : pôles transverses Direction qualité Recommandations bénéfiques pour la performance Cabinet urbanisme Direction sécurité Responsables assurance qualité Urbanistes, architectes de SI Équipes Sécurité DSI : direction des études DSI : direction de la production Maîtrise d œuvre Architectes logiciels, chefs de projets, développeurs Exploitation Applications Architectes de production, support technique, gestionnaires du changement, help desk Construction d architectures performantes Surveillance de la performance Figure 1.3 Organisation classique d une DSI 1.5 LES COUCHES D ARCHITECTURE DU SI Le système d information actuel est constitué de différents composants ou couches, dont l impact sur la performance est plus ou moins critique. Nous allons les passer en revue dans cette section. Nous dresserons ici un état de l art basé sur les technologies actuelles (architectures basées sur le modèle objet et des technologies web) La couche télécom La couche télécom est constituée par les éléments d infrastructure réseau du SI. On y trouve essentiellement : des équipements de routage télécom (hub, switch, routeurs, répartiteurs de charge, IPBX, etc.) ;

31 1.5 Les couches d architecture du SI 13 des équipements de sécurité (firewall, proxy, reverse proxy, passerelles IPSEC ou SSL, sondes IDS, etc. 1 ). Ces éléments sont généralement conçus sous la forme d appliance, c est-à-dire qu ils embarquent des composants «câblés en dur», plus intégrés que ceux d un PC ou d un serveur. Ils fonctionnent sans avoir recours à un système d exploitation généraliste. Certains d entre eux embarquent toutefois une couche logicielle, généralement sous la forme d informatique embarquée ou firmware. Cette couche logicielle est monolithique, elle ne fait pas appel à un empilement de logiciels. Les éléments de la couche télécom ont souvent une durée de vie plus longue que celle des PC et serveurs. Ils sont aussi plus robustes, plus aptes à traiter des flux d informations importants. La couche télécom est donc à même d offrir une bonne robustesse et une bonne capacité à monter en charge : c est la partie du SI la moins sensible en termes de performance. Cependant, les performances de cette couche peuvent entrer en jeu lorsqu on doit parcourir des réseaux de grande distance. Ces aspects seront détaillés dans le chapitre La couche matérielle La couche matérielle du SI désigne les PC et serveurs hébergeant l exécution des applications. Ces machines reposent sur un assemblage normalisé de composants matériels (processeurs, mémoire vive, disques durs, interfaces réseaux, etc.). Elles ne peuvent apporter le moindre service sans l installation d une couche logicielle fondamentale et indispensable : le système d exploitation. La plupart de ces machines sont relativement sensibles. Elles sont sujettes à des pannes de disque, des saturations mémoire ou processeur, des plantages système, etc. Seules les solutions haut de gamme et onéreuses, comme les mainframes ou les AS400, offrent un haut niveau de fiabilité. La plupart des entreprises se tournent aujourd hui vers des machines peu onéreuses en architecture x86 2, dont la fiabilité est moindre. Elles impactent donc fortement la performance du SI. La solution la plus couramment utilisée pour gérer ce manque de fiabilité est la redondance au travers du principe de «cluster» : on considère simplement qu en multipliant le nombre de machines effectuant les mêmes tâches, on réduit la probabilité d indisponibilité de l ensemble du système. Ces aspects seront détaillés dans la troisième partie. Les centres serveurs de Google constituent un bon exemple de cette tendance à la redondance : ils sont basés sur des composants matériels bon marché avec une réplication à grande échelle. Google est réputé posséder plus de serveurs! 1. Pour en savoir plus sur ces équipements voir Sécurité des architectures web, Guillaume Plouin, Julien Soyer, Marc-Éric Trioullier, Dunod, Fonctionnant avec des processeurs Intel ou AMD et supportant les systèmes d exploitation Windows, Linux et Mac OS.

32 14 Chapitre 1. Problématiques de performance des SI La couche logicielle La couche logicielle est la partie immatérielle du SI. Elle est constituée d un empilement applicatif dont la complexité va croissant depuis quelques années. Cet empilement est lié à la montée en puissance du développement objet basé sur des machines virtuelles (Java et.net, par exemple) offrant des services avancés de gestion de la mémoire. Ces développements objets sont généralement hébergés sur des serveurs d application qui offrent de précieux services (gestion des sessions utilisateurs, des sources de données, de la haute disponibilité) mais ajoutent un étage à la pile logicielle. Ainsi, on fait face, dans une application JEE classique, à une pile constituée : d un système d exploitation ; d une machine virtuelle ; d un serveur d application ; de frameworks applicatifs ; d une application à exécuter. La performance de la couche logicielle est aujourd hui la plus difficile à maîtriser, en raison : de l empilement décrit ci-dessus ; du cycle de vie rapide et donc du manque de stabilité des couches constituant le socle logiciel (système d exploitation, machine virtuelle, et serveur d application) ; des risques de plantage liés à la mauvaise optimisation de la mémoire par les développeurs (ce point est aujourd hui moins critique du fait de la prise en charge de la gestion de la mémoire par les machines virtuelles) ; de la complexité de leur paramétrage, pas toujours maîtrisée par les équipes de production. Compte tenu du nombre de couches dont elle est constituée, l architecture logicielle est souvent imprévisible en termes de fiabilité. Ainsi, les architectes peu familiarisés avec la performance ne savent généralement pas dimensionner les machines répondant aux besoins de leurs utilisateurs et contournent le problème en recommandant les machines les plus puissantes du marché. L objectif de cet ouvrage est de leur offrir des métriques et une méthodologie pour mieux maîtriser ces dimensionnements (voir troisième partie pour l infrastructure et quatrième partie pour le développement logiciel) Les architectures distribuées Les systèmes d information modernes sont de moins en moins composés d applications isolées : avec la montée en puissance des architectures SOA, les applications communiquent entre elles. Ces communications sont essentiellement gérées : au travers de batchs : programmés la nuit, ils permettent des traitements et échanges de données ;

33 1.5 Les couches d architecture du SI 15 de manière asynchrone : dans ce cas, des files de messages permettent de collecter des demandes de traitement et de les traiter en différé en fonction des ressources disponibles ; de manière synchrone : dans ce cas, les échanges s effectuent en temps réel, et les utilisateurs doivent attendre la fin des échanges pour pouvoir continuer à travailler. L impact des traitements par batch est relativement léger en termes de performance du SI, dès lors que leur volumétrie est maîtrisée. En revanche, les traitements asynchrones et synchrones peuvent créer des goulets d étranglement extrêmement visibles des utilisateurs. Les traitements asynchrones nécessitent un gestionnaire de files d attente (MOM Message Oriented Middleware 1, EAI Enterprise Application Integration 2, ESB 3 ) qui doit être parfaitement dimensionné pour ne pas perdre de message, ni freiner les traitements. Les traitements synchrones sont très critiques en termes de performance, car ils ont un impact direct sur les utilisateurs de l application. De plus, dans le cadre d une invocation à distance, par exemple l appel à un web service partenaire, la latence réseau peut avoir un impact non négligeable. La deuxième partie analyse la problématique de performance et de robustesse de telles applications, et propose des éléments de solution Récapitulatif La figure 1.4 présente les différentes couches du SI. Ce paragraphe évoque des performances mitigées au niveau des couches logicielles et architecture distribuées dans le cadre des technologies web. Ces technologies apportent cependant une flexibilité indispensable pour assurer l agilité du système d information décrite précédemment. L enjeu des SI actuels est donc de concilier cette flexibilité avec la fiabilité et la qualité de service que proposaient les mainframes. La suite de cet ouvrage proposera des pratiques permettant d atteindre cet objectif. Ces pratiques porteront sur l architecture logicielle, l infrastructure matérielle et le développement logiciel. 1. MOM : Message Oriented Middleware. 2. EAI : Enterprise Application Integration. 3. ESB : Enterprise Software Bus.

34 16 Chapitre 1. Problématiques de performance des SI Appel asynchrone middleware Couche applicative Couche matérielle application frameworks serveur application machine virtuelle système d exploitation socle logiciel Appel synchrone Appel asynchrone Service Couche matérielle Couche matérielle Couche réseau Figure 1.4 Les différentes couches d architecture techniques du SI En résumé Ce chapitre a montré comment la performance du système d information est aujourd hui devenue un élément stratégique pour les entreprises. Il a aussi abordé la difficulté qu il y a à maîtriser la performance des architectures actuelles, de par leur complexité liée à un empilement de couches techniques.

35 2 Les fondamentaux de la performance Objectif L objectif de ce chapitre est de définir précisément les notions fondamentales de la performance des systèmes d information. Il présente les quatre piliers sur lesquels repose la performance, c est-à-dire les qualités que doivent posséder les applications, à savoir : les temps de réponse (response time) ; la disponibilité (availability) ; la robustesse (robustness) ; la capacité à monter en charge (scalability). La lecture de ce chapitre est fondamentale pour pouvoir aborder les autres parties de cet ouvrage. 2.1 LE TEMPS DE RÉPONSE Le terme «temps de réponse» désigne la durée d exécution d une opération sur le SI. Cette opération, par exemple l accès d un collaborateur à un portail, peut recouvrir l invocation de plusieurs tiers techniques (serveur web, serveur d application, base de données, etc.).

36 18 Chapitre 2. Les fondamentaux de la performance Cette durée s entend «sous une charge unitaire», c est-à-dire en réponse à la sollicitation d un seul client (par exemple, un utilisateur unique s adressant à une application ou bien une application unique s adressant à un service tiers) (figure 2.1). Îlot applicatif une opération application serveur application Un utilisateur (charge unitaire) Temps de réponse machine virtuelle système d exploitation couche matérielle Figure 2.1 Temps de réponse applicatif à une opération unitaire On utilise des termes différents pour qualifier les typologies d accédants aux opérations. Lors d actions interactives, issues d êtres humains, on parle de «temps de réponse» ; lors d appel par batch, on parle de «temps de traitement». Les temps de réponse/de traitement se mesurent en secondes (s) pour les traitements courts, en minutes (min) ou en heures (h) pour les traitements longs. Par exemple : 2 à 4 secondes pour afficher une page sur un site web marchand ; 120 minutes pour traiter les facturations en attente dans la base client. Lorsqu on parle du temps de réponse d une application, on considère le plus souvent que la latence réseau est nulle, c est-à-dire qu on considère une réponse en réseau local. Les tests de montée en charge permettant de qualifier les temps de réponse sont d ailleurs généralement menés au plus près de l architecture applicative et matérielle. Rappel : on définit par latence, le temps écoulé entre le moment où on initie une action et celui où on constate le résultat de cette action. Il est cependant des cas où le réseau a un impact non négligeable. Par exemple dans le cas d un accès à une application web en réseau étendu ou, de manière plus criante encore, dans le cas d une SOA basée sur l invocation de services hébergés chez des partenaires. Dans ces cas-là, la prise en compte de la latence réseau dans le calcul de temps de réponse est indispensable.

37 2.2 La capacité à monter en charge LA CAPACITÉ À MONTER EN CHARGE Le terme «capacité à monter en charge» ou sa version anglicisée «scalabilité» désigne l aptitude d une application à offrir des bons «temps de réponse» quand la quantité de traitements simultanés augmente. Il s agit donc de savoir bien gérer l augmentation du nombre d opérations unitaires sur un îlot applicatif donné. La capacité à monter en charge s exprime par «une durée maximum de traitement pour un niveau de charge donnée», c est-à-dire un temps de réponse pour un volume de charge. On parle aussi de débit ou throughput, mesuré en nombre de tâches simultanées par unité de temps. Par exemple : 3 secondes maximum pour afficher une page web avec 100 utilisateurs simultanés sur le site ; 3 h 30 maximum pour traiter les factures des clients en base de données. La capacité à monter en charge est une caractéristique beaucoup plus importante que les temps de réponse car elle précise le contexte dans lequel ceux-ci doivent être atteints. Îlot applicatif N opérations application serveur application Charge utilisateurs machine virtuelle système d exploitation Capacité à monter en charge couche matérielle Figure 2.2 Capacité à monter en charge 2.3 LA DISPONIBILITÉ Définition générale La disponibilité d un composant du système d information désigne le ratio de temps pendant lequel il est en état de fonctionner correctement sur une période de temps donnée (figure 2.3). La disponibilité s exprime en pourcentage, elle est notée A (pour availability) en anglais, et D (pour disponibilité) en français.

38 20 Chapitre 2. Les fondamentaux de la performance uptime downtime downtime = 4 jours/an disponibilité = 99 % janvier mars juin septembre décembre Figure 2.3 Disponibilité d un système On parle généralement de disponibilité de 90 %, 95 %, etc. À partir de 99 % on parle d architecture à «haute disponibilité». La disponibilité peut concerner : une application ou un service ; un équipement matériel (serveur, routeur, etc.) ; un équipement réseau (routeur, répartiteur de charge, etc.) ; un îlot applicatif ou une plate-forme complète. On parle de «tolérance aux pannes» pour un système qui peut fonctionner lorsqu un de ses composants est défaillant et peut être remplacé à chaud, c est-à-dire sans arrêt du service. La disponibilité n est jamais de 100 % : en effet, les composants électroniques et informatiques sont toujours faillibles, de plus il est généralement nécessaire d arrêter les systèmes de temps à autre pour des opérations de sauvegarde ou de maintenance. On peut s approcher des 100 % en déployant des systèmes redondants Calcul de la disponibilité Pour pouvoir chiffrer la disponibilité d un système, il est au préalable nécessaire de définir un certain nombre de concepts : L uptime désigne le temps de bon fonctionnement ou temps écoulé depuis le dernier démarrage ou le dernier «plantage». Le MTBF (Mean Time Between Failures) est le temps moyen entre deux «plantages» pour un composant d architecture. Il représente la mesure du taux de défaillances aléatoires dans un lot de composants, à l exclusion des pannes systématiques, dues par exemple aux défauts de fabrication, et de l usure due à l usage. L AFR (Annualized Failure Rate) est l inverse du MTBF rapporté à une année, c est-à-dire qu il représente la proportion de composants à changer chaque année. Ainsi, si des disques ont un MTBF de 1,2 million d heures, il faudra

39 2.3 La disponibilité 21 changer 0,73 % des disques chaque année (le mode de calcul de cette valeur est donné dans la figure 2.5). Le downtime désigne le temps d arrêt lié à un dysfonctionnement. Le MTTR (Mean Time To Repair) désigne le temps moyen nécessaire au rétablissement du service, c est-à-dire le temps d intervention permettant de remettre l architecture en ordre de marche. L AST (Agreed Service Time) désigne l exigence de continuité de service convenue avec la maîtrise d ouvrage. Par exemple, on peut convenir que le système fonctionnera aux heures de bureau, ou bien tous les jours sauf le week-end, ou encore 24 h/24. Sur la base de ces définitions, on peut définir la disponibilité (A) de trois manières différentes (figure 2.4). A = MTBF MTBF + MTTR ou A = UpTime UpTime + DownTime ou A = AST DownTime AST Figure 2.4 Méthodes de calcul de la disponibilité Ainsi, pour améliorer la disponibilité d un composant, on peut augmenter le MTBF au moyen des actions suivantes : Redondance de l infrastructure matérielle (routeurs, firewall). Redondance de l infrastructure logicielle (clusters). Redondance des sites de production. On peut aussi réduire le MTTR au moyen des actions suivantes : Formation des équipes d intégration et de production. Définition de procédures d exploitation standardisées. Mise en place de solutions de monitoring et de supervision. La formule de calcul de l AFR en pourcentage est donnée par la figure 2.5 (8 760 étant le nombre d heures par an).

40 22 Chapitre 2. Les fondamentaux de la performance 8760 AFR(%) = 100 MTBF Figure 2.5 Méthodes de calcul de l AFR On a vu que la haute disponibilité commence à 99 %. Les très hautes disponibilités s expriment généralement en ajoutant des 9 dans la partie décimale : on parle ainsi de disponibilités de 99,9 %, 99,99 %, etc. Le tableau 2.1 présente ces hautes disponibilités avec les temps d indisponibilité (downtime) associés. Tableau 2.1 Downtime des architectures à haute disponibilité Indisponibilité/downtime Disponibilité secondes/an minutes/an heures/an jours/an 90 % % % ,8 % ,9 % ,99 % ,999 % ,9999 % 32 99,99999 % 3 Les chiffres exprimés précédemment concernent un ensemble monolithique : lorsqu on doit calculer la disponibilité d un système constitué de plusieurs composants élémentaires, il est nécessaire d appliquer des règles qui rappellent le calcul des résistances dans un circuit électrique. Pour un système S constitué de N éléments E 1 à E n, ces règles sont celles des figures 2.6 et 2.7. A S = A E1 A E2. A En Figure 2.6 Disponibilité d un système S composé de n éléments E en série A S = 1 (1 A E1 ) (1 A E2 ) (1 A En ) Figure 2.7 Disponibilité d un système S composé de n éléments E en parallèle

41 2.3 La disponibilité 23 Ainsi, un système constitué d un serveur web à 95 % de disponibilité, d un serveur d application à 98 % de disponibilité, et d une base de données à 92 % de disponibilité offre une disponibilité de : 0,95 x 0,98 x 0,92 = 0,8565 soit 85,65 % Le mythe des cinq neuf Le mythe des cinq neuf porte sur la croyance selon laquelle une disponibilité de 99,999 % offre un service aux utilisateurs de 99,999 %. Cette hypothèse, qui paraît logique au premier abord, est invalide pour un certain nombre de raisons : Lors du rétablissement du service après un plantage, les opérations humaines génèrent du temps perdu. Elles sont généralement menées dans le stress, sans processus documenté, et de manière irrationnelle. En effet, les administrateurs de systèmes recourent rarement à des simulations de pannes (comme peuvent le faire les pompiers) pour s entraîner aux opérations de rétablissement de service. Ainsi, une panne de 10 minutes n est pas du tout équivalente à dix pannes d une minute ; d où l aspect trompeur des chiffres de disponibilité Les arrêts de service dus à des opérations de maintenance programmées sont rarement intégrés aux chiffres de disponibilité. Enfin, une erreur classique consiste à considérer que le cumul de deux composants à 99,999 % de disponibilité offre un taux de disponibilité de 99,999 %. La réalité est tout autre (cf. paragraphe précédent). Cet enjeu des cinq neuf est donc une vue de l esprit, un mythe. Il l est d autant plus que dans le cadre des applications informatiques de gestion, il est très rare de mettre en œuvre une disponibilité supérieure à 99 %. Les problématiques d atteinte des cinq neuf restent donc assez théoriques. Enfin, on recommande d être pragmatique dans la définition des engagements de performance et d utiliser des indicateurs plus compréhensibles des maîtrises d ouvrage, comme par exemple 5 minutes d indisponibilité par semaine Disponibilité et business La disponibilité d une application a un impact direct sur l activité de ses utilisateurs, et donc sur la performance de l entreprise (cf. Avant-propos). L atteinte d un très haut niveau de disponibilité étant très coûteuse en termes de matériel, de logiciels et de surveillance humaine, on arbitre généralement son niveau en fonction des enjeux métiers. Ainsi, les ressources consacrées à l atteinte d un haut niveau de disponibilité doivent être arbitrées en fonction du coût d une indisponibilité pour les utilisateurs métiers (tableau 2.2).

42 24 Chapitre 2. Les fondamentaux de la performance Tableau 2.2 Exemples de coûts d indisponibilité pour des applications critiques dans quelques secteurs d activités (source : Meta Group) Secteur d activité Coût moyen par heure Banque d investissement 6,48 M$ Télécom 2,00 M$ Web marchand 1,1 M$ Pharmacie 1,0 M$ Chimie 0,7 M$ Réservation aérienne 90 k$ L arbitrage doit être effectué uniquement sur des critères rationnels de calcul de coûts : en effet, il est dangereux de poursuivre une disponibilité idéale qui s avérerait être un gouffre financier. La figure 2.8 illustre la croissance exponentielle des coûts pour l atteinte d une disponibilité supérieure à 99,99 %. A 99,9999 % 99,999 % 99,99 % Le coût de franchissement des derniers niveaux est très élevé 99,9 % 99,8 % 99 % 98 % Figure 2.8 Caractère exponentiel des coûts de haute disponibilité 2.4 LA ROBUSTESSE La robustesse d un système désigne sa capacité à ne pas «planter» et «perdre ou corrompre» des données ou des messages lorsqu il est soumis à des sollicitations inhabituelles. Il s agit donc d une mesure de la disponibilité des systèmes et de l intégrité des informations en situation de stress.

43 2.4 La robustesse 25 L intégrité peut porter sur : des données échangées avec d autres systèmes (messages, fichiers, etc.) ; des données persistantes stockées dans des bases de données, annuaires, serveurs de fichier, etc. La robustesse s exprime par une grandeur scalaire sans unité, par exemple : pas plus d un message perdu pour messages traités ; au maximum trois redémarrages d un serveur de bases de données par mois. En résumé Ce chapitre montre que les DSI disposent d un outillage mathématique conséquent pour mesurer et gérer les problématiques de performance. Ces indicateurs chiffrés sont utilisés pour définir les engagements de services vis-à-vis des maîtrises d ouvrage (cf. chapitre 3). Ils sont de plus utilisés pour anticiper les pannes, ce qui permet de rationaliser l achat de matériel.

44

45 3 L organisation de la performance Objectif Ce chapitre présente l organisation à mettre en œuvre au sein des équipes de la DSI pour assurer la performance du système d information. Il introduit un modèle de maturité pour la performance : ce modèle permet d évaluer les pratiques d une entreprise et de les améliorer étape par étape. 3.1 ORGANISATION DES ÉQUIPES DE PRODUCTION Méthodologie de mise en œuvre de la performance La mise en œuvre d une démarche de rationalisation autour de la performance dans une DSI est généralement du ressort de la direction de l exploitation. Cette dernière est en effet responsable de la continuité de service vis-à-vis des maîtrises d ouvrage et c est donc elle qui s engage sur les fameuses SLA (cf. section 3.1.2). La problématique récurrente qu elle rencontre est qu elle doit s engager sur la base d une architecture conçue par la direction des études et qu elle ne la maîtrise pas toujours. Cet aspect sera évoqué dans la suite de ce chapitre. Les acteurs de la direction de l exploitation sont : Les architectes de production : ils conçoivent les plates-formes logicielles, matérielles et réseaux vouées à héberger les applications métiers. Leur rôle

46 28 Chapitre 3. L organisation de la performance est de construire des socles capables d offrir la disponibilité attendue par les maîtrises d ouvrage. Les gestionnaires du changement : ils analysent systématiquement l impact de toute demande de mise en production, afin d éviter d introduire des instabilités dans la plate-forme d entreprise. Les techniciens de production : ils exploitent la plate-forme dans les tranches horaires définies par les conventions de services (par exemple : 5 jours par semaine, 24 h/24, etc.). Leur rôle est d assurer la maintenance, le monitoring et les interventions en cas d incidents sur les plates-formes de production. Le support utilisateur (help desk en anglais) : il répond aux demandes des utilisateurs lorsque ceux-ci constatent un dysfonctionnement de leurs applications. Le help desk est généralement structuré en plusieurs niveaux : les équipes de niveau 1 prennent tous les appels utilisateurs et les redirigent vers des experts techniques de niveau 2 ou 3 lorsque cela s avère nécessaire. La mise en œuvre d une démarche de maîtrise de la performance s appuie de manière classique sur le référentiel ITIL (Information Technology Infrastructure Library). ITIL est un ensemble de bonnes pratiques pour la fourniture de services informatiques. Ce référentiel, issu du monde anglo-saxon, vise à déployer des pratiques de manière progressive, en fonction des besoins. ITIL propose un référentiel pour la «gouvernance informatique». Cette dernière propose des pratiques sur : la formalisation des contrats de service (SLA) ; le chiffrage des coûts des services sous-jacents ; la gestion des demandes de service en amont des projets ; la gestion de la continuité de service ; la gestion de la capacité. ITIL offre donc un outillage pour définir et suivre les attentes de performance vis-à-vis du SI. Il définit des niveaux de maturité, permettant à l entreprise utilisatrice de situer sa progression dans l adoption de la démarche. Les cinq niveaux de maturité du référentiel ITIL sont : Le niveau technologique : ce niveau est basé sur des personnes clefs expertes en technologies et irremplaçables. Le niveau produit ou service : à ce niveau, les infrastructures sont documentées et des systèmes d alertes sont déployés. Le niveau orienté client : à ce niveau, le suivi des infrastructures dans la durée permet d anticiper les problèmes et besoins. Le niveau orienté business : à ce niveau, on est capable de définir et de gérer les SLA. Le niveau chaîne de valeur : à ce niveau, la maturité des infrastructures participe à la compétitivité de l entreprise.

47 3.1 Organisation des équipes de production 29 Sur la base d ITIL, les équipes de production documentent leurs pratiques pour leur usage propre, ainsi que pour l usage des autres équipes de la DSI. Des documentations simplifiées sont ainsi produites afin de sensibiliser tous les profils de la DSI. Par ailleurs, des recommandations sur les architectures assurant robustesse et haute disponibilité peuvent être rédigées à l attention de la direction des études (cf. section 3.1.4). Figure 3.1 Organisation de l exploitation dans une DSI Performance et maîtrise d ouvrage La direction de l exploitation s engage vis-à-vis des maîtrises d ouvrage sur des niveaux de disponibilité et des temps de réponse. Il s agit de mettre à disposition «l énergie informatique» nécessaire aux utilisateurs métiers (cf. figure 3.1). ITIL offre un canevas pour formaliser ces engagements : Le Service Level Requirement (SLR) constitue l expression des besoins utilisateurs. Le Service Level Agreement (SLA) définit la convention de niveau de service. L Operational Level Agreement (OLA) définit les conventions de service entre les équipes de support. Il s agit donc d engagements entre équipes techniques, transparents pour l utilisateur final. L Underpinning Contract (UC) définit les contrats de sous-traitance Performance et direction des études Au sein de la direction des études, on trouve généralement des équipes d urbaniste et d architectes de SI dont le rôle consiste à définir et à maîtriser les contours de l architecture du système d information. Ces équipes travaillent en particulier sur :

48 30 Chapitre 3. L organisation de la performance la cartographie des processus métier, applicatifs, référentiels du SI, et la définition des solutions destinées à traiter les événements métier ; la mise en œuvre des architectures SOA ; les socles d échanges du SI : middlewares, EAI, ESB, etc. ; les frameworks structurants et réutilisables dans les divers applicatifs. Elles doivent travailler en étroite collaboration avec les architectes de production afin de faire des choix compatibles avec les socles définis par ces derniers. Ces choix doivent en particulier permettre le monitoring et l exploitation des applicatifs par les techniciens d exploitation. Ils doivent aussi garantir une performance et une disponibilité optimales des systèmes. La collaboration entre architectes de SI et architectes de production est cruciale. Les premiers apportent des socles logiciels permettant l industrialisation des développements applicatifs et le respect de l état de l art en termes de technologies IT. Les seconds proposent une plate-forme apportant robustesse et disponibilité à ces applicatifs. La collaboration efficace de ces équipes offrira une garantie de robustesse, de productivité et de pérennité des socles du SI. Elle n est pas toujours aisée du fait des différences culturelles et des différences de priorité de ces deux équipes. Par exemple, les architectes de SI ont tendance à vouloir migrer les anciens systèmes pour suivre l état de l art, tandis que les architectes de production souhaitent les conserver car leur performance est mieux maîtrisée Performance et maîtrises d œuvre Au sein des maîtrises d œuvre, on trouve généralement : les architectes applicatifs qui conçoivent les applications unitaires à la demande des maîtrises d ouvrage ; les chefs de projet qui encadrent le développement ou l intégration de ces applicatifs et sont en relation directe avec les maîtrises d ouvrage ; les développeurs qui construisent les applications ; les intégrateurs, dont le rôle est de préparer les applicatifs à la mise en production. Ces équipes utilisent généralement une méthodologie plus ou moins structurée pour la gestion des cycles de vie projet. Parmi ces méthodologies, l approche CMMI 1 (Capability Maturity Model Integration) est particulièrement appréciée des DSI aujourd hui. CMMI est un guide de bonnes pratiques, comparable à ITIL, qui permet aux maîtrises d œuvre de déployer une méthodologie adaptée à leur contexte (complexité, aspect stratégique des projets, degré d exigence des maîtrises d ouvrage, etc.). De même que pour ITIL, on parle pour CMMI de cinq niveaux de maturité : 1. Pour appréhender la méthodologie CMMI voir CMMI, Un itinéraire fléché vers le Capability Maturity Model Integration, Richard Basque, Dunod, 2006.

49 3.1 Organisation des équipes de production 31 Niveau initial : à ce niveau, l aboutissement des projets repose sur quelques personnes compétentes, parfois appelées «héros». Niveau reproductible : à ce niveau, les pratiques de gestion de projet sont documentées et partagées au sein de l entreprise. Niveau défini : à ce niveau, les solutions techniques sont normalisées et maîtrisées. Niveau géré : à ce niveau, la performance des équipes est mesurée. Niveau optimisé : à ce niveau, la performance des équipes suit un cycle d amélioration permanente. Les architectes applicatifs, en charge de concevoir les nouvelles applications, suivent de manière logique les recommandations issues des équipes d architectes de SI et d urbanistes. Il est crucial qu ils collaborent aussi avec les architectes de production afin de produire des architectures compatibles avec les contraintes d exploitation. Sans cela, ils risqueraient d introduire des instabilités dans la plate-forme de production. On parle parfois pour cela d «effet papillon» : cet effet qualifie le risque qu une petite erreur au sein d un vaste système entraîne des réactions en chaîne et rende ce système instable. Une vérification de la conformité des architectures applicatives par les architectes de production permettra d éviter cet «effet papillon» Performance et exploitation Comme nous l avons vu dans le chapitre précédent (Les fondamentaux de la performance), la disponibilité est un des piliers de la performance. Pour l assurer, il faut bien évidemment mettre en place de la redondance aux différents niveaux de l infrastructure mais également mettre en place des bonnes pratiques d exploitation. Mais cela ne suffit pas toujours. On néglige parfois (souvent?), l aspect humain de l exploitation. En effet, il est tout à fait inutile de mettre en place 12 serveurs en cluster si derrière, les équipes en charges du MCO 1 ne sont pas motivées pour maintenir un niveau de service correct. Les études 2 de la Federal Reserve Bank of Boston montrent que : «Tant que la tâche n implique qu un talent mécanique, les bonus ont fonctionné comme attendu : plus la récompense financière est forte meilleure est la performance. Mais dès que le travail demandé nécessite, ne serait-ce que quelques petits, talents de réflexion, la motivation par la rémunération conduit à de moins bonnes performances». Et bien que l aspect exploitation soit souvent vu comme «purement mécanique» (on applique les consignes d exploitation et c est tout), la réalité du terrain montre que cela ne suffit pas. Le schéma de la figure 3.2 détaille la vie d un incident de production. 1. Maintien en Condition Opérationnel 2. Études N (juillet 2005) : Ariely, Gneezy, Lowenstein et Mazar

50 32 Chapitre 3. L organisation de la performance Figure 3.2 Cycle de vie de résolution d un incident Il est fondamental, pour une bonne performance du SI, de réduire au maximum le MTTR 1 et pour cela il faut impérativement réduire le temps de détection (en utilisant des outils de supervision) et les temps de diagnostic et d application de la solution. Ces deux derniers sont à la responsabilité de l équipe d exploitation et, si cette dernière se dit «de toute façon ça tombe toujours en panne et on verra ça plus tard», votre MTTR risque fort d augmenter tout comme l insatisfaction des utilisateurs. Comment mobiliser l équipe d exploitation à la performance? En l impliquant dès les phases amont du projet : À quoi sert l application? Quelle est la population d utilisateurs? Que fait-elle? Comment est-elle architecturée? En lui fournissant les outils dont l exploitation a besoin : Un fichier de trace de lignes par jour n est pas très utile. Un support de la maîtrise d œuvre lors des premiers temps d exploitation beaucoup plus. En prenant en compte leurs retours d expérience Une équipe d exploitation gère souvent un nombre élevé d applications et sait assez bien distinguer ce qui est facilement exploitable (donc potentiellement plus performant) de ce qui ne l est pas. 1. Mean Time To Repair : temps moyen de rétablissement du service.

51 3.2 Maturité dans la performance MATURITÉ DANS LA PERFORMANCE Ce paragraphe présente une méthodologie d analyse de la maturité en termes de performance issue du Computer Management Group (CMG), une association américaine qui s intéresse à la performance des SI. Cette approche est inspirée des modèles à maturité de type Capability Maturity Model (CMM). Elle propose, elle aussi, une montée en maturité en cinq étapes. Elle présente l avantage d intégrer tous les acteurs du système d information, à savoir les études, la production et le business Niveau 1 : le statut quo Le niveau 1 est celui par défaut des organisations qui n ont pas de démarche de gestion de la performance IT. L organisation n a absolument pas intégré la gestion de la performance dans ses processus IT. Cette situation présente plusieurs caractéristiques : L absence de coopération entre les services des études et de la production. Par exemple, les développeurs produisent des applications sans connaître les contraintes des exploitants. Les problèmes ne sont traités que lorsque leurs conséquences deviennent dommageables. Les solutions mises en œuvre sont généralement des rustines qui traitent davantage les symptômes que les causes profondes. Les équipements (serveurs, stockage) sont achetés et déployés sans véritables démarches de dimensionnement (sizing) ou de gestion de la capacité (capacity planning). La gestion des incidents en production consomme beaucoup de ressources. Les décideurs considèrent le SI comme une fonction de support. Ils sont peu impliqués dans la résolution des problèmes de performance qu ils estiment être une affaire de spécialistes Niveau 2 : la mesure Ce niveau est celui de la prise de conscience de l impact de la performance du SI sur l activité du business. Il se caractérise par la mise en œuvre d une stratégie de mesure généralisée de la performance : le monitoring. Les informations collectées sont utilisées pour créer des indicateurs. Des seuils sont définis pour chaque indicateur et les franchissements de seuils peuvent déclencher des événements. On découpe habituellement ce niveau en trois sous-niveaux : Monitoring de disponibilité : il permet de mesurer la disponibilité des composants. Monitoring simple des temps de réponse : il permet de mesurer les temps de réponse des requêtes utilisateurs. Monitoring avancé des temps de réponse : il permet de mesurer les temps de réponse des requêtes utilisateurs et de détailler le temps passé dans chaque composant.

52 34 Chapitre 3. L organisation de la performance Niveau 3 : l optimisation des performances Au niveau 3, les équipes des études et celles de la production travaillent ensemble dès le lancement des projets. Cette collaboration vise à : la mise en œuvre de solutions permettant de connaître à tout instant l état des composants à l intérieur des applications ; la traçabilité totale des actions utilisateurs sur le SI ; la généralisation des pratiques de tests de charge pour les applications critiques (cf. chapitre 15) Niveau 4 : l optimisation du métier Ce niveau introduit un fort degré de participation des utilisateurs aux décisions impliquant le SI. Il est caractérisé par : la mise en place de solutions de surveillance et d amélioration de la productivité des utilisateurs ; la totale maîtrise des applications et des éléments d infrastructure par les équipes IT ; une forte implication du management dans les décisions concernant le SI. À ce niveau, les équipes de production déploient les SLA en accord avec les maîtrises d ouvrage Niveau 5 : l optimisation des processus Au niveau 5, la performance entre dans le domaine des processus métiers : la direction de la production et les maîtrises d ouvrage collaborent afin d augmenter la compétitivité de l entreprise. Ce niveau voit l intégration des aspects financiers (ROI 1, TCO 2, etc.) à la démarche de gestion de la performance. Il n a aucun impact technique. Les indicateurs métiers et techniques sont agrégés et on tend vers la notion d entreprise en temps réel. En résumé On a vu dans ce chapitre que la performance est un engagement fondamental de la DSI vis-à-vis des métiers. La bonne gestion de «l énergie informatique» est cruciale pour la compétitivité de l entreprise. Des pratiques émergent pour bien la gérer et pour cadrer les relations client/fournisseur entre la DSI et les maîtrises d ouvrage. 1. ROI : Return On Investment. 2. TCO : Total Cost of Ownership.

53 4 Contractualiser la performance Objectif Ce chapitre présente les différentes notions autour de la contractualisation de la performance entre la DSI et les utilisateurs. Il explicite les notions de contrat de service, d objectif de performance en introduisant les notions de temps et de point de retour des services. Il traite également des problématiques de plan de continuité d activité. Les entreprises ont besoin de nos jours de mettre en place des solutions informatiques performantes. Aussi demande-t-on de plus en plus à la DSI de garantir les performances des applications qu elle met à la disposition des utilisateurs. ITIL, que nous avons abordé rapidement dans le chapitre 1 propose quelques outils pour permettre à la DSI de s engager. Mais nous verrons par la suite que cet engagement n est pas à sens unique et que dans la contractualisation des performances tous les acteurs de l entreprise sont parties prenantes. 4.1 LA QUALITÉ DES SERVICES La gestion des niveaux de service (Service Level Management) fait partie du processus de Support des Services. Il permet de mettre en œuvre et de gérer la qualité des services qui sont fournis par la DSI. Cela doit se faire avec des coûts maîtrisés et de manière à

54 36 Chapitre 4. Contractualiser la performance améliorer et à aligner en permanence les besoins de l entreprise sur les capacités de la DSI à fournir ces services. Avant de mettre en place un suivi de la qualité des services, il convient bien entendu de fournir aux utilisateurs un descriptif de ce que la DSI est en mesure de leur proposer : parler de gestion des niveaux de service présuppose donc la définition d un catalogue de services Catalogue de services et orientation client Le catalogue de services offre un mécanisme de communication et de traduction qui permet à la DSI d organiser et présenter la valeur ajoutée fournie aux utilisateurs par le biais des services en question. La mise en œuvre de ce catalogue doit être un travail commun entre les équipes métier de l entreprise et la DSI. En effet, il ne sert à rien de proposer un service fonctionnant 24H/24, 7 jours/7 et 365 jours par an si le besoin n est pas avéré. Ce serait investir inutilement dans des solutions démesurées. La collaboration avec les métiers est d autant plus primordiale que le catalogue de services doit expliquer dans un langage compréhensible, à la fois par les utilisateurs et la DSI, les caractéristiques de ces offres, en précisant les contraintes qui y sont attachées : engagement réciproque (métier/dsi), contraintes de mise en œuvre, disponibilité, coût de mise en œuvre et coût récurent. Les principaux avantages que l on peut attendre de la mise en place d un catalogue de services sont : une plus grande transparence sur ce que l informatique sait faire ; un allégement de la charge de travail quant à la définition des architectures ; une plus grande transparence sur les coûts, c est-à-dire-sur ce que l utilisateur va payer. Un dernier avantage est la possibilité de mesurer la qualité de services que propose la DSI, car on ne peut mesurer que ce que l on a clairement défini L engagement autour des services À partir des éléments du catalogue des services, il sera possible de définir un contrat de service (ou SLA). Ce SLA va spécifier l ensemble des niveaux de service à fournir par la DSI (ou son prestataire informatique) à destination de ses clients. Il s agit bien d un engagement formel et contraignant, établi entre un fournisseur et un client. Un SLA peut englober un ou plusieurs services. On peut tout à fait définir un SLA pour la fourniture d un service «Poste de travail», qui comprendra la fourniture : d un équipement physique (l unité centrale, l écran, le clavier, la souris),

55 4.1 La qualité des services 37 d un service de réseau (pour que le poste soit connecté au SI de l entreprise), d une messagerie, d espace de stockage sur le réseau, d un accès à Internet, etc. Chaque sous partie de ce SLA sera nommée OLA pour Operational Level Agreement. On peut même avoir une dépendance hiérarchique entre les OLA comme le montre la figure 4.1. Figure 4.1 Service, SLA et OLA UC = UNDERPINNING CONTRACT (CONTRAT DE SOUS-TRAITANCE) Définition ITIL : un contrat passé entre un fournisseur de services des Technologies Informatiques et une tierce partie. La tierce partie fournit des biens ou des services qui soutiennent la fourniture d un service des TI à un client. Le contrat de sous-traitance définit les moyens et les responsabilités qui sont nécessaires pour atteindre les niveaux de service cible d un SLA.

56 38 Chapitre 4. Contractualiser la performance Contenu d un SLA Il existe autant de SLA que d entreprises mais on se doit de retrouver dans tout contrat de service les éléments suivants : Description des services : Les objectifs métiers, c est-à-dire à quoi ils servent. Fonctionnalités : Description fonctionnelle et technique (matérielles et logicielles) du service et les activités qu il couvre. Les niveaux de services Plages d ouverture et nombre d utilisateurs : le service est-il disponible 24h/24 ou de 9H à 18H? Y aura-t-il 5 ou 2500 utilisateurs? Volumes de données traitées Objectifs de disponibilité : Voir paragraphe pour le calcul de la disponibilité Objectifs de résolution des incidents : Temps de prise en compte et temps de résolution Responsabilité des parties Modalités de suivi et tableau de bord Prix et facturation On remarque, au vu de ce plan, qu un certain nombre d engagements ne peuvent être pris par la DSI que sous certaines conditions. En effet, comment peut-on assurer que le traitement d imputation des mouvements comptables se terminera à 5 heures du matin si le volume triple? Comment garantir la capacité de montée en charge d une application si les utilisateurs passent de 5 à 2 500? Ce n est pas possible. Il est donc nécessaire, lors de la mise en place d un SLA, d avoir un engagement à la fois de la DSI, mais également des utilisateurs quant à l utilisation qui sera faite du service Mise en place d un SLA Comment souvent avec ITIL, il est préférable d adopter une démarche pragmatique. La bonne approche consiste à partir de l existant, à mesurer dans un premier temps ce que l on est véritablement capable de faire. C est en quelque sorte une approche par «petits pas». Prenons par exemple le nombre d incidents, il faut dans un premier temps mesurer le temps de traitement et la durée d indisponibilité constatée. Puis il faut se fixer des objectifs réalistes et atteignables sans obligatoirement les communiquer aux clients. Exemple : 80 % des incidents traités en moins de 4 heures. Une fois atteints, il faut hausser le seuil de l objectif à 85 % puis à 90 % et ensuite réduire le temps d indisponibilité à 2 heures, puis 1 heure et ainsi de suite. Bien entendu, et comme nous l avons déjà précisé plus haut, la mise en place d une gestion de la qualité des services ne peut se faire sans l adhésion de toutes les parties prenantes du SI (utilisateurs, études, exploitation). De plus il faut garder à l esprit qu ITIL comme toute gestion de processus est foncièrement attachée à une politique

57 4.2 Gestion des incidents 39 d amélioration continue : «ce que vous faites aujourd hui peut-être fait encore mieux demain». Quelques écueils à éviter : Pas d objectifs atteignables ou vérifiables : si vos objectifs sont irréalisables vous ne pourrez jamais les réaliser. Pas d harmonisation des OLA et UC : si la somme de vos OLA est de 5 heures vous ne pouvez pas avoir un temps de rétablissement inférieur à 15 minutes Pas de vision globale : les besoins de vos métiers et vos propositions doivent concorder «Le tir à la corde» : si chaque partie campe sur ses positions, rien ne peut progresser. Il faut aussi bien, de la part des métiers comme de la DSI, une volonté d aller dans le sens de l amélioration. La bonne mise en place d une gestion des niveaux de services ne peut se faire sans un esprit de «partenariat» entre les métiers et la DSI et surtout une volonté d aller de l avant en se donnant des objectifs réalisables et améliorables. 4.2 GESTION DES INCIDENTS Il ne faut pas considérer le dysfonctionnement d un système informatique comme étant une exception. C est une règle. Un Système d Information performant est donc un système d information capable de gérer des pannes avec célérité et efficacité. Dans ce cadre nous allons utiliser deux notions : celle du RTO 1, et celle du RPO 2. En cas d incident, il convient de restaurer le service aussi rapidement que possible tout en minimisant les conséquences négatives sur le business, ceci dans l optique d assurer le meilleur niveau de service possible en termes de qualité mais surtout de disponibilité RTO Le RTO est une durée qui doit être définie à l avance et en fonction des besoins de l entreprise. Si nous prenons le cas d un système de gestion de la production, comme par exemple un ERP 3, on se rend rapidement compte que si ce dernier vient à ne plus fonctionner, l activité de l entreprise va se retrouver au point mort, mettant en danger 1. Recovery Time Objective : Objectif de Temps de Reprise. 2. Recovery Point Objective : Objectif de Point de Reprise. 3. ERP : Enterprise Ressource Planning.

58 40 Chapitre 4. Contractualiser la performance la pérennité de cette dernière. Le RTO de cet ERP devra donc être extrêmement court. En revanche, le RTO de l application permettant aux salariés de consulter les menus du restaurant d entreprise pourra lui être beaucoup plus long, puisque c est loin d être une application critique. Deux concepts sont à distinguer : d une part le temps nécessaire à la reprise du service et d autre part celui nécessaire à la résolution de l incident. En effet, ces deux notions sont malheureusement souvent confondues alors qu elles sont bien distinctes. Lorsque nous parlons de rétablissement du service, il n est en aucun cas sousentendu que nous avons résolu les causes du dysfonctionnement, ni même que nous les connaissons. Nous avons simplement permis au service de «refonctionner». Nous le verrons ultérieurement (cf. chapitres 10 et 12), des techniques simples permettent d obtenir un RTO relativement fort (clustering, bascule DNS), mais ces artefacts ne sont en aucun cas utiles pour le diagnostic et la résolution des causes profondes de l incident RPO ITIL défini le RPO comme suit : La quantité maximale acceptable de données pouvant être perdues lors de la restauration d un service après une interruption. L objectif d un point de reprise est exprimé sous la forme d une durée avant la panne. Généralement, définir un RPO revient à définir les objectifs de sauvegarde et d en connaître les plages. Prenons en exemple un ensemble de traitements de nuit mettant à jour le datawarehouse comptable de l entreprise. À l intérieur de ce lot de traitements, une sauvegarde de la base de données est prévue à 20 heures. En cas d incident grave le jeudi matin, la DSI sera en mesure de garantir un RTO à J 1 (sauvegarde du mercredi soir). Mais le RPO ne se limite pas à une gestion fine des sauvegardes. Il est tout à fait possible d envisager des points de reprise dans des usages «temps réel». Prenons l exemple d une application de commerce en ligne, hébergée sur un cluster avec maintien de session (cf. chapitre 14). En cas de bascule d un nœud du serveur vers l autre, la perte de donnée peut tout à fait se limiter à ne plus voir le dernier produit ajouté au panier. Nous avons là un RPO très faible puisqu il se limite à la perte de la dernière action utilisateur RTO et RPO Le RTO et le RPO sont deux notions liées. Lorsque l on analyse ces deux indicateurs, il est tout à fait possible de déterminer le temps total d interruption d un service. Comme nous l avons vu précédemment le MTTR englobe : le temps de détection de l incident,

59 4.3 Le plan de continuité 41 le temps de prise de décision du passage en mode secours, le temps de mise en œuvre des procédures de secours, et enfin le délai de contrôle et de relance du service. La somme de ces temps se doit d être inférieure au RTO défini au préalable. Il est important de noter qu en fonction du domaine d activité de l entreprise, le RTO et le RPO ne seront pas mis systématiquement en relation. Comme nous l avons vu, un site de commerce en ligne aura avant tout besoin d assurer le retour de la fonctionnalité d achat mais pourra tout à fait faire face à la perte d une commande. 4.3 LE PLAN DE CONTINUITÉ En cas de sinistre, de panne majeure au niveau du système d information, les entreprises performantes se doivent de mettre en place un plan de continuité d activité (PCA). Dans ce contexte la définition du RTO et du RPO permet de planifier les actions à mener en cas de sinistre, mais aussi et surtout d adopter une stratégie d investissement informatique en vue d une situation catastrophique. Un PCA est un ensemble de mesures qui visent à assurer, face à divers scénarios de crises, y compris extrêmes, le maintien des activités essentielles de l entreprise. Le cas échéant, un mode dégradé peut être instauré de façon temporaire, jusqu à la reprise planifiée des activités Éléments à prendre en compte dans l élaboration d un PCA Le premier, et non des moindres, est une bonne identification des applications sensibles de l entreprise. Pour en revenir à nos précédents exemples, pouvoir consulter les menus du restaurant d entreprise n est pas d un intérêt fondamental pour la bonne marche de l entreprise. A contrario la disponibilité de l ERP de la société l est. Un autre point fondamental est une bonne identification des SPOF 1. Il est tout à fait inutile de mettre en œuvre un cluster avec 12 serveurs sans avoir prévu plusieurs sources d alimentation électrique. Car à la moindre coupure d alimentation électrique, les 12 serveurs seront tous à l arrêt. Pour finir il est indispensable de tester le plan de continuité car il ne faut pas perdre de vue que ce dernier ne sera utilisé qu en cas de crise majeure (incendie dans le Datacenter, crue, ou tout autre évènement grave). Dans ces conditions la réaction des collaborateurs de l entreprise peut être très différente de la normale). Il est donc indispensable de les préparer. 1. Single Point Of Failure : point d un système informatique dont le reste du système est dépendant et dont une panne entraîne l arrêt complet du système.

60

61 DEUXIÈME PARTIE Performance et architecture d entreprise L objectif de cette partie est de présenter les enjeux architecturaux de la performance et de la robustesse des applications du système d information (SI). La performance n est pas une qualité qui s acquiert par miracle au moment de la mise en production d une application. Au contraire, la recherche d une bonne performance débute dès les études de conception de l architecture de cette application, et plus généralement résulte d une architecture pertinente au niveau du système d information ; d où l importance de ces enjeux architecturaux. Mais qu entend-on par architecture? Comme l a rappelé la partie précédente, ce terme désigne (i) la décomposition du SI et de ses applications en un ensemble de composants logiciels et matériels, et (ii) l étude des relations (c est-à-dire des communications) entre ces différents composants. Cette partie s intéresse essentiellement aux enjeux de performance liés aux communications entre les différents composants, telles que définies par la conception architecturale. Le comportement de chaque composant, c est-à-dire la problématique de performance individuelle d un composant donné, sera abordé dans la troisième partie ainsi que dans le chapitre 15.

62 44 Performance et architecture d entreprise La mise en place d une architecture comporte trois phases : Le choix d un modèle d architecture : ce modèle définit les catégories de composants logiciels à modéliser et à développer/réutiliser, et sert ainsi de cadre de référence aux travaux de définition et de modélisation de l architecture logicielle de chaque application. Pour élaborer ce modèle, on s appuie sur les modèles disponibles, par exemple le modèle SOA. La définition de l architecture logicielle de chaque application, ou architecture applicative, c est-à-dire : la décomposition de l application métier en composants logiciels ; la spécification du rôle de chaque composant ; et l étude des communications entre ces composants. Et enfin, la définition de l architecture de déploiement, c est-à-dire : la définition puis la mise en place de l infrastructure (matériel, réseau, logiciels de base, etc.) ; et la répartition des composants logiciels sur les différents composants de cette infrastructure. Chaque phase implique des risques de performance et il convient d analyser les enjeux de performance avec ces différents points de vue. Quel est alors le contenu de la présente partie? Le chapitre 5 propose un modèle d architecture générique, orienté SOA, et analyse de façon générale les enjeux de performance de ce modèle. Il propose de ce fait une véritable démarche pour repérer/minimiser certains risques majeurs. Puis, chacun des chapitres suivants applique cette démarche, en se focalisant sur une «couche» de l architecture. Dans une architecture SOA, les services jouent un rôle clef : le chapitre 6 présente les problématiques de performance spécifiquement liées aux services, en particulier les performances des services d accès aux informations métier et aux référentiels, ou services CRUD 1. Le déploiement de plus en plus fréquent de processus métier e-business rend le SI dépendant de la robustesse de ces processus : le chapitre 7 traite de ces problématiques de robustesse et de performance des processus métier. Les applications interactives représentent la partie visible du SI pour les utilisateurs : leur performance est une condition sine qua non de l acceptation de l application par ces utilisateurs. Le chapitre 8 revient donc sur quelques problèmes clefs de performance et de robustesse de ces applications. 1. CRUD : Create Retrieve Update Delete.

63 Performance et architecture d entreprise 45 L exemple «Fil Rouge» Pour illustrer le propos, cette partie s appuiera sur un exemple «Fil Rouge». Fil Rouge est une entreprise de distribution de produits, jouant le rôle de grossiste entre d une part un ensemble de magasins détaillants et, d autre part, un ensemble de fabricants. Ce distributeur dispose d entrepôts régionaux afin de mailler le territoire national et d accélérer la livraison des produits. Son SI a été construit sur le modèle «un détaillant envoie directement ses commandes à l entrepôt régional auquel son magasin est rattaché». Les envois se font par des moyens traditionnels (fax, mail, courrier). Ce modèle n est plus adapté à une gestion commerciale et marketing moderne. D une part, il n utilise pas de façon efficace les outils Internet actuels (accès interactif ou envoi de message de commande) et futurs (accès via les mobiles). D autre part, il ne permet pas de traiter différemment les magasins «stratégiques» (ceux représentant le montant de commandes le plus important) et les autres : par exemple, si l entrepôt de rattachement d un magasin stratégique est en rupture de stock, il est indispensable qu un autre entrepôt puisse livrer ce magasin. Enfin, ce modèle ne permet pas non plus de traiter simplement la gestion des stocks : que faire en cas de baisse des stocks sur une région? Comment répartir une commande entre plusieurs entrepôts? Que faire si un entrepôt est fermé pour cause d inventaire? Etc. Pour résoudre ces problèmes, le grossiste met en place une plate forme de gestion de commande, centralisée à l échelle nationale, et automatisée : elle recevra les commandes issues de l informatique de chaque magasin (sous forme de message XML) et répartira ces commandes vers les différents entrepôts en fonction de critères multiples (état des stocks, urgence et montant de la commande, importance du client, etc.). Cette plate forme s insère cependant dans un SI existant : par exemple, elle devra s interfacer avec le SI de gestion des stocks (décentralisé dans chaque entrepôt), et avec le SI de gestion des magasins clients. Par ailleurs, une application interactive, de type Portail, permettra à des petits magasins d accéder à cette plate forme via des formulaires permettant de saisir et de transmettre une commande. La performance et la robustesse de cette plate forme nationale sont clairement un point crucial sur le plan métier. En particulier, pour attirer les détaillants, Fil Rouge s engage contractuellement à répondre en x secondes à toute commande envoyée automatiquement. La réponse inclut la date de livraison prévisionnelle de ladite commande.

64

65 5 Les enjeux architecturaux de la performance Objectif L objectif du chapitre est de présenter les principaux risques de performance d une architecture de système d information. Une démarche est proposée pour ce faire : le chapitre en décrit les trois principales étapes. Chaque étape est associée à une analyse de risque. Les risques sont décrits sous forme d anti-pattern, qu il convient de détecter aussi précocement que possible. 5.1 DÉMARCHE PROPOSÉE La démarche «architecture et performance» proposée comprend trois étapes. Ces étapes s inscrivent dans une démarche architecturale globale, telle que présentée par la figure Construire une architecture Cette démarche débute par la définition d un modèle général du système d information (SI). Ce modèle va mettre en évidence les différentes couches de composants logiciels constituant ce SI. Il permet de repérer les types de composants à développer et/ou à assembler pour construire les nouvelles applications destinées à s insérer dans ce SI.

66 48 Chapitre 5. Les enjeux architecturaux de la performance 1 Définir Définir le le modèle d architecture Niveau SI 2 Choisir Choisir les les patterns architecturaux Niveau Solution Mettre en place le le référentiel des composants & frameworks réutilisables dans les solutions Définir l architecture d une solution Architecture applicative & Architecture de déploiement Concevoir Concevoir et et développer les les composants de de la la solution Processus, application MVC, services 3 Détecter les les anti-patterns de de performance Niveau usine logicielle & Composants réutilisables Intégrer la solution Figure 5.1 La démarche «architecture et performance» Ce modèle s appuiera sur l approche SOA, non pas parce que c est la dernière mode informatique, mais parce que cette approche est pertinente pour résoudre («contribuer à résoudre» serait plus juste) plusieurs problèmes clefs d un SI moderne, tels que son ouverture vers le monde extérieur (clients, etc.) ou la valorisation de l existant mainframe. Cette approche s appuie sur l usage de patterns architecturaux. Une fois le modèle défini, débute le travail sur chaque solution métier à mettre en œuvre. On parle de solution : il ne s agit pas en effet de développer une application unique, mais un ensemble de composants (processus, services, IHM 1, etc.) qui seront intégrés et déployés pour répondre au besoin exprimé. Définir une solution, c est en fait définir deux architectures : L architecture applicative (ou architecture de composants) : elle définit l ensemble des composants à développer ou à réutiliser. Chaque composant appartient à un type de composant défini dans le modèle du SI. L architecture de déploiement : elle définit et dimensionne l infrastructure permettant d exécuter les composants de l architecture applicative. Elle définit également comment les composants de l architecture applicative sont déployés sur cette infrastructure. 1. IHM : Interface homme-machine.

67 5.2 Étape 1 : modéliser l architecture du SI modernisé Construire une architecture performante Quelles sont alors les trois étapes de la démarche «architecture et performance»? La première étape met en évidence, dès la modélisation du SI, l un des risques architecturaux, sinon le risque majeur, sur le plan des performances : la «traversée des frontières». La deuxième étape consiste à raffiner le modèle d architecture, en choisissant un «pattern architectural» destiné à minimiser le risque évoqué ci-dessus. Le chapitre présente donc quelques patterns architecturaux majeurs. Enfin, la troisième étape consiste à traquer les risques résiduels en repérant les anti-patterns de performance, qui sont présentés dans les derniers paragraphes du chapitre. On remarquera que la méthodologie de construction de l architecture met également en évidence une étape de mise en place de frameworks et composants réutilisables. Les anti-patterns de performance s appliquent également à ces outils de base. 5.2 ÉTAPE 1 : MODÉLISER L ARCHITECTURE DU SI MODERNISÉ Cette section présente un modèle d architecture logique générique et en dévoile le risque architectural majeur Les contraintes du SI L architecture d un système d information modernisé doit répondre aux différentes contraintes que rencontre une entreprise de ce début de XXI e siècle : Ouverture du système d information à l écosystème de l entreprise. Dématérialisation des événements métier échangés entre l entreprise et cet écosystème. Traitement en temps réel des événements métier. Flexibilité du système d information vis-à-vis de l évolution des produits, de l organisation, de la réglementation, etc. L ouverture du système d information L ouverture du système d information permet à l entreprise de dialoguer plus facilement avec ses clients, prospects, partenaires commerciaux, fournisseurs, autorités de régulation, etc. Elle repose sur la dématérialisation de plus en plus systématique des événements métier reçus ou émis par l entreprise. Par événements métier, on désigne les requêtes adressées par l écosystème à l entreprise (envoi d une commande par exemple), les réponses émises par l entreprise (facture émise), ou les événements

68 50 Chapitre 5. Les enjeux architecturaux de la performance spontanément émis par l entreprise (envoi d un message signalant le retrait d un produit du catalogue). Dans notre exemple «Fil Rouge», les événements entrants seront par exemple une demande de devis envoyée par mail par un client, l envoi d une commande via un message XML par le SI de ce client, la consultation de l avancement de la commande via le Portail, ou l enregistrement d une réclamation (parce qu un produit commandé est arrivé en mauvais état) via le call center. Les événements sortants seront par exemple l émission d une facture XML, l envoi d un signal d alerte signalant le retrait d un produit du catalogue de l entreprise, ou l envoi par mail des promotions du jour sur tel ou tel produit. La dématérialisation des événements métier et leur traitement en temps réel Les événements métier sont de plus en plus numérisés, du fait de la généralisation de l usage d Internet (portail, messagerie XML, mail, etc.) pour les interactions commerciales, marketing ou financières. Quant aux supports traditionnels, courrier papier comme conversations téléphoniques, ils sont eux-mêmes numérisés à la volée, via la GED pour le papier, via les call center ou les serveurs vocaux pour la voix. Comme l a rappelé la première partie, cette dématérialisation a de multiples avantages, ce qui explique son succès. Elle facilite notamment la réactivité commerciale vis-à-vis du client : on parle d entreprise temps réel. Le temps réel dont on parle ici concerne l échelle humaine des traitements. La performance du SI et sa robustesse conditionnent bien évidemment le respect de cette exigence de temps réel, comme l a rappelé la première partie. Par ailleurs, cette dématérialisation permet l historisation des événements métier liés à un même client, et il devient ainsi possible de détecter des opportunités supplémentaires de vente de produits et services. On remarquera que ces contraintes pèsent de la même façon sur des organisations et structures publiques ou para-publiques. Dans le cas d une structure publique, on parle d usager et non plus de client, de «guichet unique pour le citoyen» et non plus de «portail e-business pour le client et prospect», etc., mais la logique d évolution du SI reste identique Modèle d architecture logique La figure 5.2 présente un modèle d architecture d un SI répondant à ces différentes contraintes. Il s agit d un modèle logique d architecture, c est-à-dire d un modèle qui se limite dans un premier temps à identifier les différents types de composants de l architecture. Ce modèle ne se préoccupe pas d aspect logiciel (choix d un environnement Java ou.net, par exemple), ni d aspect matériel (ce n est pas une architecture de déploiement).

69 5.2 Étape 1 : modéliser l architecture du SI modernisé 51 GESTION DES ÉVÉNEMENTS ENTRANTS Application interactive de type portail S erveur de réception de message (fichier, mail ) Web service (façade) d accès au S I Call Center SERVICES TECHNIQUES SERVICES MÉTIER PROCESSUS MÉTIER Traitement automatisé asynchrone Application interactive Service applicatif S ervice fonctionnel Service C R UD (entité) Service technique Service technique Serveur d envoi de message Infos non structurées B ases de données Figure 5.2 L architecture d un SI modernisé Cette architecture est décomposée en couches et est SOA 1. Une couche offre en effet un ou plusieurs services à la couche supérieure et fait appel aux services de la couche inférieure. 1. Le lecteur intéressé par une description plus précise de l approche SOA pourra se reporter à la référence [FournierMorel2006].

70 52 Chapitre 5. Les enjeux architecturaux de la performance Les couches du modèle d architecture SOA Ces couches sont : Les principes SOA Couche «gestion des événements métier entrants/sortants» : son rôle est de gérer et d archiver les événements échangés par l entreprise, et de les transmettre à la couche «applications:composites». Couche «applications composites» : au sein de cette couche, les processus métier ont pour rôle de traiter les événements entrants, en orchestrant les interventions des acteurs humains et des acteurs automatisés. Les acteurs humains utilisent des applications interactives. Processus et applications interactives font appel aux services métier. Un processus automatisé (processus e-business) se présente comme un service pour la couche «gestion des événements» 1. Couche services métier : les services métier encapsulent la logique métier et l accès aux informations métier. Ils obéissent ainsi à une logique de modularité logicielle et à une logique de réutilisation pour certains d entre eux. Couche services techniques : les services techniques encapsulent des traitements transverses, réutilisables par les autres couches. Ce sont par exemple : un service de log, un service de génération de document (PDF, XML, CSV, etc.), un service d envoi de message électronique. Ce peut être également un service de mapping objet-relationnel facilitant l accès aux bases de données SQL. Couche base de données. La couche services métier distingue elle-même plusieurs types de services : Les services applicatifs, ou service façade d exécution d une tâche, qui font appel aux services suivants : Les services fonctionnels, ou services d exécution de règles métier. Les services CRUD, ou services d accès aux entités métier. Les principaux principes de conception d une architecture à base de service sont les suivants : Principe de contractualisation : un service propose à ses clients un contrat clairement défini, listant les requêtes qu il accepte et précisant les informations d entrée et de sortie. Principe d encapsulation : un service masque la façon dont il répond aux requêtes de ses clients. Autrement dit, un client doit se satisfaire de la description du contrat pour utiliser le service, il n a pas besoin d en connaître l implémentation. 1. Plus exactement, c est le gestionnaire de processus (moteur BPEL ou équivalent) qui se présente comme un service pour les composants (portail, serveur de messages XML, etc.) de la couche «gestion des événements entrants». Le chapitre 7 reviendra sur ce point plus en détail.

71 5.2 Étape 1 : modéliser l architecture du SI modernisé 53 Principe de simplicité : un service est «sans état» : lorsqu il répond à un client, il ne tient pas compte des échanges précédents avec ce client. Principe d autonomie : un service ne doit pas dépendre d un autre service de même nature pour répondre à une requête. Par exemple, un service CRUD (service permettant de rechercher, lire et écrire les informations associées à une entité métier : par exemple, service d accès au catalogue, service d accès aux clients, etc.) ne doit pas appeler un autre service CRUD. Principe de délocalisation : la réponse d un service à une requête d un client ne doit pas dépendre de sa localisation. Ce principe peut aussi se comprendre de la façon suivante : le client ne doit pas connaître à l avance la localisation des services qu il appelle, mais doit faire appel à un service de localisation qui lui fournit les informations nécessaires. Le modèle adapté aux SI en «silos» Ce modèle ne suffit pas nécessairement pour représenter un SI très hétérogène, organisé par silos métier, ce qui est souvent le cas des très grandes entreprises. Il est nécessaire de prévoir alors une couche de communication entre ces silos, afin de faciliter la mise en place de processus transverses, comme l illustre la figure 5.3. GESTION DES ÉVÉNEMENTS ENTRANTS PROCESSUS MÉTIER TRANSVERSES Bus d entreprise (ESB) (web) service d accès au silo (web) service d accès au silo (web) service d accès au silo Figure 5.3 Modernisation d un SI «en silos» Le risque majeur : le passage de frontière Du point de vue des performances, le risque majeur très général, identifié à ce stade, concerne la communication entre les différentes couches repérées par les modèles présentés ci-après (figures 5.2 et 5.3).

72 54 Chapitre 5. Les enjeux architecturaux de la performance Risque général : la traversée de frontières peut être très coûteuse en performance. Il s agit d enfoncer une porte qui se referme régulièrement sur les doigts des informaticiens, en rappelant simplement que cette traversée active en effet un grand nombre de composants : composants métier certes, mais aussi composants logiciels de base (middleware : web service, EJB 1 ; couche de sécurité : chiffrement, gestion de jeton, etc.) et composants matériels (routeurs, cartes réseau, etc.). L architecte doit donc se muer en douanier afin de surveiller de près la communication entre couches. Une première conséquence est qu il faut minimiser les frontières physiques : «traverser le réseau», autrement dit distribuer des composants sur différents serveurs, est un risque important sur les performances. Contrairement à certaines affirmations, «le réseau n est pas gratuit» et le chapitre 10 montrera pourquoi. Le paragraphe suivant présente les patterns architecturaux permettant de maîtriser ces passages de frontière physique. 5.3 ÉTAPE 2 : CHOISIR LES PATTERNS D ARCHITECTURE Mieux vaut prévenir que guérir, dit l adage populaire. Choisir des patterns de performance c est donc tenter de prévenir les problèmes de traversée de frontière ; de façon plus modeste, c est provoquer très en amont la réflexion sur les performances. Nombre de patterns de performance sont en réalité applicables à des niveaux très différents d un système d information (infrastructure matérielle, architecture technique ou logicielle). En voici trois qui nous paraissent particulièrement importants La redondance L un des patterns de performance les plus simples est la mise en place d une redondance des données. Il existe effectivement une dualité fondamentale entre la nonredondance des données et les performances d un système. Une base de données complètement normalisée par exemple, exigera en contrepartie davantage d opérations pour manipuler les données en question. Inévitablement, le niveau de performance en pâtira. À l inverse, un moyen simple d améliorer les performances d un système consiste à pré-calculer une proportion significative de résultats plutôt que de les calculer à la volée au moment où la requête est effectuée. Une forme extrême de dénormalisation est d ailleurs mise en œuvre aujourd hui dans certains systèmes distribués tels que certains entrepôts de données nonrelationnels. Il faut bien prendre conscience cependant qu un surcroît de redondance exigera, parallèlement, une vigilance accrue quant aux sources possibles d inconsistance. Des mécanismes automatiques devront détecter et palier systématiquement aux éventuelles inconsistances entre les diverses versions de données. 1. EJB : Enterprise Java Bean.

73 5.3 Étape 2 : choisir les patterns d architecture 55 Par exemple, lorsqu il s agit de gérer des copies locales d objets métier au sein d un cluster de machines, c est la couche d infrastructure logicielle, nommée serveur d application, qui prendra en charge cette redondance. La mise en œuvre de mécanismes de redondance robustes relève le plus souvent d algorithmes complexes et spécialisés qui ne sont pas du ressort d un développeur métier. L erreur à éviter en l occurrence est de redévelopper manuellement des mécanismes de redondance mis à disposition par les éditeurs de bases de données ou de serveur d applications. En un mot, la gestion de la redondance, comme celle de la sécurité, ne peut relever du simple bricolage de développeur débutant : il faut connaître et utiliser les mécanismes mis à disposition par ailleurs Mécanisme de chargement paresseux Au niveau d une architecture logicielle, le chargement paresseux, lazy loading en anglais, est un pattern d architecture particulièrement efficace qui permet de ne charger en mémoire vive que le strict minimum des données nécessaires à un traitement. Il existe en réalité de nombreuses situations où ce pattern s applique. La conversion de données extraites d un ensemble de tables d une base relationnelle en objets métiers codés dans un langage de programmation objet (on parle alors de «mapping objet-relationnel») en constitue un bon exemple. À titre d illustration, imaginons que l on souhaite charger en mémoire les données d un client. Outre le nom et le prénom du client, celles-ci comprennent typiquement ses adresses privées et professionnelles, ses coordonnées bancaires et la liste de ces derniers achats. Une solution grossière et peu performante consisterait à créer une grappe d objets qui encapsule la totalité de ces données. Pourtant, dans les cas défavorables, si le client a effectué de nombreux achats par exemple, un chargement complet des données pourrait s avérer extrêmement coûteux en ressources mobilisées. Typiquement, de nombreuses requêtes SQL complexes seront générées, alors même qu une part significative des données ainsi chargées sera inutile dans les traitements qui suivent. C est là qu intervient le lazy loading : le chargement effectif des données en mémoire n interviendra qu au dernier moment, lorsque celles-ci seront réellement nécessaires à la poursuite du traitement. Comme pour les mécanismes de réplication, la programmation explicite d un mécanisme de lazy loading est extrêmement délicate. En réalité elle n est pas du ressort d un développeur d applications métier. Le plus souvent, il s agira pour ceux-ci de bien maîtriser les tenants et aboutissants des options de paramétrage offertes par les outils qu ils utilisent Simplicité Nombre de problèmes de performances sont aujourd hui liés à une complexité mal maîtrisée des systèmes. Celle-ci, en effet, a tendance à croître à mesure que s accumulent les évolutions exigées par l ouverture du système d information, par son adaptation à des besoins métiers en constante évolution et, souvent aussi, par une charge utilisateur croissante.

74 56 Chapitre 5. Les enjeux architecturaux de la performance Une autre cause d augmentation de la complexité des systèmes informatiques, plus pernicieuse celle-là, est paradoxalement la conséquence d une disponibilité d importantes ressources matérielles et logicielles. Qui dit disponibilité bon marché de ressource dit, par la même occasion, gaspillage de ces ressources. Ceci vaut particulièrement au niveau de l architecture logicielle qui accumule aujourd hui sans compter les couches et les mécanismes d encapsulation. Utilisés à bon escient, ces mécanismes (on parle à ce titre des frameworks) permettent de masquer une partie de la complexité inhérente aux tâches les plus techniques. Les frameworks de mapping O/R mentionnés au paragraphe précédent en constituent d ailleurs une bonne illustration. Ils prennent en charge la génération de code SQL et les mécanismes de chargement paresseux. Pour autant, une utilisation irréfléchie de ces mécanismes de génération de code pourra porter préjudice aux performances car ils mettent en œuvre des ressources disproportionnées lorsque les tâches sont élémentaires. Trop souvent aujourd hui les frameworks sont utilisés comme palliatif à l absence de conception et de compréhension globale des problèmes à résoudre. Ceci est particulièrement vrai pour des développeurs débutants lorsqu ils sont livrés à eux-mêmes dans des environnements de travail déstructurés. Pour qui sait y regarder de près cependant, les gains de performance potentiels liés à une simplification du code sont particulièrement importants. Plus généralement, le souci constant de simplicité et d économie de moyen contribuera à rendre une architecture plus intelligible et donc plus flexible dès lors qu il s agira d optimiser ses performances Patterns SOA On distingue trois patterns architecturaux de mise en œuvre de l approche SOA, en abrégé «patterns SOA», ayant chacun pour objectif la conception et le déploiement de services. Ces patterns sont présentés dans le tableau 5.1. Le chapitre 7 revient plus en détail sur les avantages et inconvénients de ces différentes approches SOA.

75 5.3 Étape 2 : choisir les patterns d architecture 57 Tableau 5.1 Les patterns architecturaux Pattern n 1 «ouvrir le SI (Io)» Pattern n 2 «modulariser le SI» Pattern n 3 Web 2.0 Client d un service conçu via le pattern Système d information des partenaires de l entreprise Application composite (processus BPEL, application interactive MVC, batch). Internaute, via des applications de type Web Desktop, Mashup ou Widgets. Caractéristique du service respectant le pattern Service «gros grain», normalisé, distribué, avec une garantie de sécurité et de robustesse, et éventuellement de performance. Service «gros grain» et «grain moyen», normalisé. La distribution doit être possible mais elle n est pas nécessaire. La sécurisation n est pas indispensable (dialogue client/service interne au SI). Service de type «flux d information» (accès à des news, des entrées de blog, des pages Wiki, etc.) Modalité d accès au service Synchrone lorsque le service est accédé via Internet. Asynchrone lorsque le service ouvre un silo (cf. figure 2). Synchrone lorsqu il s agit d un service métier ou d un service technique. Asynchrone lorsqu il s agit d un processus. Synchrone. Format de description du service et des opérations qu il offre Norme WSDL. Interfaces JAVA ou C#. Standard de fait REST (formalisé via le protocole ATOM par ex.). Format des informations échangées entre client et service Protocole de communication réseau Document XML (respectant un schéma de référence) contenant des informations structurées (objets métier). SOAP sur http ou sur un autre protocole (FTP, JMS, etc.) Objets (éventuellement sérialisés). Les services sont colocalisés : pas de distribution a priori. En cas de nécessité, on utilise RMI (via des EJB Session) ou JMS (via des MDB a ) dans le monde Java, MSMQ dans le monde. NET. Document XML, associé à des pièces jointes (informations) non structurées : pages XHTML, document PDF, etc. HTTP «de base» Container de service Axis, Xfire, etc. Spring. Serveur EJB3 (avec ou sans distribution). Toute application sachant répondre à des requêtes REST (gestionnaire de blog respectant RSS ou ATOM par exemple).

76 58 Chapitre 5. Les enjeux architecturaux de la performance Tableau 5.1 (suite) Exemple d utilisation du pattern architectural Dans l exemple «Fil Rouge» : la plate forme centralisée publie un web service de réception de commande, un web service de demande de devis, etc. En reprenant l exemple «Fil Rouge» : le web service de réception de commande crée pour chaque nouvelle commande un processus de traitement «traiter commande». Puis, ce processus appelle des services applicatifs, colocalisés. De même, ces services applicatifs appellent des services CRUD accédant aux bases de données. Ces services CRUD sont colocalisés avec les services applicatifs (c est à dire qu ils sont déployés dans le même serveur d application JAVA). Dans l exemple «Fil Rouge» on pourrait imaginer qu avant de passer commande, un magasin client consulte un catalogue de produits proposé sur un portail mis en place par Fil Rouge. Ce catalogue agrège les informations de plusieurs fabricants. Pour cela, les informations sont fournies par chaque fabricant sous forme de flux ATOM à partir de son propre catalogue. a. Message Driven Bean. 5.4 ÉTAPE 3 : DÉTECTER LES ANTI PATTERNS DE PERFORMANCE Adopter le bon pattern architectural est nécessaire, mais ne suffit pas à garantir un bon niveau de performance architecturale. Le modèle d architecture et les patterns associés donnent les lignes directrices, mais ne conçoivent pas le détail des services et des applications clientes de ces services. Or, le diable se niche dans les détails et il est nécessaire de continuer le travail sur les performances au niveau de chaque architecture applicative. Le paragraphe présente les principaux syndromes, ou anti-patterns, que l on peut rencontrer en construisant une solution applicative selon le modèle du SI modernisé. La figure 5.4 met en relation modèle d architecture et anti-patterns.

77 5.4 Étape 3 : détecter les anti patterns de performance 59 GESTION DES ÉVÉNEMENTS ENTRANTS Anti-pattern : la traversée des frontières PROCESSUS MÉTIER Anti-pattern : le goulet d étranglement Anti-pattern : la mitrailleuse à requêtes SERVICES MÉTIER Anti-pattern : la cascade Anti-pattern : la requête mammouth SERVICES TECHNIQUES INFORMATIONS & RÉFÉRENTIELS Figure 5.4 Localisation des risques L exemple «Fil Rouge» Pour présenter les anti-patterns, et plus généralement pour servir de point d appui concret aux différents chapitres de cette partie, il paraît utile de se doter d un exemple précis, l exemple «Fil Rouge» présenté dans l introduction de cette partie. La figure 5.5 présente une architecture possible pour installer la solution «plateforme nationale de gestion de commande» de l entreprise Fil Rouge. Cette plate-forme comprend : deux points d entrée : une application interactive de gestion de commande et un (web) service d envoi automatique de commande (sous forme de message XML) ; un processus : le processus de traitement de commande, accessible sous forme de service métier ; deux services métier de type CRUD : le service d accès au catalogue des produits et le service d accès à la gestion de stock.

78 60 Chapitre 5. Les enjeux architecturaux de la performance S.I. Client DMZ Application Application Point Point d entrée SI Site national Point d entrée WS <CRUD> <CRUD> Service métier Service métier CATALOGUE CATALOGUE <TECH> <TECH> MappingO/R Mapping O/R <PROCESSUS> <PROCESSUS> Service métier TRAITER UNE COMMANDE S.I. Entreprise Fil Rouge Point Point d entrée WS <CRUD> <CRUD> Service métier Service métier STOCK STOCK <TECH> <TECH> Accès Accès Legacy Site local SGBDR LEGACY Figure 5.5 Une architecture possible pour l exemple «Fil Rouge» Quel est le rôle des points d entrée? L application interactive permet à un gestionnaire de magasin de passer une commande (par exemple une commande spéciale, une commande en urgence, etc.) et de visualiser l état du traitement, par le grossiste, des commandes déjà envoyées (commande prise en compte, commande dispatchée vers les entrepôts, commande envoyée aux transporteurs, commande en cours d acheminement, etc.). Le web service de prise de commande mis en place par le grossiste permet au système de gestion des stocks de chaque magasin de lancer automatiquement une commande d approvisionnement. Les points d entrée sont installés dans une DMZ pour des raisons de sécurité. En conséquence, les services métier accédés par ces points d entrée sont déployés sous forme de web service, afin de faciliter le passage du firewall isolant la DMZ du reste du SI. Le processus de traitement de commande utilise plusieurs services CRUD 1 d accès aux entités métier : client, commande, catalogue, stock, transport, etc. L architecture 1. CRUD signifie Create/Retrieve/Update/Delete. Il s agit donc d un service offrant toutes les opérations de recherche et de manipulation des instances d une classe métier (par exemple : le contrat, le produit, la facture, etc.).

79 5.4 Étape 3 : détecter les anti patterns de performance 61 présentée ici n en retient que deux, particulièrement représentatifs (service CRUD «catalogue» et service CRUD «stock»), pour éviter de noyer le lecteur dans des détails inutiles. La solution est déployée sur un site national (comprenant les points d entrée, le service de traitement des commandes et le service d accès au catalogue) et des sites locaux (service d accès aux stocks, qui sont gérés sur une informatique legacy de gestion des entrepôts régionaux, legacy installé sur un AS/400 par exemple). Le service d accès aux stocks est donc cloné sur chaque site local, et assure l encapsulation des accès au système legacy Le syndrome de la cascade Description Forces Risque 1 : le client attend trop longtemps la réponse du service appelé : syndrome de la cascade. Il est important de voir que cette attente peut être due (i) soit au service appelé lui-même (c est-à-dire à sa conception ou à sa programmation), (ii) soit au fait que ce service fait lui-même appel à d autres services qui eux-mêmes font appel à des services qui à leur tour, etc. : c est ce phénomène de cascade d appel de services qui est plus précisément pointé ici. Une cascade n est pas nécessairement un mal en soi. En effet, un système d information ne doit pas seulement être performant ; il doit également satisfaire d autres critères, comme la facilité d évolution et de maintenance qui induit une recherche de modularité maximale. Cette modularité est l une des raisons fondamentales incitant à mettre en place une SOA, concrétisée par une hiérarchie de services, telle que celle esquissée précédemment : cette hiérarchie induit nécessairement des appels en cascade. En fait, le problème ne vient pas de la cascade elle-même, mais de la façon dont les services dialoguent entre eux. Si chaque service est implémenté sous forme de web service, cela signifie que chaque appel de la cascade se traduit au minimum par une double conversion objet > XML (dans le service appelé) puis XML > objet (dans le service appelant). Chaque appel se traduit également par la traversée d une couche middleware. Ces différentes étapes, comme on le verra au chapitre 7, sont potentiellement coûteuses, et ce sont elles qui rendent la cascade dangereuse.

80 62 Chapitre 5. Les enjeux architecturaux de la performance Éléments de solution Il est donc indispensable de dissocier l approche SOA de l approche web service, en respectant le principe suivant : Mettre en place une architecture de services n implique pas de distribuer la totalité de ces services. En particulier, l obtention de services modulaires et réutilisables dans une SOA n implique pas l utilisation systématique de web service. Il s agit donc de faire une distinction forte entre le pattern 1 et le pattern 2 présentés dans le tableau 5.1. Le remplacement de web services par des EJB Session (dans le monde Java) n est donc pas nécessairement une réponse satisfaisante, dans la mesure où il peut y avoir également un coût de traversée de frontière. L objectif sera donc de mettre en place, autant que possible, des services sous forme de simples objets, POJO 1 dans le monde JAVA ou POCO 2 dans le monde.net. Seuls les services applicatifs auront vocation à être distribués sous forme de web service. Plus précisément, un même service pourra avoir plusieurs versions de déploiement, par exemple : une version POJO : cette version peut être incluse dans un service applicatif de plus gros grain (par exemple : un service de vérification de la validité d une commande), car elle est plus performante ; une version EJB Session : cette version est ainsi accessible au sein des différents silos fonctionnels du SI ; et une version web service, pour permettre une ouverture du service aux partenaires extérieurs à l entreprise, ouverture fortement sécurisée de surcroît. Conseil : pour éviter le syndrome de la cascade, il faut pouvoir déployer un service sous une forme standard, et (si besoin) sous une forme distribuée. Dans l exemple «Fil Rouge», cela pourrait impliquer que le service CRUD d accès aux produits du catalogue soit cloné/déployé en deux instances, chacune des instances attaquant la même base de données. La première instance, directement utilisée par le processus de traitement de commande, serait déployée sous forme d EJB Session voire sous forme d un simple POJO. L autre instance, accédée par l application Portail située en DMZ, serait déployée sous forme de web service pour faciliter son accès. Cela suppose que le moteur de gestion de processus, utilisé pour automatiser le processus de traitement de commande, et basé sur BPEL (dans un contexte SOA), soit capable d accéder directement à des services de type POJO. Certains moteurs le permettent, d autres non. 1. POJO : Plain Old Java Object. 2. POCO : Plain Old C# Object.

81 5.4 Étape 3 : détecter les anti patterns de performance Le syndrome de la mitrailleuse à requêtes Description Forces Risque 2 : le client doit appeler trop souvent un service fournisseur pour effectuer son propre travail > on parle du syndrome de la mitrailleuse à requêtes. Une application ou un service client invoque de nombreuses fois un même service fournisseur au sein d un même traitement. Bien que, individuellement, chaque invocation soit performante, la multiplication par 10, 20 ou 30 de la même invocation conduit le client à présenter un temps d exécution rédhibitoire. Un exemple permet de bien comprendre ce syndrome. Dans le cas de l exemple «Fil Rouge», il est intéressant d analyser à nouveau le service de gestion du catalogue de produits. Ce service offrira au minimum deux opérations : une opération de lecture d une rubrique du catalogue : l opération accepte en entrée l identifiant d une rubrique et retourne la liste des identifiants des produits contenus dans cette rubrique (en fait, elle retournera probablement une liste de doublets (identifiant du produit description très synthétique du produit)) ; une opération de lecture des caractéristiques d un produit : l opération accepte en entrée l identifiant d un produit, et retourne la description complète du produit. Un use case du portail fait apparaître le besoin suivant : permettre à un utilisateur de sélectionner plusieurs produits de la même rubrique (sans limitation) et d accéder à un comparatif de ces produits. Il y a alors risque de mitrailleuse à requêtes, puisque l application cliente, en l occurrence le portail, devra accéder à l opération de lecture de produit autant de fois qu il y aura de produits sélectionnés par l utilisateur. Ce syndrome est moins aisé à détecter que le syndrome de la cascade, car il dépend non pas de la conception de l architecture elle-même, mais de l utilisation de cette architecture au sein des use case de la solution. Il provient souvent d une conception incomplète du service fournisseur : plus précisément, une opération est inadéquate ou manquante. Seule une analyse fine des use case de l application peut mettre en évidence l inadéquation ou l incomplétude du service. Éléments de solution De façon générale, combattre ce risque implique de respecter le principe suivant : Lorsqu on traverse une frontière client/fournisseur, le client doit autant que possible n adresser qu une requête (logique) à son fournisseur, et recevoir en retour une seule réponse (logique). Il est question de requête et de réponse logique, car c est aux couches basses (middleware) d éventuellement découper cette requête et cette réponse en trames

82 64 Chapitre 5. Les enjeux architecturaux de la performance réseaux physiquement aptes à circuler sur un réseau IP, et ce de façon transparente pour les développeurs des composants logiciels métier «client» et «service fournisseur». Conseil : pour minimiser le risque de mitrailleuse à requêtes dans les services CRUD, il faut inclure dans les contrats de ces services, des opérations permettant de lire et écrire des objets «en groupe» et non pas à l unité. Dans l exemple présenté ci-dessus, il faut prévoir une opération de lecture «en bloc» d une liste de produits : l opération prend en entrée non plus un identifiant de produit, mais une liste (bornée) d identifiants de produit : ceci permet de respecter le principe de minimisation des échanges édicté ci-dessus Le syndrome de la requête mammouth Risque 3 : le service appelé renvoie un bloc trop important d information > on parle du syndrome de la requête mammouth. Description Forces Le service, en général un service CRUD, présente de mauvaises performances, car il recherche et renvoie une collection d objets ou un document XML hypertrophié, c est-à-dire contenant «trop d information» par rapport au besoin réel du client. Cette situation peut survenir quand l ensemble des objets métier manipulés dans la solution constitue un graphe d objet complexe. Dans notre exemple, l objet «commande» est relié à une collection de «lignes de commande», chaque objet «ligne de commande» est associé à un objet «description du produit commandé» et à un ou plusieurs objets «bon de livraison», etc. Que se passe-t-il alors lorsque l application cliente du service CRUD d accès aux commandes demande la commande n xxx? Si le service parcourt le graphe, en «suivant les relations» entre objets, il risque de récupérer l ensemble des objets qui sont reliés à la commande et, de fil en aiguille, de récupérer une bonne partie de la base de données! Si, de plus, le graphe est cyclique, le service risque tout simplement de boucler ou de planter. Éléments de solution Deux solutions sont possibles. La première consiste à prévoir autant d opérations de lecture qu il y a de cas d utilisation. Dans l exemple cité, cela signifie qu il faudra (i) une opération de lecture de la commande, (ii) une opération de lecture de la commande et de ses lignes de commande, (iii) une opération de lecture de la commande, des lignes de commande, des produits associés, etc. C est-à-dire autant

83 5.4 Étape 3 : détecter les anti patterns de performance 65 d opérations qu il y a de parcours possibles du graphe des objets métier rattachés à la commande. Cette solution n est pas très satisfaisante car elle risque de conduire à l hypertrophie du service concerné, c est-à-dire à la multiplication incontrôlée des opérations offertes par ce service. La performance du service s obtient alors au détriment des exigences de maintenabilité et de réutilisabilité dudit service, ce n est pas un très bon compromis. La seconde solution consiste à appliquer le pattern scénario, que l on peut résumer comme suit : Conseil : pour éviter le syndrome de la requête mammouth, le client du service CRUD spécifie explicitement au service les objets qu il souhaite récupérer. Ce pattern sera expliqué plus en détail dans le chapitre 6, consacré aux services Le syndrome du goulet d étranglement Description Forces Le service déployé présente de mauvaises performances, car il est soumis à de trop nombreuses requêtes : il constitue de fait un «goulet d étranglement» dans le système. Ce syndrome est en général nettement aggravé, si le service est accédé via une «traversée de frontière» physique. Un exemple permettra d illustrer le syndrome. Dans l exemple «Fil Rouge», est mis en place un service métier permettant d accéder à ce qu on appelle classiquement la «synthèse client», c est-à-dire l ensemble des informations qui permettent de comprendre rapidement qui est ce client, et quelle est sa situation vis-à-vis de l entreprise (dernières commandes en cours, état des commandes non encore livrées, dernière facture non payée, etc.). Ce service sera sollicité par de nombreuses solutions : la solution portail de commande, la solution plate-forme de commande (vérification automatisée de l absence de contentieux), la solution call center, la solution gestion commerciale (qui permet à un commercial de vérifier la situation de ses clients et de mettre à jour la prospection), etc. S il n existe qu un seul exemplaire déployé du composant logiciel «service synthèse client», ce composant risque bien d être un goulet d étranglement. Éléments de solution Il existe trois solutions complémentaires : accélérer l accès au service si celui-ci est un web service ; dimensionner convenablement le matériel supportant le composant logiciel ; cloner le service, c est-à-dire déployer autant d exemplaires du composant logiciel qu il existe de solutions clientes.

84 66 Chapitre 5. Les enjeux architecturaux de la performance Les accélérateurs d accès aux (web) services seront présentés dans le chapitre 6. Un dimensionnement correct peut impliquer le recours à des solutions de cluster, ces solutions seront présentées dans le chapitre 12. Le clonage du service peut se faire avec ou sans clonage de la base de données associée, comme l illustre la figure 5.6. client1 client2 client3 Service client1 client2 client3 client1 client2 client3 Clone1 Clone2 Clone3 Clone1 Clone2 Clone3 synchronisation Figure 5.6 Clonage du service Si le clonage du service proprement dit est lié à la performance, le clonage de la base de données associée est plutôt lié à une exigence de robustesse. Si la base de données existante n offre pas le niveau de robustesse nécessaire, alors une nouvelle solution (par exemple, une plate-forme de traitement automatique de commandes ouverte 24 h/24) aura intérêt à travailler sur un clone de la base de données, afin de garantir le niveau de robustesse nécessaire. Ce clonage implique la mise en place d un composant de gestion de la duplication des mises à jour entre les différents clones de la base de données. Ce composant introduit à son tour une problématique de performance, en fonction des exigences des différentes solutions en matière de «fraîcheur» des données accédées. Si une solution ne peut supporter d avoir des données désynchronisées, cela implique que les modifications introduites par les autres solutions soient propagées au fil de l eau, «en temps réel». Le goulet d étranglement est d autant plus pernicieux que des tests d intégration, le plus souvent en volumétrie réduite, ne permettent pas de le détecter facilement. Sans précaution, ce syndrome se déclenche en production, lors d une montée en charge

85 5.4 Étape 3 : détecter les anti patterns de performance 67 progressive, voire quelquefois plusieurs années après un démarrage, entraînant une chute brutale du système. Conseil : ne PAS négliger les tests de préproduction, c est-à-dire des tests effectués avec une volumétrie représentative ET dans le cadre d une architecture SI représentative (multi-utilisateurs/multi-applications clientes) Conclusion La figure 5.7 récapitule les risques que nous venons de décrire dans ce chapitre. Les chapitres suivants vont approfondir certains de ces risques, en les détaillant et en approfondissant les éléments de solution déjà abordés. S.I. Client Application Anti-pattern : le goulet d étranglement Point d entrée SI <PROCESSUS> Service métier TRAITER UNE COMMANDE Point d entrée WS <CRUD> Service métier CATALOGUE <TECH> Mapping O/R SGBDR Anti-pattern : la mitrailleuse à requêtes Anti-pattern : la cascade Anti-pattern : la requête mammouth Point d entrée WS <CRUD> Service métier STOCK <TECH> Accès Legacy LEGACY Figure 5.7 Les risques de l architecture «Fil Rouge»

86 68 Chapitre 5. Les enjeux architecturaux de la performance En résumé Ce chapitre a présenté une démarche générale d analyse des risques liés spécifiquement à la conception d une architecture du système d information. Cette démarche comprend trois étapes : (1) adopter un modèle du SI, (2) choisir le ou les patterns d architecture pertinents, et (3) analyser les risques, c est-à-dire repérer les anti-patterns de performance. Sur le plan méthodologique, il importe donc, dès le démarrage de l étude d architecture, de définir la check-list des risques à maîtriser, risques qui devront faire l objet d une revue spécifique.

87 6 Performances des services d une SOA Objectif Les services constituent un élément clef d une SOA, car ils portent les espoirs de modularité du SI, de réutilisabilité de composants, et d homogénéité de l accès aux informations métier. L objectif de ce chapitre est donc de présenter une analyse détaillée de la problématique de performance des services. Ce chapitre passera en revue les principaux problèmes de performance, et présentera les éléments de solution utilisables par un architecte. Le présent chapitre présente les principaux problèmes de performance et de robustesse de conception des services d une SOA. Pour rester concret, le chapitre reprendra d abord l analyse des problèmes potentiels de l exemple «Fil Rouge», tels que synthétisés dans la figure 5.6 du chapitre précédent. On s intéressera donc en priorité à deux anti-patterns : l anti-pattern «goulet d étranglement», qui concerne plus particulièrement le déploiement de web services : c est l objet du premier paragraphe ; l anti-pattern «requête mammouth», qui concerne plus particulièrement les services CRUD : c est l objet du deuxième paragraphe. On s intéressera ensuite à l approche REST, qui est présentée comme une alternative aux web services, en termes de simplicité et de performance. Après avoir brièvement rappelé le fondement de cette approche au travers du protocole le plus

88 70 Chapitre 6. Performances des services d une SOA intéressant (ATOM), on présentera les avantages et inconvénients de cette approche. On conclura sur la problématique de la conception de services robustes. 6.1 LA PERFORMANCE D UN WEB SERVICE : LES POINTS CLEFS Enjeux Que se passe-t-il lorsqu un client envoie une requête à un service métier distant, service publié et déployé sous forme d un web service? Quelles sont les différentes étapes de traitement de cette requête? Quels sont les goulets d étranglement potentiels? Par exemple, dans notre exemple «Fil Rouge», que se passe-t-il lorsqu un client envoie automatiquement une commande au web service de réception des commandes? Point d entrée WS S.I. Client DMZ Portail Point d entrée WS Site national Point d entrée WS <CRUD> Service métier CATALOGUE <TECH> Mapping O/R <PROCESSUS> Service métier TRAITER UNE COMMANDE Point d entrée WS <CRUD> Service métier STOCK <TECH> Accès Legacy Site local SGBDR LEGACY Figure 6.1 Optimiser les web services Il s agit ici «d ouvrir le capot», au moins une fois, sur le cheminement de cette requête entre client et service métier, même si bon nombre des étapes de ce cheminement sont prises en charge par des outils, notamment les ESB (ex EAI). Les vendeurs de ces outils n hésiteront pas à en souligner le côté magique, puisqu un «simple» paramétrage permettra de les mettre en œuvre mais un architecte se doit

89 6.1 La performance d un web service : les points clefs 71 d ouvrir le capot au moins une fois, car c est vers lui que se tourneront les regards si des problèmes de performance surgissent. Le service est décrit par un contrat WSDL et activé via le protocole SOAP sur HTTP. On fait de plus l hypothèse (réaliste) que le service se doit d être sécurisé. Ceci implique que le message envoyé par le client au service soit : identifié, ce qui signifie que l en-tête du message doit comprendre un identifiant permettant au service d authentifier l émetteur du message ; chiffré, ce qui signifie que tout ou partie du message doit être chiffré pour assurer la confidentialité des données transportées ; signé, ce qui signifie que le message comporte une signature, c est-à-dire une information permettant au récepteur de savoir (entre autre) si les données ont été corrompues ou non. Il existe de multiples façons d effectuer la sécurisation d un service, d où la nécessité de décrire la politique de sécurité à appliquer à chaque service. Cette politique est décrite via l utilisation de la norme WS-SecurityPolicy. La figure 6.2 illustre le cheminement d une requête émise par un client vers un (web) service. 1 S.I. Client 2 Annuaire des services 20 3 Connecteur WS Service authentification Service décryptage Service validation & traduction 18 & contrôle XML / XML Service routage interne 11 Service archive & audit Annuaire authentification 13 Mapping XML/objet 12 Logique métier du service Figure 6.2 Le cheminement d une requête entre un client et un (web)service Les principales étapes de ce cheminement sont décrites dans le tableau 6.1.

90 72 Chapitre 6. Performances des services d une SOA Tableau 6.1 Le cheminement d une requête d un client vers un service Étape Description du traitement Commentaire 1, 2 Le client, plus exactement l infrastructure web service côté client, accède à un annuaire décrivant le service à invoquer. Cet annuaire contient notamment la politique de sécurité à respecter pour émettre la requête. Cette étape peut être réalisée à compile time (c est le développeur qui prend en compte ces informations) ou à runtime (dans le cas d un appel dynamique). Elle n intervient donc pas forcément dans la problématique de performance. 3 Le client émet la requête identifiée / chiffrée / signée. 4 Le point d entrée dans le secteur de service reçoit la requête et peut la sauvegarder à des fins de robustesse (pour éviter les pertes de message entrant) et d audit (reconstituer la «vie» de la requête pour en tirer des statistiques de performance). Le point d entrée peut également effectuer des opérations techniques, comme décompresser un fichier compressé (le message «SOAP» est en effet une «pièce jointe» d une requête http, et peut à ce titre être compressé par le client). 5, 6, 7 Le serveur procède à la validation de l identité de l émetteur (authentification), puis à la vérification de la signature du message (le message n a pas été corrompu ou modifié pendant son transport). En ce qui concerne l authentification, le serveur accède à un service (annuaire) qui lui permet de vérifier que cette identité est bien valide. 8 Le serveur procède au déchiffrement du message. 9 Le serveur procède à la validation syntaxique de la requête. La requête transporte des informations sous forme d un document XML décrit par un schéma XSD (intégré dans le fichier WSDL). Cette étape de validation consiste à vérifier que le document XML est effectivement conforme à ce schéma (typage des attributs par exemple). 9 (suite) Le serveur procède éventuellement à un transcodage XML/XML. Il n est pas rare en effet que le format XML utilisé pour des échanges entre entreprises obéisse à un standard, mais qu en interne, pour des raisons de commodités, ce soit un autre format qui soit utilisé. Autre cas d utilisation de cette étape : lorsque le client utilise une version x du service, et que, en interne, le service a été upgradé en version x + 1.

91 6.1 La performance d un web service : les points clefs 73 Tableau 6.1 (suite) Étape Description du traitement Commentaire 10 Le serveur reroute la requête via un service de routage interne. L URL «officielle» du service, décrite dans son contrat WSDL, et donc connue et appelée par le client, n est pas nécessairement l URL interne au SI (pour des raisons de sécurité par exemple). D autre part, il est possible que le serveur ESB convertisse l appel synchrone au service en un appel asynchrone via son MOM. 11,12 Le service, plus exactement la logique métier, est enfin invoqué! Cependant, avant l invocation de cette logique métier proprement dite (étape 12), il va falloir procéder à une étape de transformation XML objet (étape 11). En effet, le service est codé dans un langage de programmation, le plus souvent JAVA ou C#. Ce code travaille non pas sur XML mais sur des objets. Il est donc nécessaire de prévoir un outil de mapping, c est à dire de conversion entre le format (texte) XML et le format objet attendu. 13 à 20 Le service renvoie sa réponse, cette réponse va suivre les étapes inverses.

92 74 Chapitre 6. Performances des services d une SOA Chaque étape est potentiellement gourmande en temps CPU! Cet exemple met donc bien en évidence combien il est prudent de ne pas multiplier les services «distribués» afin d éviter l anti-pattern «cascade» (même si certaines étapes sont facultatives au sein d un intranet, telles les étapes sécuritaires). Mais il ne s agit pas non plus de jeter le bébé avec l eau du bain : la mise en place de web services est incontournable, comme le montre l exemple «Fil Rouge». Comment alors éviter le syndrome du goulet d étranglement? Éléments de solution Cette section présente une synthèse des solutions à disposition de l architecte pour éviter ce syndrome. Ces solutions portent d abord sur le temps de réponse unitaire (en combien de temps le service renvoie-t-il la réponse?), et ensuite sur la montée en charge de ce service (combien de requêtes le SI peut-il traiter en 1 minute/en 1 heure?). Chaque solution se concentre sur un problème particulier ; elles sont donc complémentaires. Chaque solution possède également ses contraintes ; elles doivent donc faire l objet d étude d opportunité avant d en valider l usage. Les accélérateurs matériels orientés SOA Principe La plupart des étapes d acheminement d une requête sont génériques : elles ne dépendent pas de la requête proprement dite. On peut donc envisager de les accélérer à l aide de processeurs spécialisés, appelés aussi XML appliance, tels que ceux de la gamme Websphere DataPower d IBM. Ce type de processeur peut être installé de deux façons : soit en frontal : il est installé entre le point d entrée Internet (routeur) et le(s) serveur(s) d applications ; soit en dérivation : il est installé comme coprocesseur du serveur d application, et est appelé en cas de besoin. Un processeur frontal prendra en charge la totalité des étapes présentées ici. Un processeur en dérivation ne prendra en charge que les étapes les plus gourmandes en CPU, afin de soulager le serveur d application. L installation en dérivation peut induire des contraintes de choix : tel processeur ne pourra fonctionner qu avec tel serveur d application. Il convient donc d être prudent dans le choix d une telle solution, d autant que ces solutions sont encore jeunes. Rôle et place de l accélérateur matériel La figure 6.4 montre comment l exemple «Fil Rouge» pourrait bénéficier de la mise en place de tels accélérateurs matériels.

93 6.1 La performance d un web service : les points clefs 75 S.I. Client Annuaire des services Connecteur WS Service authentification & contrôle Service décryptage Service validation & traduction XML / XML Service routage interne Service «archive» & audit Annuaire authentification Mapping XML/objet Logique métier du service Figure 6.3 Rôle et place d un accélérateur matériel S.I. Client Application <PROCESSUS> Service métier TRAITER UNE COMMANDE Point d entrée WS <CRUD> Service métier CATALOGUE <TECH> Mapping O/R S.I. Entreprise Fil Rouge <CRUD> Service métier STOCK <TECH> Accès Legacy SGBDR LEGACY Figure 6.4 Usage d un accélérateur matériel dans l exemple «Fil Rouge»

94 76 Chapitre 6. Performances des services d une SOA En fonction du coût, on pourra limiter leur usage au seul web service ouvert vers Internet, puisque c est à ce niveau que la problématique sécuritaire est certainement la plus critique. Les accélérateurs logiciels orientés SOA : les caches XML Principe Les accélérateurs matériels ne résolvent qu une partie de l anti-pattern «goulet d étranglement», puisqu ils portent sur l acheminement de la requête, mais pas sur l exécution du service lui-même. Or, un service n est pas toujours très rapide, pour au moins deux raisons : le mapping XML objet, qui a un coût en termes de CPU ; cette raison est récurrente (c est-à-dire présente quel que soit le service) ; le mapping objet relationnel, potentiellement coûteux, d autant que l on cumule avec le risque de la «requête mammouth», qui s additionne lui-même au coût d accès à la base de données (c est-à-dire aux disques durs, qui sont les composants matériels les plus lents) ; ceci concerne essentiellement les services CRUD. Bien évidemment, chacun de ces points peut faire l objet d une étude d optimisation spécifique, on y reviendra. Mais, quelles que soient les optimisations apportées, il n en reste pas moins qu invoquer un service reste globalement coûteux en tout cas, plus coûteux que... si on ne l invoque pas. Comment ne pas invoquer un service? En installant un cache XML entre le client et le service 1. Le rôle de ce cache est de stocker systématiquement les réponses fournies par le service : à chaque nouvel appel du service, le cache recherche s il a déjà la réponse. Si oui, il renvoie cette réponse sans invoquer le service lui-même : la performance est effectivement accélérée. Si non, il invoque le service, et il stocke la réponse du service. Les réponses sont stockées directement au format XML, afin d éviter tous les traitements de mapping, d où le terme de cache XML. L efficacité d un tel cache dépend de plusieurs facteurs clefs, qui guideront l architecte dans son étude d opportunité. Tout d abord, le service auquel on associe un cache doit être un service CRUD essentiellement orienté «lecture d information» : si le service est orienté «mise à jour d information», le cache n a aucun intérêt, puisqu il n y a pas de réponse à stocker. En effet, le service répond à son client «OK mise à jour effectuée» ou «KO problème rencontré», mais cette réponse est ponctuelle, elle n a d intérêt que pour un seul client, elle n a donc pas ce qu on appelle de durée de vie : son time-to-live est 0. Admettons maintenant que le service soit orienté «lecture d information». Le cache n aura d intérêt que si chaque réponse du service a une durée de vie suffisamment longue pour intéresser plusieurs clients successifs. Par exemple, la durée de vie de la 1. On voudra bien noter que ce qui suit s applique à tout type de cache, pas seulement aux caches XML.

95 6.1 La performance d un web service : les points clefs 77 cotation d une action de bourse n excédera pas x secondes. La mise en place d un cache associé au service d accès aux cotations n aura d intérêt que s il y a «beaucoup» d appels au service en moins de x secondes. Enfin, le cache ne sera utile que si son utilisation n est pas plus coûteuse que le service lui-même : on a en effet tendance à oublier que le cache est lui-même un composant logiciel, et que ce composant a donc un coût d utilisation en termes de performance. On reviendra un peu plus loin sur ce point crucial mais trop souvent négligé. Implémentation On a vu que la performance intrinsèque du cache est importante : quels sont alors les points clefs de cette performance? La figure 6.5 montre le principe de conception d un tel cache. Il repose sur deux ingrédients : un gestionnaire de cache ; un référentiel local, stockant les informations sous forme XML, accessible via un moteur de requête XQUERY. Client SOAP CACHE XML SOAP <TECH> Gestionnaire du cache Service <TECH> Requêteur XQUERY SGBD XML Figure 6.5 Conception d un cache XML Le gestionnaire de cache a pour rôle de : recevoir les requêtes de lecture adressées au service ; pour chaque requête, rechercher dans le référentiel local si la réponse existe déjà (au format XML) ; si la réponse existe déjà, décider si la réponse est encore valable : [date de création ou de modification de l information] + [time-to-live] > [date courante] si la réponse n est plus valable, la supprimer ;

96 78 Chapitre 6. Performances des services d une SOA s il n existe pas de réponse, ou si la réponse stockée n est plus valable, transmettre la requête au service invoqué ; lorsque le service renvoie la réponse au gestionnaire, celui-ci la stocke dans son référentiel local puis la renvoie au client concerné. Le référentiel local a pour rôle de lire et d écrire les informations au format XML. Pour interroger ce référentiel, il est nécessaire de disposer d un moteur de requête adapté à XML ; on utilisera pour cela XQUERY : en (très) bref, on dira que XQUERY est un SQL adapté à XML. Pour obtenir un cache efficace, la première question clef est de savoir si le référentiel est persistant sur un disque, ou s il réside uniquement en mémoire centrale. Compte tenu des considérations qui précèdent, un référentiel en mémoire sera préférable. La persistance des informations en cache n est pas nécessaire et surtout elle peut rendre le cache inopérant car trop peu performant (cf. section suivante). L autre question clef réside dans la gestion de la durée de vie des informations stockées dans le cache. Qui détermine cette durée de vie? A priori c est au service détenteur de l information de fournir cette information : cela implique alors de modifier le contrat d appel de ce service, pour que la réponse fournie par le service inclût obligatoirement cet attribut. Cependant, il est rare qu un service n offre que des opérations de lecture d informations : il offre souvent des opérations d écriture permettant de modifier ces informations. Dans ce cas, le cache intervient également : lorsqu il reçoit une requête en écriture, il doit regarder si l information transmise (et qui doit modifier la base de données) est déjà en cache. Si oui, alors il doit supprimer cette information 1 avant de transmettre la requête au service appelé. Retour sur les performances Ce qui précède permet de préciser le propos en matière de performance intrinsèque du cache. Soit Tservice le temps d exécution unitaire du service, et Tcache le temps d exécution unitaire du cache. Soit n le nombre d appels au service (donc n est également le nombre d appels au cache) sur une période donnée alors : avec : n = n 1 + n 2 + n 3 n 1 est le nombre de succès d appel en lecture du service, c est-à-dire le nombre de fois où le cache a déjà la réponse (dans le jargon, on parle de nombre de «hits») ; n 2 est le nombre de fois où le cache n a pas la réponse en cas d appel en lecture. Lorsque le cache n a pas la réponse, on suppose que Tcache est le même à l aller 1. Pourquoi le cache ne remplace-t-il pas directement l information en cache par la nouvelle valeur transmise? Parce que ce serait faire l hypothèse que le service va effectivement rendre persistante cette valeur transmise. Or, que se passe-t-il si le service refuse la valeur transmise (pour non conformité à une règle de gestion par exemple), ou ne peut accéder à la base de données à cause d un problème technique momentané? Le cache serait incohérent. Pour des raisons de simplicité, il vaut donc mieux que le cache se contente de supprimer la valeur en cache.

97 6.1 La performance d un web service : les points clefs 79 (examen du référentiel de réponse) et au retour (stockage de la réponse par le cache et renvoi de la réponse) ; n 3 est le nombre d appels du cache en écriture : on suppose pour simplifier que le cache n a un coût qu au moment de l appel du service (invalidation éventuelle de l information en cache), il n intervient quasiment pas au retour du service. Pour que l utilisation du cache soit pertinente, il est donc nécessaire que le coût d utilisation du cache soit (nettement) inférieur au coût d utilisation du service seul : n 1 *Tcache + n 2 *(Tcache(aller)+Tservice +Tcache(retour)) + n 3 *(Tcache(aller) + Tservice) «(n 1 + n 2 + n 3 ) * Tservice ce qui se traduit par : Tcache «[n 1 / (n 1 + 2*n 2 + n 3 )] * Tservice Cette formule, bien qu approximative, confirme que : si le service appelé est très performant, le cache doit donc être encore plus performant puisque la formule ci-dessus suppose que dans tous les cas de figure, on doit avoir Tcache «Tservice ; plus il y a d appels en écriture (n 3 grand donc n 1 petit), moins le cache est intéressant quelle que soit sa performance intrinsèque (Tcache doit se rapprocher de 0!) ; plus le nombre n 1 de succès du cache est faible, quel que soit le nombre d appels, plus la performance du cache doit être là aussi excellente pour être rentable ; plus n et surtout n 1 sont grands, plus le cache peut être rentable. Conseil : la mise en place d un cache doit être associée à un service CRUD utilisé principalement pour des lectures d information. L utilité du cache est conditionnée à la fois par son efficacité (le nombre de succès n 1 doit être suffisant) et par sa performance intrinsèque (le temps d exécution du cache doit être «bon» vis-à-vis du temps d exécution du service lui-même). L efficacité d un cache se paye (en général) par une complexité de son algorithmique donc par une performance sujette à caution... Attention donc aux déceptions. Rôle et place du cache XML Dans notre exemple «Fil Rouge», comme le montre la figure 6.6, le service susceptible de bénéficier le plus d un tel cache est le service d accès au catalogue de produit. En effet, d une part ce service est essentiellement un service de lecture d information (n 3 faible) et, d autre part, les informations de type description de produit sont stables : elles ont une durée de vie de l ordre de l heure voire de la journée, ce qui constitue une durée de vie importante vis-à-vis du trafic attendu sur la plate-forme de commande ; le cache a donc toutes les chances d avoir un taux de succès (n 1 grand) important. Enfin, le service CRUD repose sur un outil de mapping objet/relationnel, qui repose sur un SGBD relationnel, qui repose sur l accès à des disques durs : il a un Tservice important, le cache peut ne pas être «instantané» (Tcache proche de zéro)!

98 80 Chapitre 6. Performances des services d une SOA S.I. Client Application Point d entrée SI SI CACHE XML <PROCESSUS> Service métier TRAITER UNE UNE COMMANDE Point d entrée WS Point d entrée WS <CRUD> <CRUD> Service Service métier métier CATALOGUE <TECH> Mapping O/R S.I. Entreprise Fil Rouge <CRUD> <CRUD> Service Service métier métier STOCK <TECH> Accès Legacy SGBDR SGBDR LEGACY Figure 6.6 Utilisation d un cache XML dans le «Fil Rouge» Le service «traiter une commande» est un service de type «mise à jour d information», il ne peut bénéficier d un cache. Le service «accéder aux stocks» est un service de lecture d information, mais le niveau des stocks évolue constamment : le cache risque donc d être constamment invalidé par ces évolutions. Pour aller plus loin On notera que le rôle d un cache XML peut être étendu à d autres fonctions : par exemple, comme le montre la figure 6.7, il pourrait servir d agrégateur, lorsqu un service doit appeler d autres services externes. Dans le cas du Fil Rouge, on pourrait par exemple imaginer que le catalogue Fil Rouge agrège des informations issues (par exemple) de catalogues fournisseurs (via des accès WS), et/ou de blogs de consommateurs (via des accès REST). Le cache devient alors le service d agrégation lui-même. Pour une description plus détaillée de ce type de solution, on consultera la référence [Cohen2007].

99 6.1 La performance d un web service : les points clefs 81 Client SOAP «CACHE» XML SOAP <TECH> Cache & Agrégation Service <TECH> Requêteur XQUERY SOAP SGBD XML Service REST Service Figure 6.7 Extension du rôle du cache XML Les accélérateurs logiciels génériques : accès asynchrone & MOM Principe Le problème de performance rencontré ici avec le «goulet d étranglement» n est pas uniquement un problème de temps de réponse unitaire : c est également un problème de montée en charge. L orientation fondamentalement synchrone des web services peut, de ce point de vue, poser problème : tant que chaque étape du traitement par le WS de la requête courante n est pas franchie, la requête suivante ne peut être traitée. Un accélérateur matériel peut résoudre le problème pour les étapes «génériques» (étapes 4 à 10 du tableau 5.1), mais pas pour l exécution du service proprement dite (étapes 11, 12, 13, 14). Un accélérateur logiciel peut contribuer à résoudre le problème des services d accès «en lecture», mais quid des accès à des services de type «exécution de règles métier» ou «mise à jour des informations»? L anti-pattern «goulet d étranglement» menace encore! D où l intérêt de travailler en mode asynchrone à l intérieur du SI. En convertissant un appel externe synchrone en un appel interne asynchrone, il est possible d améliorer la montée en charge du système. La messagerie asynchrone (MOM : Middleware Orienté Message) gère une queue dans laquelle elle empile les requêtes entrantes. On «clone» alors le service (via la mise en place d un pool de threads, chaque thread exécutant un clone du service) : chaque clone vient piocher à son rythme dans la queue des requêtes. De ce fait, chaque clone s exécute en parallèle il s agit en fait

100 82 Chapitre 6. Performances des services d une SOA d un pseudo-parallélisme puisque tous les clones s exécutent sur le même serveur d application. Cela implique que le code du service n utilise pas (ou le moins possible) de variable globale, c est à dire de variable devant être partagée par les différents clones (threads). Et si cette utilisation est inévitable, il convient de mettre en place la politique appropriée de protection de ces variables globales. Si ce «pseudo-parallélisme» ne suffit pas, on peut passer à un vrai parallélisme, en mettant en cluster le serveur exécutant le service. Le chapitre 8 approfondit ce sujet en abordant la performance des processus, et le chapitre 12 présente la problématique de la mise en place de cluster. Un problème critique : les outils de binding XML objets L utilisation de XML se généralise dans les systèmes d information, notamment via l utilisation des web services, mais aussi via l utilisation de XML pour décrire les objets métier «de référence» dans les échanges entre silos du SI, échanges s effectuant via des EAI ou des ESB. Ces informations XML doivent être manipulées par du code, Java, C# ou autre. Il est donc nécessaire de traduire ces informations (textuelles) en objets (c est-à-dire en structure de données manipulable par le code), et réciproquement. Ces traductions ne sont pas gratuites, et il importe donc de choisir soigneusement l outil de traduction. La bonne nouvelle est que l offre de traducteurs est abondante, notamment dans la communauté Open Source. La mauvaise nouvelle est que leurs performances sont très inégales. De plus, cette offre étant en évolution permanente, on s en tiendra à une description des catégories d outil. Il existe deux grands types d outil : les traducteurs de document et les convertisseurs à la volée. Les traducteurs, qui s appuient sur la norme DOM 1, fonctionnent en deux grandes étapes (on prend ici l exemple de la traduction XML > Objet) : 1. le document XML est converti en une représentation arborescente (Java ou autre) du document : les objets obtenus sont des «nœuds», des «attributs», des «commentaires», etc. ; 2. puis le traducteur parcourt les nœuds de l arborescence obtenue pour créer les objets métier («commande», etc.) et valoriser leurs attributs («date de commande», «émetteur», etc.). Ces traducteurs ne sont pas performants, pour plusieurs raisons. Tout d abord, le service doit attendre que les deux étapes soient effectuées pour pouvoir accéder aux informations métier. Ensuite, la représentation arborescente obtenue contient des informations inutiles, comme les commentaires : autrement dit le traducteur effectue des opérations inutiles. Enfin, ce type de traducteur est un gros consommateur de mémoire. Il faut donc choisir un convertisseur «à la volée» : un tel outil parcourt l arborescence contenue dans le fichier texte XML et, à chaque élément de cette 1. DOM : Document Object Model.

101 6.2 La performance des services CRUD 83 arborescence, prend la décision de le traduire ou non. Le traducteur construit directement les objets métier et leurs attributs. Il n y a donc plus qu une seule étape de construction des objets métier. La performance qui en résulte est nettement meilleure. Dans un tel convertisseur, il y a deux grands modules : l itérateur qui parcourt l arborescence, et le traducteur qui convertit un élément textuel (par exemple, du texte) en un élément de code (par exemple, une valeur d attribut). Sans rentrer dans les détails, on retiendra qu il existe deux types de convertisseur à la volée : les convertisseurs de type SAX 1 : ce type d outil donne la priorité à l itérateur de l arbre. L itérateur parcourt l arbre et appelle le traducteur en tant que de besoin (appel de type CallBack) ; les convertisseurs de type StAX 2 : ce type d outil donne la priorité au traducteur. Le traducteur appelle l itérateur pour parcourir l arborescence, cette priorité permet au convertisseur de se focaliser plus facilement sur les éléments significatifs de l arborescence. Il sera donc (en général) plus performant. On utilisera donc les convertisseurs de type StAX, comme JiBX de la communauté SourceForge, mais en comparant soigneusement leurs performances. 6.2 LA PERFORMANCE DES SERVICES CRUD Enjeux Les services d accès aux entités, ou services CRUD, jouent un rôle clef quelle que soit l architecture ou la solution à mettre en place. Simple ou complexe, multicouches ou non, toute architecture orientée «nouvelles technologies» met en place d une façon ou d une autre ce type de service. L optimisation de ces services est donc une nécessité absolue (figure 6.8). Or, ces services souffrent notamment de l anti-pattern «requête mammouth», présenté au chapitre précédent : comment éviter que l invocation d un service CRUD ne ramène dans ses filets «toute la base de données»? Contrairement aux solutions concernant les (web) services d ouverture du SI, toutes relativement récentes, les éléments de solution présentés ici existent depuis que les problèmes soulevés existent, c est-à-dire depuis que les langages objets sont devenus d usage courant, et que le mapping objet/relationnel entraîne des problèmes hélas endémiques. 1. SAX : Simple Api for XML. 2. StAX : Streaming Api for XML.

102 84 Chapitre 6. Performances des services d une SOA <CRUD> Service métier CATALOGUE DMZ Portail S.I. Client Point d'entrée WS <TECH> Mapping O Site national Point d'entrée WS <CRUD> Service métier CATALOGUE <PROCESSUS> Service métier TRAITER UNE COMMANDE Point d'entrée WS <CRUD> Service métier STOCK Site local <TECH> Mapping O/R <TECH> Accès Legacy SGBDR LEGACY Figure 6.8 Optimiser les services CRUD Éléments de solution Ne pas distribuer! Un premier élément de solution est de ne pas distribuer ces services sous forme de web service, afin (entre autres) d éviter de cumuler mapping objet relationnel et mapping objet XML. Si on ne peut faire autrement, on a vu précédemment que la mise en place d un cache XML peut être intéressante. Mais le syndrome dont on souhaite se prémunir est indépendant de la (non) distribution d un service CRUD. Le pattern «Scénario» Principe Un exemple, associé au service CRUD «catalogue» du Fil Rouge, permet d illustrer le principe de ce pattern. Tout d abord, la figure 6.9 présente le diagramme UML des classes gérées par ce service CRUD. Le service gère un ou plusieurs catalogues. Chaque catalogue possède plusieurs rubriques. Chaque rubrique contient une liste de produits. Chaque produit est associé à une fiche descriptive et à une ou plusieurs fiches tarifaires. Les commandes sont associées aux produits commandés. Réciproquement, il peut être intéressant de relier les produits aux commandes en cours. La fiche descriptive du produit contient un attribut «texte» et peut le cas échéant être associée à d autres objets (photos, vidéos, blogs de consommateur, etc.).

103 6.2 La performance des services CRUD 85 Catalogue 1 Rubrique 1 Produit Commande FicheDescriptive Tarif Figure 6.9 Diagramme de classe «catalogue Fil Rouge» La figure 6.10 présente le diagramme d instances associé au diagramme de classe, c est-à-dire le contenu de la base d information à un moment donné. L application Portail va avoir besoin de lire ces informations : pour afficher le catalogue et la liste de ses rubriques ; pour afficher la liste des produits d une rubrique ; pour afficher une fiche descriptive d un produit ; pour afficher l historique des prix d un produit, c est-à-dire la liste des fiches tarifaires d un produit ; pour afficher la liste des commandes associées à un produit et émises par un même client donné ; etc. L application doit-elle lire les objets concernés un par un, on parlera alors de chargement (lazy initialization)? Ou au contraire ramener l ensemble des informations nécessaires «en bloc», dès le début d une session utilisateur on parlera de chargement par anticipation.

104 86 Chapitre 6. Performances des services d une SOA catalogue1 Rubrique1 Rubrique2 Produit1 Produit2 Produit3 Produit4 Produit5 Fiche Descriptive1 Fiche Descriptive2 Fiche Descriptive3 Fiche Descriptive4 Fiche Descriptive5 $$1 $$2 $$3 $$4 $$5 CommandeN Figure 6.10 Diagramme d instance «catalogue Fil Rouge» La réponse est... qu il n y a pas de réponse toute faite : tout dépend de l application et de ses cas d utilisation. Pour un site web «simple», l habitude est de pratiquer systématiquement un chargement paresseux à chaque demande d un client web. Dans le cas d un système d information, ce genre d habitude conduit rapidement à une inflation de requêtes SQL (on risque in fine le syndrome «mitrailleuse à requêtes»), donc à une dégradation intolérable des performances. Il faut donc pratiquer l anticipation, mais «avec modération», pour ne pas risquer le syndrome de la requête mammouth. De plus, anticiper systématiquement conduit à ramener des informations inutiles, plus exactement des informations que l utilisateur ne consultera pas «dans la majorité des cas». Comment faire? Le principe proposé est de gérer explicitement le concept de scénario de chargement. Supposons par exemple que l application cliente souhaite afficher la liste des produits de la rubrique 1, avec leur prix : l application n a donc pas besoin des fiches descriptives, mais elle a besoin de la fiche de prix. Elle souhaite donc récupérer les informations grisées dans la figure Pour cela, le développeur de l application va préciser explicitement au service le scénario de chargement à suivre. Ce scénario décrit le cheminement dans le graphe de classe de la figure 6.9 : dans l exemple, le scénario sera le chemin [Rubrique > Produit > Fiche de prix]. Ce pattern est d autant plus important que le diagramme de classe associé au service CRUD est constitué d un graphe d objets complexe, qui peut dans certains cas être cyclique.

105 6.2 La performance des services CRUD 87 Scénario de chargement Rubrique1 catalogue1 Rubrique2 Produit1 Produit2 Produit3 Produit4 Produit5 Fiche Descriptive1 Fiche Descriptive2 Fiche Descriptive3 Fiche Descriptive4 Fiche Descriptive5 $$1 $$2 $$3 $$4 $$5 CommandeN Figure 6.11 Scénario de Chargement Conseil : envisager l utilisation du pattern Scénario de Chargement lorsque le service CRUD est associé à un graphe d objets complexe. Comment déterminer la «profondeur raisonnable» du scénario de chargement? Autrement dit, comment le concepteur de l application cliente du service doit-il spécifier le scénario de chargement à utiliser? En analysant le use case associé à son application cliente. En effet, le use case (s il est bien formalisé) distinguera entre un cas nominal d utilisation de l application par ses utilisateurs, et des cas alternatifs de mise en œuvre, correspondant à des situations plus rares. Le concepteur spécifiera le scénario de chargement en fonction du cas de mise en œuvre. Implémentation lorsque la source de données est une base de données Cette section a pour objectif de donner quelques indications sur la mise en œuvre de ce pattern en relation avec l utilisation d une base de données et d un outil de mapping objet Ì relationnel, tel que Hibernate ou TopLink. Mise en œuvre On remarquera tout d abord que ces outils de mapping utilisent le concept de Proxy, afin de faire la distinction entre un objet existant en base de données mais pas chargé en mémoire, et un objet qui n existerait pas en base. La figure 6.12 illustre ce qu obtient le service CRUD en interrogeant la base de données via Hibernate. Ceci pose un

106 88 Chapitre 6. Performances des services d une SOA problème subtil mais redoutable car le service qui a récupéré ce graphe d objet peut avoir à le renvoyer vers son application cliente au travers d une frontière physique (un réseau). Rubrique1 Produit1 Produit2 Produit3 Proxy Proxy Proxy $$1 $$2 $$3 Figure 6.12 Le graphe d objets résultat du chargement (résultat intermédiaire) Que faire alors de ces proxys lors de la «traversée de frontière»? Ce sont des objets (instances) techniques, spécifiques du mapping Objet Relationnel. Ces objets vont poser des problèmes de transformation XML Objet (l outil de traduction doit connaître la description de ces objets techniques, qui est spécifique). De plus, ils poseront un problème à l application cliente qui, pour les récupérer à partir du flux XML, devra utiliser une classe appartenant à un package Java spécifique du mapping Objet relationnel, et qui n a donc rien à faire du côté client. La solution est de remplacer ces proxys par des Null dans le graphe d objets, comme l illustre la figure Sauvegarde Mais ce n est pas terminé. L application cliente peut vouloir en effet modifier le graphe d objets qu elle a obtenu. Imaginons par exemple que l utilisateur final soit un fabricant qui utilise l application portail pour modifier un de ses produits et supprimer la fiche produit associée. La figure 6.14 montre le graphe d objets renvoyé par l application cliente vers le service CRUD pour mise à jour.

107 6.2 La performance des services CRUD 89 Rubrique1 Produit1 Produit2 Produit3 NULL NULL NULL $$1 $$2 $$3 Figure 6.13 Le graphe d objets envoyé par le service CRUD vers son client Rubrique1 Produit1 modifié Produit2 modifié Produit3 NULL NULL NULL $$1 modifié NULL $$3 Figure 6.14 Le graphe d objets modifié par le client et renvoyé au service CRUD

108 90 Chapitre 6. Performances des services d une SOA Après vérification (contrôle d intégrité via des règles de gestion), le service CRUD va mettre à jour la base de données via l outil de mapping. Mais si le service lui fournit directement le graphe de la figure 6.14, l outil de mapping va supprimer les objets «fiche descriptive», c est-à-dire les remplacer par des Null, sans se poser de question. Il faut donc reconstituer un graphe contenant les proxys qui sont autant de garde-fous pour l outil de mapping. Pour cela, le service CRUD doit exécuter une fusion entre le graphe des modifications (figure 6.14) et le graphe initial (figure 6.12), en s aidant du scénario de chargement, qui permet de savoir notamment quels sont les Null à prendre en compte, c est-à-dire les Null correspondant à une mise à jour de la base de données. Cette fusion est illustrée par la figure Rubrique1 État modifié État initial Rubrique1 Produit1 modifié Produit2 modifié Produit3 Produit1 Produit2 Produit3 NULL NULL NULL Proxy Proxy Proxy $$1 modifié NULL $$3 $$1 $$2 $$3 Scénario de chargement Rubrique1 État final Produit1 modifié Produit2 modifié Produit3 Proxy Proxy Proxy $$1 modifié NULL $$3 Figure 6.15 Graphe d objets modifié fourni à l outil de mapping Cette mécanique n est pas triviale à mettre en place, mais elle est générique : il est donc possible de la réutiliser sur les différents services CRUD à mettre en place. Sauvegarde asynchrone Cette mécanique de sauvegarde peut cependant causer, dans certains cas, un souci de performance intrinsèque. On obtient le paradoxe que, pour rendre plus performante la lecture de données, on pénalise alors l écriture en base de données. Si c est le cas, une possibilité est de rendre asynchrone l opération de sauvegarde du service CRUD. Une

109 6.2 La performance des services CRUD 91 fois invoqué via une messagerie asynchrone, le service travaille «en tâche de fond», le client a repris la main. Mais cela suppose que la messagerie garantisse la robustesse de l acheminement de la requête : il faut que le client soit certain que sa demande de sauvegarde en base de données ait été prise en compte. Un exemple de plus où performance et robustesse sont liées dans la recherche de l architecture la plus efficace. Implémentation orientée legacy Un service CRUD peut encapsuler non pas l accès à une base de données relationnelle, mais un système existant (legacy). Admettons par exemple que l exemple «Fil Rouge» nécessite l accès à des informations clients & contrats gérés sur un mainframe ou un AS/400 : un contrat CTR contient un historique de situations, chaque situation contractuelle SIT contient la liste des services souscrits par le client, un service SER contient une liste de conditions tarifaires à appliquer aux commandes, une condition tarifaire COND associe un produit et une liste de ristourne, une ristourne RIST associe un seuil de déclenchement de la ristourne (quantité commandée) et un taux de réduction, etc. Un tel service fonctionnerait alors comme suit : 1. le service CRUD reçoit une demande de chargement de l objet CTR(id) avec le scénario «récupère les objets correspondants aux classes SIT, SER, et COND, sans les RIST (c est-à-dire les produits concernés sans les conditions détaillées)» ; 2. il récupère dans un fichier de méta information le nom (ou l identifiant) du ou des services mainframe à invoquer ; 3. le service dialogue avec le legacy pour lui demander de récupérer les infos ; 4. il récupère un ou des buffers d information (buffer CICS, etc.) ; 5. il transmet ces buffers aux mappeurs élémentaires (un mappeur par classe d objet, un mappeur effectue la transformation buffer instance de classe) ; 6. il relie dynamiquement les objets entre eux ; 7. le service renvoie la grappe d objet à son client. Cette simplicité apparente cache quelques problèmes potentiels. Tout d abord, comment éviter la mitrailleuse à requêtes? Ce syndrome apparaît si le service CRUD est obligé d appeler autant de services mainframe qu il y a d objets à récupérer. Par exemple, s il y a N objets SIT à récupérer, le service enverra N requêtes vers le legacy pour récupérer les SER correspondants à chaque SIT. S il y a M SER, il enverra M requêtes pour récupérer les instances COND, etc. Le concept de scénario de chargement est donc intéressant dans ce cas de figure. Bien évidemment, l idéal serait de développer sur le mainframe un service CRUD équivalent : le service CRUD Java ou C# devient alors un simple aiguilleur de requête vers ce service. Ceci suppose que deux conditions soient remplies : Le legacy est suffisamment «ouvert» pour permettre le développement d un tel service ce n est pas toujours le cas, si ce legacy est très ancien.

110 92 Chapitre 6. Performances des services d une SOA Il n y a pas de limite de communication entre le service CRUD et le legacy dans des cas fréquents impliquant des mainframes, des couches de communication monde web Ì mainframe ont été mises en place mais elles limitent le volume d information transportée sur le réseau. Il est alors nécessaire de modifier cette couche de communication pour augmenter sa capacité, ou bien alors prévoir le découpage et la reconstitution des messages. Conclusion En conclusion, le pattern de scénario de chargement n est pas seulement utile pour la lecture d un graphe d objets. Il est également utile, voire incontournable, pour l écriture de ce même graphe d objets en base de données. On remarquera un point très important : les problèmes rencontrés ici sont incontournables dès lors qu il existe une traversée de frontière physique entre le service et ses clients. Or, l apparition d AJAX va rendre ce cas de figure de plus en plus fréquent (cf. chapitre 8). 6.3 UNE SOLUTION MIRACLE? WS * VERSUS REST Revenons ici sur un sujet délicat : le monde des WS-* est-il trop complexe pour être vraiment utilisable, notamment sur le plan des performances? Le sujet est délicat car il relève autant de l effet de mode que de la réalité concrète : Effet de mode : il est de bon ton en informatique de brûler rapidement ce qu on a adoré, et de chercher un remplaçant paré de toutes les vertus. Réalité concrète : oui, le monde des WS-* est complexe, car il recherche la complétude. Mais, le succès du Web 2.0 n est pas qu un effet de mode, si l on en croit les milliards de dollars et d euros qui sont en jeu, et si l on en juge par le succès du bon vieux Web 1.0. Utiliser les protocoles à la base du Web 2.0 peut donc être une opportunité intéressante Enjeux Face à cette complexité des normes WS-*, le succès du Web 2.0, et en particulier de la blogosphère, qui repose techniquement sur l approche REST, a en effet propulsé cette approche comme un concurrent potentiel des web services. Cette approche est d ailleurs l un des patterns architecturaux proposés au chapitre précédent. Mais qu est-ce exactement que REST 1, et que peut-on en attendre réellement? 1. REST : Representational State TransferD après Roy Fielding, le créateur de cet acronyme : «REST is intended to evoke an image of how a well-designed Web application behaves : a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use».

111 6.3 Une solution miracle? WS * versus REST Brève présentation de REST Les principes de REST L approche REST repose sur deux principes : Un service REST est un service d accès CRUD à une ressource informationnelle identifiée par son adresse Internet (URL). Exemples de ressource : news d un site web, entrée d un blog, page d un wiki, flux podcast, multimédia, etc. Invoquer un service REST, c est-à-dire accéder à la ressource, c est utiliser directement le protocole http (au lieu d utiliser une surcouche comme SOAP). HTTP permet d envoyer à un serveur web des requêtes (HTTPrequest) chaque requête contenant un mot-clef, tel que GET, POST, PUT, DELETE, TRACE décrivant le type de requête, etc. Le serveur répond avec une HTTPresponse contenant notamment le statut d exécution de la requête (par exemple : le classique 404 not found) et éventuellement un contenu (page HTML, flux XML, etc.). Appliquer le pattern REST consiste essentiellement à définir pour chacun des mots clefs HTTP une sémantique spéciale. Le protocole ATOM Un exemple permettra d illustrer cela, en listant les services offerts par un serveur de contenu supportant ATOM : ATOM est un protocole conforme à REST et couramment utilisé dans le monde de la gestion de contenu web. Pourquoi ATOM, alors qu il existe d autres protocoles équivalents (RSS 1.0, RSS 2.0)? D abord, ATOM a l avantage d être standardisé par l IETF 1, l organisation qui veille à la destinée technique d Internet 2. Ensuite, il est explicitement conçu pour être extensible et indépendant des technologies d implémentation des clients et des serveurs utilisant ATOM pour dialoguer. ATOM manipule deux entités de base, les entrées (ATOMEntry) et les flux (ATOMFeed). Une entrée décrit une information, c est-à-dire un contenu atomique géré par le serveur de contenu. Un flux est associé à un ensemble d informations rassemblées par le site ou par une rubrique du site. Le tableau 6.2 présente les services ATOM : conformément à REST, il s agit de définir précisément la sémantique que ATOM associe à chaque type de requête HTTP. 1. IETF : Internet Engineering Task Force. 2. Cette présentation n est pas tout à fait rigoureuse. ATOM désigne à la fois (i) un format d échange de contenu, c est-à-dire un formalisme XML décrivant un certain type de contenu (les entrées et les flux), et (ii) un protocole de publication de ressources respectant ce format d échange. Le format d échange, appelé aussi format de syndication, est effectivement standardisé par l IETF (RFC 4287). Le protocole de publication, d abord proposé indépendamment, a été récupéré par l IETF, et est à l état de draft. Le site consacré à ce processus de standardisation IETF est à l adresse

112 94 Chapitre 6. Performances des services d une SOA Tableau 6.2 Les services définis par le protocole ATOM Service ATOM Mot clef HTTP Sémantique du service Résultat du service Créer une information POST + ATOMEntry Permet de créer une nouvelle information en utilisant une requête POST contenant un ATOMEntry Une URL sur l information nouvellement créée sur le serveur Éditer une information GET + URL de l information Rechercher l information identifiée par son URL Un ATOMEntry Mettre à jour une information PUT + ATOMEntry Mettre à jour l information avec l information de l ATOMEntry contenue dans la requête HTTP Une response HTTP 201 created Supprimer une information DELETE + URL de l information Supprimer l information identifiée par son URL Une response HTTP 201 created Rechercher des informations GET + URL du service d information Interroge le serveur pour récupérer les dernières informations créées Un ATOMFeed, contenant les informations demandées : le flux contient en particulier les x derniers documents créés (x = 5 par exemple), plus un lien vers les y derniers documents créés (y = 20 par exemple) Ci-après, un exemple commenté d ATOMEntry. <entry> <title> Un exemple d entrée </title> <summary> tres simple... </summary> <author> <name>martin Dupont</name> < >martin@dupont.fr/</ > </author> <issued> t12 :29 :29</issued> <created> t14 :10 :58Z</created> <modified> t14 :10 :58Z</modified> <id> urn :uuid :30a76c80-d288-18k2-b91B d0bf2</id> <content type="application/xhtml+xml" xml :lang="en-us"> <!-- ici le contenu de l entrée. Alternative : il est possible de mettre ici l URL du contenu--> </content> </entry>

113 6.3 Une solution miracle? WS * versus REST 95 Et un exemple simplifié d ATOMFeed : <feed> <!-- le lien vers les 20 dernières entrées du site --> <link rel="prev" type= application/x.atom+xml title="les 20 Entrees precedentes" href=" <!-- ci-dessous, le lien vers le service permettant de creer une entree : avant qu une entrée existe, elle n existe pas, dirait Mr de Lapalisse, donc on ne peut pas se créer. Il faut donc un service dédié --> <link rel= service.post type= application/x.atom+xml" title="créer une nouvelle information" href=".."/> <!--- et maintenant les x dernières entrées, avec leur contenu --> <entry> <id> <!-- le lien vers le service permettant d éditer l entree --> <link rel= "service.edit" type= application/x.atom+xml" href="/blog/xx.atomapi"/> <title> mon entree...</title> <content> <!-- ici, on trouve en général un résumé ou bien les premières lignes du blog --> </content> <issued> t20 :52 :57-05 :00</issued> <modified> t20 :52 :57-05 :00</modified> </entry> <entry>... </entry> </feed> Analyse REST apparaît donc comme très simple, et qui dit simplicité dit moins de risque sur les performances. La généralisation de REST permettrait de pouvoir réutiliser les acquis de plus de 10 ans d utilisation de HTTP. Par exemple, il serait possible d utiliser des outils de gestion de cache éprouvés tels que SQUID. De plus en plus d observateurs affirment que ce type de protocole sera généralisé pour développer et déployer tout type de service CRUD. S il fallait une preuve de l intérêt de l approche REST dans le cadre d une SOA, le W3C vient de la donner, en débutant fin 2006 un travail de normalisation autour de la norme WS-TRANSFER 1. Cette norme revient à définir, dans un cadre web service, comment un client peut accéder à des ressources (informations), via des messages qui s appellent... GET, POST, DELETE! On se demandera : quel peut bien être l intérêt de réinventer HTTP au-dessus de SOAP/WSDL? Il suffit d en rester au web de base! Mais est-ce si simple...? Il ne faut pas oublier qu à l origine ce type de protocole est prévu pour manipuler avant tout des informations pas ou peu structurées. Vouloir l utiliser dans le monde des SI de gestion, qui manipule des informations beaucoup plus structurées, pose donc des problèmes : 1.

114 96 Chapitre 6. Performances des services d une SOA Comment récupérer non seulement une commande, mais également les lignes de cette commande, la description du produit commandé par ligne, le ou les bons de livraison, etc.? Avec REST, il faudra faire autant de demandes qu il y aura de ressources concernées (il n y a pas de pattern «scénario de chargement»), et de plus il faudra utiliser les ATOMFeed dans un contexte non prévu au départ. Comment rechercher non pas les «x dernières commandes», mais les commandes «reçues entre telle et telle date et non encore livrées» : autrement dit, comment utiliser (simplement) des critères de recherche? Comment mettre en place une recherche gérant le phénomène des listes longues (cf. chapitre 8 sur la performance des solutions)? Comment demander un devis, c est-à-dire la valorisation d une commande? L approche REST est orientée «données» et non pas «traitement», or les services SOA ne sont pas uniquement orientés données. Comment sécuriser les échanges entre clients et services REST? Ces services sont avant tout destinés au monde Internet et, par nature, ne sont pas sécurisés. Or, ce point est au contraire très important dans les échanges entre entreprises Conclusion On voit donc que l approche REST, malgré sa simplicité et sa souplesse (ou à cause de cela), pose un certain nombre de questions pertinentes et non résolues à ce jour : il ne faudrait pas en conséquence jeter le bébé (les WS-*) avec l eau du bain. Certes, l approche WS-* n est pas triviale, et peut poser de sérieux problèmes de performance. Mais l approche REST pose d autres problèmes et il conviendra d être prudent avant de sortir REST de son contexte Internet pour l appliquer au SI. La préconisation est donc d attendre les futures versions du protocole ATOM, versions qui pourraient prendre en compte certaines questions évoquées ci-dessus (critères de recherche, gestion de collection hiérarchique), avant de lancer une évaluation concrète. Il est par ailleurs nécessaire d être vigilant quand à la problématique de sécurité : on suivra donc l évolution de la norme WS-Transfer, mieux à même de bénéficier des avancées réelles des web services sur ce terrain. En conclusion, il est plus que probable que REST et WS-* continueront à cohabiter dans le futur, comme les langages dynamiques (à la PHP ou à la Groovy) coexistent depuis longtemps avec les langages statiques (à la C# ou à la Java). 6.4 LA ROBUSTESSE DES SERVICES Cette section expose les enjeux de la robustesse des services et propose des éléments de solution. La généralisation inéluctable de l approche service implique en effet de se poser quelques questions sur ce problème. Comme l a rappelé le chapitre 2, la robustesse comprend deux volets : la disponibilité du service, c est-à-dire la proportion de temps pendant laquelle il est en état de bon fonctionnement sur une période de temps donnée ;

115 6.4 La robustesse des services 97 l intégrité du service, c est-à-dire sa capacité à ne pas corrompre le système d information pendant des conditions de fonctionnement dégradées ou lors de panne : par exemple, une panne du service ne doit pas se traduire par une perte ou une altération des données en base de données ou de messages dans une file d attente. La disponibilité est mesurée en pourcentage («le service est disponible pendant 99 % du temps de fonctionnement»), l intégrité s exprime par une grandeur scalaire sans unité («un message perdu tous les messages reçus»). Le chapitre 2 (tableau 2.1) montre que, si on admet un fonctionnement 24 h/24, une disponibilité de 99,9 % (un chiffre apparemment élevé) implique que le service peut être arrêté jusqu à 9 heures par an, ce qui peut être intolérable. Une question préliminaire est : l hypothèse de fonctionnement 24 h/24 est-elle fondée? Cette hypothèse est en effet très contraignante. Plusieurs raisons laissent cependant penser que ce sera de plus en plus la norme de fonctionnement pour les services métier : l entreprise temps réel peut avoir des clients qui travaillent eux-mêmes la nuit ou une bonne partie de la nuit et des fins de semaine (le terme client désigne ici aussi bien les acteurs humains les salariés du client que les acteurs «machines», c est-à-dire le système informatique dudit client) ; l entreprise temps réel peut être internationale, tout en voulant centraliser ses traitements : le décalage horaire entraîne alors naturellement un tel fonctionnement 24 h/24 ; l entreprise temps réel continue à avoir des traitements métier batch, par exemple pour émettre des facturations ou suivre les aspects contentieux : ces batchs peuvent s appuyer sur des services métier. Or, ils s exécutent de préférence la nuit (ce qui pose par ailleurs des problèmes de planification batch/tp aux équipes de production : l internationalisation ou le travail nocturne impose la coexistence des batchs et des applications interactives, ce qui implique des problèmes d accès à des ressources partagées, donc des problèmes de performance). Par la suite, nous distinguerons l aspect disponibilité et l aspect intégrité, dans la mesure où les solutions pertinentes sont de nature différente. L aspect disponibilité sera traité plus globalement au chapitre 8. L aspect Intégrité est évoqué dans la section suivante Enjeux de l intégrité des services La nécessité pour un service de ne pas corrompre les données sur lesquelles il travaille paraît évidente. Cet enjeu concerne non seulement les services CRUD, mais également les services ou les applications «clientes» de ces services.

116 98 Chapitre 6. Performances des services d une SOA Éléments de solution «intégrité» Les éléments de solution doivent être pris : au niveau du service lui-même ; au niveau des applications ou services clients du service. Le service en tant que tel assure l intégrité de l accès aux ressources qu il gère en utilisant les outils classiques du transactionnel ACID (commit/rollback). La question est un peu plus complexe lorsque le service concerné invoque d autres services, comme c est le cas des services applicatifs. Il peut être nécessaire de rendre transactionnel un tel service. Dans l exemple «Fil Rouge», le processus de traitement de la commande peut faire appel à un service de gestion des livraisons. Un tel service fera appel d une part au service CRUD «commande» (pour mettre à jour la date prévisionnelle de livraison) et, d autre part, au service CRUD «bon de livraison» (pour créer un nouvel objet «bon de livraison»). Le service de gestion des livraisons doit assurer l intégrité des mises à jour des bases de données. Ceci implique que les services CRUD soient inclus dans une transaction à deux phases. Ces services ne pourront être déployés en tant que web service, les WS n étant pas transactionnels. Ils devront être déployés soit en tant qu EJB, soit en tant que services Spring ou équivalent. Ce qui, par conséquent, conduit au conseil suivant : Conseil : il est nécessaire de distinguer le développement d un service et son mode de déploiement. Dans certains cas, le même service sera déployé sous forme de service POJO, d EJB voire de web services. Et les applications clientes? Elles doivent mettre en place une politique de reprise sur erreur : que se passe-t-il si le service invoqué renvoie une exception «transaction non effectuée»? On rejoint ici la discussion sur la disponibilité des applications et des services, abordée au chapitre 8.

117 6.4 La robustesse des services 99 En résumé En décomposant la chaîne d envoi par un client d une requête à un web service, nous avons illustré en premier lieu comment un architecte (ou un intégrateur) doit aborder l analyse a priori des performances d un service. Cette approche est généralisable même lorsque l accès à un service ne se fait pas via les protocoles WS-* : en suivant pas à pas le cheminement d une requête, l architecte doit s interroger sur l impact de chaque couche traversée. Nous nous sommes ensuite interrogés sur les performances d une catégorie de service : les services CRUD. Toute démarche architecturale s appuyant de près ou de loin sur SOA fera émerger une bibliothèque de services CRUD. La question des outils de mapping objet/relationnel est importante : ces outils n ont pas été pensés pour s insérer dans une architecture de service, il importe donc d être vigilant sur le plan des performances. La simplicité est souvent l amie de la performance. Nous nous sommes donc interrogés sur l utilisation de l approche REST, présentée comme une approche plus simple que l approche web services. Enfin, nous avons rapidement analysé la problématique de robustesse des services.

118

119 7 Robustesse et performance d un processus métier Objectif L objectif du chapitre est de présenter de façon synthétique les enjeux de robustesse et de performance des processus métier automatisés au sens SOA. Dans ce contexte SOA, un processus est considéré comme un service métier : cependant, l obtention des niveaux de performance et de robustesse adéquats pour ce type de service implique des solutions spécifiques, complétant les solutions présentées au chapitre précédent. 7.1 RAPPEL SUR LES PROCESSUS MÉTIER Un processus métier décrit l ensemble des activités que l entreprise doit exécuter pour traiter un événement métier qui lui est adressé. Le processus métier est défini par : l événement métier «déclencheur», qui est à l origine de la création du processus : par exemple, la réception d une commande ; les événements métier que le processus échange avec le monde extérieur : par exemple, l envoi d une demande de livraison à un transporteur ;

120 102 Chapitre 7. Robustesse et performance d un processus métier les activités qui doivent être exécutées pour traiter les événements ; les règles conditionnant le passage d une activité à une autre ; pour chaque activité, et en fonction des choix d organisation de l entreprise, l acteur (ou le groupe d acteur) qui doit exécuter l activité 1. Il est indispensable de bien différencier modèle de processus, processus ou instance de processus exécutant le modèle et moteur de processus exécutant les instances. Un modèle de processus décrit de façon générique comment l entreprise réagit à un type d événement métier : par exemple, le modèle de processus «traiter une commande» décrit comment l entreprise Fil Rouge traite toute commande envoyée par les magasins clients. Une instance de processus associée à ce modèle traite un événement métier individuel. Par exemple : le processus «traiter la commande n XYZ en date du 10 juin 2010 émise par le magasin Martin» sera associé au modèle de processus «traiter une commande». Le moteur de processus est le composant logiciel qui crée et exécute les instances de processus. Pour cela, il reçoit les événements métier sous forme de messages XML, messages envoyés par les applications frontales (portail, serveur de message). Si l événement est un événement déclencheur, le moteur sélectionne le modèle de processus concerné, crée une nouvelle instance de processus associée à ce modèle, et exécute les activités décrites par le modèle de processus. Dans le contexte SOA, toute activité d un modèle est exécutée sous forme d un appel à un service métier : un processus est donc vu comme un «chef d orchestre» enchaînant une suite d appel à des services métier. Un modèle de processus est décrit à l aide d un dialecte XML, appelé BPEL (Business Process Execution Language) : le moteur de processus est donc à la base un interpréteur BPEL. Les processus sont donc considérés comme automatisés, ce qui est un changement fondamental par rapport à l approche traditionnelle du workflow «human driven» des années Cette approche automatisée des processus est une des raisons fondamentales 2 de l intérêt pour l approche SOA, car elle fournit une solution à l émergence des «processus e-business» concomitante de l utilisation du Web pour lier l entreprise à son écosystème. 7.2 CONTENU DU CHAPITRE Cette automatisation croissante des processus pose alors bien évidemment la question de leur robustesse et de leur performance. Ce chapitre présente en premier l enjeu de robustesse des processus métier. Dans la mesure où ces processus ne relèvent 1. Soulignons d ailleurs qu une activité peut être plus ou moins décomposée afin de pouvoir être attribuée à plusieurs acteurs différents. 2. Les autres raisons étant l ouverture du SI (via les web services), la modularité des nouvelles applications et la réutilisation du parc logiciel existant (lorsque c est possible/souhaitable).

121 7.3 Robustesse d un processus métier 103 pas de la problématique des transactions courtes, ACID, mais de la problématique des «transactions longues», la robustesse devient en effet un problème qui peut être complexe : les solutions envisageables peuvent avoir un impact fort sur les performances. D où la nécessité d analyser en premier la problématique de robustesse des processus avant d évoquer les aspects performance, objet de la deuxième partie du chapitre. Nota important Ce chapitre évoque essentiellement des considérations techniques. Or, il est important de noter que la performance globale d un processus métier peut également dépendre de la performance des acteurs humains, lorsque le processus fait intervenir ces acteurs (pour traiter une exception par exemple). Les enjeux humains appartiennent à la problématique de la gouvernance du système d information, notamment au suivi des processus (mise en place du BAM 1 ), mais cette problématique sort du cadre de ce livre ROBUSTESSE D UN PROCESSUS MÉTIER Enjeux La question posée est : que doit-il se passer lorsque le moteur de processus rencontre un problème (serveur en panne par exemple)? Un arrêt intempestif de ce moteur entraîne l arrêt des processus en cours d exécution : que faut-il faire pour reprendre l exécution de ces processus? Il importe en effet de bien comprendre que l exécution d un processus ne peut être assimilée à une transaction courte, de type ACID (comme une requête SQL), transaction qui laisse le système dans un état cohérent par construction. La durée d exécution d un processus se mesure en dizaines de secondes, voire en minutes, en heures, ou en jours si le processus interagit avec des systèmes externes ou s il demande l intervention d un acteur humain. Un processus est donc une transaction «longue». L arrêt intempestif du moteur de processus a toutes les chances de laisser le processus et les bases de données associées dans un état plus ou moins cohérent. Pour expliquer le problème qui peut se poser, on prend le modèle de processus illustré par la figure 7.1. Ce modèle (simplifié 3 ) décrit les différentes étapes de traitement d une commande. Chaque chiffre désigne une étape au niveau de laquelle la panne peut intervenir. La question devient alors : que se passe-t-il lorsque le moteur s arrête aux étapes 1, 2 ou 3? 1. BAM : Business Activity Management. 2. Voir par exemple la référence déjà citée [Caseau2007]. 3. Le modèle est simplifié du fait (entre autre) qu il ne décrit pas comment sont traitées les exceptions levées par les différentes étapes du processus : que se passe-t-il (par exemple) lorsque la commande

122 104 Chapitre 7. Robustesse et performance d un processus métier commande réponse S.I. Client Vérifier commande Vérifier et réserver stock Vérifier et réserver transport Envoyer réponse S.I. Entreprise S.I. Fournisseur Figure 7.1 Le modèle de processus «traiter une commande» On s intéresse dans ce qui suit aux réponses logicielles. Ces solutions sont complémentaires d une solution matérielle basée sur une infrastructure de type cluster, car cette solution matérielle ne peut à elle seule garantir l intégrité du système Solution n 1 : repartir de zéro Principe La première solution possible est tout simplement d exécuter à nouveau le processus depuis le début. C est une solution dont le principe a le mérite semble-t-il de la simplicité. Mais dans les faits, elle n est pas vraiment applicable lorsque le processus interagit avec le monde extérieur. L exemple du modèle de processus présenté par la figure 7.1 va permettre de bien comprendre le problème. Si le processus est arrêté au point 1, on peut envisager de le redémarrer depuis le début : en effet, l activité «vérifier la commande» s est contentée de lire les informations dans différentes bases de données afin d effectuer les vérifications nécessaires. Rejouer cette vérification n a pas d impact particulier. est erronée, ou que le contrat du client émetteur de la commande ne lui permet pas de passer commande, ou qu il n y a plus de stock?

123 7.3 Robustesse d un processus métier 105 Analyse En revanche, si le processus est arrêté au point 2, quel serait l impact d une reprise depuis le début? Cette reprise impliquerait d exécuter une deuxième fois l activité 1 mais aussi l activité 2 «vérifier et réserver stock» : le processus effectuerait alors une nouvelle réservation de stock. On se retrouve donc avec deux réservations de stocks pour la même commande, dont une réservation «orpheline», c est-à-dire une réservation qui ne se traduira jamais en demande de livraison, tout en bloquant des stocks. La situation devient incohérente. Il est possible (sur le papier) de résoudre ce problème soit en évitant de rejouer les activités déjà exécutées, soit en «compensant» les activités du processus déjà exécutées, c est-à-dire en supprimant les mises à jour de bases de données avant de reprendre l exécution du processus. Éviter de rejouer le même service Éviter de rejouer une activité, c est faire en sorte que le service associé à l activité ne soit pas exécuté une seconde fois. Cela implique que tout service appelé par le processus contrôle systématiquement qu il n a pas déjà traité la requête auparavant. Comment faire? La solution «implicite» consiste à déléguer au service le soin de détecter lui-même qu il est invoqué une seconde fois sur la même requête : cela suppose que le service conserve d une façon ou d une autre la requête précédente. Or c est un principe de base d une SOA, un service doit autant que possible être stateless, c est-à-dire qu il doit éviter de mémoriser ses invocations passées. Dans ce cas de figure, la mémorisation est non seulement obligatoire mais lourde à mettre en place. La solution «explicite» consiste à demander à tous les clients d un service (ici, en l occurrence, le moteur de processus) de gérer un identifiant de requête et de le transmettre au service invoqué. Le service se charge alors de détecter qu on l invoque avec un identifiant déjà utilisé : cette détection peut être générique et incluse dans le framework de développement des services métier. Cette solution «explicite» est plus simple, mais elle suppose quand même que le service ne soit plus tout à fait stateless. Elle suppose de : concevoir l interface du service pour y inclure l identifiant de requête ; concevoir l implémentation du service pour y inclure la mémorisation de l identifiant et sa vérification systématique ; définir comment un client construit l identifiant de requête, afin que deux invocations identiques du service produisent le même identifiant 1 dans l exemple présenté, l identifiant peut par exemple être construit à partir de l identifiant de la commande. 1. C est donc le problème inverse du problème habituellement posé, qui est celui de l unicité d un identifiant généré. Dans le cas de figure évoqué ici, on veut que dans certains cas l identifiant généré ne soit pas unique!

124 106 Chapitre 7. Robustesse et performance d un processus métier Conclusion Compenser le processus Compenser le processus signifie ici : avant de reprendre l exécution du processus depuis le départ, déclencher un mécanisme ayant pour objectif de supprimer toutes les mises à jour de base de données déjà effectuées. La norme BPEL prévoit qu on puisse modéliser la logique de compensation directement au sein du modèle de processus, ce qui permet au moteur de lancer lui-même ce mécanisme de compensation. Mais la modélisation de ce mécanisme suppose que deux hypothèses soient simultanément validées : Ces mises à jour n ont pas été exploitées entre-temps par d autres processus/acteurs. Il est possible de retracer l historique de ces mises à jour. La première hypothèse dépend du processus lui-même. Dans l exemple utilisé, il est clair que la réservation de stock (activité 2) va être «plus ou moins rapidement» exploitée par le système de logistique (SCM 1 ) gérant l entrepôt, pour préparer le colis à expédier via le transporteur sélectionné. Dans ce cas, il est inutile de chercher à compenser le processus : c est trop tard! La seconde hypothèse suppose que le concepteur du processus sache retracer les mises à jour possibles, afin qu un «mécanisme de reprise» annule au préalable ces mises à jour. C est faisable, mais assurément complexe. L apparente simplicité de la solution «repartir de zéro» se paie donc par une complexité accrue de la conception des services appelés par le processus ou de la mise en place d une mécanique de compensation potentiellement complexe. De plus, ces solutions ne résolvent pas le cas de figure classique de l interaction entre le processus et un SI extérieur ; en effet, comment «compenser» un message déjà envoyé à un acteur humain (mail vers un client par exemple) ou à un SI (invocation d un web service) qui par définition échappe au contrôle de l architecte de l entreprise? Renvoyer un mail ou invoquer à nouveau un web service peut provoquer des incidents coûteux Solution n 2 : isoler le processus Principe Le principe de cette solution est de faire en sorte que le processus n ait un impact sur le monde extérieur qu à la fin de son exécution, et «en bloc». Le processus doit donc être modifié comme suit : chaque activité écrit non plus dans une base de données ou dans le système cible, mais dans un objet dédié, appelé Dossier ; en fin de processus, le contenu du Dossier est écrit en bloc dans les différentes bases de données. 1. SCM : Supply Chain Management.

125 7.3 Robustesse d un processus métier 107 Si le moteur de processus a un problème, c est-à-dire si le processus en question s arrête brutalement, son Dossier devra être effacé (ce qui est très simple si le Dossier n existe qu en mémoire centrale du serveur accueillant le moteur), et le processus pourra être repris sans précaution particulière. Si on reprend l exemple, le processus modélisé par la figure 7.1 est modifié comme illustré par la figure 7.2. L activité «vérifier et réserver stock» devient l activité «vérifier stock» : elle consulte les bases de données du ou des entrepôts susceptibles d avoir en stock le produit commandé, puis elle écrit dans le Dossier l entrepôt choisi pour fournir les produits. L activité «vérifier et réserver transport» devient l activité «vérifier possibilité transport» : elle consulte le ou les transporteurs candidats, puis elle écrit dans le Dossier le transporteur choisi pour livrer les produits. Une nouvelle activité est introduite : l activité «réserver stock et transport». Elle consiste à exploiter le contenu du Dossier pour transmettre les réservations à l entrepôt et à la société de transport sélectionnés. Vérifier commande Vérifier stock Vérifier possibilité transport Réserver stock & transport Envoyer réponse Figure 7.2 Modèle de processus «isolé» Analyse La première conséquence visible est qu il faut modifier le processus d un point de vue métier. Sur le plan méthodologique, ce n est pas gênant si la réflexion sur la robustesse est prise en compte dès le départ, c est-à-dire si cette modification ne résulte pas d une prise de conscience tardive de la problématique. La seconde conséquence est que, sur le plan purement métier, ce type de solution peut poser le problème suivant : si le processus est trop «lent», les stocks concernés n auront-ils pas été entre-temps utilisés par un autre processus? La même question se

126 108 Chapitre 7. Robustesse et performance d un processus métier pose pour le transporteur : sera-t-il toujours disponible au moment de la réservation effective? On peut envisager deux réponses à cette question : Ignorer la question, c est-à-dire ne rien faire ce qui est de loin la réponse la plus simple! Effectuer des «préréservations». Ignorer la question, c est supposer que l exécution du processus sera suffisamment rapide pour que la probabilité d échec de la réservation finale soit très faible. En cas d échec, le processus est rejoué depuis le départ, en effaçant son Dossier. Pour adopter cette réponse, il est nécessaire de mener une étude préliminaire des paramètres de traitement : fréquence d arrivée des commandes, probabilité que deux commandes portent sur le même produit dans le même laps de temps, rapidité de traitement de ces commandes... On voit ici que robustesse et performance sont très liées. La seconde réponse, mettre en place des «préréservations», est décrite dans le paragraphe suivant Solution n 3 : processus avec préréservations Principe Le contexte de la solution est que le processus est rendu robuste via le concept de Dossier, mais il doit interagir avec le monde extérieur pour réserver des ressources. Le principe de la solution est de mettre en place un concept de préréservation, comme modélisé par la figure 7.3. Réservation non confirmée Vérifier commande Vérifier & préréserver stock Vérifier & préréserver transport Confirmer résa stock & transport Envoyer réponse Figure 7.3 Modèle de processus isolé avec préréservations

127 7.3 Robustesse d un processus métier 109 Analyse En fin de processus, l activité «réserver stock et transport» devient «confirmer les préréservations». Chaque préréservation est associée à une durée de vie (équivalent d un time out) : les préréservations qui dépassent leur durée de vie sont simplement supprimées. La durée de vie d une préréservation est définie en fonction de la durée moyenne d exécution d un processus. Ainsi, si un processus se plante et est rejoué une seconde fois, les préréservations effectuées lors de la première exécution du processus finiront par être supprimées, sans autre préjudice que d avoir bloqué un produit en stock pendant quelques dizaines de secondes ou quelques minutes. Cette solution implique que chaque fournisseur de service (ici, la gestion de stock et la société de transport) mette en place un tel concept dans son système d information. Lorsque le fournisseur de service est une entreprise extérieure, cela implique une négociation qui dépasse probablement les prérogatives de la direction informatique. Autre conséquence : si, de façon extraordinaire, un processus constate que ses préréservations ont été supprimées avant qu il les confirme, il devra simplement être rejoué depuis le début. Ceci ne pose pas de problème technique, en revanche cela entraîne une perte de performance d exécution voire le non-respect de l engagement de service pris pour traiter une commande. Il faut donc que cette situation soit statistiquement rare : pour cela, la durée d une préréservation doit être d un ordre de grandeur supérieur à la durée d exécution moyenne d un processus Solution n 4 : prévoir des points de reprise du processus Principe Analyse Les solutions précédentes fonctionnent, mais ne sont pas simples à mettre en œuvre si on les regarde dans le détail. Y a-t-il alors une solution plus simple? La solution proposée ici repose sur le principe de la mise en place de points de reprise du processus. Plus précisément, le processus sauvegarde régulièrement son état courant, comme l illustre la figure 7.4. On parle de point de reprise. En cas de problème, le processus redémarre au dernier point de reprise sauvegardé. Cette solution est d autant plus intéressante que l on peut confier au moteur le soin d effectuer lui-même ces sauvegardes, en le paramétrant convenablement. La plupart des moteurs BPEL offrent cette possibilité. À première vue, cette solution est la plus simple puisque le moteur d exécution de processus prend lui-même en charge la mise en œuvre de la solution. On la privilégiera, en étant cependant bien conscient de deux problèmes potentiels. D abord, cette solution a un coût important sur le plan des performances (écriture en bases de données). À tel point (cf. section 6.4) que l une des principales recommandations pour optimiser la performance d un processus est de minimiser le nombre de points de reprise.

128 110 Chapitre 7. Robustesse et performance d un processus métier Vérifier commande Vérifier et réserver stock Sauvegarde état processus Réserver transport Sauvegarde état processus Envoyer réponse Figure 7.4 Modèle de processus avec points de reprise Ensuite, il faut être conscient qu il existe des failles dans cette solution. Par exemple, que se passe-t-il si le processus «plante» pendant ou juste après l exécution d une activité, mais avant que la sauvegarde d état ait eu lieu? La reprise du processus entraînera la réexécution de l activité... et on en revient aux discussions concernant les solutions précédentes Conclusion sur la robustesse des processus Pour assurer la robustesse des processus, on étudiera en priorité la solution «rendre les processus robustes en prévoyant des points de reprise». Cependant, il faudra étudier en complément la possibilité de mettre en place soit des services auto-défensifs contre une réexécution (gestion d un identifiant de requête), soit une gestion de l isolation des processus via un Dossier. Ces solutions peuvent éventuellement être des alternatives si la solution des points de reprise est intolérable sur le plan des performances, ou si sa robustesse est jugée insuffisante. 7.4 PERFORMANCE D UN PROCESSUS MÉTIER Enjeux La performance d un processus métier se mesure par le temps d exécution unitaire du processus et le nombre de processus exécutés par unité de temps.

129 7.4 Performance d un processus métier 111 Dans l exemple «Fil Rouge», on fixera par exemple comme objectifs : un traitement d une commande en moins de 30 secondes (temps d exécution unitaire) et la possibilité pour la plate-forme de traiter 10 commandes par minute. L atteinte de ces objectifs de performance repose donc sur la possibilité d exécuter plusieurs processus en parallèle : l exemple proposé montre qu une exécution séquentielle permet de traiter au maximum deux commandes par minute. Comme l illustre la figure 7.5, un parallélisme excessif fait chuter la performance unitaire d exécution et, à partir d un seuil, ne permet plus de montée en charge linéaire (à partir de ce seuil, le retour sur investissement économique devient donc difficile à justifier). L enjeu est donc de trouver le point d équilibre entre performance unitaire, montée en charge et concurrence d exécution. Performance Montée en charge Temps d exécution unitaire Source : ORACLE Seuil Nombre de processus s exécutant en parallèle Figure 7.5 BPM (Business Process Management) : performance unitaire versus montée en charge Éléments de solution Principes La question principale porte sur l architecture générale à mettre en place, et en particulier sur les accès au moteur de processus, ce moteur risquant d être un «goulet d étranglement». Lorsqu un événement métier arrive (par exemple une commande sous forme d un message XML), les objectifs de cette architecture doivent être : de permettre la création et l exécution rapide d un nouveau processus traitant cet événement métier ; de permettre la montée en charge, c est-à-dire le parallélisme de traitement. Le principe de la solution est de «désynchroniser» l arrivée des messages et l activation du moteur. Pour cela, on met en place des files d attente, ou queues, dans

130 112 Chapitre 7. Robustesse et performance d un processus métier lesquelles le ou les frontaux (serveur réceptionnant les messages XML ou application interactive de type portail) déposeront les messages à traiter par le moteur de processus. La figure 7.6 positionne l architecture proposée. S. I. Client Application Application Point d entrée SI <PROCESSUS> <PROCESSUS> Service <PROCESSUS> Service métier métier TRAITER Service métier TRAITER UNE métier TRAITER UNE COMMANDE UNE COMMANDE UNE COMMANDE Point d entrée WS Point d entrée WS <CRUD> Service <CRUD> métier CATALOGUE Service métier CATALOGUE <TECH> <TECH> Mapping Mapping O/R O/R S.I. Entreprise Fil Rouge <CRUD> Service <CRUD> métier Service STOCK métier STOCK <TECH> Accès Legacy SGBDR SGBDR LEGACY LEGACY Figure 7.6 Rôle et place de l architecture asynchrone Plus précisément, cette architecture implique la mise en place de trois composants, comme l illustre la figure 7.7 : les files d attente : ce sont par exemple des queues JMS (dans le monde Java) ; les listeners, c est-à-dire des composants chargés d espionner les files d attente, de dépiler les messages, et enfin d activer le moteur : ce sont par exemple des MDB, Message Driven Bean ; le moteur proprement dit, multithreadé : chaque thread est créé par un des listeners pour traiter un message.

131 7.4 Performance d un processus métier 113 File d attente Listeners Moteur BPEL SERVICE SERVICE SERVICE Sauvegarde état processus Figure 7.7 Zoom sur l architecture asynchrone Les risques de goulet d étranglement Le tableau 7.1 analyse les risques de goulet d étranglement, et donne ainsi les clefs de la performance d une telle architecture (en gras, les préconisations les plus efficaces). Le dimensionnement des files d attentes, le nombre de listeners, le paramétrage des threads et la mise en place d un cluster sont donc autant d éléments à dimensionner convenablement, puis à vérifier, en phase de conception de l architecture, puis en phase d intégration.

132 114 Chapitre 7. Robustesse et performance d un processus métier Tableau 7.1 Les risques de goulet d étranglement Problème Diagnostic Élément de solution File d attente engorgée Moteur BPEL sous utilisé Goulet d étranglement = listener Augmenter le nombre de listeners. Augmenter le nombre de files d attente. Demander à un listener de dépiler plusieurs messages à la fois. Si nécessaire (monde Java) : utiliser directement les API JMS (MessageListener) et non pas les MDB. File d attente engorgée Moteur BPEL saturé Goulet d étranglement = moteur Minimiser le nombre de sauvegarde d état des processus (c est à dire minimiser l accès à la base de données associée). Optimiser le paramétrage du moteur : augmenter le nombre de threads, diminuer les écritures dans les fichiers de log et d audit. Si cela ne suffit pas : rajouter un nœud de traitement au cluster. File d attente non engorgée Moteur BPEL non saturé File d attente non engorgée Moteur BPEL non saturé Goulet d étranglement = service appelé Goulet d étranglement = application cliente Veiller à la granularité des services invoqués. Transformer les appels des services via SOAP en appel Java ou C# (c est à dire ne pas déployer les services en WS quand c est possible). Sinon appliquer le chapitre 6. Dédier une file d attente prioritaire pour chaque application cliente. Demander à une application cliente d empiler dans la file plusieurs messages à la fois. Quelques points clefs La performance du moteur BPEL Un premier point clef concerne la performance du moteur, en particulier vis-à-vis de la sauvegarde de l état de chaque processus en cours d exécution. On a vu (cf. section 7.3.5) l importance de cette sauvegarde. Or, cette sauvegarde peut potentiellement avoir à écrire en base de données, une masse importante d informations, ce qui constitue un risque sur les performances. D où l intérêt de pouvoir paramétrer finement cette sauvegarde : dans certains cas, il n est pas nécessaire de sauvegarder l ensemble des informations du contexte, mais uniquement l identité des entités racines. Dans l exemple «Fil Rouge», il est inutile de sauvegarder l ensemble des objets du contexte (commande, client, produit, etc.) dans la base de sauvegarde ; l identité de la commande peut suffire. Mais cela suppose que le moteur, lorsqu il

133 7.5 Conclusion : les architectures de déploiement 115 restaure l état d un processus à reprendre, sache reconstituer cet état à partir de ces éléments minimums. Or, beaucoup de moteurs se contentent de sauvegarder le contexte du processus BPEL en «bloc», et de restaurer «en bloc». La performance des services invoqués Un autre point clef concerne la performance des services appelés par le moteur. En effet, celui-ci n est jamais qu un orchestrateur enchaînant les appels de service. La performance d un processus dépend certes du moteur mais également des services appelés. Les éléments de solution présentés au chapitre précédent pour accélérer les services peuvent donc s appliquer. Cependant, une remarque s impose : un moteur BPEL ne sait, en principe, invoquer que des web services. Or, il pourrait être plus performant d utiliser des services «non distribuables», c est-à-dire des services déployés sous forme de simples composants Java ou C#, ceci afin d éviter de passer systématiquement par l étape sérialisation/désérialisation XML objet. Comme il existe des moteurs BPEL capables d appeler directement du Java (ou du C#, dans le cas de l outil de Microsoft, WWF 1 ), ce point peut faire partie des critères de sélection du moteur BPEL. Une remarque sur la remarque : qu un moteur BPEL sache invoquer un service directement sans passer par l infrastructure web service, très bien. Mais l architecte doit être vigilant sur la granularité des services invoqués. Il ne faut pas utiliser cette facilité pour faire du moteur BPEL un orchestrateur de microservices, c est-à-dire faire de BPEL un langage de programmation. Cela multiplie les appels de service, ce qui est de toute façon très néfaste pour les performances (et pour la robustesse) : le moteur devient une mitrailleuse à requêtes! Règle : ne pas utiliser BPEL comme un langage de programmation, mais bien comme un langage de description de processus métier! 7.5 CONCLUSION : LES ARCHITECTURES DE DÉPLOIEMENT Au terme de ce chapitre, il est intéressant de conclure sur les architectures de déploiement possibles pour une plate-forme reposant sur un moteur de gestion de processus (BPM), que l on souhaite performante et robuste. Cette conclusion peut aussi être vue comme une introduction apéritive à la troisième partie, qui détaille certains aspects importants comme la gestion de cluster. La première architecture de déploiement possible est proposée par la figure 7.8. Cette architecture est dite «horizontale», parce qu elle dédie un serveur ou un cluster de serveur à chaque «couche» de composant : points d entrée des événements métier, file d attente, moteur de processus et ses listeners, services métier et enfin base de 1. WWF : Windows Workflow Foundation.

134 116 Chapitre 7. Robustesse et performance d un processus métier données. Ce type d architecture est certes intéressant par ses capacités intrinsèques de performance et de robustesse, mais il est bien évident qu il est complexe à déployer, à paramétrer et à superviser. Figure 7.8 Architecture de déploiement «horizontale» Une alternative est apparue plus récemment avec les architectures dites «verticales». Ce type d architecture consiste à limiter le nombre de serveurs et à concentrer sur un seul serveur l ensemble des composants permettant de gérer un processus métier. La figure 7.9 illustre le propos. Ce type d architecture apparaît clairement plus simple, mais n est-ce pas au détriment des performances et surtout de la robustesse? En ce qui concerne la performance unitaire, cette architecture limite le «passage des frontières», signalé au chapitre 6 comme étant une des causes majeures de non-performance. Pour ce qui concerne la montée en charge, le recours à des serveurs plus puissants (serveurs SMP) est une solution simple.

135 7.5 Conclusion : les architectures de déploiement 117 Figure 7.9 Architecture de déploiement «verticale» Mais quid de la robustesse? Pour obtenir le niveau de robustesse adéquat, il est nécessaire qu en cas de panne d un serveur «vertical», l autre serveur soit capable de prendre le relais : ceci implique notamment que les deux serveurs partagent tous les messages entrants, quelle que soit la file d attente concernée. Ceci peut se faire en utilisant de nouveaux outils, qui permettent de mettre en place une mémoire «partagée» par différents serveurs, de façon transparente pour les applications déployées. Les files d attente sont alors placées dans cette mémoire partagée. Ces outils (on citera Terracotta et Gigaspaces), bien que récents, suscitent d ores et déjà beaucoup d intérêt. La figure 7.10 illustre le propos. Il est important de noter que certains de ces outils ont des versions Open Source : ceci permet au minimum de se former puis de réaliser des applications pilotes concrètes à moindre frais, avant de décider de généraliser ce type d architecture.

136 118 Chapitre 7. Robustesse et performance d un processus métier Mémoire partagée Figure 7.10 Architecture de déploiement «verticale» avec mémoire partagée Une remarque importante : cette architecture «verticale» avec mémoire partagée est compatible avec les différentes solutions «logicielles» de robustesse. En particulier, si le moteur est capable d écrire dans la mémoire partagée l état correspondant à un point de reprise (cf. section 7.3.5) : La reprise de l exécution du processus par le serveur n 2 suite à un plantage du serveur n 1 peut s effectuer très rapidement. Les performances sont globalement meilleures puisque les points de reprise ne sont plus sauvegardés dans une base de données mais dans une mémoire partagée gérée en RAM. De la même façon, l objet Dossier, évoqué dans la section 7.3.3, peut également être partagé par les deux serveurs la mise en place de cette solution ne dépend pas de l éditeur du moteur BPEL, mais de l architecte de la solution.

137 7.5 Conclusion : les architectures de déploiement 119 En résumé L obtention d un haut niveau de robustesse est l une des clefs du déploiement de processus automatisés au cœur des métiers de l entreprise. Le chapitre décrit et analyse plusieurs approches pour rendre robuste un processus. L approche s appuyant sur des «points de reprise» présente le meilleur compromis simplicité/efficacité. Mais elle peut poser des problèmes de performance, d où l intérêt de présenter d autres approches de robustesse. La performance peut être un autre point clef, en particulier la capacité de montée en charge. L obtention d un bon niveau de performance s appuiera sur une architecture logicielle adaptée, s appuyant sur une utilisation raisonnée de l asynchronisme. Le chapitre analyse les goulets d étranglement possibles et les mesures correctives. Le chapitre conclut sur les infrastructures de déploiement adaptées au déploiement de processus métier, en mettant en évidence le lien indissoluble entre robustesse et performance.

138

139 8 Performance d une solution métier Objectif Dans l architecture d un SI moderne, les services sont des composants nécessaires mais pas suffisants pour répondre aux besoins des utilisateurs et des métiers. Il est nécessaire de penser non seulement «services» mais aussi «solution métier». Après avoir très brièvement rappelé ce qu on entend par solution, l objectif du chapitre est de présenter les problématiques de performance et de robustesse rencontrées lorsqu on conçoit l architecture d une solution métier. Un SI moderne, comme l a rappelé le chapitre 5, a pour objectif premier de permettre à l entreprise de traiter les événements métier que lui envoient ses clients, ses prospects, ses partenaires commerciaux, etc. Pour traiter un événement, comme la réception d une commande dans l exemple «Fil Rouge», les acteurs de l entreprise s appuieront sur des processus plus ou moins automatisés, et sur des applications interactives. Ces composants logiciels s appuieront à leur tour sur les services métier et les services techniques nécessaires. On désigne par solution métier, l ensemble des composants qu il faut déployer pour traiter un événement métier (ou un ensemble d événements métier). Ces composants seront notamment : les applications interactives front-office/middle office/back office ; les processus métier, automatisés (BPEL) ou non ; les services métier ;

140 122 Chapitre 8. Performance d une solution métier les batchs métier ; les services techniques ; les batchs techniques (synchronisation de référentiel, impression en masse, etc.) ; les bases de données, référentiels. La performance et la robustesse des services et des processus sont nécessaires mais pas suffisantes pour assurer la performance et la robustesse globale d une solution métier. Il est nécessaire de tenir un raisonnement global, prenant en compte tous les composants de la solution. Pour étudier les performances d une solution au sein d une architecture de services, le présent chapitre procédera donc par étapes : il étudiera tout d abord la problématique de la performance globale d une solution, en analysant le lien entre une application interactive, les services dont elle est cliente, et la ou les bases de données associées ; il étudiera ensuite la robustesse d une solution ; enfin, il abordera la question délicate de la performance d un Portail, qui est positionné dans une SOA comme la structure d accueil des applications interactives d une solution. 8.1 LA PERFORMANCE D UNE SOLUTION Enjeux : le problème des listes longues L enjeu de performance est lié aux différentes architectures possibles pour réaliser une application interactive et la relier aux services dont elle est cliente. Le problème est plus particulièrement lié aux différents «étages» qu une information parcourt, depuis le disque sur laquelle elle est persistante, jusqu à la page qui affiche cette information. Pour illustrer cette problématique, on va s appuyer sur l analyse de l application de consultation du catalogue Produit de l exemple «Fil Rouge», et plus précisément sur un cas de figure représentatif, fréquemment rencontré dans les SI : la gestion des «listes longues». Le cas d utilisation est le suivant : l utilisateur final invoque l application interactive de consultation du catalogue ; l application affiche l écran de recherche dans le catalogue : cet écran est un formulaire permettant de sélectionner et de valoriser les critères de recherche pertinents. Par exemple, l utilisateur peut rechercher tous les produits de la catégorie «peinture à l eau», bénéficiant d un label «peinture bio», et livrables dans la région «Centre» ; l utilisateur valide l écran de recherche ; l application lance la recherche dans la ou les bases de données concernées ; l application affiche le résultat de la recherche dans un écran listant l ensemble des résultats.

141 8.1 La performance d une solution 123 L application est réalisée selon le modèle MVC adapté au contexte SOA. On distingue donc : les vues : écran affichant le formulaire de recherche, écran affichant la liste des résultats ; le contrôleur : composant logiciel «chef d orchestre» de l application : il récupère le formulaire de recherche, lance la recherche en faisant appel au service d accès au catalogue, récupère le résultat de la recherche, active l affichage de l écran de résultat ; le modèle : composant stockant les objets métier récupérés en tant que résultat de l invocation de services métier par le ou les contrôleurs de l application son rôle dépend de la conception de l application, et en particulier du comportement exact du contrôleur ; le service métier CRUD d accès au catalogue ; la base de données. Du point de vue performance, ce cas d utilisation pose plusieurs questions : Quel doit être le comportement de l application (de son contrôleur, essentiellement) lorsqu une recherche peut fournir plusieurs dizaines voire plusieurs centaines ou milliers de résultats possibles c est ce qu on appelle la gestion des listes longues? Comment afficher rapidement la liste des régions, la liste des catégories de produit, etc., dans le formulaire de recherche affiché par le navigateur? On suppose ici que l utilisateur ne saisit pas au clavier ce genre d information, mais qu il choisit dans une liste déroulante la valeur désirée (ce qui minimise les erreurs de saisie et améliore l ergonomie de l application). On remarquera que l optimisation des opérations de recherche peut également avoir un intérêt dans le cas où l application cliente n est pas une application interactive, mais est un batch. Un batch peut traiter des listes potentiellement longues, et dans ce cas la discussion qui suit s applique tout autant sinon plus. Principe de base : la pagination mais quelle pagination? Sur le plan métier, on sait qu afficher une liste «longue» dans un seul et même écran obligera l utilisateur à se déplacer («scroller») dans la liste. Du point de vue utilisateur, c est très peu ergonomique et à proscrire. D un point de vue technique, l affichage en tant que tel de ce méga écran peut être très long. L affichage doit donc être paginé : cela signifie que l application découpe la liste de résultat en sous-listes de n items (n = 5, 10, 20, rarement plus), et elle affiche les résultats obtenus page par page, chaque page contenant une sous-liste. La question devient donc : comment gérer la pagination? Une solution simple consiste à : ouvrir un curseur sur la base de données ; via le curseur, récupérer la liste longue item par item ; transformer la liste longue en autant d objets métier ;

142 124 Chapitre 8. Performance d une solution métier passer la liste d objets à l application ; l application découpe elle-même la liste en sous-listes. Cette solution souffre évidemment de l anti-pattern «traversée de frontière» : frontière entre le monde SQL et le monde Objet (Java, C#, etc.), et au sein du monde Objet, frontière entre l interface SQL (JDBC dans le cas de Java) et le monde des objets métier. Elle cumule en effet tous les coûts : coût d exécution de la requête par le moteur de base de données ; coût de la récupération de la liste via le curseur, ce qui multiplie les échanges réseaux si la base de données est physiquement séparée du serveur d application Java hébergeant l application ; coût des transformations successives [données tabulaires SQL] > [structure JDBC] > [objets métier]. Si la liste est vraiment très longue, on peut de plus avoir les problèmes suivants : Si on utilise un pool de connexion (géré par le serveur d application par exemple), la connexion utilisée par une telle recherche va être accaparée longtemps : le nombre de connexion étant en nombre fini dans le pool, il peut y avoir un problème de montée en charge si trop d utilisateurs lancent des recherches simultanément. La JVM (Java Virtual Machine) peut avoir un problème de gestion mémoire si le volume d objets (objets JDBC, objets métier) à gérer est trop élevé. En conclusion, si la liste de résultats est vraiment longue (et c est l hypothèse de travail), non seulement il ne faut pas l afficher «en bloc» (dans un seul écran), mais il ne faut pas non plus la récupérer «en bloc». Il est donc non seulement nécessaire de paginer l affichage visuel mais également d essayer de paginer l accès aux données. La mise en place d un seuil limite Cependant, avant toute recherche effective, il est indispensable dans un premier temps de (se) poser la question suivante : la récupération d un trop grand nombre d objets métier a-t-elle un sens sur le plan métier? En effet, il est rare qu un utilisateur ait besoin d afficher plusieurs milliers de résultats, ou ait le loisir de naviguer dans des dizaines de pages... L application interactive doit donc, avant de lancer la récupération effective des résultats, vérifier la taille de la liste longue. Le service métier CRUD concerné (dans notre exemple : le service CRUD catalogue Produit) doit donc offrir une opération liretailleresultatrecherche(criteresderecherche). L opération sera par exemple implémentée directement via un SELECT COUNT * FROM tableproduit, classique. Si la taille dépasse un seuil N fixé par la maîtrise d ouvrage, l application ne lance pas la recherche et demande alors à l utilisateur de compléter les critères de recherche. Dans notre exemple, si l utilisateur lance par inadvertance la récupération de l ensemble du catalogue, l application affichera un message «désolé, votre recherche conduit à un trop grand nombre de résultats, veuillez affiner cette recherche».

143 8.1 La performance d une solution 125 Présentons maintenant deux grands types de solution pour gérer la pagination globale d une liste longue : Les solutions orientées «optimiser les requêtes à la base de données». Les solutions orientées «gérer un cache applicatif» Éléments de solution : gérer les listes longues en optimisant les requêtes à la base de données Ce type de solution part du principe qu un moteur de base de données relationnelles est un composant très performant, et qu il sera toujours plus efficace de se reposer sur ce composant pour obtenir les performances adéquates. Ceci suppose que la méfiance ancestrale entre les architectes «objets» d une part et les DBA de l autre a disparu, mais ce n est pas le sujet ici. On notera simplement que cela implique une organisation adaptée pour mieux faire communiquer ces profils au sein d un projet. La recherche paginée d une liste longue : esquisse d une solution standard Présentation de la solution Le service CRUD d accès au catalogue offre une opération de recherche (le R de CRUD) ayant une signature ressemblant à : rechercherunepagedexxx(criteresderecherche,taillepageaffichee, numeropage) XXX représente l entité métier sur laquelle porte la recherche (ici, ce sera rechercherunepagedeproduit()). Les paramètres sont : la liste des critères de recherche ; la taille d une page, c est-à-dire le nombre de résultats à afficher par page (le nombre n) ; le numéro de la page recherchée ou le rang m du premier résultat à obtenir ce qui revient au même : rang premier résultat = (taille page * (numéro page 1)) + 1. Le service renvoie une liste d objets correspondant à la page à afficher. Le principe de l implémentation du service consiste à ouvrir un curseur SQL «scrollable» sur la base de données, et à l utiliser pour récupérer les résultats de la recherche. Le code suivant donne une idée de la solution en pseudo code JDBC JDBC 4.0 du fait de l utilisation de DriverManager mais, à part cela, ce pseudo code est compatible avec JDBC à partir de la version 2.0, c est-à-dire à partir de l apparition des scrollableresultset. Les programmeurs Java expérimentés voudront bien ne pas s attarder sur les multiples omissions de ce pseudo code (gestion des exceptions, de la connexion, etc.), mais l objectif n est pas ici d écrire un cours sur l utilisation de JDBC.

144 126 Chapitre 8. Performance d une solution métier { // //on récupère une connexion sur la base de données // (1) maconnexion=drivermanager.getconnection(mabasededonnees) ; (2) marequete=maconnexion.createstatement() ; // //on crée la requête SQL // (3) string requetesql= SELECT * FROM +matable+ WHERE +<criteresderecherche> // // on demande au moteur de base de données d exécuter la requête // puis on récupère le curseur associé au résultat // le curseur est une instance de resultset, la classe de base de JDBC // pour représenter un curseur ouvert sur une base de données // relationnelle. // Plus exactement, il s agit d un scrollableresultset, // qui offre des possibilités de navigation étendues // (4) moncurseur=marequete.executequery(requetesql) ; // //on calcule le rang du premier item de la page à afficher // (5) premieritemdelapage=(numeropage-1)*taillepageaffichee + 1 // //on positionne le curseur sur cet item // (6) moncurseur.absolute(premieritemdelapage) ; (7) i = 1 ; // //on récupère les items de la page et on les transforme en objets // à afficher // (8) while(moncurseur.next() and i < taillepageaffichee) (9) {unresultatdelapage=transformerenobjet(moncurseur) ; (10) lalisteaafficher=lalisteaafficher.add(unresultatdelapage) ; (11) i=i+1 ;} (12) moncurseur.close(); (13) marequete.close() ; (14) return lalisteaafficher ; } Lignes 1-2 : on récupère une connexion sur la base de données, puis on crée une requête «vide». Ligne 3 : on crée la requête SELECT. Ligne 4 : on demande au moteur de base de données d exécuter la requête : le résultat est un curseur «pointant» sur le résultat. Le curseur est une instance de resultset, la classe de base de JDBC pour représenter un curseur ouvert sur une base de données relationnelle. Plus exactement, il s agit d un scrollableresultset, qui offre des possibilités de navigation étendues. Ligne 5 : on calcule le rang du premier item de la page à afficher. Ligne 6 : on positionne le curseur sur cet item.

145 8.1 La performance d une solution 127 Lignes 8-11 : on récupère les items de la page et on les transforme en objets à afficher. Analyse de la solution Cette solution suppose qu une condition soit remplie : le support de curseur «scrollable» par le moteur de base de données. En effet, dans certains cas (version ancienne d Oracle par exemple), ce support n est pas natif : le driver JDBC émule alors le curseur scrollable et pour cela récupère la totalité de la liste. La liste complète des résultats transite donc sur le réseau entre le moteur de base de données et le monde objet, à l insu du concepteur logiciel. Attention donc aux choix d infrastructure! Supposons la condition remplie : la liste complète des résultats ne transite pas «sur le réseau» entre le moteur SQL et le monde objet. Cette solution évite bien le syndrome de la traversée de frontière. Cependant, elle souffre encore de quelques problèmes potentiels. Le premier problème concerne le moteur de base de données. Celui-ci reçoit et exécute la requête SQL, et il construit de toute façon la liste complète des résultats dans son espace propre, alors qu en fait on ne s intéresse qu à une sous-liste : le moteur travaille inutilement. Le deuxième problème est lié au driver JDBC. Celui-ci récupère un par un les résultats (chaque fois que next() est invoqué) en base de données et les fournit au service : il y a donc autant d allers-retours avec la base qu il y a d items à récupérer. Même si ces échanges sont limités en nombre (en fonction de la taille de la page), ce n est pas nécessairement efficace (le syndrome de la mitrailleuse à requêtes guette). Le troisième problème concerne la navigation dans les pages. Si l utilisateur revient à une page déjà affichée, l application relancera une requête déjà effectuée, donc demandera un travail inutile. Avant de proposer des optimisations pour résoudre ces problèmes, il faut préciser que si l absence de performance nuit gravement à la santé d une solution, le mieux est également l ennemi du bien. Autrement dit, il faut d abord être bien sûr que ces problèmes ont un impact notoire sur les performances avant de lancer une phase d optimisation. Quelques optimisations possibles Paramétrer le cache du moteur Une première optimisation est de paramétrer correctement le moteur pour que, suite à la première requête (qui rapatrie la première page vers l application), il garde la liste complète en mémoire cache. Dans ce cas, le moteur n aura plus besoin de réexécuter la requête SQL sauf si le cache est invalidé par la mise à jour (par un autre utilisateur) d une donnée présente dans le cache. Évidemment, cette optimisation n est intéressante que si l utilisateur navigue dans plusieurs pages : si, statistiquement, il ne s intéresse qu à la première page, le cache SQL n aura pas d impact puisqu il n y aura qu une seule invocation du service CRUD.

146 128 Chapitre 8. Performance d une solution métier Optimiser les requêtes L idée ici est d aider le moteur à ne pas construire tout de suite la liste complète des résultats. Une première optimisation possible et simple est d utiliser la clause LIMIT : RequeteSQL = SELECT... FROM... WHERE <criteresderecherche> LIMIT m OFFSET n Cette clause demande au SGBDR de récupérer n items à partir de l item de rang m. Cette clause est supportée par exemple par les SGBDR MySQL et PostgreSQL. Il est facile de coder l équivalent en PL/SQL ORACLE (via des requêtes imbriquées). Encore faut-il être certain que le moteur ne soit pas obligé de construire la liste complète pour pouvoir gérer le positionnement sur l item de rang m! Car sinon, on ne gagne rien en matière de performance. Une solution plus intéressante serait d utiliser un identifiant unique (clef primaire, index unique) de chaque ligne tabulaire : RequeteSQL = SELECT... FROM... WHERE < criteresderecherche>, rowid BETWEEN m AND m+n-1 ORDER BY rowid ASC Hélas, ce n est pas si simple : il n est pas possible de garantir que les identifiants soient contigus, sans «trou» 1, à moins de gérer à la main cet identifiant unique, ce qui est un prix sans doute excessif à payer. Cette solution basée sur les identifiants uniques ne fonctionne que si la pagination se fait en séquence, d une page à la page suivante (ou précédente), sans saut de page. Dans ce cas, on modifiera le traitement comme suit. D une part, on utilise la requête suivante : RequeteSQL = SELECT... FROM... WHERE < criteresderecherche>, rowid > lastrowid ORDER BY rowid ASC Cette requête récupère a priori tous les résultats de la page demandée, mais aussi des pages suivantes : il faut donc demander au moteur de ne chercher que le nombre correspondant à une page, et pour cela, on utilise moncurseur.setmaxrows(taillepageaffichee). Cette solution nécessite que l application gère un contexte permettant de mémoriser le dernier identifiant récupéré, lastrowid, et que ce contexte devienne un paramètre d appel du service CRUD. 1. Il existe de multiples raisons pour lesquelles, à un moment donné, la liste des entiers correspondant aux identifiants est une liste «à trou» : suppression d item, partitionnement de la table, etc. Les DBA luttent contre ce phénomène, nuisible de façon générale aux performances, mais cela implique des restructurations elles-mêmes coûteuses en temps : leurs interventions ne s effectuent pas en continu. D où la présence de ces trous.

147 8.1 La performance d une solution 129 Minimiser le coût du réseau Une optimisation possible et simple est de demander au curseur de rapatrier (entre le driver et le moteur de base de données) les résultats non plus un par un (paramétrage standard), mais n par n. Pour cela, on utilisera moncurseur.setfetchsize(taillepageaffichee). Là encore, il faut vérifier que l infrastructure mise en place (driver JDBC et moteur de base de données) supporte une telle optimisation. Dans un monde distribué, un autre moyen d optimiser le coût réseau est de mettre en œuvre le principe de convoyeur Un convoyeur est une sous partie des attributs d un objet métier utilisés dans certaines vues particulières d une application. L avantage d utiliser un convoyeur est que l on ne transporte qu une sous-partie des attributs et non l intégralité de ceux de l objet métier. Dans le cas des EJB ou de CORBA, il a aussi l avantage de ne pas contenir de méthode ce qui allège grandement le poids des données transportées. Il a également l avantage d alléger la charge au niveau de la base puisque l on ne recherche que les données que l on va réellement afficher. Attention cependant aux deux points suivants : Ne pas mettre en œuvre autant de convoyeur que de vue du même objet métier car sinon on augmente de façon non négligeable la complexité de l application. Si votre application utilise un cache, la mise en œuvre de convoyeur peut surcharger ce dernier. En effet, on trouvera dans le cache à la fois les objets métier mais également leurs convoyeurs. Anticiper L utilisateur consulte la page courante p. L application peut alors anticiper sur les besoins futurs de l utilisateur, en faisant le pari qu il va consulter les pages suivantes p+1, p+2, etc. La première anticipation possible est de rapatrier plus d information qu il est nécessaire pour afficher une page. Par exemple, l application récupérera en une seule requête les éléments de la page courante et ceux de la page suivante. Une fois sur deux, l application n aura pas à invoquer le service, mais chaque invocation du service sera un peu moins performante. Malgré cela, le gain en performance est le plus souvent appréciable. Cette optimisation est simple en soi, mais elle implique que l application mette en place un cache applicatif pour garder en mémoire les résultats non encore affichés. La seconde anticipation possible consiste à lancer le chargement d une page de façon asynchrone, «en tâche de fond». Lorsque l utilisateur demande l affichage de la page p, l application lance le chargement de la page p+1 de façon asynchrone. Ceci implique que l application soit multithreadée : ce niveau de complexité doit être réservé à des cas de figure particuliers.

148 130 Chapitre 8. Performance d une solution métier Un bref retour sur les web services Il est intéressant de noter que la communauté des web services a récemment pris en compte cette problématique de la gestion des listes longues, via un processus de normalisation entamé en 2006 par le W3C. Cette norme, WS-ENUMERATION 1, standardise le dialogue entre un client et un service de type «accès à des informations», lorsque ce dialogue ne peut se contenter d un seul échange une requête/une réponse pour obtenir le résultat attendu, parce que ce résultat est précisément une «liste longue». Elle repose essentiellement sur deux messages au sens WSDL : enumerate ; pull. La requête enumerate permet au client de prévenir le service concerné qu il va lui demander de répondre à des requêtes de demande d information (les requêtes pull). Le message enumerate peut prendre en entrée un paramètre filter, qui contient une liste des critères de recherche. La réponse enumerateresponse contient l identifiant du contexte qui va permettre ultérieurement au client d interroger le service. Une requête pull permet au client de demander une partie (une «page») des résultats attendus. Cette requête prend en paramètre l identifiant du contexte renvoyé par la requête enumerate, et éventuellement un paramètre précisant le nombre maximal de résultats attendus (la taille de la page). La réponse pullresponse renvoie les résultats demandés, et éventuellement un indicateur endofsequence indiquant que le service a renvoyé tous les résultats disponibles. La réponse peut également renvoyer un nouvel identifiant de contexte. La norme ne précise pas le comportement du service à réception d une requête enumerate. Le service peut lancer effectivement la recherche pour récupérer l ensemble des résultats possibles, ce qui correspond à la solution de base «standard» proposée plus haut. Ou bien il peut attendre une requête pull pour lancer effectivement la recherche sur la source de données concernée, ce qui correspond aux optimisations évoquées. Cependant, le comportement correspondant le mieux à ce qui est normalisé est le suivant : à réception d une requête Enumerate, le service anticipe le lancement d une requête et récupère la liste de résultats (ou, au minimum, la liste des clefs primaires correspondant aux résultats) ; le client lit page par page, de façon séquentielle, les résultats. Il y a autant de requête Pull que de pages à lire ; à chaque envoi de page via une réponse pullresponse, le service envoie également au client un contexte mis à jour, de façon à sauvegarder le numéro de page envoyé. 1.

149 8.1 La performance d une solution 131 Il est difficile de se prononcer sur l avenir de ce processus de normalisation : «encore une norme WS-*!» diront certains lecteurs. D autant que transformer un service CRUD en un web service augmente la probabilité de non-performance en raison du syndrome de la «traversée des frontières», et c est à éviter de façon générale. D autre part, le service respectant la norme doit être stateful (pour gérer le contexte), ce qui complique la conception du service. Enfin, on aurait aimé que le W3C harmonise ses travaux sur WS-Transfer (permettre à une application cliente d effectuer des recherches sur des ressources informationnelles à la mode REST) et sur WS-Enumeration (éviter le syndrome de la liste longue lorsqu une application cliente lance une recherche)... Mais cet effort du W3C montre au moins que le problème de la gestion des «listes longues» est un problème général et endémique, qui conditionne souvent la performance globale d une solution. De plus, il est possible de s inspirer de ce travail pour concevoir un service d accès aux données lorsqu il est obligatoire de déployer ce service sous forme de web service : contrairement à d autres normes WS-*, cette norme est simple à comprendre! Éléments de solution : gérer les listes longues en utilisant un cache applicatif Ce type de solution part du principe que plus les requêtes envoyées au moteur de base de données seront simples, plus l architecture sera globalement performante et simple à déboguer. Il s agit donc de reporter la complexité de la pagination sur l application interactive, c est-à-dire sur son contrôleur (au sens MVC). Principe de la solution L idée de base est que l application récupère l ensemble des clefs primaires des résultats, garde cette liste dans un cache, puis calcule elle-même l accès paginé à la base de données. Les accès à la base de données se font directement, via les clefs primaires, ce qui, si la base est correctement paramétrée/indexée, est la façon la plus performante d accéder aux données. Le service CRUD offre alors deux opérations à l application : RechercherListeDesIdentifiantsDeXXX(criteresDeRecherche) LireGroupeDeXXX(listeDesIdentifiants) La première opération récupère uniquement la liste des identifiants des résultats de la recherche. L obtention de cette liste peut se faire simplement, via un curseur simple (pas besoin d un curseur scrollable) par exemple. Comme on ne ramène qu une colonne, le volume des données transférées (lors du passage de la frontière moteur SQL > monde objet) est limité au maximum. La seconde opération lit directement en base les items d une page via leur identifiant unique. L application garde le résultat de cette opération de lecture groupée dans le cache applicatif. Cette opération repose sur une requête SQL semblable à : RequeteSQL = SELECT... FROM... WHERE rowid IN listedesidentifiants ORDER BY rowid ASC

150 132 Chapitre 8. Performance d une solution métier Intérêt de la solution Cette requête est a priori très rapide (utilisation d un index). Ce type de solution est intéressant voire incontournable dans les cas où : l utilisateur va naviguer dans les différentes pages de résultat, en revenant fréquemment sur des pages déjà affichées ; la source de données n est pas un moteur SQL, mais une application (Cobol sur mainframe, etc.). Lorsque l utilisateur revient sur une page déjà affichée, l application n a pas à relancer une requête déjà exécutée : elle récupère les résultats à afficher dans son cache. En revanche, si l utilisateur n utilise le plus souvent (statistiquement) que la première page, la solution «orientée requête» sera toujours plus efficace (un seul appel de service au lieu de deux). Cette solution est également plus simple à mettre en œuvre (voire la seule autorisée par les architectes) lorsque la source de données n est pas une base SQL (directement accessible via un outil de mapping objet-relationnel ou via JDBC ou ADO.Net), mais une base de données accessible uniquement via une application (progiciel, programme Cobol sur mainframe, etc.). La base est alors opaque du point de vue accès à la base de données (i.e. il n est pas possible d appliquer les optimisations évoquées précédemment) Élément de solution : accéder à des données stables On revient ici sur la problématique de l affichage des listes déroulantes (affichage de la liste des régions par exemple) : la vue doit accéder à un service transverse d accès à ces données pour «anticiper» de façon performante cet affichage. Elle utilisera pour cela des composants graphiques AJAX. Pour accélérer l accès à ces informations, il est possible : de cacher ces informations au niveau du navigateur lui-même ; de forcer le moteur de base de données à mettre ces données dans son propre cache. Dans la mesure où ces informations sont stables (i.e. sont mises à jour très peu souvent, leur durée de vie étant de l ordre de la journée voire du mois ou de l année), les caches peuvent être très efficaces Conclusion : la gestion de cache On revient ici sur la problématique des caches introduite au chapitre 7 et évoquée dans ce qui précède. La figure 8.1 montre qu il est possible de mettre des caches à tous les étages de l architecture d une solution.

151 8.1 La performance d une solution 133 Certains de ces caches sont globaux : tous les utilisateurs accéderont aux informations contenues dans ces caches. Exemple : le cache associé au moteur de base de données. D autres caches gèrent la notion de session : chaque utilisateur est associé à un espace de données dédié. L utilisateur A accède uniquement à l espace de données qui lui est dédié dans le cache, et pas aux espaces des autres utilisateurs. Exemple : le cache du navigateur web, le cache applicatif. Il est bien clair que l architecte d une solution devra être attentif à la maîtrise de ces différents caches. Des caches mal gérés ou supportant mal une brusque montée en charge peuvent en effet nuire à la robustesse de l application, en conduisant à des comportements aléatoires, par exemple si un cache gérant des sessions commence à «mélanger» les informations de différentes sessions. CACHE S.I. Client CACHE Application Point d entrée SI CACHE XML <PROCESSUS> Service métier TRAITER UNE COMMANDE Point d entrée WS Point d entrée WS CACHE CACHE <CRUD> Service métier CATALOGUE <TECH> Mapping O/R <CRUD> Service métier STOCK <TECH> Accès Legacy CACHE SGBDR LEGACY Figure 8.1 Des caches à tous les étages

152 134 Chapitre 8. Performance d une solution métier 8.2 ROBUSTESSE D UNE SOLUTION Enjeux de la disponibilité d une solution Un petit exemple simple permet de prendre conscience du problème. L objectif de disponibilité d une application est en général d atteindre la loi des «cinq 9», c est-àdire atteindre une disponibilité de 99,999 %, qui correspond à 5 minutes d arrêt par an pour un fonctionnement 24 h/24 (cf. chapitre 2, section 2.1.3). Supposons qu une application cliente invoque plusieurs services pour s exécuter. La disponibilité de l application est le produit de la disponibilité des services (cf. chapitre 3). Si l on suppose pour simplifier que la disponibilité de chaque service est identique, alors cette disponibilité est donnée par la formule de la figure 8.2. n Robustesse (Si) = Robustesse (client) Figure 8.2 Disponibilité d un service en fonction de la disponibilité «cible» Si l application invoque cinq services, une disponibilité de 99,999 % pour cette application implique donc une disponibilité de 99,9998 % pour chaque service, soit un arrêt de 63 secondes au maximum par an! Ce calcul est certes simpliste : il fait notamment l hypothèse que tous les services sont logés à la même enseigne de disponibilité, ce qui n est pas tout à fait exact : ce sont les services distribués, impliquant une chaîne de composants nombreux, et «traversant le réseau», qui sont a priori les plus difficiles à robustifier. Les services «locaux» sont moins sensibles. Cela dit, ce type d objectif reste et restera difficile à tenir : en effet, l exigence de productivité sur les projets se traduit par des délais de réalisation toujours plus courts ce qui est souvent contradictoire avec l exigence de qualité, qui se traduit par la nécessité de tester longuement les services, surtout s ils sont destinés à être réutilisés. Autrement dit, garantir un tel niveau de disponibilité est quasiment impossible. Conseil : l hypothèse d une panne d un service est la norme, pas l exception, surtout pour les services distribués. Il vaut mieux prévoir ce cas de figure dès la -conception des services et/ou des applications clientes de ces services. Il ne faut pas jouer l autruche, «cachez cette panne potentielle que je ne saurais voir», sinon, le SI sera sujet à des pannes de service d autant plus brutales qu elles seront non prévues. Or, une telle panne peut impliquer l arrêt brutal des applications clientes, c est-à-dire l arrêt des relations entre l entreprise et le reste du monde, ce qui est intolérable. Pourtant, le zéro panne n est pas un objectif économiquement réaliste la plupart du temps. Serait-ce alors la quadrature du cercle?

153 8.2 Robustesse d une solution Éléments de solution «disponibilité» Les grands types de solution Il existe deux grands types de solution : le premier type de solution, solution matérielle orientée «architecture d infrastructure», consiste à mettre en place une architecture de haute disponibilité, à base de cluster ; le second type de solution, solution logicielle orientée «architecture fonctionnelle», consiste à concevoir la solution pour qu elle résiste à une panne de service. La première solution est en général privilégiée, car elle est générique, c est-à-dire qu elle ne dépend ni du service ni du métier impliqué : elle peut donc être réutilisée sur d autres services/solutions métier. Mais elle ne permet pas d obtenir une disponibilité de 100 %, sauf à encourir un coût économique généralement insupportable pour la plupart des entreprises (coût d achat du matériel et du logiciel de base, coût de mise en place, coût de supervision, etc.). La seconde solution est donc complémentaire, d autant qu elle peut être moins coûteuse sur le plan technique si elle est prise en compte dès la conception architecturale. Elle impose cependant un dialogue intense avec la maîtrise d ouvrage, comme on va le voir. De plus, lorsque la solution dépend d un fournisseur de service externe à l entreprise (comme dans l exemple du processus utilisé au début de ce chapitre), la garantie de service est encore moins évidente, même s il y a négociation avec pénalité en cas de manquement. La question à se poser en priorité est donc de savoir quel est le coût potentiel d une panne, et définir ainsi le retour sur investissement attendu des solutions à mettre en place. L objectif est de déterminer l équilibre solution type 1 et type 2 à mettre en place. Le premier type de solution est décrit dans la troisième partie (chapitre 12 notamment). On s intéresse donc dans ce qui suit au second type. Ce type de solution doit répondre précisément à la question : que se passe-t-il lorsque le service S tombe en panne? Trois réponses sont possibles : la réponse «fonctionnement alternatif» ; la réponse «fonctionnement dégradé» ; la réponse «fonctionnement transparent». La réponse «fonctionnement alternatif» L application détecte la panne du service : elle stoppe son fonctionnement nominal, mais elle propose à ses utilisateurs un contournement de cet arrêt momentané. Dans l exemple «Fil Rouge», si la plate-forme de commande détecte l indisponibilité d un service et s arrête, elle peut soit au minimum signaler à l utilisateur cet arrêt

154 136 Chapitre 8. Performance d une solution métier pour le faire attendre, soit dérouter le flux de commande vers un autre système, par exemple, envoyer les commandes par mail à l équipe commerciale ou au call center, qui rappellera le client. La qualité globale du service de l entreprise diminue, mais au moins les clients sont prévenus «qu il se passe quelque chose» on sait l importance de la communication en temps de crise. Au passage, on remarquera dans cet exemple l importance du dialogue entre les différentes parties prenantes de la DSI, comme le soulignait la première partie. Il montre en effet deux caractéristiques récurrentes de la réflexion sur la robustesse : Toute solution de ce type devra être spécifiée avec/par la maîtrise d ouvrage concernée, car elle seule peut mesurer l impact de la réponse proposée sur son business. Le dialogue avec les MOA est une première clef du succès. Toute solution de ce type implique la détection de la panne, donc la mise en place d un système de supervision adapté. Un tel système relève d une collaboration entre architectes applicatifs et architectes de la direction de la production. Le dialogue avec la production est donc une seconde clef du succès. L obtention de niveaux corrects de performance et de robustesse est donc bien un vecteur puissant de cohérence au sein de la DSI, et entre la DSI et ses donneurs d ordre. La réponse dégradée L application détecte la panne de service : elle ne s arrête pas mais propose un fonctionnement dégradé. Il y a en fait deux cas de figure : soit le service en panne n est pas strictement indispensable, l application peut s en passer : le service global est dégradé mais l application cliente n est pas arrêtée ; soit le service est indispensable : dans ce cas l application tente d utiliser un «service de repli», elle bascule sur ce service. Dans l exemple «Fil Rouge», on peut supposer que la plate-forme de commande fasse appel, dans le processus de réception et de traitement des commandes, à un transporteur. Ce transporteur, via son SI, met à disposition un web service qui permet de savoir si le transporteur peut prendre en charge la livraison de la commande, à quel coût, et pour quelle date prévisionnelle de livraison. En cas de panne de ce service, deux options s offrent à Fil Rouge : s en passer ou faire appel à un autre service, c est-à-dire, dans cet exemple, à un autre transporteur. Dans la première option, «se passer du service», la plate-forme de commande renverra une réponse partielle à l émetteur de commande. Cette réponse comprendra (par exemple) le montant de la commande, sa disponibilité en stock, mais ne comprendra pas la date estimée de livraison (en précisant pourquoi). Cela suppose que la plate-forme permette à un client de consulter ultérieurement l état de sa commande,

155 8.2 Robustesse d une solution 137 voire qu une fois revenue à une situation nominale, elle sache envoyer ce qu on peut appeler «un complément de réponse». Dans la seconde option «utiliser un autre service», Fil Rouge devra négocier avec plusieurs transporteurs : le service de référence sera fourni par le transporteur de référence EconoTransport, avec qui Fil Rouge a négocié un deal avantageux ; si EconoTransport est en panne, Fil Rouge peut se rabattre sur DepanoTransport, qui accepte de dépanner mais avec un engagement de livraison moins performant : par exemple, il ne s engage pas sur une date précise mais sur une période de temps. La réponse transparente L application détecte la panne de service. Elle ne s arrête pas et continue à offrir un service nominal du point de vue de l utilisateur final, mais pas du point de vue de la performance, qui peut être moins bonne. C est évidemment la situation idéale. Supposons dans l exemple «Fil Rouge» que l entreprise ait négocié avec le transporteur RapidoTransport pour que celui-ci traite les commandes émises par les clients VIP (qui ont droit à une livraison express, y compris le dimanche). En cas de panne du service EconoTransport, qui traite les autres commandes, la plate-forme de commande pourrait alors arbitrer entre faire appel à DépanoTRansport et RapidoTransport. En choisissant RapidoTransport, le service rendu par Fil Rouge reste nominal, à deux problèmes près : un temps de réponse un peu moins bon puisque comprenant la détection de la panne puis l appel à un autre service ; un surcoût du traitement de commandes «normales». Si le premier inconvénient apparaît comme très acceptable dans la plupart des situations, le second inconvénient peut en revanche poser des problèmes : un calcul économique est nécessaire pour justifier l usage d une telle solution de repli. D autres exemples peuvent être cités, lorsque le service incriminé repose sur une ressource (base de données, annuaire, serveur de mail, etc.) et qu il existe une autre ressource sur laquelle le service peut se dérouter. Par exemple, la base centralisée de log est en panne, le service de log utilise alors un fichier de log local. Un autre type de solution repose sur l utilisation d un cache, puisque celui-ci permet de masquer momentanément l indisponibilité du service. Cela implique cependant que le service soit accédé principalement pour des lectures d information et que l information concernée ait une durée de vie suffisante. Cela restreint la portée d une telle solution.

156 138 Chapitre 8. Performance d une solution métier 8.3 MISE EN ŒUVRE D UN PLAN BATCH Enjeux Les problématiques de performance d un plan batch sont en grande partie les même que celles d une application classique. La principale différence se situe dans le volume d information traitée et la quantité de calculs à effectuer. Il s avère donc que les problèmes de performance vont être décuplés dans le cadre des plans batch. Mais avant de rentrer dans le vif du sujet, quelques rappels autour des plans batch. Un plan batch est un ensemble de traitements qui s enchaînent de manière automatique sans l intervention d un être humain. Les principaux bénéfices à attendre d un plan batch sont : partager des ressources informatiques entre plusieurs programmes ; déplacer des traitements lourds au moment où les ressources informatiques sont le moins sollicités par les utilisateurs, et par la même occasion optimiser l utilisation des serveurs ; automatiser l enchaînement des tâches et éviter tout ralentissement ou erreur dus à une intervention humaine. Les plans batch ne sont pas récents, leur naissance est associée au Mainframe. Les principales raisons de leur mise en œuvre sont des problématiques de rentabilité et de compétitivité. Si l on prend exemple sur la comptabilité, une opération telle que la facturation des clients est une opération qui se prête parfaitement au traitement par lot (traduction de batch en français). En effet toutes les factures doivent être émises en même temps et surtout à une date donnée, au risque de voir leur règlement reporté d un certain temps et par rebonds de créer des trous dans les finances de la société. Autre intérêt, à l époque les équipements informatiques étaient très dispendieux et il fallait optimiser les investissements en matériel en les utilisant aussi bien de jour (avec des utilisateurs) que de nuit (plan batch). On aurait pu penser que l avènement des architectures réparties (Unix, Linux, Windows), de part le plus faible coût des serveurs et l augmentation de la puissance de calcul, aurait sonné le glas des traitements par lot. En réalité, c est tout le contraire qui s est passé. Tout d abord, l expansion de l informatique au cœur des métiers a généré de nouveaux besoins, que cela soit en termes de reporting ou d analyses de données. De là, les volumes de données ont fortement augmenté et les besoins de traitement également. Les plans batch ne se limitent plus simplement à la réalisation de tâche finale mais sont également utilisés pour le précalcul de certaines données qui seront ensuite utilisées par des utilisateurs via des interfaces graphiques. Mais le problème ne se limite pas à la seule application et le batch qui lui est associé. De nos jours les applications sont de plus en plus interdépendantes et cela ajoute de la complexité aux traitements de nuit. Dans ce contexte, résoudre l équation suivante n est pas toujours chose facile :

157 8.3 Mise en œuvre d un plan batch 139 Heure d arrivée des données en provenance d une autre application + temps de traitement local < heure d arrivé des utilisateurs Éléments de solution Afin de donner quelques pistes d optimisation, nous prendrons l exemple d un traitement d alimentation d un entrepôt de données. Ce type de traitement se déroule généralement en trois temps : Collecte : où l on verra les problèmes d optimisation des fils de traitements. Agrégation : nous aborderons quelques astuces au niveau des bases de données. Mise à jour : ou comment mettre les bons traitements aux bons endroits. Optimisation des fils de traitements La figure 8.3 montre clairement un problème d optimisation. En effet, les quatre piles de traitements fonctionnent en parallèle, mais le plan dans sa globalité doit attendre la dernière des piles (ici la pile 2) avant de poursuivre son déroulement. Figure 8.3 Répartition de la charge de travail

158 140 Chapitre 8. Performance d une solution métier Ici le problème se situe au niveau de l algorithme de répartition des données à traiter entre les différentes files. Son mode de fonctionnement est simple, la première pile prend un fichier le traite et regarde s il y a d autre fichier à intégrer. Un FIFO, trié selon la date d arrivée, n est souvent pas la meilleure façon de procéder. Il faut lui préférer une répartition en fonction de la taille des données à intégrer. Figure 8.4 Optimisation de la répartition de la charge de travail Dans cet exemple le gain est de plus de 20 % du temps simplement en changeant l ordre de prise en compte (80 min. de temps de traitement contre 107). Désactivation des index et des contraintes Les contraintes d intégrité sont des outils puissants pour garantir l intégrité référentielle des données d une base. Elles permettent de valider, avant insertion, la conformité des données par rapport à certaines règles. Cette validation n est malheureusement pas sans impact sur les performances. Autant sur une requête unitaire ce coût peut-être considéré comme négligeable, autant sur insertions il commence à se faire sentir. De même sur les index (et encore plus sur les index

159 8.3 Mise en œuvre d un plan batch 141 partionnés) le temps de mise à jour est souvent un facteur de non-performance à l insertion. Alors que faire? Tout désactiver pendant la durée du plan batch et ne réactiver qu à la fin? Sûrement pas! En effet il n est pas impossible, voir même certain, que les données qui viennent d être insérées vont être réutilisées dans la suite des traitements. Et là une requête de type SELECT sans index risque fort de vous coûter un maximum de temps. La bonne façon de procéder est de calculer les index au moment où ceux si sont les plus utiles. La figure 8.5 illustre une solution Figure 8.5 Calculer les index au moment le plus opportun De plus les moteurs de base de données modernes sont tout à fait capables de traiter ce re-calcul en parallèle d une autre requête pour peu que cette dernière ne touche pas la même zone de données. Des ordonnancements judicieux Lors de la définition des ordonnancements, il ne faut pas perdre de vue les objectifs du plan batch et plus particulièrement quand ces objectifs sont multiples comme par exemple : Intégrer un certain volume de données. Mettre de côté les données en erreur au sein de l application. Fournir des données valides à une autre application. Ici il est primordial de revoir l offre des priorités surtout si la mise à l écart des données en erreur s avère coûteuse en temps.

160 142 Chapitre 8. Performance d une solution métier En effet, l application qui attend les données n a que faire des erreurs, et doit donc être «servie» avant la phase de nettoyage. Il est donc plus judicieux de : Intégrer les données. Fournir des données valides à une autre application. Traiter les erreurs. À ce sujet, on rencontre souvent l enchaînement d opération suivant : INSERT INTO data_ok (...) SELECT... FROM stagging WHERE flag=1 ; DELETE FROM stagging WHERE flag=1 ; RENAME TABLE stagging to data_ko ; On lui préférera : INSERT INTO data_ko (...) SELECT... FROM stagging WHERE flag=0 ; RENAME TABLE stagging to data_ok ; En effet, il est à espérer que le volume d erreur est moins important que le volume de données correctes et donc la seconde solution «déplacera» beaucoup moins de donnée. En résumé Une solution regroupe des applications, clientes de services (métiers et techniques). Après avoir défini ce concept, le chapitre illustre la façon d analyser les problèmes de performance propres à la conception d une solution. Il s appuie pour cela sur un exemple classique et souvent rencontré : la gestion des listes longues, c est-à-dire la récupération en base de données, puis l affichage d un grand nombre d objets répondant à une recherche multicritères. On illustre ainsi l importance de la compréhension par les architectes et les développeurs de la façon dont il faut franchir la frontière entre la base de données et le monde objet. Le chapitre décrit ensuite rapidement les travaux du W3C sur ce thème (WS-Enumeration). Comment obtenir une solution globalement robuste en cas de panne d un service? Le chapitre analyse trois approches complémentaires : contourner la panne, détecter la panne et proposer un fonctionnement dégradé, détecter la panne et basculer sur un service alternatif. L analyse proposée met en lumière non seulement les enjeux techniques mais également les enjeux économiques. Le chapitre conclut en examinant la problématique des traitements différés car avec l explosion du volume de données à intégrer ces derniers dépassent fréquemment la plage de temps (le plus souvent de nuit) qui leur était allouée pour se dérouler.

161 TROISIÈME PARTIE Optimiser les infrastructures L objectif de cette partie est d étudier le rôle des éléments d infrastructure sur la performance du système d information en général et des applications en particulier. Le terme infrastructure doit ici être entendu au sens le plus large du terme, à savoir l ensemble des composants matériels et logiciels utilisés pour faire fonctionner les applications. Ces composants sont le plus souvent mutualisés (cas des réseaux ou des annuaires LDAP) ou font du moins l objet d une normalisation interne afin de se prémunir contre l effet SICOB 1 et ses conséquences désastreuses. La première bulle Internet ( ) a entraîné une extrême fragmentation des SI, tant sur le plan applicatif que sur celui des infrastructures : multiplication des langages de développements, prolifération des plates-formes d exécutions, apparition de nouveaux middleware (portails, gestion de contenu...). En réaction, ces dernières années ont vu les entreprises se lancer dans des démarches de rationalisation de leurs systèmes d informations. Qu elles se nomment normalisation, urbanisation, consolidation, virtualisation ou encore externalisation, ces approches visent, d une part, à réduire les coûts et, d autre part, à améliorer les performances globales du SI. 1. SICOB : du nom d un salon informatique qui s est tenu pendant 40 ans à Paris jusqu en 1992 et où les constructeurs et les éditeurs de logiciels présentaient leurs nouveaux produits. L expression «c est le SICOB» fait référence à un étalage de technologies hétérogènes et le plus souvent incompatibles entre elles.

162 144 Optimiser les infrastructures En parallèle, la complexité des offres des constructeurs et des éditeurs s est fortement accrue et la mise en place d une infrastructure à la fois performante, agile et peu coûteuse est un défi que doivent relever nombre de responsables informatiques. En effet, entre les offres totalement intégrées des géants IBM et Microsoft, les produits des éditeurs spécialisés (BEA, Oracle, Progress, Tibco, etc.) et la montée en puissance des solutions Open Source, les arbitrages sont délicats. Cette partie n a pas pour ambition de faire le tour de toutes les questions d infrastructure informatique (il existe déjà une littérature abondante sur ce sujet) mais plutôt de fournir au lecteur une grille de lecture pour comprendre les enjeux de performance au niveau de chacune des briques de l infrastructure informatique, et de faire les choix les plus adaptés à son contexte et à son budget. Les thèmes abordés dans cette partie sont d abord l infrastructure matérielle avec les réseaux puis le stockage. Ensuite, un chapitre entier est consacré aux solutions de clustering. L approche retenue pour ce sujet est centrée sur les concepts plutôt que sur les solutions des éditeurs. Cette démarche permet de mieux appréhender les différences de fond et de fournir des critères objectifs pour évaluer les solutions du marché. La partie se termine par deux chapitres de recommandations pour les bases de données et les serveurs d applications.

163 9 Les Datacenter Objectifs Les Datacenter (ou centres de traitement de données) sont des installations spécialisées permettant le regroupement des éléments informatiques sensibles comme les applications, les infrastructures (logicielles, systèmes et matérielles), ainsi que les équipements réseaux dans un environnement le plus sécurisé possible. Ils représentent l enveloppe du système d information car c est en leurs seins que se joue toute la production informatique de l entreprise. Ils doivent garantir un haut niveau de service afin d assurer l intégrité et le fonctionnement des équipements et applications hébergées. Ils doivent également se doter de moyens de pilotage et de suivi nécessaires, que ce soit en termes d outils de surveillance ou de personnel dédié. Les problématiques de performance auxquels ils sont soumis sont principalement liées à la disponibilité. En effet, regrouper la plus grande partie de son système d information présente le risque de tout perdre si l on perd son Datacenter et qu il n est pas prévu de solution de secours. Nous nous attacherons, dans ce chapitre, à positionner le Datacenter dans la politique de performance de l entreprise. Nous aborderons les différents types de Datacenter et nous verrons comment mettre en place un plan de continuité de l activité en prenant en compte l hébergement du système d information.

164

165 9.2 Les différents types de Datacenter 147 La mise en œuvre des deux axes de réflexion abordés ci-dessus conduit à des réalisations diverses : Mise en place d un bon niveau de résilience sur chaque site, par exemple via la division du site en zones pouvant se secourir mutuellement afin de parer rapidement à certaines défaillances locales. Utilisation de sites «doubles», de type «campus», géographiquement proches l un de l autre. Chacun de ces sites fait office de miroir pour l autre via un réseau à haut débit. Installation de sites distants d au moins 10 km (mais de moins de 50 km), afin de limiter le risque d être touché par le même sinistre tout en permettant un niveau de synchronisation élevé. Installation d un site de secours réellement éloigné du site principal (au moins de 150 km), qui servira de site de secours en cas de sinistre majeur touchant le site principal ou l un des sites proches. La distance ayant un impact sur la synchronisation des données, il conviendra de prendre en compte ce point au niveau du PCA. 9.2 LES DIFFÉRENTS TYPES DE DATACENTER Classification L association américaine «Uptime Institute» a établi une classification des Datacenter en quatre groupes, appelée «tiers» en anglais, en fonction du niveau de disponibilité garantie par le type d installation : «Tiers 1» : regroupe les Datacenter n ayant qu une seule alimentation électrique, un seul système de refroidissement et aucune redondance des équipements qu ils hébergent. La disponibilité nominale de ce type de centre est de 99,671 %, correspondant à un temps d arrêt cumulé moyen annuel de 28,8 heures. Il est donc impossible de parler de haute disponibilité dans ce cas. «Tiers 2» : regroupe les Datacenter ayant une voie unique pour l alimentation électrique et le refroidissement, mais disposant de moyens de redondance permettant une disponibilité nominale de 99,749 % (soit 22 heures d arrêt par an). Ayant passé la barre des 99 %, il est envisageable de traiter des applications sensibles. Toutefois le manque de redondance sur les alimentations engendre un risque fort pour l entreprise car il s agit là d un SPOF 1 au niveau du SI dans son intégralité. «Tiers 3» : regroupe des Datacenter plus complets que les tiers précédents car bénéficiant de plusieurs voies d alimentation et de refroidissement (dont une seule voie active). Une partie des équipements est redondante, ce qui 1. Single Point of Failure : point d un système informatique dont le reste du système est dépendant et dont une panne entraîne l arrêt complet du système.

166 148 Chapitre 9. Les Datacenter permet de réaliser une bonne partie des opérations de maintenance sans arrêt des machines. Ce type de Datacenter offre une disponibilité de 99,982 % par an, la durée moyenne annuelle d arrêt étant de 1,6 heure. «Tiers 4» : regroupe les Datacenter offrant le plus haut niveau de disponibilité (99,995 % soit une durée d arrêt moyenne annuelle de 0,4 heure). Ils possèdent plusieurs voies actives pour l alimentation électrique et le refroidissement, ainsi qu un nombre élevé d éléments d infrastructure redondants et tolérants aux pannes. Cette classification et reconnue par les principaux acteurs du marché des Datacenter et un nombre croissant de Datacenter se font certifier sur cette base. Selon une étude du CRIP 1 (Club des Responsable d Infrastructure et de Production), réalisée début 2009, la majorité des centres français serait en mesure d approcher (voir même d être certifié) Tiers 3 car ils disposent de redondance au niveau : des alimentations électriques, de la climatisation, d accès opérateur, d accès Telecom Impacts La haute disponibilité n est pas sans impact sur les coûts. La mise en œuvre des moyens nécessaires pour garantir le niveau de service offert par les différents tiers implique des coûts et contraintes de plus en plus élevés en fonction des tiers : Coût de construction, de maintenance et d équipement du Datacenter. Coûts liés à la consommation électrique et aux besoins en refroidissement associés. Coût de la surface réservée aux éléments techniques mis en œuvre pour garantir le Tiers retenu (et donc ne pouvant être utilisée pour héberger les éléments du SI). Coût induit par un besoin de personnel sur site (croissant avec le niveau du tiers). Un autre élément important à prendre en compte lors de la création d un Datacenter est la question des délais de construction et d équipement : là aussi le délai croît avec le niveau de tiers cible. 1. Association française (Loi 1901) réunissant des responsables d infrastructures ou de production de grandes entreprises ou d entités utilisatrices des technologies de l information.

167 9.3 La gestion des risques LA GESTION DES RISQUES Les Datacenter hébergeant les éléments techniques nécessaires au bon fonctionnement de l entreprise, il faut donc les considérer comme faisant partie des ressources critiques. En effet tout dysfonctionnement (voire pire toute destruction) peut avoir un impact négatif considérable sur le SI de l entreprise. À ce titre ils doivent faire l objet de politiques de gestion des risques spécifiques, qui traitent aussi bien des risques externes qu internes aux Datacenter. Typiquement la prise en compte des risques est divisée en trois types (risques naturels, humains et techniques) et selon deux axes : risques intrinsèques et risques extrinsèques Risques intrinsèques Les risques naturels peuvent avoir de trois origines : climatique (tornade, foudre, etc.), géologique (séisme, éruption volcanique, etc.), hydraulique (inondations par exemple). Ces risques sont liés à la situation géographique au sens large, et influent sur le choix de l emplacement des Datacenter. Afin de limiter le risque que deux sites soient touchés par une inondation on évitera de les placer dans la même vallée fluviale. Les risques d origine humaine englobent les actes malveillants (de type sabotage ou vol), les erreurs humaines ou méconnaissances des consignes à appliquer, les intrusions en tout genre. Les risques liés au personnel du Datacenter peuvent être liés à un manque de formation ou encore à l absence de PCA complet et éprouvé. Par exemple les exercices de reprise sur sinistre peuvent améliorer le niveau de maîtrise des procédures d urgence en cas de problème grave. Les risques liés à des personnes tierces peuvent être contenus par la mise en œuvre d une surveillance et une limitation des accès physiques aux installations. Les risques techniques : panne matérielle, mauvais fonctionnement d un équipement critique, usure ou défaillance, etc.

168 150 Chapitre 9. Les Datacenter Ces risques sont en général bien connus et étudiés dès la conception des installations du Datacenter. Ils sont généralement adressés par la mise en place d équipements de secours, des solutions de réparation rapide ou de redondance Risques extrinsèques Il faudra aussi tenir compte des risques externes liés à l environnement géographique du Datacenter (proximité d une zone dangereuse type Seveso ou encore risques de pollution par exemple) ainsi qu aux risques de défaillance des fournisseurs critiques (alimentation électrique notamment). Il faudra également tenir compte de l environnement politique de la zone où le centre sera implanté. Une forte instabilité de la région ne peut pas être propice à la sécurité de l endroit et présente donc de forts risques quant à la pérennité des installations. Au-delà des risques listés ci-dessus, une bonne gestion des risques devra tenir compte des contraintes techniques issues des architectures techniques mises en place au niveau du SI. Ce point conditionne notamment les modalités de mise en place d un site de secours ainsi que les conditions de basculement. 9.4 DATACENTER ET PCA Classification des sites de repli Un des éléments essentiels à prendre en compte lors de l établissement d un PCA est la distance entre un Datacenter et le site de reprise (notion de disponibilité). On pourra adopter les dénominations suivantes : Datacenter «campus» : le site de reprise est très proche (moins de 10 km en général). Datacenter «métropolitain» : le site de reprise se situe à moins de 50 km. Datacenter «régional» : le site de reprise se situe à moins de 100 km. Datacenter «continental» : le site de reprise est situé à plus de 100 km. Cette notion est particulièrement importante lors de la prise en compte des sinistres qui pourraient survenir sur le Datacenter. Le tableau 9.1 met en lumière la couverture d un sinistre en fonction du type de site. Actuellement on note une nette préférence pour les solutions de reprise locales ou à distance modérée, qui permettent notamment de mettre en place des mécanismes de synchronisation de données entre les différents sites, ce qui allège d autant la liste des actions à mener en cas de bascule, et donc le temps de rétablissement du service.

169 9.4 Datacenter et PCA 151 Tableau 9.1 Site et bascule Site Campus Métropolitain Régional Continental Sinistre Serveur OK OK OK OK Site OK OK OK OK Ville... OK OK OK Régional OK a OK National OK a. En fonction de la zone sinistrée. Ce délai de rétablissement d un niveau de service acceptable est attaché à la notion de RTO 1, mais également à celle de RPO 2 (voir chapitre 4, section 4.2 pour plus de détails Types de bascule On distingue les types de reprise sur sinistre en fonction du couple RTO/RPO : Bascule quasi immédiate d un site vers un site voisin, sous réserve que les connexions réseaux et le niveau de synchronisation des données entre les sites le permettent. Ce type de bascule peut être impossible en cas de sinistre majeur. Bascule en quelques minutes (délai pouvant aller à quelques dizaines de minutes), nécessitant parfois une intervention humaine au niveau exploitation. Bascule en quelques heures, impliquant en général des travaux aux niveaux des serveurs (configuration, mise à niveau des applications installées, récupération d au moins une partie des données, etc.). Ce cas correspond en général à une reprise effectuée sur un site distant bénéficiant d un certain niveau de préparation. Bascule en quelques jours (en général une à deux journées), cas correspondant en général à une préparation de la reprise limitée et/ou une récupération des données lente ou difficile. Le choix du type de bascule se fera essentiellement en fonction du degré de criticité des différentes applications (et donc de l exigence de continuité d activité induite) et compte tenu des contraintes posées par le Datacenter. Ainsi l hébergement d une application non critique dans un Datacenter de tiers élevé peut être considéré comme un luxe puisque le coût est démesuré si le temps de bascule acceptable est de l ordre d une journée. 1. RTO : Recovery Time Objective : correspond au temps estimé de retour du service, y compris en mode dégradé. 2. RPO : Recovery Point Objective : correspond au volume estimé de données perdues (mais que l on pourra récupérer au moins partiellement ultérieurement).

170 152 Chapitre 9. Les Datacenter Il faudra, de plus, prendre en compte les contraintes induites par l architecture technique des différentes applications, et surtout concernant la synchronisation des données entre sites distants. Ce dernier point est d autant plus complexe à traiter que l entreprise dispose d un nombre élevé d applications utilisant des technologies variées et parfois anciennes pour certaines. Il pourra être nécessaire de déterminer différents groupes d applications : Applications devant bénéficier d une bascule instantanée. Applications nécessitant un délai de reprise de l ordre du quart d heure, temps nécessaire à la réalisation d un certain nombre de travaux. Applications ne pouvant pas être remises en service avant plusieurs heures. Ce délai est en général induit par des traitements lourds de préparation de la bascule. Applications ne pouvant pas être redémarrées avant au moins une journée, dont la bascule implique une série de travaux de type sauvegarde ou interventions humaines complexes. Le croisement de l ensemble de ces contraintes permet de déterminer la répartition des différentes applications en fonction du type de Datacenter comme le montre le tableau 9.2. Tableau 9.2 Site et bascule Site Campus Métropolitain Régional Continental Reprise Instantanée OK OK Possible Impossible 15 minutes OK OK OK Difficile 4 heures Luxe OK OK Possible Plusieurs jours Luxe Luxe Luxe OK Si la répartition logique issue de cette réflexion n est pas conforme aux attentes en termes de disponibilité, on pourra envisager des travaux au niveau du Datacenter comme des applications afin de modifier les contraintes techniques. Mais avant d engager ces travaux, il convient de valider que le niveau d exigence est aligné sur les coûts des travaux à réaliser. Il n est pas rare que les exigences soient revues à la baisse si le retour sur investissement n est pas acceptable. Dans certains cas les niveaux de disponibilité sont fixés par la réglementation (cas des services dits «vitaux»). Les délais de reprise ainsi imposés vont alors conditionner les choix techniques tant au niveau des applications que des Datacenter, mais elles vont également conditionner les scénarios de reprise. Un élément supplémentaire à inclure dans les réflexions de conception d un PCA concerne les éléments de pilotage du Datacenter, éléments essentiels permettant de s assurer du bon fonctionnement du SI.

171 9.4 Datacenter et PCA 153 En résumé L explosion des besoins informatiques de l entreprise a contraint la DSI à abandonner les anciennes salles machines pour investir dans de nouveaux bâtiments plus à même de satisfaire aux exigences des utilisateurs. Ces changements entraînent de nouvelles problématiques telles que la gestion de l alimentation électrique, la mise en place de solutions de climatisation efficientes, mais également de nouveaux questionnements quant à la gestion des risques inhérents à une plus forte disponibilité des applications. Nous avons dans ce chapitre abordé ces problématiques et remis en perspective l importance du Datacenter dans la performance des architectures IT.

172

173 10 Les réseaux Objectif Les systèmes d information sont passés, en une quinzaine d années, d une informatique essentiellement construite autour de systèmes centraux et de postes de travail autonomes à une informatique distribuée où la plupart des composants sont reliés entre eux par un réseau. D abord utilisés pour des usages internes avec les LAN, les réseaux se sont généralisés avec l adoption de TCP/IP qui a permis la construction d un gigantesque inter-réseau : Internet. Dans le même temps, la dérégulation du secteur des télécoms a permis une baisse continue des coûts de connexion. Tout naturellement, les applications informatiques ont dû suivre cette évolution et se transformer progressivement pour tirer partie des réseaux. Aujourd hui, les applications «standalone», c est-à-dire non prévues pour travailler en réseau, sont devenues marginales. Désormais, les réseaux constituent le système nerveux des systèmes d information d entreprise. Les architectes sont donc quotidiennement confrontés à l utilisation des réseaux pour les applications qu ils conçoivent ou maintiennent. Ce chapitre fait le point sur les conséquences de l utilisation intensive des réseaux dans les nouvelles architectures applicatives. Il s agit de briser un certain nombre d idées reçues au sujet des réseaux. L expérience montre que ces idées sont à l origine de la majorité des problèmes de performance dans les applications distribuées. L objectif de ce chapitre est de dresser un inventaire des mauvaises pratiques et de donner au lecteur des solutions pour les éviter sur les projets.

174 156 Chapitre 10. Les réseaux 10.1 FONDAMENTAUX Une évolution continue Le lecteur est sans doute familier avec la loi dite de «Moore», du nom de Gordon Moore, un des fondateurs d Intel. Cette loi empirique stipule que la puissance de traitement des microprocesseurs (CPU) double tous les 18 mois. Elle est vérifiée de façon constante depuis sa formalisation à la fin des années Il existe deux autres lois similaires qui concernent les réseaux. Il s agit des lois de Gilder et de Metcalf. La loi de Gilder, formulée par George Gilder, un spécialiste américain des nouvelles technologies, avance que «la bande passante des réseaux croît trois fois plus vite que la puissance des microprocesseurs.» Ce qui signifie que la bande passante disponible double en moyenne tous les 6 mois. Cette loi, tout comme celle de Moore, continue régulièrement à être vérifiée. La loi de Metcalfe, de Robert Metcalfe, père des réseaux Ethernet et cofondateur de 3COM, s exprime comme suit : «l utilité d un réseau est égale au carré de son nombre de nœuds ou d utilisateurs». Cette loi contrebalance la loi de Gilder car elle exprime la croissance exponentielle des besoins utilisateurs vis-à-vis des réseaux. La figure 10.1 illustre la loi de Metcalfe avec les réseaux téléphoniques. Figure 10.1 La loi de Metcalfe Alors, dans un contexte où la bande passante disponible augmente très rapidement, pourquoi se préoccuper particulièrement des aspects réseaux dans les architectures applicatives? Il existe au moins deux bonnes raisons à cela : Les besoins de communication explosent littéralement et la croissance de la bande passante n est pas toujours capable d absorber le surplus de trafic si celui-ci n est pas un minimum optimisé. La bande passante n est qu une propriété des réseaux parmi d autres, c est celle qui est le plus souvent mise en avant, mais ce n est pas toujours la plus importante.

175 10.2 Les réseaux et la performance Les propriétés des réseaux Du point de vue de la performance, il est possible de caractériser les réseaux à l aide de cinq propriétés : La bande passante correspond à la quantité d informations qu un réseau est capable de transporter sur une période de temps donnée. Elle s exprime en Mo/s ou en Go/s. Il convient d être vigilant car il s agit généralement d une donnée brute, la bande passante réellement disponible pour les applications est en réalité inférieure. La latence désigne le temps de transport d un paquet d un point à un autre du réseau. Elle est généralement mesurée par des outils tels que ping qui calculent le temps d un aller-retour entre deux points (RTT ou Round-Trip Time). La latence s exprime généralement en ms. La perte de paquets correspond au ratio des paquets émis qui n arrivent pas à destination dans le temps imparti. Un taux élevé de perte de paquets entraîne nécessairement une réduction de la bande passante disponible. La perte de paquets s exprime sous la forme d un pourcentage. La disponibilité correspond à la période pendant laquelle le réseau est effectivement accessible et utilisable. Elle s exprime sous la forme d un pourcentage. Elle a fait l objet d une étude détaillée dans la première partie (cf. chapitre 2). La gigue est la variation de latence sur une période de temps donnée. C est une caractéristique importante, en particulier pour les réseaux de transport de la voix LES RÉSEAUX ET LA PERFORMANCE Dans les années 1990, deux architectes de SUN Microsystems, Peter Deutsch et James Gosling (l architecte en chef de Java) ont dressé un constat des pratiques de développement en matière d informatique distribuée. Ce constat est désormais connu sous le nom «Les huit idées fausses de l informatique distribuée». Quinze ans plus tard, il reste toujours d actualité. Ces affirmations sont les suivantes : 1. La latence est nulle. 2. La bande passante est illimitée. 3. Le réseau est fiable. 4. Le réseau est sécurisé. 5. La topologie du réseau ne change pas. 6. Il y a un seul administrateur. 7. Les coûts de transport sont nuls. 8. Le réseau est homogène. Les sections suivantes reviennent en détail sur chacun de ces points, les illustrent par des exemples concrets et donnent des conseils pour y remédier.

176 158 Chapitre 10. Les réseaux Idée fausse n 1 : la latence est nulle C est une des erreurs les plus couramment commises par les équipes de développement. Elle a deux causes principales : Les progrès importants qu ont connu les technologies réseaux ces dernières années donnent parfois l impression aux développeurs que les appels distants (RPC) sont devenus aussi rapides que les appels locaux à l intérieur d une même machine. Les bibliothèques (API) récentes encapsulent tellement bien les appels aux couches réseaux qu il est désormais très facile d effectuer des appels à des composants distants. La maîtrise et la compréhension des sockets TCP/IP ne sont plus requises dans les projets courants. Pour rappel, la latence est le temps de propagation du signal entre deux points du réseau. La latence est donc d autant meilleure qu elle est faible. Dans les réseaux vocaux, une latence élevée se traduit par une sensation d éloignement de l interlocuteur tandis que sur les réseaux de données cela provoque des temps d attente plus élevés. L erreur la plus souvent commise par les équipes de développement consiste à négliger cette latence et à la considérer comme très faible au regard des temps de traitements. Il s agit là d une approximation fréquente qui bien souvent ne révèle ses effets négatifs qu au moment du déploiement en production. Les raisons en sont multiples, on peut citer par exemple : L utilisation en phase de développement de bases de données qui tournent sur les mêmes machines que le serveur d application. Les développeurs pensent alors disposer d une réserve de puissance, puisqu en production il y aura deux serveurs au lieu d un seul. C est généralement un mauvais calcul car les communications entre la base de données et le serveur d application ne se feront plus en local et utiliseront le réseau. Chaque appel subira donc un retard supplémentaire dû à la latence du LAN. Plus les appels seront nombreux, plus l application sera ralentie. La réalisation de tests de performance qui ne tiennent pas compte des contraintes réelles du déploiement. Ce cas a été rencontré il y a quelques années lors de l audit d une application bancaire dont les serveurs étaient situés en Europe et les utilisateurs en Afrique noire. Ces derniers se connectaient à l application en passant par des réseaux satellitaires à très forte latence (Round-Trip Time d environ ms). L application qui faisait de très nombreux appels aux serveurs fonctionnait parfaitement lors des tests en Europe mais était totalement inutilisable sur le terrain à cause des temps d attente induits par la latence. Elle a dû faire l objet d un coûteux refactoring pour résoudre ce problème. La latence est une des principales causes de problèmes de performance dans les applications distribuées. Elle est directement à l origine de l anti pattern «mitrailleuse à requêtes» qui est évoquée dans le chapitre 5.

177 10.2 Les réseaux et la performance 159 Alors, quels sont les paramètres qui influencent directement la latence des réseaux? Il s agit de : La distance à parcourir entre les deux points. La nature du ou des réseaux utilisés pour acheminer la communication (i.e. les réseaux hertziens ont une latence plus élevée que les réseaux filaires). Le nombre de routeurs à franchir. Plus celui-ci est élevé, plus la latence augmente, chaque franchissement de routeur se traduisant par une recopie des données sur un nouveau réseau. Or, ces opérations de recopie, même très rapides, prennent du temps. La latence est une caractéristique qui est peu affectée par les progrès sur les équipements matériels. Alors que la bande passante a considérablement augmenté ces dernières années, les progrès en matière de latence sont bien moindres et les perspectives d amélioration à moyen terme ne sont pas très encourageantes. En effet, la latence minimale est fixée par une barrière physique infranchissable : la vitesse de propagation de la lumière. Voici quelques exemples de calcul et de mesure de la latence minimale pour un ping réseau entre un client utilisant une connexion ADSL à Paris et différents serveurs situés sur le LAN, en région parisienne, à Boston et à San Francisco : Vitesse de la lumière dans le vide : c vide = km/s Vitesse de la lumière dans une fibre : c fibre = 2/3 c vide = km/s Serveur sur le LAN (même sous réseau) Temps d aller retour moyen : P = 1 ms Nombre de sauts : Hop = 0 Serveur en région parisienne Distance estimée à 10 km, soit 20 km aller retour. Latence théorique minimale : L mini = 20/ = 0,1 ms Temps d aller retour moyen : P = 40 ms Nombre de sauts : Hop = 6 Serveur à Boston (USA côte Est) Distance estimée à km, soit km aller retour Latence théorique minimale : L mini = / = 55 ms Temps d aller retour moyen : P = 120 ms Nombre de sauts : Hop = 14 Serveur à San Francisco (USA côte Ouest) Distance estimée à km, soit km aller retour Latence théorique minimale : L mini = / = 90 ms Temps d aller retour moyen : P = 200 ms Nombre de sauts : Hop = 19 Ces rapides calculs et les relevés de mesure montrent clairement que le passage du LAN au WAN présente un coût élevé en termes de latence. Celui-ci se manifeste de façon aiguë par le ping important (40 ms) pour l accès à un serveur situé à proximité

178 160 Chapitre 10. Les réseaux du client mais sur un autre réseau. La principale cause de cette lenteur est le passage du réseau téléphonique cuivre au réseau fibre optique de l opérateur. Ensuite, pour les exemples sur Boston et San Francisco, c est de toute évidence la distance et la présence de quelques routeurs supplémentaires sur le trajet qui allongent les temps de latence. Le calcul de la latence théorique basée sur la vitesse de la lumière permet de connaître précisément la marge de progression dont on dispose dans la perspective de la généralisation des réseaux fibres optiques. De toute évidence, celle-ci est assez faible, particulièrement pour les communications longue distance. Il va donc falloir systématiquement intégrer cette contrainte dans les projets. Par ailleurs, en plus de la latence intrinsèque du réseau, il faut aussi tenir compte de la latence liée aux opérations de marshalling/unmarshalling. Ce problème est particulièrement sensible avec les protocoles basés sur XML tels que SOAP ou REST. Il s agit du temps passé dans les transformations de format entre les modèles mémoire des objets Java/.NET et les documents XML contenant les paramètres d appels et de retour qui sont transférés sur le réseau. Ces opérations peuvent être très coûteuses à la fois en CPU et en temps de traitement. Alors, comment tenir compte des effets de la latence réseaux sur les applications? On retiendra trois pistes d action : 1. Réduire le plus possible les allers-retours entre composants distribués et privilégier, autant que possible, la mise en place de services avec une forte granularité pour éviter les rafales d appels. 2. Évaluer l impact des opérations de marshalling/unmarshalling par rapport aux temps de transfert et de traitement des appels. Limiter quand c est possible les quantités de données transférées. 3. Réaliser des tests de performance dans un environnement qui présente les mêmes caractéristiques réseaux que l environnement de production en matière de latence. Il existe des outils qui permettent de simuler de telles conditions (Shunra, Opnet, etc.). 4. Intégrer les contraintes de latence dès la phase de conception pour éviter de retenir une solution incompatible avec le contexte de production. 5. Pour les applications déployées à l échelle mondiale, il peut être opportun de prévoir un déploiement dans des centres de production proches des utilisateurs pour réduire les temps de transport Idée fausse n 2 : la bande passante est illimitée On retrouve pour cette seconde affirmation, les mêmes causes que pour la première. L évolution des performances des réseaux, conjuguée à l arrivée de bibliothèques qui rendent les appels réseaux quasi-transparents, a désensibilisé les équipes de développement aux problèmes de bande passante. Cela se manifeste par des applications qui transfèrent des quantités d informations toujours plus importantes, même quand ce n est pas absolument nécessaire.

179 10.2 Les réseaux et la performance 161 Les conséquences de la sous-estimation de la consommation de bande passante sont généralement moins graves que dans le cas de la latence. En effet, il est possible d y remédier par des mesures telles que la compression de données ou l élargissement des tuyaux réseau. Tout comme pour la latence, les problèmes de bande passante ne sont généralement détectés qu en phase de production car les équipes de développement n effectuent généralement pas leurs tests avec un niveau de charge suffisant pour les dépister. Les mesures préventives à mettre en œuvre sur les projets sont les suivantes : 1. Évaluer l impact des protocoles retenus sur la consommation de bande passante et dimensionner les tuyaux en conséquence. 2. Utiliser, quand c est possible, la compression des données à la volée au moment du transfert (i.e. compression gzip du protocole http 1.1). 3. Réaliser des tests de performance dans un environnement qui présente une bande passante équivalente à celle de l environnement de production Idée fausse n 3 : le réseau est fiable La fiabilité des réseaux a beaucoup progressé ces dernières années, mais c est également le cas de leur complexité. Leur fonctionnement dépend de nombreux équipements (switch, routeur, firewall, modem, etc.) qui sont loin d offrir un niveau de disponibilité et de fiabilité de 100 %. Par conséquent, le niveau de fiabilité du réseau est souvent égal à celui de son composant le plus faible. Cela revient à dire que l on ne doit pas considérer les réseaux comme fiables mais, au contraire, comme non fiables a priori. Cette affirmation est d autant plus vraie que la plupart des réseaux sont aujourd hui interconnectés et que l on maîtrise rarement tous les équipements qui les composent. Quelles peuvent être les conséquences du manque de fiabilité du réseau? On en dénombre plusieurs parmi lesquelles : La perte d informations durant les échanges. L altération des données échangées (contenus altérés, mauvais ordre d arrivée des messages, etc.). La duplication d informations à la suite d incidents de communication. C est donc à l architecte applicatif qu il revient de mettre en œuvre des solutions pour fiabiliser la communication sur le réseau. Il dispose pour cela de plusieurs possibilités : 1. L amélioration de la fiabilité du réseau par l utilisation d équipements présentant moins de risque de défaillance et/ou par la redondance des composants critiques. 2. L utilisation de solutions logicielles capables de sécuriser les échanges, même sur des réseaux peu fiables. Il s agit généralement de solutions de type MOM ou middleware orientés messages. On peut citer par exemple : Sonic MQ de Progress Software, Rendez-Vous de Tibco ou encore WebSphereMQ d IBM.

180 162 Chapitre 10. Les réseaux Ces solutions sont bien sûr non-exclusives. La première dépend des équipes d infrastructure réseau et télécom tandis que la seconde est du ressort des architectes et des urbanistes Idée fausse n 4 : le réseau est sécurisé Cette affirmation pourrait se vérifier dans le cadre de réseaux fermés, c est-à-dire non reliés à Internet, sur lesquels seuls des postes hautement sécurisés seraient branchés. Dans la pratique, il n en est rien, les réseaux sont reliés les uns aux autres et les postes utilisateurs sont encore bien souvent des passoires en matière de sécurité. La propagation régulière de virus, adware et autre spyware sur les réseaux des entreprises est là pour en attester. Les solutions à mettre en place pour sécuriser les réseaux sont les suivantes : 1. Isoler les serveurs de production dans des zones protégées et fermer tous les accès réseaux non-indispensables au bon fonctionnement des applications. 2. Restreindre l accès physique (salles blanches) et logique (logon) aux serveurs aux seuls exploitants. Les équipes de développement ne doivent jamais y avoir accès (dans la pratique, c est malheureusement encore loin d être le cas). 3. Utiliser des référentiels d entreprise pour mettre en place une stratégie unifiée d authentification et de gestion des habilitations. Aujourd hui, les applications doivent toutes être capables de se connecter à des référentiels de type annuaire LDAP ou Active Directory. 4. Mettre en place des solutions centralisées de détection des problèmes de sécurité à l échelle des parcs de serveurs (virus, intrusion...) et les maintenir à jour en permanence. 5. Utiliser des solutions telles que les Virtual Private Networks (VPN) pour gérer les connexions depuis des réseaux physiques externes. La mise en œuvre de ces mesures dépasse largement le périmètre de travail des architectes applicatifs. En revanche, ceux-ci restent garants du respect des règles de sécurité de l entreprise dans les applications Idée fausse n 5 : la topologie du réseau ne change pas La topologie d un réseau est son organisation physique. On peut par exemple citer le plan d adressage IP ou encore l emplacement des serveurs sur les différents sites de production. En ce qui concerne les postes clients, la topologie des réseaux change de plus en plus souvent avec l émergence des réseaux mobiles. Il est donc important pour l architecte de ne pas s appuyer sur la topologie du réseau pour construire ses applications mais, au contraire, d utiliser des solutions techniques pour s en abstraire au maximum. Les solutions proposées sont : 1. L utilisation systématique de noms DNS au lieu d adresse IP «en dur» dans la configuration des composants applicatifs.

181 10.2 Les réseaux et la performance Mettre en place une solution de communication offrant un haut niveau d abstraction et une centralisation des informations réseaux. Les produits de types ESB (Enterprise Service Bus), qui sont une surcouche des MOM mentionnés dans la section précédente, sont d excellents candidats. Ils utilisent généralement des notions de point d entrée ou canal qui sont totalement indépendantes des ressources physiques et qui, le plus souvent, sont reconfigurables à chaud Idée fausse n 6 : il n y a qu un seul administrateur Cette affirmation n est vraie que sur certains réseaux locaux, et encore à condition de ne considérer que les aspects purement télécom. Dans la réalité, le réseau est souvent connecté à Internet ou à d autres réseaux via des liens VPN. De plus, il existe presque autant d administrateurs que de types de serveurs : bases de données, groupware, web, mainframe, Windows ou encore Linux. En bref, les responsabilités sont largement diluées et il n existe pas de superadministrateur doté des pleins pouvoirs sur l ensemble des équipements/applications, sauf dans les toutes petites organisations. Alors, pourquoi se soucier de ce découpage des rôles? Tant que l application fonctionne bien en production, pas de problèmes. En revanche, dès qu un incident survient, il devient urgent d effectuer un diagnostic et de trouver une solution. Cela requiert le plus souvent la coopération de plusieurs administrateurs (i.e. réseau et base de données). Malheureusement, ceux-ci ne sont pas ou peu associés aux choix d architectures dans les phases de conception/développement et l administrabilité des applications est bien souvent imparfaite. Les préconisations pour faciliter la gestion des incidents sont : 1. d associer les différents administrateurs aux projets dès la phase de conception pour assurer une administrabilité maximale. Cela comprend au minimum la standardisation des règles de configuration des applications ; 2. de rendre les applications monitorables. Cela passe par une gestion industrialisée des logs et, dans certains cas, par l instrumentation des applications avec des outils spécialisés tels que Quest PerformaSure ou Wily Introscope Idée fausse n 7 : les coûts de transport sont nuls Cette affirmation recouvre en fait deux choses distinctes : d une part que le transfert de données n est pas neutre du point de vue des temps d exécution et, d autre part, que la bande passante n est pas gratuite. Le premier point a déjà été traité au paragraphe sur la latence. En effet, le transport de données implique nécessairement des opérations de transformation de format. Ces opérations sont appelées sérialisation/désérialisation ou encore marshalling/unmarshalling. Il faut donc être attentif aux protocoles utilisés. Le second point concerne les coûts de transport sous l angle financier. L augmentation régulière de la bande passante disponible et la baisse continue des prix se font dans un contexte d explosion des volumes de données à transférer. Par conséquent, on

182 164 Chapitre 10. Les réseaux ne peut se reposer uniquement sur le progrès technique pour absorber les besoins. Il faut donc une démarche active de contrôle de coûts. Les solutions préconisées sont les suivantes : 1. Sélectionner des protocoles de communication peu verbeux et limiter les quantités d informations échangées au minimum nécessaire. 2. Estimer les quantités de bande passante nécessaires pour les applications et dimensionner les tuyaux en conséquence. 3. Mettre en place une démarche de capacity planningen anticipant, sur la base des estimations du business, les besoins futurs en bande passante Idée fausse n 8 : le réseau est homogène La standardisation des protocoles de communication autour de TCP/IP a ouvert les portes à l interopérabilité des systèmes, mais cela n a fait que renforcer le caractère hétérogène des réseaux. Par exemple, aujourd hui, il n est plus rare de trouver des postes de travail Windows qui utilisent des serveurs de fichiers tournant sur Linux (Samba). La solution préconisée ici est de privilégier systématiquement l utilisation de protocoles standard et, si possible, ouverts (i.e. HTTP, SOAP, etc.) et d éviter le plus possible d avoir recours à des solutions propriétaires Synthèse des recommandations Le tableau 10.1 récapitule, pour chacune des huit idées fausses, les solutions à mettre en œuvre pour éviter de répéter indéfiniment les mêmes problèmes.

183 10.2 Les réseaux et la performance 165 Tableau 10.1 Synthèse des idées reçues et des recommandations Idées reçues La latence est nulle La bande passante est illimitée Le réseau est fiable Le réseau est sécurisé La topologie du réseau ne change pas Il n y a un qu un seul administrateur Les coûts de transport sont nuls Le réseau est homogène Solutions 1. Augmenter la granularité des services. 2. Évaluer l impact des opérations de marshalling. 3. Réaliser les tests de performance dans des environnements similaires à celui de production. 4. Intégrer les contraintes de latence dès la conception. 5. Rapprocher géographiquement les centres de production des utilisateurs. 1. Évaluer l impact des protocoles de communication sur la consommation de bande passante. 2. Utiliser quand c est possible la compression des données à la volée. 3. Réaliser les tests de performance dans des environnements similaires à celui de production. 1. Utiliser des équipements réseaux plus fiables et utiliser au besoin la redondance pour les plus critiques d entre eux. 2. Mettre en place des solutions logicielles de type MOM capables de garantir les échanges. 1. Isoler les serveurs dans des zones protégées. 2. Restreindre l accès physique et logique aux serveurs et équipements réseaux sensibles. 3. Utiliser des référentiels du type annuaire pour l authentification des utilisateurs et la gestion des habilitations. 4. Mettre en place une solution centralisée de surveillance des serveurs 5. Utiliser un VPN pour les connexions externes. 1. Utiliser des noms DNS au lieu des adresses IP. 2. Mettre en place un ESB pour s abstraire de la topologie physique. 1. Associer les différents administrateurs aux projets dès la phase de conception. 2. Rendre les applications monitorables par une meilleure gestion des logs et l utilisation de solutions d instrumentation. 1. Sélectionner des protocoles de communication efficaces. 2. Estimer précisément les besoins en bande passante. 3. Anticiper les besoins futurs par une démarche de capacity planning. 1. Privilégier systématiquement l utilisation de standard, si possible ouverts au lieu de protocoles propriétaires.

184 166 Chapitre 10. Les réseaux 10.3 TECHNIQUES DE DISPONIBILITÉ AVEC LES RÉSEAUX Le propos de cet ouvrage n est pas ici de présenter l intégralité des techniques de haute disponibilité à partir de solution réseau. Evan Marcus et Hal Stern l on fait brillamment dans leur Blueprints for High Availability (ISBN : ). Les programmes suivants illustrent simplement comme il est possible de mettre en place des solutions de disponibilités en utilisant des techniques purement réseau VIP et Health Check Une adresse IP virtuelle 1 est une adresse IP qui n est pas directement reliée à une interface réseau physique. Cette adresse peut donc être partagée entre plusieurs équipements, un couple de serveurs formant un cluster par exemple. Pour un même réseau, le protocole IP ne permet pas d avoir deux fois la même adresse sinon il y a conflit. Une adresse IP virtuelle ne peut donc être portée que par un équipement et par un seul à un moment donné. Basculer une adresse IP depuis une interface réseau est une opération facilement scriptable car elle ne demande que quelques commandes système Le health check, ou vérification de service régulier en français, est une technique qui permet à différents équipements informatiques de vérifier de manière régulière la présence et le fonctionnement d équipement de même nature qu eux. Sur le principe, chaque élément émet à périodicité régulière un message nommé Heartbeat. Ce message, très court, s apparente un message de type «Hello». Les règles de politesse réseau imposent à tous les équipements qui ont reçu ce «bonjour» d y répondre. Ainsi l émetteur sait qui est présent et qui est hors service. Figure 10.2 Principe des VIP el0:0 représente l interface physique de l équipement (qu on nomme également el0). A contrario el0:1 symbolise l adresse virtuelle. 1. Traduction française de Virtual IP.

185 10.3 Techniques de disponibilité avec les réseaux Bascule DNS Un serveur DNS est un équipement attaché au réseau de l entreprise. Il fait le lien entre les noms de serveurs (HostName) et les adresses IP. Dans un réseau d entreprise on peut trouver plusieurs serveurs DNS organisés de manière hiérarchique. Cette organisation se calque sur celle des noms de domaines. La figure 10.3 montre un exemple de l organisation des noms de domaines internet. Figure 10.3 Organisation des noms de domaine (source Wikipédia). Nous pouvons très bien imaginer autant de serveur DNS que de niveau : Un serveur DNS racine gérant les domaines.com,.org,.net, etc. Des serveurs secondaires (dit récursifs), gérant wikipedia, fsf, sqli. D autres serveurs récursifs permettant de résoudre les sous niveaux... Les figures 10.4 et 10.5 illustrent comment mettre en place une solution de disponibilité à l aide de DNS. Dans notre cas, nous avons deux serveurs web qui hébergent la même application (connue sous le nom de «appli.sqli.com»). Un des serveurs (OVALIE) est considéré comme le serveur principal, c est-à-dire que par défaut le serveur DNS renvoie l adresse IP lorsqu on lui demande de résoudre «appli.sqli.com». Figure 10.4 Fonctionnement en mode nominal

186 168 Chapitre 10. Les réseaux Imaginons maintenant que le serveur principal vienne à disparaître, suite à un incident grave. Il suffit de modifier le paramétrage du DNS pour que ce dernier résolve maintenant le nom de l application en fonction de l adresse IP du serveur de secours (ici LIVAROT). Figure 10.5 Passage en mode backup La modification d un serveur DNS reste toutefois une opération pilotée par l homme. On ne peut donc pas espérer mettre en œuvre une solution hautement disponible (A >= 99 %) uniquement à base de bascule DNS. Cependant, ce type de solution peut être envisagé dans les cas suivant : Bascule sur une application peu sensible (ou une indisponibilité de plusieurs minutes est acceptable). Bascule en cas de PCA entre deux sites : dans ce cas, la bascule DNS se fera sur les serveurs racines du domaine de l entreprise Redondance de routeur virtuel VRRP est un protocole définit par le RFC L objectif est d augmenter la disponibilité de la passerelle par défaut pour tous les serveurs d un même sous-réseau. Le principe de fonctionnement de celui-ci est relativement simple. Chaque routeur fait partie intégrante d un groupe de routeur, au sein duquel il possède une priorité servant à l élection du maître de ce groupe. Le routeur maître est considéré comme le routeur actif. Le master VRRP possède une adresse IP virtuelle et une adresse MAC virtuelle associée à cette VIP. En cas de défaillance de l équipement, l élection se joue donc à nouveau et ce couple d éléments virtuels est attribué au routeur étant élu maître. Lorsqu une machine pointera donc vers l adresse IP virtuelle, ce sera donc systématiquement l adresse MAC virtuelle qui sera retournée lors de requêtes ARP.

187 10.3 Techniques de disponibilité avec les réseaux 169 Figure 10.6 VRRP avec deux routeurs Un health check permet à chaque routeur d un groupe de contrôler régulièrement l état de ses voisins et de dérouler les bons algorithmes en conséquence. Tous ces échanges sont réalisés en multicast, tous les membres du groupe sont donc informés en permanence de l état de santé de leurs voisins. Ces messages périodiques sont échangés avec une période par défaut de 3 secondes et le temps de latence avant qu un routeur considère son voisin comme coupé est de 10 secondes (hold interval). Dans un groupe VRRP, il n y a pas de notion de partage de la charge, c est le routeur maître qui assure exclusivement la transmission des paquets pour le routeur virtuel. S il y a un nombre d hôtes suffisant, il est toutefois possible de définir plusieurs groupes VRRP sur chacun des routeurs, et de configurer autant de groupes d hôtes qui auront chacun une passerelle par défaut différente. VRRP est concurrencé par de nombreux autres protocoles de niveau 3 comme : Hot-Standby Router Protocol (HSRP) : protocole propriétaire CISCO très proche de VRRP. ICMP Router Discovery Protocol (IRDP) : protocole plutôt obsolète et beaucoup moins puissant puisque son hold interval est de 30 minutes et son health check de 10 minutes.

188 170 Chapitre 10. Les réseaux En résumé Ce chapitre a présenté les principales propriétés des réseaux et leurs conséquences sur les applications. À l heure où la quasi-totalité des applications sont aujourd hui connectées soit à un réseau local, soit à l Internet, la prise en compte des particularités des réseaux dans la conception des applications est devenue indispensable. Deux architectes de SUN, Peter Deutsch et James Gosling, ont exprimé les erreurs le plus souvent commises sous la forme des huit idées fausses de l informatique distribuée. Ce chapitre les a reprises une par une et a proposé des solutions pratiques pour y remédier. L accent a été mis, en particulier, sur les problèmes liés à la latence qui est de loin la principale cause de problèmes de performance dans les applications distribuées. Nous terminons par quelques notions réseaux permettant d envisager des solutions de performance comme la bascule DNS ou le VRRP.

189 11 Le stockage Objectif Ce chapitre a pour objectif de présenter les principales architectures de stockage des données. Le sujet est traité principalement sous l angle des temps de réponse (latence), du débit et de la disponibilité. Le but n est pas ici de dresser une liste exhaustive des solutions disponibles, mais de livrer aux architectes une synthèse des enjeux de performance en matière de stockage. Ce chapitre aborde les points suivants : 1. Les disques durs. 2. Les stratégies d accès aux données. 3. Les techniques d amélioration des performances du stockage (RAID). Le domaine du stockage concerne l ensemble des technologies utilisées pour assurer la persistance physique à moyen et long terme des données applicatives. Il s agit donc des supports non-volatils, ce qui exclut les mémoires de type RAM. Pour simplifier, nous nous limiterons au cas des disques durs qui sont le support de stockage le plus couramment utilisé. La performance d un système de stockage repose essentiellement sur trois points : 1. Les interfaces d accès aux disques durs. Il s agit de la technologie utilisée pour connecter les disques durs aux systèmes. 2. Les stratégies d accès aux données qui offrent le choix entre des accès de bas niveau, de haut niveau, locaux ou distants.

190 172 Chapitre 11. Le stockage 3. Les solutions RAID qui permettent d agir directement sur la disponibilité et le débit des systèmes de stockage DISQUES DURS ET INTERFACES D ACCÈS Les disques durs sont des périphériques mécaniques qui stockent les informations sur un support magnétique. Ils sont constitués de plateaux circulaires qui tournent à grande vitesse et d un bras munis de têtes de lecture capables de parcourir chacune l intégralité d un plateau. Ils disposent généralement aussi d un bloc de mémoire tampon (cache) destiné à améliorer les performances des entrées-sorties. Les caractéristiques d un disque dur dépendent : Pour la capacité de stockage : de la densité des informations sur les plateaux ; de la taille des plateaux ; du nombre de plateaux. Pour la latence et le débit : de la vitesse de rotation des plateaux (en tours par minute ou RPM) ; de la taille de la mémoire tampon. Par ailleurs, le type d interface qui relie le disque au serveur a une grande importance pour la performance. Il s agit du protocole et de la connectique utilisés pour le faire communiquer avec l extérieur. Les standards les plus utilisés sont décrits dans les sections qui suivent. Figure 11.1 Un disque dur 3,5 (Source WikiMedia) Du point de vue de la performance, il ne faut pas perdre de vue que ces périphériques sont mécaniques et utilisent des pièces en mouvement. Il est donc naturel que les taux de panne soient beaucoup plus élevés sur les disques durs que sur d autres types de périphériques. C est la raison pour laquelle on a recours à des technologies particulières pour traiter ce problème (voir la section RAID de ce chapitre).

191 11.1 Disques durs et interfaces d accès Le standard S ATA S-ATA (Serial Advanced Technologie Attachmement) est le bus de données le plus communément utilisé pour les disques durs. Il offre de nombreuses améliorations telles que l allongement de la longueur de câble, l augmentation du débit ou encore la capacité d ajouter/enlever des périphériques à chaud (hot-plug). Il existe plusieurs variantes de la norme S-ATA, elles se différencient essentiellement par leur vitesse de transfert de l information (tableau 11.1). Tableau 11.1 Les différentes versions du standard S ATA Version Vitesse de transfert théorique Vitesse de transfert réelle S ATA/150 1,5 Gbits/s 1,2 Gbits/s soit 150 Mo/s S ATA/300 3,0 Gbits/s 2,4 GBits/s soit 375 Mo/s S ATA/600 6,0 GBits/s 4,8 GBits/s soit 600 Mo/s Si on confronte ce tableau à celui qui présente les caractéristiques des disques durs, on s aperçoit du premier coup d œil que la version de base de S-ATA offre déjà un débit réel très supérieur à celui des disques les plus rapides du marché. En fait, il s agit de la bande passante globale, elle peut être partagée entre plusieurs périphériques connectés sur le même port. Ce débit très élevé ne présente donc que peu d intérêt lorsqu un seul périphérique est connecté. Le standard S-ATA est la norme de référence pour les ordinateurs portables, les postes de travail et les serveurs d entrée et de moyen de gamme. Il est peu utilisé pour les disques durs à très haute vitesse ( RPM). Ses capacités de stockage très élevées et ses coûts raisonnables en font de plus en plus un challenger de solutions telles que SCSI qui ont longtemps dominé le marché des serveurs Le standard SCSI Le bus d échange SCSI a été créé en 1981 à partir d un ancien bus nommé SACI et qui avait été mis au point par Alan Shugart, un ingénieur d IBM connu pour avoir conçu le premier disque dur dans les années SCSI signifie littéralement Small Computer System Interface. C est un bus d échange de données destiné à relier des ordinateurs entre eux où des ordinateurs à des périphériques quels qu ils soient. Dans la pratique, SCSI est surtout utilisé aujourd hui pour connecter des disques durs à des serveurs. Il permet le branchement de 15 disques par contrôleur utilisé. Il existe plusieurs normes SCSI : SCSI 1 est la norme telle qu elle a été publiée dans les années SCSI 2 et 3 sont des améliorations apportées dans les années 1990 et SCSI se distingue de S-ATA par la longueur de câbles permise entre le serveur et les périphériques. En effet, celle-ci est d environ 25 m contre 1 m pour S-ATA. C est un avantage très important pour les serveurs car cela laisse plus de latitude si l on souhaite stocker les disques dans des baies séparées des serveurs.

192 174 Chapitre 11. Le stockage Le standard SCSI prévoit un nombre important de variantes, le tableau 11.2 reprend les plus importantes et leurs principales caractéristiques. Tableau 11.2 Les différentes versions du standard SCSI Version SCSI 1 Fast SCSI Fast Wide SCSI Ultra SCSI Ultra Wide SCSI Ultra 2 SCSI Ultra 2 Wide SCSI Ultra 3 SCSI Ultra 320 SCSI Ultra 640 SCSI Vitesse de transfert 5 Mo/s 10 Mo/s 20 Mo/s 20 Mo/s 40 Mo/s 40 Mo/s 80 Mo/s 160 Mo/s 320 Mo/s 640 Mo/s Comparé aux débits offerts par la norme S-ATA, le SCSI n apporte pas de nouveaux avantages, les ordres de grandeur étant à peu près les même. En revanche, les systèmes SCSI gèrent mieux les accès concurrents, ce qui en fait la solution la plus adaptée pour les applications transactionnelles. Néanmoins, ses coûts de fabrication sont plus élevés, tant pour les cartes que pour les composants électroniques à intégrer sur les périphériques. L utilisation de SCSI est aujourd hui clairement confinée au monde des serveurs haut de gamme qui nécessitent les meilleurs composants, tant sur le plan de la performance pure (le débit) que sur celui de la disponibilité. C est la raison pour laquelle les disques durs SCSI sont presque toujours de type RPM. Sans surprise, ils sont aussi plutôt coûteux. Les capacités offertes sont généralement de 36 Go, 73 Go, 143 Go ou 300 Go, ce qui est très en retrait par rapport à la limite de Go pour les disques moins rapides. En 2004 est apparu un nouveau standard appelé SAS (Serial Attached SCSI) qui devrait à terme remplacer le SCSI traditionnel. SAS présente les caractéristiques suivantes : Support de 128 périphériques par carte contrôleur. Compatibilité avec les disques durs S-ATA. Cependant, la réciproque n est pas vraie, les disques durs SAS ne peuvent pas être reliés à des cartes S-ATA. Un débit de 360 Mo/s par périphérique (et non partagé par tous les périphériques reliés à la carte). Ce débit devrait rapidement passer à 750 Mo/s puis ensuite à 1,5 Go/s. Distance maximale de 8 m entre la carte et les périphériques.

193 11.1 Disques durs et interfaces d accès 175 La plupart des constructeurs continuent néanmoins à supporter à la fois les standards SAS et SCSI. Toutefois, à terme, ce dernier devrait disparaître Le standard FC FC ou Fibre Channel est un protocole qui a été créé pour assurer la liaison à très haut débit entre des super-calculateurs et leurs zones de données. C est le protocole le plus utilisé pour les réseaux de stockage. Les disques durs offrant une interface FC sont toujours les plus performants et les plus onéreux. Contrairement à ce que son nom peut laisser croire, le standard FC peut fonctionner soit sur une paire de fils cuivre torsadée, soit sur de la fibre optique. Les réseaux FC peuvent être construits autour de trois topologies distinctes : En point-à-point (FC-P2P), le serveur est directement relié au périphérique. Ce mode ne permet pas de relier directement plus de deux périphériques. En boucle (FC-AL), les périphériques sont reliés ensemble et forment un anneau similaire à celui des anciens réseaux Token ring. Ce mode permet l interconnexion de 127 périphériques. En revanche, il n est pas possible d ajouter ou de retirer les composants à chaud dans cette configuration. En commutation (FC-SW), les périphériques sont reliés entre eux par l intermédiaire d un commutateur (switch) assez similaire à ceux utilisés pour le protocole Ethernet. Le nombre de périphériques connectables est quasiment illimité et il est possible d en enlever/rajouter à chaud sans éteindre l ensemble du système. Les réseaux FC présentent les caractéristiques suivantes : Un très haut niveau de débit : 2 GBits (250 Mo/s), 4 GBits (500 Mo/s), 6 GBits (750 Mo/s) et bientôt 10 GBits (1,25 Go/s). Le support des communications longue distance : de plusieurs centaines de mètres jusqu à plusieurs dizaines de kilomètres selon les variantes. Dans ce domaine, Fibre Channel domine largement les protocoles concurrents tels que S-ATA et SCSI qui restent cantonnés aux échanges sur des courtes distances. Cela fait de Fibre Channel la solution de référence pour relier des réseaux de stockage sur des sites distants. Les installations Fibre Channel se caractérisent par une forte complexité et des coûts très élevés. Elles sont exclusivement réservées aux organisations disposant de gros budgets et devant déployer des applications critiques Conclusion sur les interfaces d accès Il existe trois grandes familles d interfaces pour interconnecter des disques durs avec des serveurs : S-ATA, SCSI/SAS et FC. Le tableau 11.3 récapitule leurs principales caractéristiques.

194 176 Chapitre 11. Le stockage Tableau 11.3 Synthèse des principaux types de disques Type 2,5 (pour les portables) 3,5 (pour les serveurs moyens de gamme) 3,5 (pour les serveurs haut de gamme) Vitesse de rotation RPM à RPM à RPM Latence 6 ms 4 ms 2 ms Débit max. 40 Mo/s 80 Mo/s 120 Mo/s Capacité max. 600 Go 2 To 320 Go AFR/MTBF 2,65 % H 0,73 % H 0,63 % H Prix au Go Élevé Moyen Très élevé Le choix d une de ces solutions parmi les trois disponibles n est pas toujours évident car, au cours de ces dernières années, les performances de la technologie S-ATA se sont considérablement améliorées et l écart avec le SCSI s est en partie comblé. À tel point que l on trouve parfois aujourd hui des disques haut de gamme ( RPM, 150 ou 300 Go) avec une interface de type S-ATA. Néanmoins, ces disques sont vendus à des tarifs proches de ceux des modèles SCSI. Pour compliquer encore le choix, on trouve désormais des solutions de réseaux de stockage utilisant des disques S-ATA alors que ce secteur était traditionnellement réservé au SCSI. Quoi qu il en soit, les meilleurs disques durs ne sont généralement disponibles qu en SCSI/SAS ou FC. Mais pour combien de temps encore? Par ailleurs, aucune de ces interfaces n adresse directement la question de la disponibilité en offrant, par exemple, des mécanismes de redondance. Ces derniers font l objet d une standardisation séparée connue sous le nom RAID. Dans certains cas, ils peuvent être implémentés directement sur les cartes contrôleurs quel que soit le type de l interface : S-ATA, SCSI/SAS ou FC. Les systèmes RAID sont décrits en détail dans la section suivante LES SYSTÈMES RAID Les systèmes RAID sont nés à la fin des années 1980 lorsque trois chercheurs de l université de Berkeley ont cherché à construire des systèmes offrant un haut niveau de performance et de disponibilité à partir de disques durs classiques. RAID signifie Redundant Array of Inexpensive Disks. C est en fait une famille de normes utilisées pour combler les lacunes des interfaces S-ATA, SCSI et FC en matière de disponibilité. Certaines d entre elles permettent également d augmenter les performances (débit) des systèmes disques. Les techniques RAID sont généralement implémentées par les interfaces d accès (S-ATA, SCSI...) mais certaines d entre elles peuvent aussi être mises en place de façon logicielle, généralement au niveau du système d exploitation.

195 11.2 Les systèmes RAID 177 Les sections suivantes présentent les modes RAID les plus couramment rencontrés. Ces modes forment aujourd hui des standards reconnus qui sont mis en œuvre par la plupart des constructeurs de matériels. Il en existe d autres plus rares ou qui ne sont pas totalement normalisés. L objectif est de présenter succinctement chacune des solutions et de présenter leurs avantages et inconvénients respectifs particulièrement dans les domaines de la performance Les modes simples Le RAID 0 Les modes dits simples sont ceux qui ne font appel qu à une seule technique RAID en même temps, par opposition à ceux qui en combinent plusieurs à la fois. Ces modes sont les suivants : RAID 0, RAID 1, RAID 3, RAID 5. Le RAID 0 utilise une technique appelée striping ou agrégats par bandes. Ce mode permet d assembler plusieurs disques physiques pour former un disque logique. Les données des fichiers sont réparties sur l ensemble des disques du système. Cette répartition s effectue par bloc. Avec ce procédé, chaque disque possède un morceau de chaque fichier, mais aucun disque ne possède un fichier dans son intégralité. Ce mode requiert un minimum de deux disques. Les disques qui forment un système RAID 0 doivent tous avoir la même capacité de stockage. Si ce n est pas le cas, la capacité de stockage effectivement disponible sera égale à celle du plus petit disque, multipliée par le nombre de disques. ABCDEFGH ABCD EFGH Figure 11.2 Schéma de fonctionnement du RAID 0 L éclatement des données d un même fichier sur plusieurs disques physiques offre un avantage certain pour la performance des opérations de lecture et d écriture. En effet, au lieu de solliciter un seul disque à chaque opération, il est possible de paralléliser les

196 178 Chapitre 11. Le stockage Le RAID 1 tâches en sollicitant simultanément tous les disques. Il en résulte une nette amélioration des entrées sorties. En revanche, du point de vue de la disponibilité, le RAID 0 est un assemblage de composants en série. La disponibilité de l ensemble se réduit donc de façon proportionnelle au nombre de disques qui la composent. L indisponibilité de l un d entre eux entraîne automatiquement l indisponibilité de toutes les données. Le domaine d utilisation du RAID 0 est celui des applications avec des opérations disques nombreuses (i.e. manipulation de gros fichiers multimédia) qui ne nécessitent pas un haut niveau de disponibilité. Néanmoins, les avantages du stripping en matière de performance sont repris dans d autres modes RAID qui offrent en plus des avancées en matière de disponibilité. Le RAID 1 utilise un procédé appelé mirroring ou miroir qui consiste à dupliquer à l identique les données sur plusieurs disques. Dans un système RAID 1, tous les disques (généralement deux) contiennent donc exactement les mêmes données. La figure 11.3 illustre le stockage d un fichier sur un système RAID 1. Le fichier est en fait stocké intégralement une fois sur chaque disque. ABCDE FGH ABCDE FGH ABCDE FGH Figure 11.3 Schéma de fonctionnement du RAID 1 Le RAID 1 augmente fortement la disponibilité des données car il permet au système de survivre au crash de l un des deux disques qui le constituent. Il offre aussi une amélioration des performances, car les informations étant stockées en double il est possible de paralléliser les opérations de lecture. Les opérations d écriture se font en revanche à un rythme normal. Si les disques ne sont pas identiques, les opérations d écriture s effectuent à la vitesse du plus lent des deux modèles. Attention, le RAID 1 pose un sérieux problème de coûts car sa mise en œuvre entraîne une surconsommation de 100 % de la capacité disque nécessaire.

197 11.2 Les systèmes RAID 179 Le RAID 1 est un mode à réserver aux applications critiques nécessitant un haut niveau de disponibilité. Le RAID 3 Le RAID 3 est un procédé qui combine à la fois le striping et le parity-checking ou contrôle de parité. Ce dernier est un mécanisme qui permet de reconstituer des informations à partir d un fragment de données et d un code de contrôle. Ce mode nécessite l utilisation d au moins trois disques. L un des disques est dédié au stockage des informations de parité. Celles-ci permettent la reconstitution des données à partir de l un ou de l autre des deux autres disques. ABCDEFGH A C E G B D F G Parité (A-B) Parité (C-D) Parité (E-F) Parité (G-H) Figure 11.4 Schéma de fonctionnement du RAID 3 Ce mode présente un double intérêt sur le plan de la performance et de la disponibilité. Il améliore les performances en lecture grâce à l utilisation du striping et offre un bon niveau de disponibilité car il est possible de perdre n importe lequel des trois disques sans interrompre l accès aux fichiers. Le RAID 3 se distingue surtout pour les accès séquentiels sur des gros fichiers, par exemple des documents multimédias. Dans la pratique, le RAID 3 est assez peu utilisé car il présente quelques inconvénients, en particulier : Le disque de parité est plus sollicité que les deux autres, ce qui peut entraîner des ralentissements et une usure précoce. Le stripping s effectue au niveau octet et non au niveau bloc, ce qui est pénalisant pour les performances. Ces inconvénients ont été corrigés dans le mode RAID 5 qui est décrit dans la section suivante.

198 180 Chapitre 11. Le stockage Le RAID 5 Le RAID 5 est un mode qui, comme le RAID 3, combine l utilisation du striping et celle du parity checking. Il y a cependant deux différences importantes avec ce dernier. D une part le stripping est effectué par bloc au lieu d être réalisé par octets et, d autre part, les codes de parité ne sont pas stockés sur un disque dédié mais répartis sur l ensemble des disques du système. Chaque partie du fichier est découpée en trois blocs de données qui sont envoyés chacun sur un disque différent, le dernier disque reçoit quant à lui les codes de parité. Cette opération est répétée autant de fois que nécessaire, sachant qu à chaque itération les codes de parité sont transférés sur un disque différent. ABCDEFGHIJKL A B C Parité (A-B-C) D E Parité (D-E-F) F G Parité (G-H-I) H I Parité (J-K-L) J K L Figure 11.5 Schéma de fonctionnement du RAID 5 Le RAID 5 permet une nette amélioration des performances en lecture grâce à l utilisation de la technique du stripping. Les accès en écriture sont en revanche un petit peu en retrait en raison des opérations de calcul de parité. La disponibilité est très bonne puisqu il est possible de perdre un disque sans perte de données ni dégradation des temps de réponse. Le RAID 5 est particulièrement intéressant pour les applications qui nécessitent des taux d entrées sorties élevés sur des faibles volumes de données. C est un des systèmes les plus utilisés pour les bases de données relationnelles. En RAID 5, il est nécessaire que tous les disques du système aient la même capacité. Le rendement en termes de stockage est relativement bon et croît avec le nombre de disques qui composent le système.

199 11.2 Les systèmes RAID Les modes composites Les modes RAID composites sont des solutions techniques qui combinent deux modes RAID simples parmi ceux décrit dans la section précédente. Ils permettent de cumuler les avantages de ces modes tout en limitant les inconvénients. Les modes composites s appliquent à des ensembles de taille plus importante avec au minimum de quatre à six disques. Les modes composites les plus courants sont : RAID 10 et RAID 50. Ils sont décrits en détail dans les sections suivantes. Le RAID 10 Le RAID 10, aussi appelé RAID 1+0, consiste à créer des zones de mirroring distinctes qui sont reliées ensemble par une relation de stripping. Ce mode est aussi appelé striped mirrors. La figure 11.6 illustre le stockage d un fichier sur un système RAID 10 composé de six disques. Ceux-ci constituent trois paires de miroir RAID 1 montées pour former une zone de stripping. Avec une telle configuration, il est possible de perdre jusqu à trois disques en même temps (un sur chaque miroir). ABCDEFGHIJKL RAID 0 ABCD EFGH IJKL RAID 1 RAID 1 RAID 1 ABCD ABCD EFGH EFGH IJKL IJKL Figure 11.6 Schéma de fonctionnement du RAID 10 Le RAID 10 offre à la fois un excellent niveau de performance en lecture/écriture et une amélioration de la disponibilité. Néanmoins, comme pour le RAID 01, cette dernière se fait au prix d une perte importante de la capacité (50 %). Ce mode est à réserver aux projets à gros budgets qui souhaitent atteindre un excellent niveau de performance sans faire de compromis sur la disponibilité.

200 182 Chapitre 11. Le stockage Le RAID 50 Le RAID 50, aussi appelé RAID 5+0. Concrètement, il s agit donc d une solution de stripping où chaque nœud repose sur un sous-système RAID 5. Le contenu est découpé en deux morceaux qui sont ensuite stockés sur un système RAID 5. ABCDEFGHIJKL RAID 0 ABCDEF GHIJKL RAID 5 RAID 5 A B Parité (A-B) G H Parité (G-H) C Parité (C-D) D I Parité (I-J) J Parité (E-F) E F Parité (K-L) K L Figure 11.7 Schéma de fonctionnement du RAID 50 Le RAID 50 offre à la fois un bon niveau de performance en lecture et une amélioration de la disponibilité. Le RAID 50 étend la capacité du RAID 5 en permettant une augmentation significative du nombre de disques qui composent le système. Son domaine de prédilection est les grosses bases de données relationnelles Conclusion sur les modes RAID Les termes RAID regroupent un ensemble de pratiques permettant de construire des assemblages de disques durs en vue d augmenter la capacité de stockage, les performances en lecture/écriture ou encore la disponibilité. Les modes RAID présentent une grande diversité et leurs propriétés sont souvent contradictoires. Le choix d une solution dépendra donc fortement de la nature de l application et des contraintes du projet. Le tableau 11.4 récapitule les principales propriétés des systèmes RAID simples et composites

201 11.2 Les systèmes RAID 183 Type Nombre de disques Niveau de disponibilité Tableau 11.4 Niveau de performance en lecture Niveau de performance en écriture Espace disque perdu JBOD 2 + Mauvais Inchangé Inchangé 0 % Raid Mauvais Très bon Très bon 0 % Raid Bon Bon Correct 50 % Raid Bon Bon Correct 33 % Raid Bon Bon Correct 10 à 20 % Raid Bon Très bon Bon 50 % Raid Excellent Très bon Bon 50 % Raid Bon Bon Correct 33 % Raid Bon Bon Correct 10 à 20 % Enfin, le tableau 11.5 présente une synthèse des domaines de prédilection respectifs pour chacun des modes RAID étudiés dans ce chapitre. Tableau 11.5 Synthèse des domaines de prédilection des modes RAID Type Domaine d utilisation Coûts RAID 0 RAID 1 RAID 3 RAID 5 RAID 10 Applications qui manipulent de gros fichiers sans réels besoins de haute disponibilité (image, son, vidéo). Applications manipulant une quantité restreinte de données critiques nécessitant un haut niveau de disponibilité. Applications travaillant sur de gros fichiers de type séquentiel (CAO, DAO, fichiers vidéo...) et nécessitant un bon niveau de disponibilité. Applications nécessitant des taux d E/S élevés sur de faibles volumes (bases de données relationnelles). Applications nécessitant de très bons niveaux de performance et de disponibilité. Petits budgets s abstenir. Normal Très élevé Élevé Élevé Très élevé RAID 50 Bases de données de grande taille. Élevé Les applications de gestion dont les données sont stockées dans des bases de données relationnelles tireront donc partie des modes RAID 5 et RAID 50. Attention toutefois, ces modes présentent une particularité en cas d incident sur l un des disques du système. L arrêt d un disque n entraîne pas de conséquences immédiates pour les utilisateurs, ceux ci continuent d accéder normalement aux données. En revanche, les problèmes risquent de survenir lors du remplacement du disque défectueux par un nouveau disque car il faudra le resynchroniser avec les autres disques et recalculer les informations de parité sans arrêter le service. Dans ces circonstances, les performances des systèmes RAID 5 et RAID 50 sont sensiblement réduites. Cela peut mener à des situations où les utilisateurs ne perçoivent

202 184 Chapitre 11. Le stockage la dégradation de la qualité de service que lors du remplacement du disque défectueux et non lors de la défaillance initiale LES STRATÉGIES D ACCÈS AUX DONNÉES Il existe donc trois familles d interfaces pour relier les disques durs au monde extérieur. Cette section aborde maintenant les différentes stratégies possibles d accès aux données. On entend par là, la nature des échanges entre, d un côté les serveurs et, de l autre, les disques de stockage. Il existe trois stratégies différentes qui sont décrites dans les sections suivantes Le Direct Access Storage (DAS) Il s agit de la stratégie d accès traditionnel, une ou des cartes contrôleurs sont installées sur le serveur et les disques y sont directement reliés. Le terme DAS a été créé après l arrivée des SAN et NAS afin de disposer d un terme équivalent pour l accès direct aux données. Les disques peuvent être soit stockés directement dans le boîtier du serveur, soit stockés dans des baies de stockages dédiées. Dans ce dernier cas, il convient de respecter les distances maximales liées à l interface d accès utilisée. Le mode DAS présente les caractéristiques suivantes : Les disques sont directement reliés au serveur. Les échanges de données entre le serveur et les disques se font en mode bloc en utilisant l une des trois interfaces disponibles (S-ATA, SCSI/SAS, FC). Il n est pas possible de relier un disque à plusieurs machines simultanément. L allocation de l espace disque qui en résulte est donc très peu optimisée, puisque chaque serveur dispose de ses propres disques et l espace libre n est pas distribué entre les machines. Cela conduit nécessairement à un gaspillage des ressources. Les coûts sont relativement faibles puisqu aucun composant additionnel n est nécessaire Le Storage Area Network (SAN) Le SAN est une approche basée sur l utilisation d un réseau dédié pour accéder aux données. Dans la pratique, on utilisera surtout le SAN pour les données applicatives et on continuera à utiliser le DAS pour les partitions systèmes. Le SAN permet une consolidation et une virtualisation des données à l échelle des salles serveurs. Concrètement, un SAN se présente sous la forme d une armoire dont la taille varie en fonction de la capacité d accueil. Cette armoire contient plusieurs baies de disques et est reliée au reste du système d information par un réseau dédié. Généralement, ce réseau est de type FC, mais de plus en plus de solutions d entrée de gamme reposent sur une alternative plus simple et moins coûteuse appelée iscsi. En fait, il s agit tout simplement d un portage du protocole SCSI sur réseau Ethernet. Les principaux

203 11.3 Les stratégies d accès aux données 185 fournisseurs de solutions SAN sont EMC, Netapp, Sun Storagetek, HP ou encore IBM. Le mode SAN présente les caractéristiques suivantes : Les disques ne sont pas directement reliés au serveur. Les échanges de données entre le serveur et les disques se font en mode bloc en utilisant des protocoles tels que FC ou iscsi. Il est possible de séparer les ressources physiques (disques) des partitions qui sont publiées sur le réseau. Il s agit d une forme de virtualisation du stockage qui offre un découplage entre la ressource physique réelle et la ressource logique qui est disponible. Cela permet notamment de redimensionner à chaud les quantités de disques alloués à un serveur. Il est possible de relier un disque à plusieurs machines simultanément. Figure 11.8 Schéma simplifié d une infrastructure SAN Cette propriété ne va pas sans poser de difficultés, car dans la vision traditionnelle du système d exploitation, c est ce dernier qui est chargé de gérer les accès exclusifs aux données qui sont dans les fichiers. Or ici, en cas d accès concurrents par plusieurs serveurs (et donc plusieurs instances de systèmes d exploitations) à un même bloc de données, on ne peut pas gérer convenablement les verrous. Cette difficulté est résolue par l utilisation de systèmes de fichiers particuliers qui prennent en charge ce type de problèmes. La mise en œuvre d un SAN n est donc pas exclusivement une question de hardware. Les coûts sont élevés car il est nécessaire d investir dans une solution complète de stockages (baie, réseaux et cartes spécifiques), mais ils sont compensés par les économies de matériels (moins de Go gaspillés) et d administration car il est désormais possible d administrer tous les disques depuis un point central.

204 186 Chapitre 11. Le stockage Il est également possible de créer un SAN à partir d une solution logicielle. C est ce que fait OpenFiler, un produit basé sur une distribution Linux et qui supporte le protocole iscsi. Son intérêt reste néanmoins assez limité puisque le principal avantage d un SAN est basé sur la robustesse des équipements matériels utilisés. Comme tout autre équipement informatique le SAN n échappe pas à certains problèmes de montée en charge ou de disponibilité. La perte d une infrastructure SAN peut être dramatique pour l entreprise puisque toutes les données sont stockées au même endroit. Il conviendra donc de prévoir une solution de secours. Pour cela les fournisseurs de solutions SAN proposent plusieurs possibilités basées sur deux grands principes : Copy On Write : dès qu une donnée est modifiée, la mise à jour est portée sur l environnement de backup (c est le cas de SRDF 1 ) SnapShot : cette technique ne modifie pas directement la donnée, elle inscrit la mise à jour sur un espace libre et modifie son BlockMap 2 afin que ce dernier représente toujours les fichiers (ou les LUNs 3 ) tels qu ils doivent être vus par les systèmes en amont. À partir de là, il est possible de sauvegarder uniquement les BlockMap (produire des Snapshots) ce qui permettra de revenir plus facilement à une écriture donnée. NetApp utilise la technique des SnapShot. Coté performance, lorsque l on utilise une infrastructure SAN il y a quelques règles à respecter : Bien repartir les LUN sur plusieurs disques afin d augmenter le nombre d axes en cas de lecture/écriture et de profiter au maximum de la bande passante (maximiser les entrées/sorties). Monitorer en permanence l utilisation du cache de votre SAN. Si vos données ne restent pas suffisamment longtemps dans le cache vous allez rapidement perdre tous les bénéfices de ce dernier. Le taux d utilisation du cache est également une donnée à surveiller pour les mêmes raisons. Dans le même ordre d idée, il convient de surveiller le débit de votre SAN car si ce dernier chute vous risquez de rencontrer de forte diminution des temps de réponse des applications (et plus particulièrement sur les bases de données) Le Network Access Storage (NAS) Cette stratégie d accès diffère sensiblement du DAS et du SAN car les protocoles utilisés pour l accès aux données sont de type fichier et non pas bloc. Généralement, 1. Symmetrix Remote Data Facility, est un produit de la société EMC permettant la réplication de données entre deux baies SAN. 2. Structure utilisée dans les SAN pour faire le lien entre les LUN et les systèmes de fichier. Elle peut-être apparentée à une table d allocation au niveau SAN. 3. Logical Unit Number : identifiant d une zone de stockage présenté à un serveur. Un système de fichier peut être composé d une ou plusieurs LUN.

205 11.3 Les stratégies d accès aux données 187 les NAS sont des petits serveurs construits autour de baies de disques qui sont pilotés par un mini-système d exploitation dédié à la gestion des données. Celui-ci expose les données des disques sur le réseau à l aide d un ou plusieurs protocoles de partages de fichiers. Les protocoles les plus utilisés sont CIFS (le protocole de Windows) et NFS (celui d Unix). Les principaux fournisseurs de solutions NAS sont les mêmes que pour les SAN. Il existe également une offre de solutions NAS logicielles, on peut citer : Samba, FreeNAS ou encore OpenFiler. Le mode NAS présente les caractéristiques suivantes : Les disques ne sont pas directement reliés au serveur. Les échanges de données entre le serveur et les disques se font en mode fichier en utilisant des protocoles tels que CIFS ou NFS. Il est possible de publier des disques virtuels qui reposent sur l utilisation de plusieurs disques physiques. Cela s obtient généralement par l utilisation conjointe du NAS avec un système RAID. Il est possible d offrir l accès aux mêmes fichiers à plusieurs serveurs simultanément (c est même l objectif principal du NAS!). L utilisation du NAS entraîne à la fois une sollicitation de son système disque mais aussi de son CPU. À partir de certains niveaux de charge (nombre de connexions, débit), cela peut devenir problématique. Ces systèmes sont extensibles au niveau des disques mais généralement pas au niveau des CPU et de la mémoire. On appelle «tête de NAS» un système NAS qui ne possède pas de disques propres et qui publie sous forme fichier des données bloc provenant d un SAN. Les solutions NAS ne sont généralement pas adaptées pour une utilisation avec des bases de données. Elles sont en revanche très performantes pour les applications qui sollicitent les systèmes de fichier de façon intensive Conclusion sur les modes d accès Il existe trois modes d accès aux données : DAS, SAN, NAS. Ceux-ci présentent tous des caractéristiques intéressantes mais le SAN et le NAS sortent clairement du lot en offrant des fonctionnalités hors de portée des DAS. Le tableau 11.6 présente une rapide synthèse de ce mode. La tendance est aujourd hui clairement à la consolidation du stockage des données. Les solutions SAN sont donc en train de s imposer progressivement dans beaucoup d entreprises. Le protocole iscsi, qui permet la création de SAN sur des réseaux Ethernet, conjugué à l utilisation de disques S-ATA contribue fortement à la démocratisation des SAN. Par ailleurs, les SAN et les NAS se rapprochent inéluctablement, notamment grâce à des technologies telles que les têtes de NAS. De plus en plus de constructeurs sont donc en mesure d offrir simultanément les deux modes d accès à partir d un même équipement.

206 188 Chapitre 11. Le stockage Tableau 11.6 Synthèse des modes d accès aux données Mode d accès Type Accès concurrents Séparation entre ressources physiques et logiques Coûts DAS Bloc Non Non Faibles SAN Bloc Oui Oui Moyens (iscsi) Élevés (FC) NAS Fichier Oui Oui Faibles à élevés selon les choix En résumé Ce chapitre a présenté les principaux enjeux du stockage en matière de gestion de la performance. Le sujet a été traité en trois parties : 1. Les disques durs et les interfaces d accès avec la présentation succincte des standards S-ATA, SCSI et FC. 2. Une étude détaillée des principaux systèmes RAID et de leur impact sur la performance et la disponibilité des données. 3. Les stratégies d accès à la donnée avec le DAS, le SAN et le NAS. Le chapitre 13 complète cette première approche du stockage en particulier en détaillant le rôle des SAN dans les clusters de SGBD.

207 12 Le clustering Objectif Le terme cluster est très couramment utilisé pour désigner des solutions capables de supporter des niveaux de charge très élevés tout en offrant un haut niveau de disponibilité. Souvent synonymes de lourdeurs techniques et de surcoûts importants, les solutions de clustering ont la réputation d être difficiles à maîtriser. Ce chapitre a pour ambition de démystifier les clusters en présentant un par un les différents concepts sur lesquels ils sont construits et les façons de les combiner pour construire des solutions robustes et aptes à faire fonctionner des applications critiques. Il présente également les solutions alternatives au clustering et confronte les différentes approches possibles en présentant leurs avantages et inconvénients respectifs. Les concepts sous-jacents au clustering sont applicables à l ensemble des composants de l infrastructure logicielle : bases de données, annuaires, serveurs d applications, middleware orientés messages. Les détails sur leur mise en œuvre sont fournis dans les chapitres suivants QU EST CE QUE LE CLUSTERING? Le terme anglais cluster signifie selon le contexte : groupe, grappe ou amas. En informatique, il est utilisé pour désigner des systèmes constitués de groupes de serveurs qui sont vus de l extérieur comme un seul et même serveur logique. Les clusters jouent un rôle croissant dans les systèmes d information pour deux raisons :

208 190 Chapitre 12. Le clustering De plus en plus d applications nécessitent une capacité de traitement importante qu un seul serveur physique peut difficilement fournir : les clusters répondent ici à un besoin de scalabilité. Les contraintes de disponibilité (i.e. 24 h/24, 7 j/7) conduisent à redonder les serveurs pour se prémunir contre les pannes matérielles et assurer la continuité de service : les clusters sont, dans ce cas, un moyen de réaliser la haute disponibilité. Certains projets utilisent des clusters afin de répondre exclusivement à des -contraintes de montée en charge (scalability), tandis que d autres n utilisent que leurs propriétés en matière de disponibilité. Parfois, ce sont ces deux propriétés qui sont recherchées simultanément. Tout dépend des besoins utilisateurs, de la criticité de l application et des moyens disponibles LES DIFFÉRENTES FORMES DE CLUSTERING Une fois le mode de scalabilité retenu, il reste à décider du rôle des différents nœuds à l intérieur du cluster. En effet, il est possible de construire des clusters dans lesquels les nœuds ne jouent pas tous le même rôle. Il existe deux formes distinctes de clustering : la forme actif/passif et la forme actif/actif. Ces deux formes sont décrites en détail dans les deux sections qui suivent Les clusters actif/passif Aussi appelée standby cluster, cette forme de cluster est construite sur un principe de redondance passive qui consiste à doubler le serveur avec un second serveur en tout point similaire au premier. La particularité de ce mode réside dans le fait que, à un instant donné, seul un des serveurs du cluster travaille réellement (le serveur actif). L autre serveur est dans un état passif. En cas de panne du serveur actif, le serveur passif deviendra actif et prendra le relais. Attention, le second serveur ne doit pas être vu comme un équipement de secours (spare) que l on déploie en cas d incident. Dans ce mode, les deux serveurs sont démarrés, mais seul l un des deux traite les requêtes utilisateurs. Le second serveur est en sommeil. Les figures 12.1 et 12.2 illustrent la mise en œuvre d un cluster actif/passif constitué de deux serveurs. La figure 12.1 décrit la situation de départ : le serveur 1 est le serveur actif et il traite toutes les requêtes entrantes. Le serveur 2, quant à lui, est en sommeil et ne traite aucune requête. La figure 12.2 décrit la situation du cluster après un arrêt du serveur 1. Le serveur 2 devient alors le serveur actif et traite désormais toutes les requêtes entrant dans le cluster.

209 12.2 Les différentes formes de clustering 191 Figure 12.1 Cluster actif/passif en situation normale Figure 12.2 Cluster actif/passif en situation de panne Il existe évidemment une troisième configuration possible qui correspond à la situation où les deux serveurs sont arrêtés en même temps. Dans ce cas, on dit que le cluster est tombé, l application n étant plus disponible. Les clusters actif/passif présentent les caractéristiques suivantes : Amélioration du niveau de disponibilité puisque les serveurs sont montés en parallèle. Pas de réel impact sur la scalabilité car seul un serveur est actif à un instant donné. Doublement des coûts, au moins sur le plan du matériel et de l administration. En ce qui concerne les licences, les éditeurs ont généralement des solutions qui

210 192 Chapitre 12. Le clustering permettent de ne payer que pour les serveurs actifs (ce point doit être vérifié systématiquement avant de choisir un produit). Relative simplicité de mise en œuvre car il n y a pas d accès concurrent à gérer. Les clusters actif/passif sont donc avant tout destinés à traiter les problèmes de disponibilité. Il est à noter qu il est possible de monter des clusters de ce type avec plus de deux serveurs pour les applications nécessitant un très haut niveau de disponibilité. Les architectes qui recherchent des solutions gérant aussi la montée en charge se tourneront vers d autres solutions Les clusters de type actif/actif Les clusters actif/actif sont construits sur le principe de la redondance active qui consiste à déployer deux ou plus de deux serveurs au lieu d un seul. Chacun des serveurs est chargé de prendre sa part du travail envoyé au cluster. Ce type de cluster fonctionne sur un mode très simple : le travail est affecté aux serveurs actifs. Si l un d entre eux devient indisponible, il cesse simplement de recevoir des requêtes. Les autres serveurs actifs doivent alors encaisser une surcharge de travail pour compenser cette défaillance. La mise en œuvre de clusters de ce type entraîne nécessairement une réflexion sur le mécanisme de distribution de la charge (load-balancing). Ce point est traité à la section Dans ce type de configuration, les serveurs peuvent être de puissance identique ou non. Il est tout à fait possible de construire un cluster de ce type en assemblant des serveurs avec des configurations CPU et mémoires distinctes. Lorsque les configurations sont similaires, on utilise le terme cluster homogène. Dans le cas contraire, on parle de cluster hétérogène. Les clusters actif/actif sont aussi appelés takeover cluster. Les figures 12.3 et 12.4 illustrent le mécanisme de fonctionnement utilisé dans les clusters actif/actif. La figure 12.3 représente un cluster homogène composé de trois serveurs nommés 1, 2 et 3. Les trois serveurs sont actifs et traitent chacun leur part des requêtes entrantes. La figure 12.4 représente le même cluster après un incident qui a entraîné l arrêt du serveur 3. L application reste disponible car les serveurs 1 et 2 traitent désormais l intégralité des requêtes. Pour que cela fonctionne bien, il est évidemment nécessaire que ces serveurs soient capables d absorber la surcharge de travail. Ce scénario peut aussi se reproduire en cas de défaillance du serveur 1 ou du serveur 2. Dans ce cas, le dernier serveur restant devra assumer seul le traitement de toutes les requêtes.

211 12.2 Les différentes formes de clustering 193 Figure 12.3 Cluster actif/actif en situation normale Figure 12.4 Cluster actif/actif en situation de panne Les clusters actif/actif présentent les caractéristiques suivantes : Amélioration de la capacité de montée en charge proportionnellement au nombre de serveurs qui sont ajoutés dans le cluster. Amélioration de la disponibilité de l application, puisqu elle ne repose plus sur un seul serveur mais sur plusieurs. Comme pour les clusters actif/passif, il s agit donc d un montage de composants en parallèle.

212 194 Chapitre 12. Le clustering Attention, pour que cette amélioration soit effective il est nécessaire d avoir une réserve de puissance significative. Si le cluster est dimensionné au plus juste, en cas de défaillance d un serveur, les serveurs restants ne pourront pas encaisser la surcharge de travail. On retrouve ici le même problème que pour les clusters de type actif/passif. La haute disponibilité se paie au prix fort. Mise en œuvre relativement complexe car ce type de configuration entraîne des difficultés techniques. Celles-ci sont dues à la gestion de la concurrence pour les bases de données et à la gestion des sessions utilisateurs pour les serveurs d application. Les clusters actif/actif sont la meilleure réponse aux problèmes de montée en charge des applications. Ils ne présentent qu un intérêt limité pour les architectes qui recherchent uniquement une amélioration de la disponibilité Conclusions sur les formes de clustering Comme nous venons de le voir, il existe deux formes de clustering en fonction des rôles joués par les serveurs à l intérieur du cluster. La première forme, appelée cluster actif/passif, ne présente d intérêt que lorsque l objectif est l amélioration de la disponibilité d une application. La seconde forme, appelée cluster actif/actif, permet avant tout d augmenter de manière presque illimitée la capacité de traitement d une application. Si elle est mise en œuvre avec un large dimensionnement des plates-formes, elle est aussi à même d améliorer la disponibilité, mais ce n est pas sa principale finalité. Le tableau 12.1 présente une synthèse des principales caractéristiques des deux formes de clusters. Tableau 12.1 Comparatif des formes de clusters Type de cluster Impact sur la disponibilité Capacité de montée en charge Nombre de serveurs par cluster Surcoûts liés au matériel Complexité Actif/Passif Excellent Aucune % Moyenne Actif/Actif Bon (Sous réserve d un large dimensionnement du cluster) Excellent Illimité 0 à 100 % selon le niveau de disponibilité Élevée Il n est donc pas possible de conclure à une supériorité de l une ou l autre de ces formes de clustering. Tout dépend des attentes des utilisateurs. Ceux qui recherchent la disponibilité se tourneront vers des clusters actif/passif tandis que ceux qui souhaitent améliorer la scalabilité choisiront des clusters actif/actif.

213 12.3 La répartition de charge LA RÉPARTITION DE CHARGE La présentation des formes de clustering a révélé un nouveau besoin : celui de la répartition de la charge de travail (load-balancing) entre les différents serveurs qui composent le cluster. Bien entendu, cela ne concerne que les clusters de type actif/actif, puisque dans le modèle actif/passif un seul serveur fonctionne en même temps. En effet, le déploiement d une application sur plusieurs serveurs n est pas suffisant pour obtenir les résultats en matière de montée en charge et de disponibilité. Il est nécessaire de disposer d un mécanisme dont le rôle est de distribuer le travail aux serveurs. Deux approches sont possibles pour traiter la répartition de charge : La première, appelée «répartition de charge statique», repose sur une prérépartition des utilisateurs sur les serveurs au moment du déploiement. La seconde, appelée «répartition de charge dynamique», utilise un composant logiciel ou matériel dédié pour répartir dynamiquement les requêtes utilisateurs sur les serveurs lors de l exécution. Elles sont décrites en détail dans les deux sections suivantes Répartition de charge statique C est la méthode la plus simple, car elle ne nécessite aucun composant logiciel ou matériel. Elle consiste à répartir de manière statique les utilisateurs sur des serveurs différents (figure 12.5). Voici quelques exemples de répartition : Les clients français utilisent le serveur A. Les clients allemands utilisent le serveur B. Le service comptable utilise le serveur C. Etc. La répartition des utilisateurs sur les serveurs peut se faire selon plusieurs approches : par localisation géographique, par département ou encore par adresse IP. Il est important de comprendre que ce type de répartition entraîne généralement la création de plusieurs «points de connexion» à l application. Par exemple, pour une application web, chaque groupe d utilisateurs accédera à l application par une URL spécifique. Cette approche présente les caractéristiques suivantes : Les utilisateurs sont toujours reliés aux mêmes serveurs physiques. La répartition du travail se fait «à la louche», certains serveurs peuvent être saturés pendant que d autres sont très peu chargés. Il est quasiment impossible de traiter la disponibilité. Si un serveur disparaît, tous les utilisateurs qui y sont rattachés ne peuvent plus accéder à l application. La seule issue possible est alors de doubler tous les serveurs en actif/passif, mais le coût d une telle mesure est exorbitant.

214 196 Chapitre 12. Le clustering Figure 12.5 La répartition de charge statique Il n est pas nécessaire d avoir recours à un composant pour effectuer la répartition de charge. La solution n est généralement pas transparente du point de vue client en raison de l utilisation de paramètres de connexion spécifiques à chaque groupe. Ce type de mécanisme de répartition de charge est assez répandu, en particulier pour les applications web. En revanche, il est plus rarement 1 utilisé pour les bases de données en raison des problèmes de synchronisation qu il entraîne Répartition de charge dynamique Cette méthode repose sur l utilisation d un composant appelé répartiteur de charge ou load-balancer, spécialement chargé de répartir les requêtes entre les différents serveurs du cluster. Par nature, ce type de répartition de charge est plus complexe à mettre en place que la répartition statique car il doit s accompagner d une réflexion sur le mode de fonctionnement du cluster. Parmi les questions soulevées, on trouve par exemple : S agit-il d une affectation dynamique mais définitive des utilisateurs à un serveur physique? ou bien est-ce que toutes les requêtes sont envoyées indifféremment à n importe quel serveur du cluster? Ce point est crucial car il pose la question de la gestion des données de la session utilisateur. En effet, si celle ci est stockée sur le serveur lui même, le répartiteur de 1. Rarement ne signifie pas «jamais». DB2 utilise cette forme de répartition de la charge statique.

215 12.3 La répartition de charge 197 charge devra en tenir compte pour aiguiller chaque requête exclusivement vers le serveur capable de la traiter, c est à dire celui qui détient la session. À l inverse, si la session n est pas stockée directement sur le serveur, il faut trouver une solution pour transférer les données de session vers le serveur qui en a besoin. Ce point est traité en détail au chapitre 14. Quelle approche utiliser pour répartir la charge? Doit-on tenir compte de la capacité de traitement de chaque serveur et/ou du niveau de consommation de ses ressources mémoire et CPU? Ce point est particulièrement sensible lorsque les serveurs présentent des différences matérielles. Comment détecter les serveurs indisponibles? Est-il possible de réintégrer un serveur indisponible dans la liste du load-balancer après que le serveur soit redevenu disponible? La figure 12.6 montre le phénomène de lissage de la charge sur l ensemble des serveurs du cluster. Figure 12.6 La répartition de charge dynamique Cette approche présente les caractéristiques suivantes : Les utilisateurs ne sont pas toujours reliés aux mêmes serveurs physiques. La répartition de la charge se fait de manière précise. Le niveau de consommation des ressources mémoire et CPU est à peu près homogène. L indisponibilité d un serveur n entraîne pas l indisponibilité de l application, à condition qu il reste suffisamment de puissance de traitement dans le cluster. La répartition de charge se fait de manière transparente pour les utilisateurs. Un paramétrage spécifique des clients n est pas nécessaire.

216 198 Chapitre 12. Le clustering Le load-balancer détient la liste des serveurs ainsi que leur état actif ou inactif. Il entretient une double relation avec les serveurs car en plus de leur envoyer des requêtes à traiter, il doit très fréquemment vérifier leur état pour éviter d envoyer des requêtes vers des serveurs devenus inactifs. Ce mécanisme de répartition de charge peut être mis en œuvre : par un composant logiciel externe au cluster, il s agit généralement d un service additionnel offert par le système d exploitation. Windows, Linux et les principaux Unix offrent des extensions de ce type. On emploie souvent dans ce cas le terme NLB pour Network Load Balancing. C est la solution retenue par Microsoft pour la plate-forme.net ; par un composant logiciel intégré au cluster et fourni par le même éditeur que celui de la solution utilisée. C est généralement le cas pour les serveurs d applications J2EE tels qu IBM WebSphere ou BEA WebLogic ; par un composant matériel dédié qui se présente sous la forme d une appliance à ajouter dans les racks. Ces produits sont appelés switch applicatifs par les fabricants. Ils fonctionnent aux niveaux réseau et session et comprennent les protocoles tels que http. Ils sont donc compatibles avec la plupart des platesformes du marché (J2EE,.NET, PHP...). Dans tous les cas, et en particulier lorsqu un haut niveau de disponibilité est recherché, il est important d intégrer le load-balancer dans les calculs de disponibilité. En effet, si celui-ci ne fonctionne plus, l ensemble des serveurs du cluster cessent immédiatement de recevoir des requêtes et l application devient indisponible. Pour supprimer ce SPOF (Single Point Of Failure), il est possible de redonder le load-balancer lui-même. Cette redondance peut-être de type actif/passif ou actif/actif selon les situations Algorithmes de répartition Les load-balancer proposent différents algorithmes de répartition de charge. Le plus connu et le plus utilisé est certainement le Round Robin 1. Son principe de fonctionnement répartition est relativement simple puisque le load-balancer redirige les requêtes selon une fonction modulo. La figure 12.7 illustre ce mode de fonctionnement. Bien que possédant l avantage de la simplicité, ce type d algorithme présente un inconvénient majeur : si les requêtes 1, 3 et 6 sont plus consommatrices en ressource que les autres, le serveur 1 risque fort de présenter des problèmes de temps de réponse alors que les deux autres nœuds seront potentiels en sous-charge. Une variante du Round Robin est le Weighted Round Robin 2. Ici la répartition est pondérée en fonction du serveur. Dans la figure 12.8, le premier serveur s est vu attribuer un poids de 1 alors que le second un poids de 3. Ainsi 25 % des requêtes sont dirigées vers le premier serveur alors que 75 % le sont vers le suivant. 1. Round Robin : Tourniquet en français 2. Weighted Round Robin : Tourniquet Pondéré en français.

217 12.3 La répartition de charge 199 Figure 12.7 Round Robin sur trois serveurs Figure 12.8 Weighted Round Robin sur 2 serveurs Ce type de répartition est particulièrement bien adapté dans les cas suivants : Les serveurs n ont pas tous la même puissance. Un des serveurs est utilisé selon plusieurs fonctions. Les algorithmes Load-based 1 résolvent la problématique de répartition uniforme de la charge). Un algorithme Load-based envoie les demandes aux serveurs en fonction des indicateurs de charge que lui remontent les serveurs. Pour déterminer l ordre d attribution, ils se basent généralement sur les remontées SMTP des serveurs qu ils ont sous leur responsabilité. Ils sont donc quelque peu intrusifs sur ces derniers Synthèse et conclusion sur la répartition de charge La répartition de charge peut s effectuer par deux procédés. L un, appelé répartition statique, se base sur une prérépartition à l avance des utilisateurs sur les serveurs, tandis que l autre, appelé répartition dynamique, répartit les utilisateurs à chaud lorsque 1. Load-based : basée sur la charge.

218 200 Chapitre 12. Le clustering l application est utilisée. Le tableau 12.2 récapitule les propriétés respectives de ces procédés. Tableau 12.2 Comparatif des formes de répartition de charge Type de répartition Impact sur la disponibilité Impact sur la montée en charge Complexité Coût Statique Dynamique Mauvais (si pas de redondance) Excellent (si redondance) Bon (si réserve de puissance) Bon Faible Faible (si pas de redondance) Très élevé (si redondance) Excellent Forte Moyen à très élevé selon la réserve de puissance et l utilisation ou non d une solution matérielle. En conclusion, on constate que le choix de la forme de répartition dépend généralement directement du budget. En effet, la répartition statique est une solution d entrée de gamme qui ne peut rivaliser avec la répartition dynamique, excepté sur le terrain des coûts LA TOLÉRANCE AUX PANNES La dernière caractéristique d une solution de clustering concerne son comportement lorsqu un incident entraîne l arrêt de l un des serveurs. Il s agit d une forme avancée de haute disponibilité. Ici, il est nécessaire de faire la distinction entre, d une part la disponibilité d un composant (le code), et celle du contexte sur lequel porte le traitement (les données). En matière de tolérance de pannes, il faut distinguer : Le fail-over désigne la capacité de transférer un processus d un nœud à un autre sur le cluster en cas de défaillance. Ce transfert n est pas instantané car il faut d abord s assurer de l indisponibilité effective du composant concerné (temps de détection). Le fail-over s applique à toutes les formes de cluster (actif/passif, actif/actif) et concerne à la fois les données et les traitements. L absence de cette propriété implique que c est aux applications clientes qu il incombe de détecter la défaillance du serveur et de s adresser à une autre machine du cluster. Le fail-back désigne la capacité de réintégrer dans le cluster un nœud qui avait été retiré suite à une défaillance (fail-over). L absence de fail-back implique la nécessité d arrêter/redémarrer la totalité du cluster pour pouvoir réintégrer le nœud défaillant. Il n est pas toujours simple d offrir ces mécanismes de protection, en particulier lorsqu il est nécessaire d assurer les sauvegardes et la synchronisation de données au

219 12.5 Les différentes formes de scalabilité 201 travers des nœuds du cluster. La gestion du fail-over des sessions HTTP dans les serveurs d application (cf. chapitre 14) illustre parfaitement cette situation LES DIFFÉRENTES FORMES DE SCALABILITÉ La scalabilité d un système se définit comme sa capacité de continuer de fournir convenablement ses services lorsque la charge de traitement augmente de manière importante. Cette charge peut être, suivant la nature de l application, soit un nombre simultané de connexions, soit un volume de messages à traiter. On entend aussi par scalabilité, la capacité d une application de tirer partie de ressources supplémentaires mises à sa disposition. Il existe trois approches différentes pour mettre en œuvre la scalabilité : La scalabilité verticale. La scalabilité horizontale. La scalabilité diagonale. Chacune de ces approches présente des avantages et des inconvénients spécifiques et aucune d entre elles ne s est clairement imposée. En fait, le choix retenu dépendra fortement, d une part du cas d utilisation et, d autre part, du budget disponible. Il n est pas rare de rencontrer plusieurs formes de scalabilité (au maximum deux en général) sur une même plate-forme La scalabilité verticale La scalabilité verticale est la capacité d étendre la puissance de traitement d un composant matériel ou logiciel en lui allouant davantage de ressources physiques telles que des processeurs (CPU) ou de la mémoire sur une même machine physique (figure 12.9). Cette forme de scalabilité est la plus ancienne de toutes, elle est mise en œuvre depuis plus de 30 ans dans les systèmes centraux de type mainframe. Bien sûr, elle est également utilisée sur des plates-formes plus récentes telles qu Unix, Linux ou Windows Server. Les architectures utilisant la scalabilité verticale sont appelées SMP (Symmetric Multi-Processing) et se caractérisent par l utilisation simultanée de plusieurs processeurs (CPU) par une même application. Celle-ci fonctionne au sein d une instance unique d un système d exploitation. On utilise généralement l appellation SMP pour désigner les plates-formes comprenant huit CPU et plus.

220 202 Chapitre 12. Le clustering Figure 12.9 La scalabilité verticale Ce type de solution présente des avantages très intéressants, en particulier : Les entrées-sorties (IO) entre les différents fils de traitement (threads) se font à très grande vitesse et avec une faible latence, puisque les échanges se font sur le bus local et ne transitent par aucun réseau extérieur. L impact sur la conception et les développements est faible voire nul car la mise en œuvre de ce type de solution n entraîne pas ou peu de contraintes techniques. L administration est facilitée par la présence d un gros serveur unique, ce qui constitue une économie significative de travail pour les équipes chargées du déploiement et du monitoring. Mais, revers de la médaille, du point de vue de la disponibilité, ce type d architecture ne présente qu un faible intérêt puisqu en l absence de redondance, le serveur constitue toujours un SPOF (Single Point Of Failure). Si le serveur s arrête de fonctionner pour une raison quelconque, avarie matérielle, plantage logiciel ou opération de maintenance, l application devient immédiatement indisponible. À noter toutefois que, sur ce type de configuration, certains composants matériels sont redondés, ce qui réduit sensiblement les probabilités de défaillance. Par ailleurs, les solutions SMP présentent un double inconvénient : Il existe une limite au nombre de processeurs qui peuvent être gérés par une seule machine (32 ou 64 processeurs suivant les plates-formes, parfois plus). Les coûts de ces plates-formes augmentent de façon exponentielle avec le nombre de processeurs.

221 12.5 Les différentes formes de scalabilité 203 Les plates-formes SMP ne sont pas des clusters puisqu elles sont basées sur l utilisation d un seul composant physique. Elles entrent néanmoins très souvent en concurrence avec les solutions de clustering classiques et ont donc toutes leur place dans ce chapitre. Il est d ailleurs courant d utiliser le terme de «cluster vertical» pour désigner ce type de solutions La scalabilité horizontale La scalabilité horizontale est la capacité d étendre la puissance de traitement d une application en multipliant le nombre de machines physiques qui lui sont attribuées (figure 12.10). Figure La scalabilité horizontale Les architectures utilisant la scalabilité horizontale sont appelées MMP (Massively Parallel Processing) et se caractérisent par l utilisation simultanée de plusieurs machines physiques par une même application. Celle-ci fonctionne donc au travers de plusieurs instances d un système d exploitation. Il n est pas rare de rencontrer des architectures MMP utilisant plusieurs centaines voire plusieurs milliers de serveurs. Dans ce type de solutions, les serveurs sont aussi appelés nœuds ou node en anglais. Les architectures mettant en œuvre la scalabilité horizontale ont des propriétés très intéressantes en matière de disponibilité. En effet, l utilisation de plusieurs serveurs physiques pour une même application est assimilable à un montage de composants en parallèle. La formule applicable pour les calculs de disponibilité est donc (cf. première partie) : Ce qui donne, par exemple, pour un cluster constitué de deux serveurs ayant une disponibilité de 98 % : A s = 1 (1 0,98) 2 A s = 1 0,0004 A s = 99,96 %

222 204 Chapitre 12. Le clustering On voit donc que la mise en œuvre d une solution de scalabilité horizontale s accompagne d une augmentation très sensible de la disponibilité du système. Évidemment, il s agit là d un gain théorique, mais la principale propriété de ce type d architecture est d abord la suppression des SPOF (Single Point Of Failure). En effet, ces systèmes sont capables de survivre à l arrêt (outage) de l un des composants qui les constituent. Ces solutions présentent aussi un intérêt important sur le plan des coûts car il est toujours nettement plus intéressant d acheter n serveurs avec un processeur (CPU) plutôt que d acquérir un serveur unique avec n processeurs. Ce constat est d autant plus vrai que le nombre n est grand. Bien entendu, cette remarque ne vaut que pour les coûts d achat et ne tient pas compte des coûts d administration. De plus, les architectures MMP sont les seules à pouvoir atteindre un très grand nombre de processeurs. En revanche, elles ont aussi trois inconvénients notables. On retiendra en particulier les suivants : Il est nécessaire de concevoir et de développer les applications avec des contraintes particulières qui accroissent la complexité de l architecture, pour pouvoir réellement tirer partie des avantages du MMP. Les échanges de données entre les différents fils de traitement (threads) se font par l intermédiaire du réseau local (LAN). Or, ce type de réseau présente une latence plus élevée et un débit moindre que celui d un bus d échange interne tel que l on en trouve sur les architectures SMP. Les opérations de déploiement et d exploitation sont plus complexes et plus fastidieuses car il faut à chaque fois répéter les opérations sur chaque serveur (nœud) du cluster. Les architectures MMP sont aussi appelées «clusters horizontaux». Elles sont très répandues car généralement plus abordables que les architectures SMP. Tous les grands acteurs de l Internet (Google, Yahoo!...) utilisent des solutions de ce type qui sont seules à même de répondre à la formidable montée en charge que ces sites subissent. À noter toutefois que le terme cluster n est employé que lorsque l ensemble des serveurs sont dédiés à une application précise et que leur nombre reste stable. On utilise plutôt le terme grid lorsque le nombre de nœuds est très important et que ceux ci peuvent être utilisés pour plusieurs usages (generic multi purpose grid) La scalabilité diagonale La scalabilité diagonale est la capacité d étendre la puissance de traitement d une application en utilisant conjointement la scalabilité verticale (augmentation du nombre de CPU) et la scalabilité horizontale (augmentation du nombre de serveurs) (figure 12.11).

223 12.5 Les différentes formes de scalabilité 205 Figure La scalabilité diagonale Les architectures utilisant la scalabilité diagonale se caractérisent donc par l utilisation de plusieurs instances de systèmes d exploitation qui utilisent chacune plusieurs CPU pour effectuer les traitements demandés. Ce type de solutions présente un double intérêt. D une part, elles permettent de bénéficier des avantages des architectures SMP et, d autre part, elles comblent la principale lacune de ces dernières en matière de disponibilité par la redondance des serveurs. Bien évidemment, les inconvénients se cumulent aussi puisque ces configurations sont plus complexes à administrer que les solutions SMP (il y a plusieurs serveurs) et utilisent le réseau pour les échanges de données entre les nœuds, ce qui ralentit les communications. De plus, les serveurs présentent un coût unitaire (par CPU) sensiblement plus élevé que dans les solutions MMP, mais tout de même moindre que dans celui des solutions SMP. Il s agit donc d une solution hybride, une sorte de compromis qui permet de cumuler les avantages des deux formes de scalabilité tout en limitant les inconvénients Conclusions sur les types de scalabilité On a vu qu il existe trois approches possibles pour traiter les besoins de montée en charge. La première, appelée scalabilité verticale, consiste à augmenter la capacité de traitement en utilisant une configuration matérielle très puissante (architecture SMP) possédant un nombre élevé de processeurs. La seconde, appelée scalabilité horizontale, permet la montée en charge en augmentant le nombre de serveurs dédiés à une application (architecture MMP). Enfin, une approche appelée scalabilité diagonale combine à la fois la scalabilité verticale et la scalabilité horizontale.

224 206 Chapitre 12. Le clustering Ces approches sont sensiblement différentes les unes des autres et présentent des avantages et inconvénients qui leur sont propres. Le tableau 12.3 fait une synthèse des relations entre les types de scalabilité et les CPU. Type de scalabilité Verticale Horizontale Tableau 12.3 Les types de scalabilité et les CPU et IO IO (Entrées/Sorties) Débit élevé Latence faible Débit moyen Latence élevée Nombre de CPU par serveur Nombre maximum de CPU Coût par CPU Élevé 1 à 4 Illimité (par milliers) Diagonale Variable 8 à 24 Illimité (par centaines) Faible Moyen Le tableau 12.4 fait une synthèse de leurs principales propriétés. Type de scalabilité Tableau 12.4 Comparatif des formes de scalabilité Améliore la disponibilité Impact sur la conception et le développement Déploiement et administration Verticale Non Faible Simple Horizontale Oui Fort Complexe (plus de complexité) Diagonale Oui Fort (plus de complexité) Intermédiaire L utilisation que l on fera des différents modes de scalabilité dépendra donc très fortement des qualités attendues pour l application. D une manière générale, on peut distinguer trois types d usages : Les applications grosses consommatrices d entrées-sorties. Bases de données relationnelles (SGBD). ERP (Enterprise Ressource Planning). Logiciels de CRM (Customer Relation Management). Entrepôts de données (Data Warehouse). Les applications traitant un nombre élevé de requêtes mais ne nécessitant pas de traitements complexes. Serveurs web (i.e. Apache HTTP Server). Annuaires (LDAP, Active Directory). Proxies. Firewall. Les applications soumises à une forte charge utilisateur et exécutant des traitements complexes. Serveurs d application (i.e. Apache Tomcat). Portails et solutions de gestion de contenu.

225 12.5 Les différentes formes de scalabilité 207 La figure présente les usages de prédilection des différentes formes de scalabilité pour ces trois familles d applications. Figure Les domaines de prédilection des trois formes de scalabilité Même si les frontières d utilisation entre les différentes formes de scalabilité ne sont pas toujours bien délimitées, on peut néanmoins dégager un certain nombre de tendances : Les SGBD et les applications fortement centrées sur la donnée (ERP, CRM) tirent très bien partie de la scalabilité verticale. En effet, dans ce type d applications, la gestion des accès concurrents induits par les mécanismes transactionnels est rendue performante par la faible latence et les hauts débits des entrées-sorties. Combinés à l utilisation de réseaux de stockage (SAN), les clusters verticaux sont à même d offrir un niveau de temps de réponse et une capacité de montée en charge excellents. Il leur manque en revanche la haute disponibilité. Celle-ci peut être atteinte par le passage à la scalabilité diagonale, moyennant une légère dégradation des performances liée aux échanges réseaux. Les clusters de base de données sont décrits au chapitre 13. Les applications n-tiers critiques (généralement web) utilisent aussi la scalabilité diagonale. Ici, la démarche consiste à concilier des besoins de montée en charge (avantage à la scalabilité verticale), avec des contraintes de disponibilité (avantage à la scalabilité horizontale) et de coûts directs (serveurs et licences)

226 208 Chapitre 12. Le clustering et indirects (administration). L étude détaillée des mécanismes de clustering des serveurs J2EE 1 est décrite au chapitre 14. Enfin, les applications web légères profitent au maximum de la scalabilité horizontale. En effet, dans ce type d applications, les accès concurrents sont peu nombreux, voire inexistants. Les nœuds du cluster n ont donc pas besoin d échanger beaucoup d informations ; l utilisation du réseau pour coordonner les serveurs n entraîne donc pas de pénalités particulières. Il n y a quasiment pas de limites au nombre de serveurs pouvant appartenir à une architecture de ce type. L étude des différents types de scalabilité met clairement en évidence le rôle de plus en plus prépondérant de la scalabilité diagonale dans les nouvelles infrastructures logicielles. En résumé Ce chapitre a présenté les concepts mis en œuvre dans les solutions de clustering, que ce soit dans le domaine des bases de données ou dans celui des serveurs d application. L appellation cluster regroupe en fait une famille de solutions techniques qui permettent d augmenter la disponibilité et/ou la capacité de montée en charge d une application. Ces solutions techniques sont basées sur quatre critères : 1. Le choix d un modèle de scalabilité : verticale, horizontale ou diagonale. 2. Le choix du rôle joué par les serveurs : actif/passif ou actif/actif. 3. La sélection d un modèle de répartition de charge : statique ou dynamique. 4. Des niveaux de protection en cas de défaillance. Les solutions développées par les éditeurs de logiciels sont construites autour de combinaisons particulières de ces quatre critères. 1. J2EE : Java 2 Enterprise Edition.

227 13 Les bases de données Objectif Les bases de données relationnelles sont depuis longtemps au cœur des systèmes d information. On a annoncé leur disparition à plusieurs reprises, notamment au profit de bases objets, mais il n en a rien été et aujourd hui elles sont plus que jamais incontournables. Par ailleurs, à l heure de la généralisation des serveurs d applications, l expérience montre qu une proportion importante des problèmes de performance reste due à une mauvaise utilisation des bases de données. Ce chapitre décrit quatre leviers efficaces pour améliorer les performances des bases de données. L administration des bases de données est un métier complexe qui est l affaire de spécialistes, les DBA (Database Administrator). Ceux-ci, en plus de la maîtrise des concepts des bases relationnelles, ont généralement une connaissance approfondie d un ou deux des SGBD du marché (Oracle, DB2, SQL Server, Sybase ou MySQL). Les éléments de solution présentés ici n ont pas pour but de transformer le lecteur en DBA chevronné. L expérience montre que le dialogue entre architectes «nouvelles technologies» et DBA n est pas facile car leurs préoccupations sont différentes. L ambition de ce chapitre est plutôt de donner aux architectes et aux développeurs des clefs pour mieux appréhender la question des performances des bases de données et, par là même, mieux communiquer avec les DBA. Les bases de données se distinguent des autres types de logiciels sur deux points. D une part, elles manipulent de très gros volume de données et, d autre part, elles font un usage intensif des entrées-sorties avec les systèmes disques. Bien que les bases

228 210 Chapitre 13. Les bases de données récentes bénéficient de l expérience accumulée depuis une vingtaine d années dans l optimisation des SGBD, la performance des accès aux données reste encore pour une bonne part entre les mains des architectes applicatifs. On retiendra en particulier quatre leviers qui ont un impact majeur sur le niveau de performance des bases de données : 1. La qualité des requêtes. 2. L utilisation des procédures stockées. 3. Le choix du bon niveau d isolation transactionnelle. 4. L optimisation du stockage et des entrées-sorties LEVIER 1 : LA QUALITÉ DES REQUÊTES Chaque requête SQL envoyée par l application au SGBD n est pas exécutée directement par le moteur. En effet, celui-ci commence par l analyser et générer un plan d exécution détaillé qui décrit les opérations à effectuer pour l exécuter. Ce plan comprend des éléments comme les tables concernées et l ordre et la manière dont elles devront être parcourues. Le vocabulaire des plans d exécution est propre à chaque base de données, mais on retrouve invariablement les mêmes concepts. Pour juger de la qualité d une requête, il est nécessaire d étudier en détail son plan d exécution. D une manière générale, plus la quantité d informations à parcourir sera faible, meilleurs seront les temps d exécution. Par exemple, on cherchera à éviter systématiquement les plans qui entraînent le parcours complet des données d une table (ce type de parcours est souvent appelé FULL-SCAN). De tels plans d exécution génèrent de mauvais niveaux de performance, surtout lorsque les tables possèdent un grand nombre d enregistrements. Dans ce cas-là, on ajoutera certainement un index pour limiter les temps de parcours. Mais il ne faut pas non plus ajouter des index dans tous les sens, car ceux-ci doivent être mis à jour lors de chaque opération d écriture! L optimisation des requêtes n est pas une tâche à laisser à la seule appréciation des développeurs. Pour l effectuer dans de bonnes conditions, il est préférable d y associer le DBA, car celui-ci maîtrise beaucoup mieux les subtilités du paramétrage des SGBD. Il faut savoir, en effet, que certaines bases de données peuvent utiliser des informations statistiques pour modifier le plan d exécution des requêtes, par exemple, pour tenir compte de la volumétrie d une table lors d une opération de jointure LEVIER 2 : L UTILISATION DES PROCÉDURES STOCKÉES Les procédures stockées sont des petits programmes qui s exécutent directement à l intérieur du SGBD. Ils sont généralement écrits à l aide de langages propriétaires tels que PL-SQL ou Transact-SQL. Depuis quelques années, les éditeurs ajoutent

229 13.3 Levier 3 : le choix du bon niveau d isolation transactionnelle 211 également le support de langages objets tels que Java ou C#. Alors pourquoi faire fonctionner des morceaux de code directement dans la base de données plutôt que dans le serveur d application? N est-ce pas violer le principe des architectures à cinq couches qui impose une stricte répartition des rôles entre les tiers? Au premier abord, les procédures stockées peuvent être perçues comme des antiquités héritées de l époque du client serveur qui seraient tombées en désuétude. En réalité, il n en est rien. Les procédures stockées continuent à jouer un rôle de premier plan pour une seule et unique raison : les performances. La manipulation des données directement sur le serveur permet d éviter des transferts de données sur le réseau et ainsi de gagner un temps précieux pour les applications. Il ne s agit évidemment pas de développer toute la couche métier dans le SGBD, mais plutôt d optimiser certains traitements lourds qui, s ils s effectuaient sur le serveur d application, nécessiteraient le transfert de quantités importantes de données. Les procédures stockées sont parfois un remède à l anti-pattern «mitrailleuse à requêtes» (cf. chapitre 5) LEVIER 3 : LE CHOIX DU BON NIVEAU D ISOLATION TRANSACTIONNELLE Le support des transactions est une propriété fondamentale des bases de données et l un des points névralgiques pour la gestion des performances. Une transaction est une séquence d instructions (requêtes) qui est envoyée à la base de données pour lire, insérer, modifier ou effacer des données. À l issue de cette séquence, et en fonction du contexte, le programme envoie ensuite à la base un ordre de finalisation. Celui-ci peut-être commit, auquel cas les modifications sont propagées définitivement dans les tables, ou bien rollback, et l ensemble des modifications sur les tables sont annulées. Les transactions permettent de garantir l intégrité des données stockées dans la base. Elles présentent quatre caractéristiques remarquables, connues sous le terme ACID : Atomicité La séquence d opérations qui compose la transaction est insécable, toutes les opérations sont effectuées ou aucune ne l est. Cohérence À l issue de la transaction, les contraintes d intégrité de la base de données sont respectées. Si ce n est pas le cas, la transaction échoue et les modifications sont annulées. Isolation Les modifications apportées durant une transaction ne doivent pas avoir d impact sur les autres transactions tant que la transaction n a pas été validée par un commit. Durabilité À l issue d un commit, la base de données doit avoir physiquement terminé les modifications des tables sur le disque dur. Sur ces quatre propriétés, l une d entre elles peut constituer un sérieux frein à la performance, il s agit de l isolation. En effet, pour garantir que les opérations réalisées simultanément par plusieurs transactions ne violent pas le principe d isolation, les SGBD utilisent une technique appelée verrouillage. Cette dernière repose sur

230 212 Chapitre 13. Les bases de données l utilisation de verrous pour empêcher une transaction de lire ou de modifier des données qui sont déjà impliquées dans une transaction concurrente. Dans ce cas, la transaction qui subit le verrou est mise en attente jusqu à ce que la transaction générée en dernier soit terminée. Les bases de données mettent à la disposition des architectes des options qui permettent d influencer le comportement du SGBD en matière de verrouillage. Ces options ont été normalisées par l ANSI et sont plus ou moins supportées par la plupart des bases de données. L approche retenue par l ANSI repose sur trois critères d isolation plus ou moins permissifs La lecture sale Aussi appelée dirty read, la lecture sale supprime l isolation entre les transactions. Sa mise en œuvre peut corrompre l intégrité des données. La figure 13.1 illustre le concept de lecture sale. Deux transactions T1 et T2 tournent simultanément. La première démarre une mise à jour des données (étape 1). La seconde les lit après que T1 les ait modifiées (étape 2). Pour une raison quelconque T1 se termine par une opération de rollback (étapes 3 et 4). Les données modifiées par T1 reprennent donc leurs anciennes valeurs. La transaction T2 continue son déroulement en utilisant des valeurs qui ne sont plus valables. 3 1 Mise à jour de la table T1 Exception 2 Lecture des enregistrements (select * from X wherey = Z) T2 4 Rollback 5 Lecture sale! La donnée n est plus valide Base de données Figure 13.1 La lecture sale ou dirty read Sans surprise, l acceptation des lectures sales permet de très bonnes performances, puisque les opérations de verrouillage sont inexistantes. Les transactions ne risquent donc pas de se gêner les unes les autres La lecture non répétable La lecture non répétable ou non-repeatable read est un phénomène qui apparaît lorsqu une même transaction lit à plusieurs reprises les mêmes données et que celles-ci ont été modifiées entre la première et la seconde lecture par une autre transaction.