Planning des évolutions de votre architecture web

Lors de la dernière conférence LinuxWorld, John Engales le CTO de Rackspace a présenté les différentes étapes de la vie d’un site web. Et même si chaque site possède sa problématique il est toujours intéressant de voir qu’il existe un schéma général.

En quelques lignes voici donc les différentes versions d’une infrastructure web typique, j’ai simplement changé deux points (en gras et/ou barré) qui sont plus proches de la réalité des cas que je rencontre de ce coté de l’atlantique :

  • Etape 1 : Architecture simple, pas de redondance, pas de complexité. Un firewall, un serveur Web et une base de données avec stockage local (load balancer web, rare à ce niveau).
  • Etape 2 : La même chose mais avec un load balancer sur deux serveurs web et une base de données un peu plus puissante
  • Etape 3 : Mise en place d’un reverse proxy, d’un cache statique et de load balancers sur les bases de données (avec synchro master/slave par exemple). Il faudra prévoir quelques recodage à cette étape.
  • Etape 4 : La complexité commence : Ajouter du memcached (ou autre), les réplications entre les bases de données deviennent trop gourmandes en ressources et il va falloir commencer le split horizontal (partitionnement des données, nécessitant un re-design des BDD). A ce niveau la mise en place de serveurs dédiés en fonction du contenu a du sens.

A partir d’ici les choses commencent vraiment à devenir sérieuses, bonne nouvelle pour le trafic du site ou du service mais il va désormais falloir assurer une disponibilité sans faille.

  • Etape 5 : Repenser l’application si les bases ne permettent pas un partitionnement géographique ou individuel (par utilisateurs). Création de cluster par utilisateurs, grosse utilisation des clefs de HASH. Le but ici est de pouvoir gérer la croissance en ajoutant des ressources de manière horizontale sur les différents niveaux de l’architecture.
  • Etape 6 : Normalement l’étape 5 permet de gérer la croissance en ajoutant des serveurs et il est possible d’ajouter de nouvelles fonctions en gérant la croissance. Il faut optimiser certaines parties du code mais l’ensemble reste sous contrôle.
  • Etape 7 : Bienvenue dans l’inconnu, les problèmes peuvent arriver de n’importe ou et dans n’importe quel ordre, mais il faudra gérer l’explosion de la bande passante, le trafic réseau interne, la puissance électrique et l’espace physique, l’obsolescence des premiers serveurs, le(s) CDN) etc…

Si vous lisez le document complet vous verrez que j’ai changé 2,3 points. Par ailleurs je pense qu’il manque dans cette présentation l’utilisation de services de type Clouds comme ceux d’Amazon. Je pense qu’ils peuvent être intégrés dans certaines étapes.

Comme d’habitude vos questions et retours d’expériences sont les bienvenues, surtout si vous êtes proche de l’étape 7 :-)

Le document :

http://www.slideshare.net/davemitz/7-stages-of-scaling-web-applications

Sur le même thème :

6 Responses to “Planning des évolutions de votre architecture web”

  1. Bonjour Marc et merci pour les informations que tu rends disponibles ici, voici un petit retour d’expérience.

    Dans une précédente mission j’ai travaillé sur la montée en charge d’un site flash qui dépasse le million de visiteurs mensuels (une marque de mode).

    A partir de l’étape 3 (500 000 visiteurs mensuels), la solution a été de repenser les accès au serveur de base de données, car celle-ci était le point d’étranglement principalement à cause de l’écriture de statistiques en temps réel. Le choix a été de passer un maximum d’éléments de contenus en statique (via des fichiers textes et XML) afin de minimiser les accès en lecture et de rapatrier les dumps de stats sur une machine de dev toutes les minutes pour minimiser les écritures (étape 4).

    Dans le même temps nous avons pu passer directement à l’étape 7 et diffuser les contenus statiques via un opérateur de CDN tout en conservant l’architecture encore relativement assez peu couteuse de l’étape 3 avec load balancing et réplication MySQL. En quelque sorte on s’est affranchi des coûts de l’étape 6.

    Le fait d’avoir d’être passé de suite à un reverse proxy nous a offert des bons temps de réponse un peu partout là où était présent l’opérateur et notamment aux USA (problématique de l’étape 5). En revanche les choix techniques (interface flash avec protocole Amf pour la communication avec la base de données) est encore un point bloquant car les requêtes de type POST ne peuvent pas être mises en cache proxy. Inévitablement les évolutions de l’infrastructure devront repasser par les étapes 4, 5 et 6.

    Concernant l’étape 7, nous nous sommes offert une option de backup de datacenter puisque nos machines étaient localisées sur deux sites.

  2. [...] avoir étudier les différentes étapes de la vie d’un site Web je vous invite aujourd’hui à découvrir le modèle CMMI. En effet maintenir la haute [...]

  3. [...] évolution, ou encore de l’architecture de votre prochain service vous pouvez aussi consulter ce  billet, il est assez similaire mais il vous permettra d’inscrire ces étapes dans le temps et ainsi [...]

  4. Bonjour,
    Quelle base de données privilégieriez vous pour avoir quelque chose qui puisse aussi bien être utilise pour un petit site, et qui pourrait facilement s’étendre sur plusieurs serveurs via réplication ?
    J’hésite entre Postgresql et Mysql, mais je penche plus sur Mysql (Partitionnement et Réplication native)
    Que choisiriez vous et pourquoi ? (en solution libre)

    Merci

  5. Marc says:

    J’utilise les deux depuis presque 10 ans mais je ne suis pas expert sur Postgresql, et encore moins sur sa réplication. Si votre site est petit j’aurais tendance à privilégier MySql qui reste la simple à mettre en place pour ce type de besoin (petit site + réplication).

Leave a Reply