Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Patterns pour haute dispo et scalabilité d’une appli web – Partie I

Poster un commentaire

Les bases

La scalabilité et la disponibilité d’un site web sont des critères d’importance pour en assurer le succès. Je pense que tous les développeurs un minimum expérimentés connaissent un certain nombre de bonnes pratiques. La plupart du temps elles ont été acquises expérimentalement.

Je voudrai montrer à travers cette série d’article qu’il existe des moyens plus organisés de monter en compétence rapidement sur ce sujet. Des patterns existent, une littérature importante est à notre disposition. Je vais essayer de vous en donner un aperçu pratique.

 

Cet article est un article d’introduction à la série. je vais y développer:

  • Le vocabulaire
  • Le cadre de cette présentation, les bases techniques
  • Présentation du projet de démo

Scalabilité et haute dispo

Scalabilité et haute disponibilité sont deux choses différentes. Précisons donc le vocabulaire:

  • La scalabilité (scalability) d’une application est sa capacité à s’adapter à sa charge. On la définit par la mesure du nombre d’utilisateurs qu’elle peut servir de façon simultanée. On s’entend sur le terme ‘simultané’ bien entendu.Je ne connais pas de traduction très satisfaisante de ce terme.
  • La haute disponibilité (availability) représente quand à elle la capacité d’une application à résister à la perte d’un de ses composants.
    L’idée n’est pas forcément que le problème soit entièrement transparent pour l’utilisateur, mais que l’application reste raisonnablement disponible. Peut être un peu plus lente, peut être en mode dégradé avec quelques services en moins. Dans tous les cas on n’a pas de plantage sauvage avec l’écran jaune de la mort ou des messages bizarres.

Scalabilité

La scalabilité est habituellement mesurée avec des paramètres comme le nombre de pages par seconde ou le nombre de requêtes par seconde. Il ne faut pas confondre ces deux mesures car une page est construite sur la base de plusieurs requêtes, il est donc normal que le nombre de pages/s soit inférieur au nombre de requêtes/s.

On rencontre parfois le terme de throughput. Ce terme est extrêmement répandu dans presque tous les domaines scientifique, il représente en quelque sorte la vitesse à laquelle quelque chose est produit ou consommé. Ici des requêtes.

 

Un système est composé d’éléments physiques il est donc normal de lui trouver une limite de traitement. Une fois cette limite atteinte les requêtes ne peuvent plus être traitées en parallèle et s’empilent dans une file d’attente. On parle de goulot d’étranglement (bottleneck). Les performances de l’application chutent alors très vite et parfois c’est l’application elle-même qui s’effondre!

  • On parle de d’évolutivité horizontale (horizontal scale ou scale-out) lorsque l’on résout le problème de scalabilité en ajoutant des serveurs supplémentaires.
  • L’évolutivité verticale (vertical scale ou scale-in) consiste à augmenter le niveau des ressources des serveurs (mémoire, CPU…).

 

Il est important de savoir plusieurs choses:

  • Les deux approches ont chacune un domaine d’application

La loi d’Amdahl permet de quantifier l’amélioration S de la latence que l’on peut attendre lorsque l’on augmente les ressources d’un système à charge constante:

2016-05-30_12-36-48

Examinons par exemple l’impact d’un doublement du nombre C de CPU dans une appli où p=40% du code ne peut être parallélisé.

Pour P = 4 on trouve:

2016-05-30_12-41-28

Pour P=8:

2016-05-30_12-42-37

On est loin de doubler les performances, mettre des CPU en plus ne sera sans pas forcément la meilleure solution.

Une façon plus triviale de dire les choses: 9 femmes ne feront pas un enfant en 1 mois!

Le scale-in est donc surtout efficace sur des services qui peuvent se paralléliser.

 

  • Ajouter des serveurs supplémentaires

Ce n’est pas toujours possible si votre code n’a pas été conçu pour. Ce dernier point sera examiné dans un autre article de cette série et ne doit pas être négligé.

Je l’analyse comme un effet de bord d’une idée très générale discutée par Martin Abbot et Michael Fisher dans un livre de référence sur la scalabilité « Scalability Rules« :

 

2016-05-30_11-00-19

Ce tableau souligne une idée très simple: plus on tarde à réfléchir sur la scalabilité d’une application, moins se sera efficace et plus se sera coûteux. La scalabilité n’est donc pas le comportement intrinsèque d’une application. Elle est scalable parce qu’elle a été conçue comme tel.

 

Si vous lisez cet article, vous êtes probablement développeur. En tant que tel une expression comme ‘parce qu’elle a été conçue’ se traduit par pattern. Un savoir faire existe et il a été formalisé par un certain nombre de patterns. Je vais développer dans les articles qui suivent les plus courants, mais je n’épuiserai certainement pas le sujet. Il y a différents ouvrages sur la question, mais une introduction intéressante pour Azure est ici:

https://msdn.microsoft.com/en-us/library/dn600223.aspx

 

Gardez tout de même en tête qu’au final c’est une application concrète qui doit être pensée. Les principes que je vais démontrer sur des exemples ne s’appliquent pas forcément à votre cas et peuvent même être contre productifs.

 

