Fit for Life approche de ses 7 années d’existence ! Et au fil des années, l’infrastructure a de beaucoup évolué. Je me souviendrais toujours de la première version du site, hébergé sur WordPress, avec deux ou trois pages (la première sur les protéines !). Et puis, au cours de l’année, le design a évolué, avec la mise en place d’une seconde version, permettant de mieux servir le contenu. Bien que ce site de base convenait tout à fait, il était cependant assez lent, en cause, le poids des pages, mais aussi du code non-optimisé et complexe. Avec l’ajout de nouvelles fonctionnalités, mais aussi le déploiement des nouveaux sites, mais également l’augmentation du trafic, il devenait difficile de garantir un niveau de performance convenable et décent permettant d’offrir aux visiteurs une agréable expérience.
En 2013, l’infrastructure a déménagé une première fois pour un serveur plus performant, cela a de beaucoup aidé à diagnostiquer et dissocier les problèmes applicatifs (site Internet, code) des problèmes infrastructures (latence réseau, temps d’accès disques, mise en cache des requêtes, etc.). Avec ce travail, le site fut capable de mieux tenir la charge et lentement servir du contenu à échelle mondiale, et ce notamment depuis le développement de la version bilingue du site.
En 2014, second déménagement ; en parallèle la version anglaise du site a connu ses premiers pas. Intéressement, la montée progressive du trafic a exacerbée un nouveau problème, celui de la performance du côté de l’applicatif, qui se retrouvait désormais à gérer une base de données de manière assez complexe, ayant alors pour conséquence une nouvelle vague de lenteurs. Cela fut assez difficile à diagnostiquer, mais surtout améliorer de manière efficace, puisqu’à ce niveau, j’estimais le site optimisé au « mieux » de sa capacité (avec la compression des pages, en-têtes d’expiration, cache navigateur, cache objets, etc.). L’ajout d’un CDN a de beaucoup aidé, mais cela m’apparaissait quoi qu’il en soit comme une fausse solution, puisqu’optimiser le contenu en amont n’indique en rien la performance au niveau de l’applicatif lui-même. Ce fut donc un raccourci qui ne me plaisait guère.
Il y a quelques années, un saut majeur dans la performance a été la transition vers des disques SSD pour la base de données, ce qui a été super. La plupart des requêtes s’exécutèrent des lors plus rapidement, résultant alors en des temps de rendement beaucoup plus court, notamment pour la plupart des ressources « statiques ». Pour les requêtes dynamiques simples, là aussi, ce fut un avantage. Cependant, il subsistait toujours certaines latences, identifiées à plusieurs niveaux :
- Connexion entre le serveur web (Apache) et la base de données (MySQL).
- Mise en cache de certaines requêtes (MySQL).
- Gestion de la mémoire par les processus (Apache).
- Libération des processus et gestion des connexions (threads en Anglais).
Cela signifiait donc que les composants communiquaient bien entre eux, mais toujours avec certains goulots d’étranglement. Ceux qui travaillent avec des applicatifs savent qu’il n’existe rarement de solution miracle, et que c’est avant tout un processus très itératif. Il est en effet impossible de « copier-coller » une configuration et espérer qu’elle marchera. Au contraire, il faut la plupart du temps installer les outils permettant de surveiller le trafic (installation de sondes logicielles) à tout niveau de communication.
C’est un travail de fourmi et de patience. Mais également un travail poussant à prendre des décisions à chaque instant (choix de la technologie, investissement temps et argent, etc.). Bref, cela demande un peu de travail.
Le mois dernier, je me suis penché plus en détail sur la performance des sites et ce pour plusieurs raisons, l’une étant l’arrivée de la GDPR, nécessitant la revue et la refonte de certains composants, mais également le faible trafic sur notre plate-forme Q&A. C’est quelque chose que je pense potentiellement lié à la performance pour cet applicatif, qui est assez gourmand en ressources. L’une des conséquences de l’arrivée de la GRDP a été le besoin de sécuriser les transactions (via certificats SSL entre autres), ce qui m’a poussé à réévaluer la gestion des ressources au travers d’un réseau sécurisé. Après des mois de travail, de recherche, et de réflexion, j’ai décidé de migrer une nouvelle fois l’ensemble des sites (bien plus long et plus compliqué que la première migration 🙂 ) et ce pour les raisons suivantes :
- Besoin de plus de contrôle sur les logiciels et les applicatifs
- Besoin d’un déploiement rapide de versions de tests afin de mesurer la performance.
- Besoin d’unifier la gestion de tous les sites (6 sites Internet à maintenir à ce jour).
Je suis donc parti à la recherche de différents hébergeurs qui répondraient à mes besoins. J’ai décidé de déployer quelques sites pilotes chez un premier hébergeur qui ne m’a pas convenu (haute latence et mauvaise performance), puis un deuxième, avec une approche « devops » qui m’a bien plu. La philosophie « cloud » permet ici de gérer avec rapidité et flexibilité des instances (serveurs) et avoir accès à des environnement de développement sur demande. Cela s’éloigne donc du modèle traditionnel qui est demandeur en temps et argent. J’ai décidé de choisir un datacenter à New-York, permettant donc de délivrer du contenu un peu partout (dans mon cas, en Europe et aux États-Unis) sans que la performance n’en souffre (le CDN compense la latence sur le trafic entre les États-Unis et le continent européen)
Cela m’a permis donc de pousser un peu plus loin et expérimenter avec deux couches supplémentaires :
- Déploiement d’instances de données en mémoire (via Redis).
- Séparation entre les service pour la gestion des requêtes statiques et la gestion des requêtes dynamiques (Nginx et Apache).
- Mise en cache des requêtes vers la base de donnés (Memcached).
Ce travail fut très positif, car il m’a permit, dans un environement de production, surveiller en temps réel le trafic des différentes requêtes et identifier rapidement les fameux goulots d’étranglement que j’ai mentionné plus-haut.
Après avoir effectué plusieurs tests et comparer les environements, j’ai progressivement migré les sites (en partant du moins important au plus important en terme de visites). La transition s’est très bien passée. J’ai décelé quelques problèmes de routage pour les e-mails, mais rien de bien compliqué.
Alors… avec tout cela, depuis Samedi, tous les sites ont été migrés vers la nouvelle infrastructure. Je suis assez content du résultat, en croisant les doigts pour que tout tourne 🙂
Il reste encore un peu de travail à effectuer. Pour les plus curieux d’entre vous, j’ai encore quelques idées :
- Essayer de précharger certaines ressources en tâche de fond. Par exemple, lorsqu’un visiteur survole un lien, le cacher en mémoire, et ce de manière transparente pour le visiteur. En cliquant sur le lien, la page est déjà chargée, il n’y a plus besoin d’effectuer l’ensemble de requêtes réseaux.
- Cacher des fragments de requêtes dynamiques. Les requêtes dynamiques sont souvent les plus gourmandes, et ce parce que le serveur (la base de données principalement) doit construire une requête, par définition dynamique, et servir les résultats, absents du cache. Cela explique pourquoi, par exemple, il est toujours plus rapide de lire une page sur un site que d’effectuer une recherche.
- Utilisation de conteneurs (Docker entre autres) pour certaines parties de l’infrastructure. Cela permettrait de réduire la latence puisque la couche de virtualisation diminue en taille.
Voilà tout. Les sites sont bien plus rapides, et plus faciles à gérer, puisque de mon côté, il est désormais plus « simple » (paradoxalement) de localiser les problèmes de performance. Je vais surveiller tout ça au fil des mois et appliquer les correctifs nécessaires si besoin. En espérant que les détails techniques vous aient plus. N’hésitez-pas à laisser vos commentaires pour la moindre question, je me ferais un plaisir d’y répondre.
Bonne navigation !
