Les architectures web – Introduction

C’est avec une émotion non dissimulée que je reprends ce blog que j’avais laissé à l’abandon depuis si longtemps. En effet, depuis de nombreuses choses se sont passées et j’en reviens ici. Je souhaite reprendre l’esprit initial de ce blog qui est de partager des informations sur l’Internet afin de pouvoir aider d’autres personnes qui se retrouveront dans des situations dans lesquelles je me suis trouvé plus tôt.

Cet article est l’introduction d’une série de billets que je compte écrire sur les architectures web appliquées aux logiciels Open Source. L’idée est de détailler les architectures permettant l’hébergement de sites Internet allant du site statique basique à un site complexe.

Les composants

Tout d’abord, il est utile de s’intéresser aux composants qui peuvent constituer une architecture web. Nous les classerons en trois catégories : les composants élémentaires, les composants de service et les composants de support.

Les composants élémentaires sont les composants que l’on retrouve dans toutes les architectures web classiques. Il s’agit du code du site qu’il s’agisse de code statique tel que du HTML ou du Javascript ou bien de code dynamique tel que du PHP, du Ruby on Rails voire même du C. Il s’agit également du jeu de données sur lequel le site se reposera afin d’afficher des données utiles à l’utilisateur. On y retrouvera ici des bases de données relationnelles ou non et les données brutes telles que des images ou des vidéos.

Les composants de service sont les composants que l’utilisateur va utiliser sans nécessairement en avoir conscience. Il s’agit des composants applicatifs chargés de générer les pages à partir du code du site, des composants de bases de données chargés de traiter les données ou bien des composants chargés de diriger l’utilisateur vers le serveur le plus approprié. Des exemples de logiciels Open Source servant de composants de service sont, par exemple, Phusion Passenger, Python, MySQL, MongoDB, nginx ou encore HAProxy.

Les composants de support sont les composants que l’utilisateur ne sera probablement jamais amené à interroger directement. Il s’agit des composants servant à assurer le bon fonctionnement et l’administration de l’architecture. On peut inclure dans cette catégorie les logiciels de gestion de configuration, les applications de supervision ainsi que les applications de déploiement de code. Des logiciels Open Source correspond à cette catégorie sont, par exemple, Puppet, chef, Nagios, Cacti, Zenoss, Webistrano ou git.

Le début

Dans cette série d’articles, nous ne nous intéresserons pas au cas de l’hébergement mutualisé. En effet, il s’agit probablement de la forme la plus simple d’hébergement du point de vue de l’utilisateur mais il s’agit en réalité d’une architecture web extrêmement complexe dont les complexités ne sont que cachées à l’utilisateur. Il est évident que la complexité d’une architecture mutualisée est différente en fonction de la taille de l’hébergeur mais néanmoins nous exclurons ce sujet de cette série d’articles.

Nous supposerons donc le cas le plus basique qui est celui d’un site web développé dans un langage de programmation tel que Ruby hébergé sur un serveur virtuel comme ceux que l’on peut trouver chez des hébergeurs tels que Gandi ou OVH pour ne citer que les plus gros. Ce site web reçoit une quantité de visite tout à fait raisonnable de l’ordre de 100 à 1000 visiteurs par jour.

Un serveur virtuel sera une solution idéale pour ce type de site car il permet la mise en place d’une pile applicative paramétrée en fonction des souhaits du développeur ou de l’administrateur système. Ainsi, toute la pile applicative sera retrouvera confinée à un système d’exploitation. Étant donné la nature d’un tel site et la probable non-criticité du service rendu, nous supposerons que les composants support sont réduits à un minimum.

La pile applicative

Dans le cas de notre site développé en Ruby, il y a plusieurs possibilités quant à la pile applicative. La solution la plus simple est d’utiliser WebRick le serveur HTTP inclus par défaut avec le framework Rails. De nombreux framework proposent un serveur web simpliste dont l’exécution se résume au lancement d’une simple commande. Cette solution permet de tester un site simplement mais est souvent limitée du fait de leur nature mono-threadés. Bien qu’un temps significatif soit gagné dans l’installation, il y a peu de chance que les performances soient au rendez-vous dès la moindre mise à l’épreuve.

C’est donc aussi rapidement qu’on se retrouve confronté au concept de « scalabilité », anglicisme issu du mot « scalability » qui décrit la capacité d’une architecture à grossir en fonction de la charge imposée. Ce sera le concept qui sera le fil conducteur de cette série d’articles.

Une fois la solution la plus simpliste éliminée, il nous reste donc à étudier l’utiliser de composants plus performants. Nous allons rapidement nous retrouver face à Apache, le serveur HTTP historique, et nginx, le serveur HTTP qui se veut rapide et flexible. Apache est probablement le logiciel Open Source pour lequel il est le plus simple de trouver des tutoriels en très grande quantité sur Internet. Il me parait même raisonnable de penser que si vous ne trouvez un article ou un tutoriel sur une fonctionnalité que vous souhaitez implémenter, c’est que c’est probablement impossible. Apache est capable d’exécuter un panel d’interpréteurs extrêmement large ainsi que des exécutables binaires via les interfaces CGI. De l’autre coté, nginx est une application dont le succès est beaucoup plus récent. La documentation est moins pléthorique qu’Apache mais elle est néanmoins assez simple à trouver.

Le choix du serveur HTTP est, selon moi, à faire en fonction de ses propres compétences à ce stade là. Si vous maitrisez l’un, vous aurez tout à fait raison de l’utiliser afin de simplifier votre architecture et rester sur des bases connues. Dans le cas de Ruby on Rails, l’installation de nginx avec le module Phusion Passenger se fait via une compilation automatisée par un script fourni. A contrario, l’installation d’Apache2 se fait via les modules présents dans n’importe quel distribution ce qui facilite grandement la tache.

Quant à l’application de gestion des données, vous aurez le choix entre MySQL et PostreSQL voire sqlite. Je n’entrerais pas dans le débat MySQL vs PostgreSQL néanmoins, comme pour le serveur HTTP, je ne peux que vous conseiller d’utiliser celui que vous maitrisez le mieux si l’objectif est de fiabiliser l’architecture. Quant à sqlite, son utilisation est en effet très simple néanmoins vous risquez de vous retrouver très rapidement limités par les fonctionnalités disponibles et les possibilités de scalabilité.

Bilan

Une telle architecture est particulièrement efficace en terme de coûts car elle ne nécessite qu’une seule VM dont le coût est relativement limité. De plus, en comparaison avec de l’hébergement mutualisé, vous aurez une liberté de manœuvre beaucoup plus grande.

L’inconvénient majeur de cette architecture simple est que vous ne disposez d’aucune redondance. Tous les composants sont des « SPOF » (Single Point of Failure ou, en Français, Point individuel de défaillance) ce qui signifie que la défaillance d’un seul de vos composants applicatifs entraine l’indisponibilité du site entier. De plus, le potentiel de performance d’une telle machine virtuelle à bas coût est relativement faible. Dès lors que le site commencera à atteindre une audience plus large et/ou plus régulière, vous allez devoir rapidement songer à passer à l’étape suivante.

Dans le prochain article, nous allons donc nous intéresser à la première étape permettant de faire grossir cette architecture afin qu’elle puisse accueillir plus de visiteurs.