Mon expérience dans le domaine à démarrée dès ma première application ASP.NET et depuis j’ai développé un certain nombre de sites e-commerce avec une problématique de trafic élevé pour plusieurs d’entre eux. Je doute tout de même être un gourou du domaine, mais il y a un message simple que je crois pouvoir faire passer:

  • En fort trafic les événements rares deviennent… plus fréquents
  • Ne devinez pas, mesurez et testez
  • Une mesure c’est bien, mais savoir ce qui a été véritablement mesuré est encore mieux

Haute disponibilité

La qualité de service ou SLA (Service Level Agreement) est mesurée par un pourcentage. Par exemple un SLA de 90% montre une indisponibilité de 10% sur une période données. Sur 1 an on peut donc s’attendre à 36.5 jours d’indisponibilité. Vous trouverez une calculette ici.

 

Dans un contexte de cloud l’importance du SLA évolue. Je vous propose de lire cette analyse intéressante:

http://www.cloud-experience.fr/content/cloud-iaas-sla-font-bon-menage?extId=&caid=

Et le message peut être encore plus direct :

http://www.cio.com/article/2883770/cloud-computing/the-death-of-the-sla.html

…  after spending over an hour on negotiating SLAs, the speaker took a question: “How flexible are cloud providers on SLAs?” His response: “It depends. The larger providers refuse to make any changes and the smaller providers will sign anything to get the business.” In other words, all your negotiating prowess will be fruitless, in the end.

Vous êtes prévenus!

 

La discussion amorcée dans ces deux articles et le résultat du théorème du CAP évoqué dans le premier d’entre eux semblent pessimistes quant à l’avenir des applications HD. Cela est vrai uniquement si vous poursuivez un objectif de 100%. Et cet objectif vous ne l’atteindrez pas.

 

Mais en fait l’idée introduite par la Haute Dispo est différente: avoir une disponibilité adaptée à son business. C’est ainsi qu’apparaissent les marges de manœuvre.

Par exemple le service de géolocalisation est probablement d’importance mineure pour un site e-commerce. Mais si votre application est une application de cartographie c’est moins évident.

 

Je voudrai enfin souligner une confusion fréquente entre HD et PRA (Plan de Reprise d’Activité). La mise en place d’un PRA ne garantit en rien la HD.

Le projet

Article très orienté démo, le projet de démo est une site qui va vous permettre de parier sur des courses d’escargots (il s’agit d’un clin d’œil, quelqu’un se souvient à quoi?). Des courses vous sont proposées et chaque course est courue par plusieurs concurrents déjà prêts à bondir hors des paddocks.

Vroom, c’est partit! Usain Bolt n’a qu’à bien se tenir!

 

Les Use cases sont les suivants:

  • Afficher la liste des courses, pouvoir faire un ‘like’ sur la course
  • Acheter des billets pour une course sélectionnée
  • Créer une nouvelle course
  • Afficher les détails d’une course avec la liste des concurrents. Possibilité de parier sur un concurrent
  • afficher la liste des concurrents
  • Voir la liste des courses où le concurrent est présent et pouvoir placer un pari
  • On ne gère que les paris Simple Gagnant

 

Vous visualiser les courses et leur cote et d’un clic vous pariez!

2016-06-24_08-55-11

 

Vous achetez des places:

2016-06-24_08-57-17

Et une confirmation s’affiche:

2016-06-19_15-02-32

En fait il est précisé que vous recevrez prochainement une confirmation. L’achat de billets n’est pas exactement temps réel.

 

Le projet complet est disponible sur mon espace Github:

https://github.com/DeLeneMirouze/EscarGo

2016-08-15_23-54-44

Il est composé d’un projet de librairie EscarGoLibrary qui contient tout le code commun aux différents projets.

Une série de projets qui correspondent à différentes étapes du projet. Nous commencerons par EscarGo, le projet d’origine sans optimisations particulières.

La base de données est attaquée par Entity Framework code first. Vous trouverez les migration ainsi qu’un seed pour alimenter les tables.

Bien entendu vous n’oublierez pas d’alimenter le fichier de configuration.

 

Dernier point. Bien que les techniques que je présente ne sont en rien spécifiques à Azure, j’ai testé et développé un projet Azure Web App. Certains exemple ne fonctionnement d’ailleurs pas autrement.

Architecture de EscarGo

Il s’agit du projet de départ que nous allons améliorer peu à peu. Son architecture est très simple:

2016-05-29_18-44-36

Une architecture 3 tiers monolithique et sans redondance de nœuds on ne peut plus classique, mais qui suffira dans nombre de situations.

EscarGo! s’appuie sur une base de données dont voici le schéma:

2016-06-19_15-09-57

 

Comme nous le découvrirons, EscarGo! n’est pas capable de monter fortement en charge tout en assurant de la haute dispo. Certaines raisons apparaissent rien qu’en examinant les deux schémas ci-dessus, d’autres sont plus subtiles.

 

Bibliographie

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s