There are only two hard things in Computer Science: cache invalidation and naming things
— Phil Karlton, 1997
« Ça marche de mon côté. Vous avez essayé de vider votre cache ? » — Votre webdesigner, il y a cinq minutes.
En 2009, suite à un oubli contractuel, Made Media s’est retrouvée responsable de l’hébergement d’un site compagnon pour l’une des émissions les plus populaires de la télévision britannique. Un site qui était, de fait, le plus fréquenté de Channel 4 au Royaume-Uni — en partie parce que l’émission avait pris l’habitude de renvoyer les téléspectateurs vers le site en direct, et d’en exploiter les retours à l’antenne. On peut témoigner de ce que ça donne niveau trafic quand un médecin télé très suivi, en prime time, pointe vers une page avec une galerie de certaines parties du corps et suggère aux spectateurs d’aller se comparer en ligne. Le graphique de bande passante doit multiplier son échelle par 10 en une seconde. Le datacenter vous appelle pour savoir ce qui se passe.
C’était un sacré serveur. Il avait probablement presque autant de puissance de calcul que votre téléphone aujourd’hui.
À l’époque, on commençait tout juste à tâter Amazon Web Services. Ce qu’on avait, en revanche, c’était une baie de serveurs web dans un datacenter à Manchester. On pouvait en dédier un à ce site. C’était un sacré serveur. Il avait probablement presque autant de puissance de calcul que votre téléphone aujourd’hui. Pas de test de charge. Pas de plan B.
Je ne sais pas ce qu’on pensait faire là-bas — peut-être arroser le serveur s’il prenait feu.
Ce qu’on a fait, c’est lire des articles sur comment résister à une attaque par déni de service. Et en tête de liste : utiliser un reverse proxy cache. Celui que tout le monde recommandait, en open source, s’appelait Varnish. On l’a installé, on a optimisé la configuration du serveur web, et on a croisé les doigts. Enfin — deux d’entre nous ont pris la M6 jusqu’à Manchester. Je ne sais pas ce qu’on pensait faire là-bas, peut-être arroser le serveur s’il prenait feu.
Le site a tenu sans broncher sur ce seul serveur, grâce à la magie du cache. À l’heure du cloud et des architectures élastiques, le cache est souvent relégué au second plan — il reste pourtant indispensable au bon fonctionnement des sites web.
La réalité, c’est que la plupart des pages web ne changent pas tant que ça. Et quand elles changent, c’est souvent dans des plages horaires prévisibles. Même si vous ne pouvez mettre en cache le contenu d’une page qu’une seconde, c’est déjà énorme quand vous traitez plus de 2 000 requêtes par seconde — comme, par exemple, en pleine ouverture des ventes d’un concert d’Ed Sheeran.
La plupart des ressources web sont tout à fait cachables : une page d’accueil, un bouton de mise en vente, un flux de disponibilité des places, un fichier javascript, un calendrier de spectacles. Et vous pouvez contrôler très précisément l’expiration du cache — en indiquant « ce contenu est valable 60 secondes » ou « ce statut expire à 10h pile, quand cet événement sera mis en vente ». Le cache HTTP est en fait au cœur même de l’infrastructure d’internet. Les fameux CDN ne sont, au fond, qu’un réseau de serveurs de reverse proxy cache, comme Varnish. Le problème, c’est que si la plupart des développeurs web maîtrisent correctement le cache HTTP, ils ne prennent pas toujours la peine de vérifier qu’il fonctionne vraiment comme prévu — parce que c’est fastidieux.
Nous intégrons les considérations de cache dans l’architecture applicative, plutôt que de les greffer à la fin.
La pire chose à faire, si vous gérez une application à forte demande, c’est de mélanger votre contenu très cachable (comme la disponibilité des spectacles) avec votre contenu difficile à mettre en cache (comme les données personnelles d’un utilisateur). Lier ces deux logiques métier a pour effet de rendre l’ensemble de votre application quasiment impossible à cacher. Peu importe la sophistication de votre architecture élastique dans ce cas, puisqu’on vient de démontrer que le cache peut apporter un gain de performance d’un facteur d’au moins 2 000. Même si votre cloud peut scaler aussi vite en une seconde (spoiler : non), vous le paierez très cher.
Chez Made Media, nous intégrons donc les considérations de cache dans l’architecture applicative, plutôt que de les greffer à la fin. Ça complique le développement — mais si le cache casse le code, c’est que le code doit être repensé. C’est ça, le cache d’abord, on verra ensuite.