{"id":175,"date":"2012-04-22T21:15:44","date_gmt":"2012-04-22T20:15:44","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=175"},"modified":"2013-09-24T14:59:19","modified_gmt":"2013-09-24T13:59:19","slug":"elasticite-des-applications-22","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/elasticite-des-applications-22\/","title":{"rendered":"Elasticit\u00e9 des applications (2\/2)"},"content":{"rendered":"<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-1543\" title=\"QualElastic3\" alt=\"\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/04\/QualElastic31.jpg\" width=\"280\" height=\"363\" \/><\/a>Dans notre dernier <a title=\"Elasticit\u00e9 des applications\" href=\"http:\/\/qualilogy.com\/fr\/elasticite-des-applications-12\" target=\"_blank\">post<\/a>, nous avons expliqu\u00e9 la notion d\u2019\u00e9lasticit\u00e9, en tant que capacit\u00e9 \u00e0 d\u00e9placer des ressources au sein d\u2019une infrastructure virtuelle afin de r\u00e9pondre avec la meilleure r\u00e9activit\u00e9 possible aux demandes m\u00e9tier et aux pics d\u2019activit\u00e9s, ces derniers pas toujours pr\u00e9visibles.<\/p>\n<p>Mais il ne s\u2019agit pas seulement de pouvoir \u2018gonfler\u2019 l\u2019infrastructure en ajoutant les ressources qui s\u2019av\u00e8rent n\u00e9cessaires, sinon \u2013 et surtout \u2013 de pouvoir \u2018d\u00e9gonfler\u2019 celle-ci en r\u00e9affectant ces ressources par ailleurs. A l\u2019image d\u2019un ballon, plus l\u2019infrastructure est \u00e9lastique, plus elle est facile et rapide \u00e0 gonfler et d\u00e9gonfler.<\/p>\n<p>Encore faut-il que les applications veulent bien s\u2019y pr\u00eater.<\/p>\n<p><!--more--><\/p>\n<p>&nbsp;<\/p>\n<p>L\u2019\u00e9lasticit\u00e9 d\u2019une application suppose :<\/p>\n<ul>\n<li>La scalabilit\u00e9 : maintenir la performance des applications lorsque augmente le nombre d\u2019utilisateurs \u2013 et g\u00e9n\u00e9ralement par cons\u00e9quence le volume de donn\u00e9es<\/li>\n<li>La capacit\u00e9 \u00e0 lib\u00e9rer les ressources lorsque la charge d\u00e9cro\u00eet.<\/li>\n<\/ul>\n<p>On distingue deux types de scalabilit\u00e9 :<\/p>\n<ul>\n<li>La scalabilit\u00e9 horizontale consiste \u00e0 distribuer une application sur diff\u00e9rentes machines. Par exemple, vous ajoutez des instances suppl\u00e9mentaires de votre serveur d\u2019application et utilisez un load-balanceur pour r\u00e9partir la charge.<\/li>\n<li>La scalabilit\u00e9 verticale consiste \u00e0 ajouter de la capacit\u00e9 (m\u00e9moire, CPU, disque dur) sur la machine qui h\u00e9berge votre application.<\/li>\n<\/ul>\n<h3><strong>Scabilit\u00e9 horizontale<\/strong><\/h3>\n<p>La scalabilit\u00e9 horizontale n\u2019est pas tr\u00e8s \u00e9lastique, puisqu\u2019elle suppose d\u2019ajouter manuellement des instances de briques d\u2019architecture qui resteront largement sous-utilis\u00e9es en l\u2019absence de pics de charge. Autrement dit, vous gonflez le ballon mais ne savez pas le d\u00e9gonfler. C\u2019est pourtant le cas que l\u2019on rencontrera le plus fr\u00e9quemment. Ce n\u2019est pas vraiment dynamique.<\/p>\n<p>Et maintenir un infrastructure bas\u00e9e sur la redondance des diff\u00e9rentes briques de l\u2019architecture applicative aboutit au cas pr\u00e9c\u00e9dent : une infrastructure surdimensionn\u00e9e afin de faire face aux pics d\u2019activit\u00e9, mais dont on n\u2019utilise la capacit\u00e9 qu\u2019\u00e0 10 ou 20%. Autant rester sur une instrastructure phyique.<\/p>\n<h3><strong>Scabilit\u00e9 verticale<\/strong><\/h3>\n<p>La scalabilit\u00e9 verticale est elle beaucoup plus \u00e9lastique. Vous installez votre application sur une machine virtuelle dont elle prendra 50% des ressources en r\u00e9gime normal, au sein d\u2019un serveur h\u00e9bergeant d\u2019autres machines virtuelles avec des applications moins sujettes \u00e0 variation de charge. Si survient un pic d\u2019activit\u00e9 impr\u00e9vu et m\u00eame violent, la machine virtuelle pourra emprunter des ressources aux machines voisines sur le m\u00eame serveur. La possibilit\u00e9 d\u2019emprunter ainsi de la m\u00e9moire est d\u2019ailleurs connue sous le nom de \u2018ballooning\u2019 (pour VMWare). Une fois le pic de charge pass\u00e9, la machine virtuelle lib\u00e8rera les ressources emprunt\u00e9es pour les restituer \u00e0 ses voisines. Tout ceci dynamiquement, avec le moins de saturation et de contention possible.<\/p>\n<p>Mais la scalabilit\u00e9 verticle atteint rapidement ses limites: vous ne pouvez pas augmenter ind\u00e9finiment la puissance CPU ou la performance I\/O d\u2019un disque dur. Vous pouvez gonfler et d\u00e9gonfler le ballon, mais dans une certaine limite.<\/p>\n<h3><strong>Elasticit\u00e9 du Cloud<\/strong><\/h3>\n<p>Toute application gagnera en \u00e9lasticit\u00e9 en allant dans le Cloud.<\/p>\n<p>Par exemple, certains traitements consommateurs de m\u00e9moire, comme la cr\u00e9ation d\u2019un objet, ne doivent pas \u00eatre effectu\u00e9s au sein d\u2019une boucle. Nombre de boucles servent \u00e0 r\u00e9aliser des traitements sur les donn\u00e9es d\u2019une table. Plus la table contient de donn\u00e9es, plus le nombre d\u2019it\u00e9rations de la boucle sera \u00e9lev\u00e9, plus la cr\u00e9ation d\u2019objets et la consommation de m\u00e9moire correspondante sera \u00e9lev\u00e9. Plus le nombre d\u2019utilisateurs sera important, plus le serveur d\u2019application effectuera ces traitements et aura besoin de m\u00e9moire.<\/p>\n<p>C\u2019est un exemple typique d\u2019une application avec une faible scalabilit\u00e9 que l\u2019on contournera en ajoutant \u2018\u00e9lastiquement\u2019 de la m\u00e9moire lors des pics d\u2019activit\u00e9.<\/p>\n<p>Autre exemple : vous load-balancez 2 serveurs d\u2019applications sur 2 machines virtuelles. Vous avez donc 2 copies du m\u00eame software mont\u00e9es en m\u00e9moire. Si l\u2019hyperviseur est capable de d\u00e9tecter ces ensembles de m\u00e9moire identiques, il peut mettre en place un m\u00e9canisme de partage m\u00e9moire de telle sorte qu\u2019un seul espace m\u00e9moire sera utilis\u00e9 et acc\u00e9d\u00e9 par les 2 machines virtuelles, de mani\u00e8re transparente. Vous \u00e9conomisez ainsi de la m\u00e9moire.<\/p>\n<h3><strong>Elasticit\u00e9 des applications<\/strong><\/h3>\n<p>Certaines techniques de programmation vont permettre de rendre une application plus ou moins \u00e9lastique. La premi\u00e8re et la plus souvent cit\u00e9e est de rendre l\u2019application la plus stateless possible. Qu\u2019est ce que cela veut dire ?<\/p>\n<p>Pour faire simple, une application stateful garde en m\u00e9moire les donn\u00e9es n\u00e9cessaires \u00e0 la session utilisateur et \u00e0 son contexte. La session est gard\u00e9e sur le m\u00eame serveur le temps que l\u2019utilisateur est connect\u00e9 : il n\u2019est pas possible de transf\u00e9rer cette session \u2013 les donn\u00e9es gard\u00e9es en m\u00e9moire \u2013 sur un autre serveur.<\/p>\n<p>Imaginons donc un site marchand avec une forte activit\u00e9 entre 9 heures et 17 heures, correspondant \u00e0 10 000 utilisateurs qui se r\u00e9partissent sur 10 serveurs. Si l\u2019application est stateful, toutes les donn\u00e9es sont stock\u00e9es en m\u00e9moire, y compris celles identifiant l\u2019utilisateur et la m\u00e9moire ne sera lib\u00e9r\u00e9e que lorsque celui-ci quitte le site en se d\u00e9connectant. Si 10% des utilisateurs oublient de se d\u00e9connecter, ou si l\u2019activit\u00e9 tombe \u00e0 1 000 utilisateurs hors de la p\u00e9riode de pointe, on gardera alors 1 000 sessions en m\u00e9moire\u2026 r\u00e9parties sur les 10 serveurs. Autrement dit, l\u2019application utilisera 10% des 10 serveurs l\u00e0 o\u00f9 1 seul serveur serait suffisant.<\/p>\n<p>Si maintenant l\u2019application est compl\u00e8tement stateless, la session n\u2019est pas gard\u00e9e en m\u00e9moire et donc n\u2019est pas attach\u00e9e \u00e0 un serveur. M\u00eame si 10% des sessions restent actives, il sera possible de lib\u00e9rer les serveurs au fur et \u00e0 mesure que d\u00e9cro\u00eet l\u2019activit\u00e9, pour ne garder qu\u2019un seul serveur occup\u00e9 \u00e0 100% (ou plut\u00f4t 2 serveurs occup\u00e9s \u00e0 50%).<\/p>\n<p>Il est difficile de programmer des applications compl\u00e8tement stateless, puisqu\u2019il faut bien stocker les donn\u00e9es quelque part, et si ce n\u2019est en m\u00e9moire, ce sera alors en base de donn\u00e9es, de mani\u00e8re au moins temporaire. Or un acc\u00e8s en base de donn\u00e9es est plus co\u00fbteux en performance qu\u2019un acc\u00e8s m\u00e9moire. On va donc s\u2019attacher \u00e0 concevoir l\u2019application en diff\u00e9rents modules ou diff\u00e9rentes sous-applications, certaines stateless, d\u2019autres stateful.<\/p>\n<p>Par exemple, l\u2019application qui g\u00e8re le panier de l\u2019utilisateur gagnera \u00e0 \u00eatre programm\u00e9 en mode \u2018stateful\u2019 avec plusieurs avantages :<\/p>\n<ul>\n<li>Ce sont les donn\u00e9es qui sont le plus acc\u00e9d\u00e9es et modifi\u00e9es durant la session, donc pour lesquelles la meilleure performance est requise : rien de pire que devoir attendre 10 secondes chaque fois que vous ajoutez un nouvel article dans votre panier, vous quitterez bien vite le site.<\/li>\n<li>Le panier a une dur\u00e9e de vie limit\u00e9e : g\u00e9n\u00e9ralement 30 \u00e0 60 minutes. Si un utilisateur reste connect\u00e9 sans mettre \u00e0 jour son panier, la session sera supprim\u00e9e de la m\u00e9moire \u00e0 l\u2019issue de ce d\u00e9lai, ce qui permettra de \u2018d\u00e9gonfler\u2019 la m\u00e9moire. Ceci r\u00e8gle le probl\u00e8me des 10% d\u2019utilisateurs qui oublient de se d\u00e9connecter.<\/li>\n<\/ul>\n<p>Les autres donn\u00e9es, telles que celles identifiant l\u2019utilisateur, peuvent \u00eatre g\u00e9r\u00e9 par un module stateless avec une table temporaire. Remarque importante : on voit \u00e9galement \u00e0 travers cet exemple qu\u2019il importe de penser en termes de dur\u00e9e de vie de chaque module et de programmer celle-ci \u00e0 travers un time-out.<\/p>\n<p>L\u2019asynchronisme est un autre m\u00e9canisme qui favorise l\u2019\u00e9lasticit\u00e9. Le traitement de votre panier sur un site marchand ne se termine pas avec la finalisation de votre achat et son paiement : il faut ensuite utiliser ses donn\u00e9es pour pr\u00e9parer votre colis, sa livraison, l\u2019enregistrer en comptabilit\u00e9, etc\u2026 Mais tous ces traitements ne sont pas urgents et peuvent \u00eatre r\u00e9alis\u00e9s lorsque les serveurs sont moins occup\u00e9s, durant la nuit par exemple. On va donc s\u2019attacher \u00e0 d\u00e9coupler le front-end \u2013 le site marchand \u2013 en envoyant un message asynchrone au back-end, les applications logistiques et comptables, avec les donn\u00e9es de votre commande pour que celles-ci soient process\u00e9es durant la p\u00e9riode de moindre activit\u00e9, sur les serveurs inactifs avec les ressources lib\u00e9r\u00e9es.<\/p>\n<p>L\u2019obstacle principal \u00e0 l\u2019\u00e9lasticit\u00e9 des applications r\u00e9side \u00e0 mon avis au niveau de la base de donn\u00e9es, certainement la plus difficile \u00e0 \u2018scaler\u2019 horizontalement. Les pistes actuelles en mati\u00e8re de gestion de la persistence semblent promouvoir l\u00e0 encore une certaine modularit\u00e9 qui permette de distribuer les informations sur diff\u00e9rentes bases de donn\u00e9es.<\/p>\n<p>Enfin, je pense que la r\u00e9alisation d\u2019applications \u00e9lastiques destin\u00e9es au Cloud va introduire de profonds changements m\u00e9thodologiques au niveau des cycles de vie de projet, car une meilleure int\u00e9gration entre les \u00e9quipes de d\u00e9veloppement, de QA et de production me para\u00eet in\u00e9luctable. Une sorte de fusion entre ITIL et Agile.<\/p>\n<p>La pr\u00e9occupation principale des \u00e9quipes de d\u00e9veloppement et de QA est de d\u00e9livrer en temps et en heure des applications de la meilleure qualit\u00e9 possible, pas la consommation de ressources. Sauf \u00e0 disposer d&rsquo;\u00e9quipes d\u00e9di\u00e9es \u00e0 la r\u00e9alisation d&rsquo;applications virtualis\u00e9es, la prise en compte de la consommation des ressources ou de l&rsquo;\u00e9lasticit\u00e9 n&rsquo;est pas \u00e0 l&rsquo;ordre du jour. Le seul point sur lequel ces deux mondes se rencontrent concerne la disponibilit\u00e9 de service et donc les accords de service (Service Level Agreement).<\/p>\n<p>Donc je suis convaincu que chaque d\u00e9veloppeur va devoir ajouter des comp\u00e9tences en mati\u00e8re de virtualisation \u00e0 son CV et que chaque soci\u00e9t\u00e9 de services va devoir se doter de ces m\u00eames comp\u00e9tences et m\u00e9thodologies afin de d\u00e9velopper des applications \u00e9lastiques.<\/p>\n<p>Le Cloud est en train de sortir des salles machines. Tenez vous pr\u00eats.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Dans notre dernier post, nous avons expliqu\u00e9 la notion d\u2019\u00e9lasticit\u00e9, en tant que capacit\u00e9 \u00e0 d\u00e9placer des ressources au sein d\u2019une infrastructure virtuelle afin de r\u00e9pondre avec la meilleure r\u00e9activit\u00e9 possible aux demandes m\u00e9tier et aux pics d\u2019activit\u00e9s, ces derniers pas toujours pr\u00e9visibles. Mais il ne s\u2019agit pas seulement de pouvoir \u2018gonfler\u2019 l\u2019infrastructure en ajoutant [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,2],"tags":[],"class_list":["post-175","post","type-post","status-publish","format-standard","hentry","category-cloud","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/175"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=175"}],"version-history":[{"count":3,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/175\/revisions"}],"predecessor-version":[{"id":1175,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/175\/revisions\/1175"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=175"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}