Concevoir l’architecture technique d’un site web à forte audience est compliqué. Rien à voir avec son site perso. Les contraintes de charge et de disponibilité sont difficiles à gérer. Cet article donne quelques idées pour concevoir une architecture Web évolutive et capable de supporter des charges importantes.

Présentation générale

Lorsqu’on conçoit une architecture deux principaux problèmes se posent. Le premier c’est la disponibilité du service, le deuxième c’est la gestion de la charge et l’évolution du système.

Éliminer le SPOF pour tolérer la panne

Pour répondre au premier problème la réponse est souvent la même: on redonde les équipements. L’objectif est d’éliminer le SPOF pour tolérer la panne d’un composant technique.

Le SPOF (Single Point Of Failure) représente le composant technique critique qui est unique. Si cet équipement tombe en panne le système entier n’est plus opérationnel. Souvent c’est l’unique serveur web, l’unique base de données, l’unique lien réseau, l’unique source d’alimentation, …

La solution est donc de redonder les équipements. Quelques idées (liste non exhaustive)ci-dessous:

• Alimentation électrique: deux sources d’alimentation distinctes, un onduleur, un groupe électrogène
• Réseau: plusieurs chemins réseaux, STP, NIC Teaming, routage dynamique
• Stockage: RAID, baie de stockage redondées (SAN, NAS)
• Système: clustering

Monter en charge

Le deuxième problème est la montée en charge. La solution est de mettre en place des systèmes scalable, de type scale out. Pour cela l’idée est de découper les couches du systèmes et de mettre en place des techniques d’équilibrage de charge sur ces différentes couches: le loadbalacing.

Le loadbalacing consiste à répartir la charge (les requêtes, des demandes de connexions) sur plusieurs systèmes. La technique de répartition est cruciale! Il existe plusieurs technique comme le tourniquet (round-robin), fixer un poids, le système le plus rapide, …

Attention: certaines techniques doivent être utiliser avec précaution. Par exemple, l’utilisation du DNS n’est pas pertinent pour répartir convenablement la charge. Les caches des différents serveurs et des clients ne permettent pas une réparation fiable de la charge.

Les architectures

L’objectif est de concevoir un site web permettent de gérer une charge importante avec une tolérance de panne des composants techniques. Les architectures que je propose utilisent tous des logiciels open source et (ou) gratuits.

Le site web de la maison

LAMP c’est l’architecture typique que tout le monde connait. Super pour un environnement de développement et un petit site web, LAMP est un package abordable pour tous. Mais les limites de cette architecture sont rapidement atteintes. Tous les composants sont sur le même serveur. La monté en charge et la tolérance de panne ne peuvent être garanties.

Le site web intermédiaire

Dans cette seconde architecture on prend en compte la performance. La base de données et le serveur web sont séparés et en plus on met un cacher en front. Ce type d’architecture est performant jusqu’à un certain niveau de charge, mais la tolérance de panne n’est pas satisfaisante.

Le site web scale out

Cette dernière architecture propose un système scale out avec une tolérance de panne. Un frontend répartis la charge sur plusieurs serveurs web. Les serveurs web communiquent avec un cluster MySQL par le biais d’un loadbalancer.

Les loadbalancers (frontend et SQL) sont composés de deux serveurs. Ces serveurs disposent d’une IP virtuelle commune avec un mécanisme de failover master/slave (CARP, UCARP). Si un loadbalancer tombe en panne, le deuxième prend le relai automatiquement grâce à l’IP virtuelle.

Le frontend peut se baser soit sur Nginx (en reverse proxy loadbalancer il est très efficace) ou alors sur HAProxy.

Le loadbalancer SQL ne peut que se baser sur HAProxy. (MySQL proxy existe mais il est encore en version alpha)

Le cluster de base de données utilisé est MySQL. Il se compose de serveur de management (management node), de serveur d’accès (SQL node) et de serveur de base de données (data node). Les données sont répliquées sur tous les data nodes.

Les serveurs d’applications sont composés de varnish et Nginx. Varnish est un excellent cacher. Il permet d’envoyer des pages statiques aux clients au lieu que le serveur http les génère à chaque fois. Nginx est un serveur http peu connu en production mais il est très puissant et il a la caractéristiques de ne pas consommer autant de mémoire que Apache lorsque beaucoup de clients interrogent le serveur. Nginx supporte un très trafic fort!

NB: A la place de Nginx on peut bien sûr utiliser Apache 2 en tant que serveur web

Pour synchroniser les fichiers sources des différents serveurs web il existe plusieurs méthodes:

• Rsync: une synchronisation des sources avec un script basé sur l’utilitaire Rsync
• NFS: le répertoire web est un montage NFS utilisé par tous les serveurs web

Conclusion

L’architecture proposée montre que mettre en oeuvre un site web à fort trafic n’est pas simple. Cette proposition n’est pas complète et il faut prendre en compte les configurations matérielles, réseaux qui doivent être adapté à la volumétrie.

Les environnement virtuels fournissent des technologies simples pour avoir de la tolérance de panne et de la haute disponibilité. L’architecture peut donc varier si elle est implémentée sur un environnement virtuel tel que VMWare vCenter ESXi.

Donnez votre avis et vos idées d’infrastructure pour un site web à très fort trafic!