Décharger les serveurs Web des contenus statiques
Mise en place d’Akamai pour mettre en cache environ 90 % des objets près des utilisateurs et soulager les serveurs physiques d’origine.
~90% des objets en cache près des utilisateursLire le récit du projet
Le point de départ
En 2008, les serveurs Web étaient physiques, derrière un seul load balancer. Aucun cache : les requêtes statiques allaient directement aux serveurs. Comme fournisseur météo, nous subissions d’immenses variations. Selon la météo et les grands événements, certains jours atteignaient vingt fois le trafic habituel, une montée comparable à celle du Black Friday pour un commerçant. Il nous fallait absorber ces pics.
Le goulot d’étranglement
À fort débit de requêtes, les sockets disponibles devenaient la limite. Le site pouvait ne plus répondre, alors qu’une grande partie de la demande concernait des contenus que l’origine n’avait pas besoin de servir à répétition.
Le changement
Avec Akamai, environ 90 % des objets étaient cachés près des utilisateurs. Seules quelque 10 % des requêtes arrivaient encore à l’origine, soit environ 90 % de délestage. Cela nous a même permis de réduire la ferme de serveurs Web.
Davantage de marge de manœuvre
Les jours chargés, prolonger la durée de cache des contenus adaptés réduisait encore la charge d’origine. Il fallait choisir où cette durée plus longue était acceptable, plutôt qu’appliquer le même réglage partout.
La leçon : servir les contenus répétitifs près des utilisateurs et considérer le cache comme un levier d’exploitation, pas seulement de performance. Résumé d’un projet historique ; les identifiants d’infrastructure et détails internes sont volontairement omis.


cloud / systèmes