Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

L’extensibilité

L’extensibilité

L’extensibilité, ou par anglicisme, « scalabilité », est la capacité d’une architecture à croître sans rupture, en ajoutant simplement du matériel.

image003

L’extensibilité est la qualité principale d’une architecture web. On l’entend pour atteindre de fortes capacités, mais elle est importante aussi à l’autre extrême, pour commencer petit, et adapter la dépense en infrastructure à la croissance. C’est en quelque sorte le moyen de payer son infrastructure en success-fee, c’est à dire en cas de réussite. Et dans ce cas, on est toujours heureux de payer.

image_opti

Le schéma ci-dessus représente différents cas de croissance de la capacité d’accueil d’une plateforme web, en fonction du nombre de serveurs qu’on y intègre :

  • En bas, une architecture médiocrement extensible : il n’y a guère à gagner en ajoutant des serveurs, et la capacité peut même rapidement se trouver dégradée, par exemple par des problèmes de synchronisation entre serveurs.
  • En haut, l’extensibilité théorique idéale : la capacité d’accueil augmente de manière linéaire avec les machines.
  • Et au milieu, le cas ordinaire type, une architecture qui est extensible jusqu’à un certain point, mais qui atteint une limite en asymptote horizontale.

L’extensibilité en trois dimensions

On peut travailler l’extensibilité selon trois dimensions, que nous appellerons ici l’extensibilité cellulaire, fonctionnelle et horizontale.

  • L’extensibilité cellulaire consiste simplement à augmenter la puissance du ou des serveurs.
  • L’extensibilité fonctionnelle, que l’on pourrait appeler aussi « verticale », consiste à répartir les fonctions de la plateforme sur des serveurs différents.
  • L’extensibilité horizontale consiste à répartir les traitements sur différents serveurs homologues.

Nous analyserons les caractéristiques de chacune de ces démarches d’extensibilité, et nous verrons que seule l’extensibilité horizontale est pratiquement sans limite.

image007

Extensibilité cellulaire

On appelle ici extensibilité « cellulaire », la capacité à faire gonfler la cellule élémentaire de l’architecture, le serveur de base : CPU, mémoire, disque, etc.

Il faut garder à l’esprit la fameuse loi de Moore, selon laquelle la puissance CPU disponible pour un prix donné est multipliée par deux tous les 18 mois.

C’est à dire que si votre plateforme a plus de 18 mois et commence à saturer, le moyen le plus simple et parfois le moins coûteux d’aller plus loin consiste à remplacer les serveurs par la dernière génération.

Mais une fois qu’on a fait cela, il faut trouver d’autres voies d’extensibilité, ou attendre à nouveau 18 mois.

Extensibilité fonctionnelle, ou verticale

Il s’agit ici de distinguer différentes fonctions dans la plateforme, et de répartir ces fonctions sur différents serveurs. Dans certains cas, ces fonctions peuvent s’organiser en couches, ou tiers, et on parlera d’architectures multi-tiers.

Ainsi on peut distinguer sur une plateforme web typique, les fonctions suivantes :

  • Le serveur HTTP, typiquement Apache,
  • Le serveur d’application, par exemple Tomcat ou Jboss,
  • Les applications web
  • La base de données.

Mais on identifie parfois d’autres fonctions, pas nécessairement en couches. Par exemple un moteur d’indexation-recherche, ou bien la distinction d’une application de back-office par rapport à un front-office.

Ces différentes fonctions, que l’on pourra appeler services dans une logique SOA, peuvent être initialement disposées sur un même serveur. Et au fur et à mesure de la montée en charge, elles peuvent être réparties sur différents serveurs spécialisés, ce qui évidemment permet de donner plus de ressources physiques, particulièrement de CPU, à l’ensemble de la plateforme.

Cette forme d’extensibilité est limitée, bien sûr, par le nombre de fonctions identifiées dans l’architecture.

Extensibilité horizontale

Enfin, comme on l’a vu, l’extensibilité horizontale consiste à répartir une même typologie de traitements, une même fonction, sur différents serveurs homologues. Nous verrons les principes et outils de ce type de répartition.

Des trois axes, c’est le seul qui soit véritablement sans limite. Mais bien sûr, les trois peuvent être combinés.

Quelle cellule élémentaire, quelle brique de base ?

En supposant que l’on soit parvenu à un degré satisfaisant d’extensibilité, on a gagné la possibilité de choisir entre N1 serveurs de capacité unitaire C1 et de prix unitaire P1, ou bien N2 serveurs de capacité unitaire C2 et de prix unitaire P2, pour une même capacité totale, c’est à dire N1C1 = N2C2.

On peut traiter la question par le simple prix unitaire de la capacité de traitement : quel est le meilleur rapport C/P, et donc le moindre coût d’acquisition de la plateforme. Cette simple analyse conduirait le plus souvent vers les serveurs les plus bas de gamme du marché.

Mais plusieurs autres considérations sont à prendre en compte :

  • Les coûts d’hébergement dépendent pour une part importante du nombre de serveurs, indépendamment de leur puissance : espace de racks, ports des switchs, etc.
  • Toute l’administration et l’exploitation prennent une complexité croissante, et donc un coût supérieur, avec le nombre de serveurs. Cette augmentation n’est cependant pas linéaire : passer de 3 serveurs à 10 serveurs peut doubler le coût d’exploitation, mais passer de 10 à 20 n’augmentera peut être que de 50%.
  • Le nombre de pannes est proportionnel au nombre de serveurs – à qualité égale – et chaque panne engendre un coût spécifique de traitement.
  • Le coût de l’électricité n’est pas négligeable, et il importe de considérer aussi le rapport C/E, capacité par Watt, qui varie de manière importante entre les serveurs.

Il s’ensuit que, à rapport puissance/prix égal, on préfèrera minimiser le nombre de serveurs. C’est à dire typiquement que si un serveur bi-processeur coûte deux fois le prix d’un serveur mono-processeur, alors on préfèrera mettre en œuvre des serveurs bi-processeurs.

Chaque étage ne s’analyse pas de la même manière, précisément parce que l’impact du nombre de processeurs peut être très différent. Ainsi, l’étage base de données est toujours moins extensible, plus difficile à paralléliser. Plutôt que de mettre en œuvre une base répartie sur 4 serveurs, il sera sans doutes moins coûteux de n’administrer qu’un serveur unique, quadri-processeurs. Mais bien sûr, on sera alors en butée, sans plus d’extensibilité horizontale.

Les serveurs multi-processeurs apportent une certaine extensibilité de manière quasi-transparente. Mais quelques-uns des problèmes liés à la parallélisation, que l’on traitera avec l’extensibilité horizontale se retrouveront déjà à l’échelle d’un serveur multi-processeurs.

Une autre considération importante en matière d’acquisition de serveurs est que l’on ne peut pas espérer une plateforme homogène en termes de configuration. Une plateforme monte en gamme progressivement, et l’on ne peut pas passer commande d’un coup pour les 3 années à venir. Sur le plan logiciel, en revanche, on s’attachera à avoir des configurations identiques, mais les écarts matériels, principalement au niveau du processeur, auront des impacts en particulier dans les dispositifs de répartition de charge, qui devront prendre en considération la puissance spécifique de chaque serveur. L'un des apports majeurs des solutions de virtualisation est justement de mieux masquer les petites différences du matériel, et donc de faciliter la gestion d’un parc hétérogène.