Questions Serveur (Partie 3): Architecture & Scalabilité

Un troisième article qui va introduire les questions d'architecture pour répondre à un besoin de scalabilité.

Pour simplifier la chose au maximum (et donc la rendre maîtrisable), on va découper classiquement une application en 3 couches:

• La couche cliente (la Vue de MVC) qui peut être une simple présentation - web 1.0 - ou un client riche (modèle MVC à part entière) - web 2.0 (c'est grossier mais je ne limite le web 2.0 à ça). Cette partie client se trouve sur le navigateur ou sur une application riche de type Adobe Air, Java Web Start, RCP, .NET...
• La couche services (le Controller de MVC), où sont regroupés l'ensemble des règles métiers. Cette partie est centralisée au niveau de serveurs d'application. En vue SOA, c'est la couche de service qui délivre des objets d'entreprises réutilisables. Il faut noter que la partie client et/ou la partie services peut consommer des services tiers.
• La couche données (le Model de MVC) implémentée par une base de données (MySQL, SQL Serveur, Oracle...).

Chacune de ces 3 couches seront traitées dans 3 articles différents. En attendant, de nombreux choix sont déjà déterminant.

On va utiliser les hypothèses suivantes pour évaluer ces choix:

• Beaucoup d'utilisateurs,
• peu de puissance de calcul à délivrer par utilisateur,
• une architecture qui s'adapte en fonction de ce nombre d'utilisateurs (dit scalable).

Nous allons aussi estimer les marges de manœuvre sur chacune des couches:

• La couche cliente - riche - est intéressante car la puissance disponible est proportionnelle aux nombre de consommateurs de l'application. Attention cependant à ne pas surcharger le navigateur en puissance de calcul et surtout en mémoire (Interview Tristan Nitot).
  
• La couche de services, elle est scalable à souhait pour accueillir un maximum d'appels de services. Les modules de load balancing de apache sont mature et éprouvés. Cependant il faut penser à bien faire attention à la bande passante car il y a toujours les load balancer qui sont des goulots d'étranglements.
• La couche de données, elle est très dépendante de la solution utilisée. En effet, la partie réplication de données est plus ou moins gourmande et administrable selon les solutions. Cette partie réplication de données étant indispensable pour répartir la charge.

En résumé, plus l'on est proche du stockage de la donnée plus il est difficile de répartir la charge et il est à l'inverse plus facile lorsque l'on est proche du consommateur de la donnée. De plus elle est naturellement plus répartie au niveau du consommateur et plus concentrée au niveau du stockage.

Les règles suivantes sont donc applicables (mais porteront à débat en fonction du besoin):

• Déplacer la charge de calcul de la couche de données vers la couche de services. Même si un calcul sera globalement moins gourmand en utilisant des procédures stockées sur la base, il est plus facilement répartissable sur la couche de service.
• Déplacer la volumétrie de traitement de données de la couche de services vers la couche cliente en travaillant sur la nécessité des requêtes entre le client et le serveur et en stockant (en tant que tampon) un certains nombres de données au niveau du client. Cette possibilité n'était pas possible avec du simple PHP/JSP/ASP.NET - sans AJAX, ou une utilisation intensive du javascript - qui générait des pages à la volé depuis le serveur pour le client (avec aussi des temps d'attente en prime).
  

Il est bien sur indispensable de créer du cache de données au niveau de la partie service pour limiter les appels à la base de données. Cependant, il est intéressant de traiter la problématique en amont.

Le schéma suivant résume et termmine l'article: