En cette rentrée 2017, les magasins Centrakor font évoluer leur présence sur le web en proposant un site de e-commerce. Je suis intervenu sur l’infrastructure et le backoffice.

Suite au travail effectué sur le site des bérets Laulhère, nous nous sommes attaqué avec l’équipe web de Cargo à la migration sur le web du site Centrakor vers une plateforme d’e-commerce.

Une infrastructure Haute Disponibilité

Projet d’une envergure plus importante, avec des ambitions qui le sont tout aussi, il fallait commencer par une infrastructure permettant de prendre des charges de visites importante. Ça tombe bien, nous avions déjà mis ça en place sur le site précédent, pour pouvoir encaisser les pics de visites pendant les campagnes de publicité télévisées.

Après plus d’un an de R&D pour la mise en place de solutions de réplications pérennes, nous avons retenu un système de 3 serveurs accédés par l’offre d’IP Loadbalancing d’OVH, et reliés entre eux par un vRack. Le risque 0 n’existant pas, nous avons essayé de couvrir tous les cas de casse matérielle ou logicielle sur lesquelles nous pouvions intervenir.

Le principe retenu, sur chaque serveur, est une VM d’entrée HAProxy, qui renvoie la partie site et la partie statique sur deux VM distinctes. Une dernière VM gère la partie base de données, avec un cluster Galera sur MariaDB.

Les HAProxy sont configurés pour utiliser en priorité les VM présentes sur leur serveur/hyperviseur, et celles des autres serveur en secours. Comme ça, si une des VM tombe, le trafic est redirigé et ça reste transparent pour l’internaute. Les sessions étant gérées en base de données, il ne perd pas son caddie ni son identification.

Première version de vente en ligne

Ce dernier point nous a posé beaucoup de problème sur la première mouture d’e-commerce mise en place (développé par un tiers) par Centrakor, basé sur un principe de ventes privées. Un des serveurs était dans le Data Center de Strasbourg et les deux autres à Roubaix. Il faut savoir qu’à l’époque, l’IP Loadbalncing d’OVH faisait de l’anycast un peu bancal, et renvoyait l’intégralité du trafic français sur Roubaix. Ça nous arrangeait, le serveur à Strasbourg était là pour couvrir une défaillance totale de Roubaix (et ça arrive qu’ils perdent tout un DC…). Le serveur sur SBG servait donc uniquement pour le backoffice.

Malheureusement, la stabilité et la continuité de services inter DC chez OVH est un peu moisie, et il nous arrivait régulièrement d’avoir des pertes de connexions sur le vRack. Le cluster Galera se mettant en sécurité quand ça arrive, pour éviter des effets de split brain, la VM de base de données de Strasbourg s’arrêtait (un peu trop) régulièrement. Ajoutez à ça un système de logs développé par la société qui avait fait le site qui était mal pensé (ils écrivaient les erreurs dans la base de données et dans un fichier. Donc quand la base tombait, le système essayait de l’écrire dans la base. Ce qui générait une nouvelle erreur, qui générait une nouvelle erreur, etc. jusqu’à remplir l’intégralité du disque et tout crasher. Le problème ne se situant que sur la partie backoffice, ça n’avait aucun impact pour les utilisateurs clients du site, et donc c’est resté en l’état.

Expérience tirée de ce premier site

Pour la mise en place du site Centrakor, nous avons donc décidé de mettre les 3 serveurs dans le même DC, en demandant à ce qu’ils ne soient pas dans les mêmes salles (pour mitiger le risque).

Le principe est toujours le même, un cluster Galera pour la réplication des données, des HAProxy en entrée pour le routage et la haute disponibilité, et des VM avec nginx pour délivrer les contenus, une pour tout ce qui est statique, et une pour le site en lui même.

Pour optimiser les temps de réponse, les nginx se trouvent derrière des Varnish, paramétrés directement depuis Magento (qui gère son Full Page Cache avec Varnish nativement)

Et le backoffice est géré sur un seul serveur (donc les routes HAProxy renvoient sur ce serveur quel que soit le serveur sur lequel on arrive)

Un Magento aux petits oignons

L’essentiel du travail effectué sur le site de Laulhère a pu être récupéré. Un saut de version a entraîné quelques ajustements, mais pour l’essentiel le principe est resté le même. Les scripts mis à l’épreuve de l’expérience Laulhère sont restés stables.

La difficulté a été de mettre en place tous les outils et scripts nécessaires pour garder en permanence les 3 instances avec les mêmes fichiers. Le backoffice étant sur le serveur 1, il faut que si un administrateur rajoute ou modifie une image d’un produit par exemple, celle-ci soit répercutée sur les 3 instances.

Pour faire ça, j’ai mis en place un observer sur la sauvegarde d’un produit, et je lance un script de synchronisation pour les images du produit. C’est un simple rsync, donc si rien n’est modifié, ça ne fait rien et ça sort aussitôt.

Les synchronisation se faisant via le vRack, c’est de l’ordre de la seconde maximum, et en général bien moins.

Mettre en place les mises à jour

Puis j’ai développé un script permettant d’exécuter une commande Magento sur toutes les instances.

J’ai ensuite mis en place un script permettant d’effectuer les mises à jour. Nous avons déterminé 2 types (niveau 2 et niveau 3) de mises à jour (enfin il y en a une troisième, niveau 1, mais c’est pour les manipulations simples ne demandant rien d’autre qu’une synchronisation de fichiers) impliquant des manipulations spécifiques. C’est lorsque nous avons besoin de recompiler ou de redéployer les fichiers statiques.

Le script suit la procédure que nous avons déterminée. Dans le cas de la procédure de niveau 3, tous les magentos sont mis en maintenance, car il va y avoir une intervention sur la base de données, du genre à faire planter les instances encore actives (puisque le cluster est à jour en temps réel)

Les mises à jour se faisant depuis le serveur n°1, on commence par rediriger le trafic arrivant sur cette instance sur un des autres serveurs.

On lance ensuite le processus de mise à jour (setup:upgrade, setup:di:compile et setup:static-content:deploy), en vérifiant à chaque étape que tout s’est bien passé.

Si tout est ok, on redirige l’intégralité du trafic sur le serveur n°1, le temps de lancer une synchronisation complète du site sur les autres instances.

On lance une purge complète des Varnish, des caches Magento, et on répartit le trafic sur les 3 instances. Et voilà !

La suite

Comme je le disais au début, le projet est ambitieux. Un travail sur la mise en place d’instance cloud qui monteraient automatiquement en frontal en cas de pic de trafic est envisagé. Si ça se fait, j’expliquerai ici les différentes étapes et les technologies retenues.

La mise en place de ce site aurait été impossible sans Jean-Marc Viguié et son équipe chez Cargo, qu’ils en soient remerciés ici.

Crédits : copies d’écran du site