Les dessous de SensCritique
Nous vous l’annoncions dans notre dernier post Medium, nous allons prendre plus régulièrement la parole pour vous tenir informés des évolutions du site.
Aujourd’hui, c’est moi Thibaut (nouveau CTO) qui vais vous décrire plus en profondeur ce qu’est la technique à SensCritique, pourquoi nous rencontrons quelques problèmes, comment ils nous impactent, et surtout comment on les corrige.
L’équipe technique s’est récemment agrandie, elle est composée de :
- Trois développeurs full-stack
- Un devOps
- Un data-scientist
- Un développeur data
- Un designer
- Un CTO
J’ai rejoint l’équipe en tant que CTO le 1er avril en pleine refonte du site.
Après avoir effectué un état des lieux de la technique, nous avons dû nous rendre à l’évidence : nous devions changer nos process et nous industrialiser.
Le legacy
Chaque entreprise a son “Legacy” : son code source un peu dépassé qui a rendu de bons et loyaux services mais qui vieillit mal avec l’âge.
Investiguer des bugs sur du Legacy c’est un peu comme tenter de réparer le moteur d’un bateau de pêche quand on est formé à réparer des moteurs de voitures. Parfois on s’y retrouve, parfois pas ! Alors on analyse, on cherche, on corrige, puis on découvre de nouvelles choses, des bonnes et des moins bonnes… (mais souvent des moins bonnes, qu’on se le dise)
Depuis deux mois, nous nous efforçons de revoir notre façon de travailler, on arrête de panser les bugs, on évite “les corrections à l’arrache” pour vraiment se focaliser sur la source de nos problèmes dans le but d’apporter une solution pérenne.
When you solve a problem, you have a solution you have to maintain. When you eliminate a problem you don’t even have to think about it because the problem no longer exists. Source
La face cachée de l’iceberg
Du point de vue d’un utilisateur, on pourrait se dire que SensCritique n’est qu’un site web lambda. Un bon vieux serveur qui tourne dans un coin qui fait le job. C’est en réalité un peu plus complexe que ça en a l’air.
La forte affluence du site a nécessité quelques modifications côté infrastructure pour supporter les pics de fréquentation, ça passe notamment par la mise en place de :
- Répartiteur de charge type HAProxy (LoadBalancing).
- Réplication SQL pour une meilleur répartition des tâches sur la base de données
- Un système de cache (Redis) avec réplication
Des technologies utilisées dans énormément d’entreprises et donc rien d’exceptionnel.
Mais pourquoi SC continue régulièrement de planter alors ???
Tout simplement parce qu’en plus du fameux Legacy qui vieillit mal, certaines technologies mises en place n’étaient pas ou peu maîtrisées. Les technos ont changé avec le temps, les équipes et les compétences aussi. Ainsi nous avons dû nous concerter pour prioriser les différents chantiers en cours, notamment la refonte du site ainsi qu’une harmonisation de l’infrastructure. Et pour y arriver nous devons parfois causer des interruptions de service.
Vous nous avez remonté de nombreux bugs et c’est grâce à ces informations et au travail de chacun que nous arriverons à proposer un site plus performant et plus agréable. Encore merci !
Pour vous permettre de mieux comprendre ce qu’il se passe, revenons sur trois bugs fréquents et voyons ce que ça implique de notre côté et comment on les traite au quotidien.
Les lenteurs du site
Bien que nous disposions de répartiteurs de charge, il arrive parfois que le site soit lent. Les lenteurs peuvent survenir pendant un pic de fréquentation ou non, c’est assez aléatoire. L’une des raisons principales de ces ralentissements est que notre infrastructure est mal dimensionnée et mal organisée. Notre système de cache (redis) contient des clés (comprendre par là des “enregistrements”) mal formatées ou régénérées bien trop souvent à la volée. Ce qui implique de devoir “recalculer” une requête alors qu’elle devrait être mise en cache et être instantanée. Quand un pic de fréquentation se fait ressentir, le système de cache est saturé et chaque requête prend plus de temps que prévu.
En plus du système de cache qui peut être saturé et qui peut tomber à tout moment, la base de données est elle aussi un “SPOF — Single Point Of Failure” (point de rupture), si celle-ci supporte trop de requêtes en provenance de plusieurs programmes (c’est notre cas), elle peut arriver à saturation.
Afin d’éviter ce type de problème, nous repassons sur chaque service, chaque programme afin de vérifier l’intégrité, la pertinence et la stabilité de celui-ci et comme vous pouvez vous en douter, ça prend du temps…
Données en retard, modifications non affichées etc.
Régulièrement il arrive que le site affiche des données antérieures ou que certaines modifications (de listes, d’information perso ou autre) ne soient pas prises en compte.
Ce désagrément est lié à un problème de synchronisation de notre base de données. Le principe est assez simple, une base de données “master” (principale) se charge de synchroniser toutes demandes de modifications à une autre base de données “slave” (secondaire).
Voyons comment cela se passe en temps normal :
Quand un utilisateur demande à voir la note d’un produit (film/série ou autre), le code redirige la requête vers SQL Slave uniquement si c’est une requête de lecture. SQL Master se charge lui de traiter les requêtes de lecture et d’écriture.
Voyons maintenant comment ça se passe quand un autre de nos programmes (en python pour l’exemple) tente d’écrire sur SQL Slave en ayant des droits super utilisateur :
Malgré le fait que notre base de données secondaire soit accessible en lecture uniquement, elle reste accessible en écriture pour tous les super utilisateurs. Quand une demande d’écriture est effectuée sur SQL Slave en tant que super utilisateur, la synchronisation entre Master<>Slave ne peut plus se faire étant donné que les deux bases de données ont des structures différentes.
La synchronisation étant bloquée, l’état de la base de données SQL Slave se fige et si personne n’intervient pour débloquer la situation les données affichées sur le site seront récupérées depuis SQL Slave avec un retard de plus en plus conséquent.
Une fois le problème bien ciblé il est assez simple de s’en prémunir en forçant l’utilisation d’utilisateur “lambda” (pas de super utilisateur) et en faisant attention à ce que la base SQL Slave soit bien en read-only.
Programme TV H.S
Pendant très longtemps le programme TV a été indisponible sur le site. La raison ? Un de nos serveurs a subi un incident en décembre dernier, toutes les données du serveur ont été perdues, notamment celle du programme TV.
Bien évidemment nous avons le code source de nos programmes… mais ça serait quand même vachement plus drôle si le code source du programme TV n’était pas le même en production que sur GitHub…
Conclusion
C’est la première fois que l’on évoque avec précision les problèmes techniques du site. Nous avons volontairement vulgarisé cet article pour qu’il soit le plus accessible possible mais n’hésitez pas à nous faire vos retours, à nous dire si vous préférez que ce soit un peu moins technique ou à l’inverse, beaucoup plus (coucou les devs, devops etc. 👋🏻)
Nous reparlerons bientôt de tech’ pour vous annoncer les grosses modifications que nous avons apportées pour la refonte du site, notamment le choix des technos (côté code et infrastructure) et les nouveaux process (intégration et déploiement continu).
