Comment nous sommes passés sur TF1, vu par Kévin de l’équipe technique
"Le site doit rester accessible, coûte que coûte !"
Le 5 mars 2018, Epopia est passé au JT de 20h sur TF1. Il s’agit d’un grand événement pour toute l’équipe, avec des retombées potentielles importantes. En effet, le JT de 20h est l’un des programmes les plus regardés en France et ce soir-là, 5,38 millions de téléspectateurs* étaient devant leur écran.
Epopia transmet le plaisir de la lecture et de l’écriture aux enfants de 5 à 10 ans. Découvrez ce jeu littéraire qui a déjà fait lire et écrire avec passion plusieurs dizaines de milliers d’enfants dans le monde entier !
Je découvre le concept !L'interview de Kevin !
Afin que que tout se déroule au mieux, notre site web devait évidemment rester accessible durant la diffusion du reportage sur TF1 et les heures qui suivent. Mais, la tâche se complique lorsque des milliers d’internautes tentent de se connecter au même moment à Epopia. Il s’agit d’un phénomène bien connu des administrateurs systèmes. Lorsque le trafic augmente suite à un passage télé, ou à la publication d’un article dans un grand média, le site est noyé sous les requêtes et ne répond plus. Il est incapable de soutenir la charge. Ou comment rater une occasion en or… Dès la fin du tournage, le compte à rebours commence. En guise d’au revoir, le journaliste nous lance : « J’ai déjà fait tomber huit sites, est-ce que vous serez les prochains ?». Défi accepté !
Présentation de notre infrastructure avant TF1
Un mois a suffit pour préparer le passage d’Epopia sur TF1. Jusqu’ici, nous n’éprouvions pas le besoin d’étudier la question des performances de notre infrastructure technique. En effet, notre trafic est relativement modeste tout au long de l’année avec un gros pic durant la période de Noël.
Nos serveurs
À ce moment-là, l’infrastructure d’Epopia fonctionnait de manière simple : un serveur physique, hébergé dans un centre de données en France, suffisant pour nos besoins, bien que cela comporte un risque. Il suffit d’un problème sur ce serveur et c’est la coupure de service. On peut avoir des tonnes de problèmes avec un serveur comme celui-ci. Le plus courant, c’est une panne matérielle, autrement dit un composant qui ne fonctionne plus. Mais il existe d’autres possibilités : une coupure d’électricité ou de réseau dans le centre de données par exemple. Par chance, ces deux événements sont très rares car les gestionnaires de ces datacenters font le maximum pour les éviter et minimiser leur impact.
La stratégie la plus courante, mais également la plus efficace, c’est la redondance. À défaut d’avoir une ligne électrique unique, on en compte deux, voire plus. Ainsi, en cas de coupure sur une ligne, la seconde peut prendre la relève. Malheureusement, aucun système n’est fiable à 100%. Nous en avons fait l’expérience en novembre dernier, lorsque tous les systèmes de redondance ont défailli au même moment, dans un centre de données de notre hébergeur. Cela a causé l’arrêt complet de tous les serveurs y étant hébergés pendant plusieurs heures.
L’architecture de l’application
Du côté de l’application, l’architecture est très classique. Elle est constituée d’un serveur web pour répondre aux requêtes et servir les fichiers statiques tels que les images, d’un serveur applicatif pour réaliser toutes les opérations que l’on peut faire sur notre site, ainsi que d’une base de données pour enregistrer toutes les informations nécessaires au bon fonctionnement de notre service.
Sur ce point-là, nous réalisons que nous sommes également fragiles. L’architecture d’une application est constituée de trois tiers : le serveur web qui relie le client à notre service, le serveur applicatif qui représente le cœur du service d’Epopia, et enfin d’une base de données. Ces trois tiers de l’application sont très liés les uns aux autres. Lorsqu’un problème se produit, peu importe s’il est localisé dans un seul des tiers, cela a pour conséquence de faire tomber tout l’ensemble.
On peut constater que nous avions donc beaucoup de travail afin d’être prêts pour notre passage sur TF1, et très peu de temps pour le faire. Mais nous sommes tout de même chanceux, car généralement on apprend qu’on va passer à la télévision le jour même !
Opération : prévenir les pannes !
Au lendemain de la nouvelle de notre passage sur TF1, c’est parti pour renforcer notre infrastructure. Mais attention ! Nous ne pouvions pas nous permettre de couper le site pendant des heures afin d’effectuer nos changements; il faut donc être méthodique pour minimiser l’impact sur la production.
Première étape
Augmenter le nombre de serveurs. Nous passons de 1 à 3 serveurs. Pour minimiser les risques, chacun d’entre eux est dans un centre de données différent. De cette façon, on répartit les risques de pannes et on multiplie par 3 la puissance de calcul; ce qui nous permettra de répondre à plus de requêtes simultanément. Effectivement, ce que les visiteurs détestent le plus, après la non-disponibilité pure et simple d’un site, c’est qu’il soit lent.
Deuxième étape
Répartir la charge. Nous possédons 3 serveurs prêts à répondre aux requêtes des visiteurs, mais nous devons maintenant faire en sorte que ces visiteurs puissent retrouver nos serveurs.
Pour cela, il faut comprendre ce qu’il se passe quand on accède à une page web, par exemple le site d’Epopia. Chaque serveur sur Internet dispose d’une adresse, permettant de le localiser sur le réseau et de communiquer avec lui. Cependant, ces adresses sont difficiles à mémoriser, c’est pourquoi nous utilisons ce qu’on appelle un nom de domaine, en l’occurrence ici il s’agit de www.epopia.com. Lorsqu’on tente d’accéder à la page web, le navigateur va effectuer une recherche, pour trouver l’adresse du serveur qui se cache derrière le nom de domaine. Avec cette adresse, il va ensuite contacter le serveur et lui demander la page web. En retour, le serveur va répondre en envoyant le contenu de la page.
Tout cela ne peut fonctionner qu’à condition qu’on ait qu’un seul et unique serveur. Dans notre cas, il y en a trois.
Alors, comment dire au navigateur de s’adresser à l’un plutôt qu’à l’autre ?
La solution, c’est d’ajouter un intermédiaire entre le navigateur et les trois serveurs, appelé « répartiteur de charge ». Son rôle est de recevoir les requêtes des visiteurs, puis de les rediriger vers l’un des serveurs. Il agit un peu comme un concierge en bas d’un immeuble qui accueille les visiteurs. Grâce à la position privilégiée du répartiteur de charge, on peut aller encore plus loin. Le répartiteur de charge est averti si un serveur est occupé, étant donné que c’est lui qui contrôle le trafic. Ainsi, il va choisir le serveur qui est le plus disponible, afin que la requête reçoive une réponse le plus rapidement possible. Le répartiteur de charges sait également si un serveur trime à faire son travail; dans ce cas, il va tout simplement arrêter de lui envoyer des visiteurs. Via ce système, on peut facilement s’adapter et ajouter ou supprimer des serveurs supplémentaires, afin de réduire les coûts lorsque le volume de trafic faiblit.
Troisième étape
Externaliser les fichiers statiques. Sur un site web, les éléments les plus lourds et donc les plus coûteux en ressources sont les éléments statiques comme les images, les vidéos, etc… La solution consiste à ne plus s’en occuper par nous-mêmes. Nous redirigeons toutes les requêtes pour ces fichiers vers des serveurs spécialisés, gérés par notre hébergeur. Cela comporte plusieurs avantages : cela décharge nos propres serveurs et améliore aussi le temps de chargement du site.
Le Jour J du passage sur TF1
Après un mois intense de préparation, le moment de révélation est enfin arrivé ! Nous allons enfin savoir si nous pouvons tenir le coup en passant sur TF1.
En moyenne, nos serveurs gèrent environ 800 requêtes par minute.
20h28 : début du reportage sur TF1, les courbes commencent à monter.
20h35 : le pic est atteint. Nos serveurs reçoivent entre 8000 et 10 000 requêtes par minute sur une période de 5 minutes environ.
Le trafic reste ensuite important toute la soirée, bien qu’il soit plus faible que celui observé lors du pic. Dans nos outils de statistiques, on compte jusqu’à 4000 visiteurs simultanés sur le site. À notre échelle, ce sont des chiffres impressionnants, et nos serveurs ont tenu le coup ! Aucune coupure de service, pas de ralentissement. Mission accomplie avec brio !
Grâce aux changements effectués dans notre infrastructure technique, nous avons pu survivre à une augmentation soudaine de trafic sans le moindre problème. Mais ce n’est qu’une première étape. Nous avons de grandes ambitions et après ce baptême du feu, nous pouvons être confiants pour la suite. La souplesse du système nous permettra de réagir rapidement en cas de besoin.
Epopia fait lire et écrire les enfants du CP au CM2, à travers des aventures par correspondance postale, dont ils sont les héros ! Partagez le goût de l’écriture et de la lecture avec votre enfant et vivez ensemble une histoire formidable !
Je découvre Epopia !Plus d'articles sur le projet Epopia !
Rechercher un article
Concept original, unique et innovant, Epopia insuffle le plaisir de la lecture et de l'écriture aux 5 - 10 ans ! Découvrez ce jeu littéraire qui fait lire, écrire et progresser les enfants du CP au CM2 tout en stimulant leur créativité !
Découvrir le concept !
Je suis enseignant(e), je découvre l'offre école !
Je suis parent, je découvre le concept !Je suis enseignant(e), je découvre l'offre école !
No comment yet, add your voice below!