IX. Le cache d'abord ! (Posez vos questions plus tard)

"Il me semble que tout va bien. Avez-vous essayé de vider votre cache ?" - Votre concepteur de sites web, il y a cinq minutes.

En 2009, en raison d'un oubli contractuel, Made Media s'est vu confier la responsabilité d'héberger un site web complémentaire pour l'une des émissions de télévision les plus populaires du Royaume-Uni. En fait, ce site web était le plus populaire de Channel 4 au Royaume-Uni, en partie parce que l'émission avait pris l'habitude de diriger les gens vers le site web et de les alimenter en retour, en direct à l'antenne. Nous pouvons témoigner du trafic généré lorsqu'un médecin populaire de la télévision, à une heure de grande écoute, pointe vers une page web présentant une galerie de certaines parties du corps, et suggère que vous pourriez vouloir aller en ligne pour vous comparer. Le graphique de la bande passante doit multiplier par 10 son axe d'échelle en une seconde. Le centre de données vous appelle pour savoir ce qui se passe.

C'était un serveur très puissant. Il disposait probablement d'une puissance de traitement équivalente à celle de votre téléphone aujourd'hui.

À l'époque, nous n'en étions qu'à nos premiers pas dans les services Web d'Amazon. Nous disposions cependant d'un rack de serveurs web dans un centre de données à Manchester. Nous pouvions dédier l'un d'entre eux à ce site web. C'était un serveur très puissant. Il avait probablement presque autant de puissance de traitement que votre téléphone aujourd'hui. Il n'y avait pas de test de charge. Il n'y avait pas de plan de sauvegarde.

Je ne sais pas ce que nous pensions faire, peut-être jeter de l'eau sur le serveur s'il prenait feu.

Nous avons donc lu quelques articles sur la manière de résister à une attaque par déni de service. Le numéro un de la liste était l'utilisation d'un Reverse Proxy Cache. L'outil Open Source que tout le monde recommandait s'appelait Varnish. Nous l'avons installé, avons optimisé la configuration du serveur web et avons croisé les doigts. En fait, deux d'entre nous ont roulé sur la M6 jusqu'à Manchester. Je ne sais pas ce que nous pensions faire, peut-être jeter de l'eau sur le serveur s'il prenait feu.

Le site web fonctionnait parfaitement sur ce seul serveur, grâce à la magie de la mise en cache. À l'heure de l'informatique en nuage et de la mise à l'échelle horizontale des applications, la mise en cache peut être négligée, mais elle reste essentielle pour que les sites web restent opérationnels.

En réalité, la plupart des pages web ne changent pas beaucoup. Et lorsqu'elles changent, c'est souvent dans des délais prévisibles. Même si vous ne pouvez mettre en cache les informations d'une page que pendant une seconde, cela reste énorme lorsque vous recevez plus de 2 000 requêtes par seconde, comme, par exemple, au milieu d'une vente en ligne d'Ed Sheeran.

La plupart des ressources web peuvent être mises en cache, qu'il s'agisse d'une page d'accueil, d'un bouton de mise en vente, d'un flux de disponibilité des places, d'un morceau de javascript ou d'un calendrier de spectacles. Vous pouvez contrôler très précisément la date d'expiration d'un cache, que ce soit en spécifiant "ce contenu est valable pendant 60 secondes" ou "ce statut expire à 10 heures exactement, lorsque cet événement sera mis en vente". En fait, la mise en cache HTTP est au cœur de l'infrastructure de l'internet. Les réseaux de diffusion de contenu tant vantés ne sont en fait qu'un réseau de serveurs de mise en cache à proxy inverse, comme Varnish. Le problème, c'est que si la plupart des développeurs web ont une connaissance raisonnable de la mise en cache HTTP, ils ne font pas souvent le nécessaire pour s'assurer qu'elle fonctionne vraiment comme prévu, parce que c'est un peu difficile.

Nous intégrons les considérations relatives à la mise en cache dans l'architecture de l'application, plutôt que de les ajouter à la fin.

La pire chose que vous puissiez faire, si vous êtes responsable d'une application à forte demande, est de fusionner votre contenu à forte capacité de mise en cache (comme la disponibilité des performances) avec votre contenu difficile à mettre en cache (comme les données personnelles d'un utilisateur). L'association de ces préoccupations commerciales a pour effet secondaire de rendre l'ensemble de l'application en grande partie impossible à mettre en cache. Dans ce cas, peu importe la fantaisie de votre architecture horizontale, car nous avons déjà démontré que la mise en cache peut apporter des avantages en termes de performances d'un facteur d'au moins 2 000. Même si votre cloud peut évoluer aussi rapidement en une seconde (spoiler - ce n'est pas le cas), vous paierez le prix fort pour cela.

C'est pourquoi, chez Made Media , nous intégrons les considérations relatives à la mise en cache dans l'architecture de l'application, plutôt que d'ajouter la mise en cache à la fin. Cela rend le développement plus difficile, mais si le cache casse le code, cela signifie qu'il faut le repenser. C'est ce que nous entendons par "cache d'abord, questions ensuite".

Lecture obligatoire

• Varnish est un reverse proxy HTTP avec mise en cache.
• Fastly est un réseau de diffusion de contenu (CDN).