De nos jours, nous travaillons sur toute forme d’applications, du CMS, au frameword Symfony en passant par les applications eCommerce pures (comme Magento 2) et tout le reste. Dans cet article, je reviens sur une application tres connue: Drupal, et comment nous avons pu la rendre scalable et modulable pour un de nos clients.
C’est la deuxième année que l’équipe responsable de http://www.tousaurestaurant.com/ travaille avec Sutunam pour optimiser leur solution Drupal en vu du pic de trafic attendu pour leur prochaine campagne de communication. Le résultat final est un site Drupal déployé avec une solution de répartition de charge (Load Balancing) et des serveurs cloud tournant sur LAMP. Un serveur front-end reverse-proxy Nginx est mis en avant. L’utilisation du reverse-proxy est particulièrement efficace lorsque les requêtes sur un simple site vont au-delà des capacités de la machine: en mettant en cache tous les contenus sans limite de validité, comme votre navigateur web.
L’architecture et les serveurs
La première chose à faire est de mettre en place le cloud. Pour cette communication spéciale nous avons opté pour la configuration suivante:
- 1 master serveur, avec Debian LAMP (Apache2, MySQL and PHP) et Nginx qui est le principal serveur front-end reverse-proxy, utilisé comme load balancer (répartition de charges).
- 1 série de node serveurs (nœuds) comme esclaves (slaves) faisant tourner Apache et PHP.
- (1 files container CDP – en option).
Le master serveur
L’environnement LAMP tourne sur le serveur principal (front-end proxy) avec Nginx et Memcache. Ce serveur fonctionne comme un proxy et sera le serveur principal pour le reste de l’année.
Pour cette occasion spéciale, le client prévoit une communication media importante (TV, journaux), le serveur Nginx sert donc de reverse-proxy et de load balancer (répartition de charge). Nginx met en cache le contenu statique pour optimiser les vitesses de chargement des pages et plus tard, repartira la charges des requêtes sur les serveurs adjacents.
Les pages Drupal ainsi que leurs contenus sont aussi configurés et optimisés pour la mise en cache (caching) que je ne détaille pas dans cet article.
Les nodes serveurs
Les serveurs nœuds fonr tourner les process PHP. Derrière Apache et PHP, le code source de Drupal est dupliqué sur chaque nœuds depuis le serveur principal toutes les 10 secondes max.
Tous les changements des fichiers système inodes sont écoutés avec la fonction du Kernel Linux: inotify et avec un algorithme offert par lsyncd, seuls les fichiers modifier seront envoyés par SSH avec librsync.
Ces serveurs n’ont pas de serveur de base de données MySQL et font leurs requêtes directement à MySQL et Memcache du serveur principal.
Comment ça marche ?
Le proxy front-end avec Nginx fonctionne ainsi:
- Nginx reçoit une requête (depuis Internet)
- Nginx check si le résultat de la requête est déjà en cache. Sinon il renvoi la requête a un node serveurs, en repartissant la charge entre les nœuds, puis reçoit la réponse.
- Nginx envoi la réponse de la requête au demandeur.
Pour garder une Haute Disponibilité et être déployée (scalable) rapidement, une image du node serveur (noeud) est créée. Un script pour déployer l’image est cree pour synchroniser les fichiers, configurer les pare-feux (firewall), fichiers de configuration et ajouter le nouveau nœud à Nginx et aux process lsyncd. Une fois Nginx redémarré, le nœuds est déployé et prêt à répondre aux requêtes.
Cette méthode prend moins de 60 secondes pour ajouter un nouveau serveur au cluster. Elle détecte automatiquement le nombres de cœurs processeurs disponibles sur les nouveaux serveurs et assigne un poids pour chacun dans la solution de répartition de charge (load balancing).
Les limites
Pour maximiser la vitesse de réponse, les applications Drupal sur les nodes servers ne communiquent pas directement avec Memcache sur le master serveur. Ils utiliseront leur propre application Memcache pour plus de rapidité. Cette solution fait gagner prés de 120ms par requête. Cependant Drupal ne permet pas encore de dupliquer plusieurs caches. Donc quand un changement de contenu est fait depuis l’administration Drupal sur le serveur principale, le cache des nodes serveurs n’est pas mis à jour.
Une autre limite est la base de données MySQL sur le serveur principal. C’est la limite principale de ce type d’architecture car elle ne peut pas répondre a une liste infinie de requêtes (en base de données) comme elles ne sont pas elle même dupliquées.
Résultats
Avec cette configuration, la solution Drupal est sur-boostée dans un environnement multi-serveurs, facilement déployable et scalable. Le pic de trafic est monté a 13,000 visiteurs simultanés (Google Analytics unit) sur 13 nœuds de 32 cœurs / 128GB RAM. 500,000 pages vues sur une heure par 100,000 visiteurs !
