Retour varnish summit

varnish-cache

Ce jeudi 16 octobre se tenait le Varnish summit à Paris, essentiellement pour présenter la version 4 du produit et des nouveau produit pour la version payante de la société Varnish Software. C’était l’occasion aussi de retours d’expérience, notamment celle de CDiscount que je met en premier parce que susceptible d’intéresser plus de monde que le reste du petit résumé que voici:

CDiscount et le SEO
CDiscount fait environ 1M de VU/jour
5000 requêtes/s
Du *3 avant noël, du *5 le 1er janvier
Ils sont passé de Akamai (2008/50000 objets en cache) puis Netscaler (2011/500000 objets en cache) et enfin Varnish (2013/10M d’objets en cache).
Ils ont toujours un CDN externe pour les éléments statiques.
Le passage à du cache en interne a été fait suite à la demande du service SEO d’augmenter le nombre de pages cachées pour que les bots Google puissent accéder aux pages rapidement et ainsi favoriser le référencement.
Ils auraient environ 15M de pages sur le site, mais le SEO veut s’assurer que certaines pages (8M) soient servies très rapidement à Google (produits clés).
Pour ça, ils ont développé leur propre bot en interne, qui parse les sitemaps et chauffe le cache Varnish toutes les nuits. Ils sont donc certains que les 8M de pages clés sont déjà dans le cache et que les bots y accèderont rapidement. Ils vont même jusqu’à changer le TTL du cache des pages en fonction du user-agent ( ce serait probablement mal vu par Google…), ils préfèrent que Google récupère les pages en cache, même si pas à jour (en général seul le prix est succeptible de changer), plutôt que d’aller la récupérer sur les backends. Les 301 sont également cachées.
Idem que SFR, ils centralisent les logs d’accès et les analysent a posteriori, le SEO peut donc savoir quand et à quelle fréquence les pages sont crawlées.

Au niveau architecture, ils sont présents dans 2 DC, 3 varnish ( 12 coeurs, 128Go) dans chaque DC. Leur load balancer font un hash des urls et chaque url a son varnish. Aucune redondance de cache donc, mais ils considèrent leur matériel et varnish suffisament stable pour se le permettre, ça leur permet en contrepartie d’avoir plus de 300Go de cache par DC. Leur hit ratio n’est cependant pas forcément énorme, 40%, ils disent que ça s’explique par le fait qu’ils font beaucoup d’A/B testing. CPU des varnish très très peu utilisé.
Ils disent avoir gagné énormément grace à l’optimisation du cache pour le crawl, le meilleur référencement les ayant fait abandonner l’achat de mots clé.
Ils ont en cours de passage à Varnish 4, leur premier tests sont concluant, meilleurs temps de réponse sur pages non présentes dans le cache

CDN SFR
Moyennement intéressant.
SFR a développé son propre CDN pour ses besoins internes. Ils veulent que les données soient accessibles le plus rapidement possible donc au plus près de leurs clients.
Ils ont pour ça l’avantage d’avoir des points de présence un peu partout en France. Leur CDN est donc composés de 12 points de présence ( dont un à Rennes, 4 en région parisienne). Dans chaque POP, des serveurs (Cisco) varnish avec 128Go et du stockage Netapp pour les videos notamment (VOD)
Depuis, ils commercialisent aussi leur CDN. Les clients ont accès à un BO qui leur permet de modifier les confs. Des templates de VCL sont utilisés et envoyés sur chacun des Varnish du CDN en live.
Les seules limites qu’il ont eu ont été des limites matérielles. Ils n’ont jamais atteint aucun limite de Varnish et ont été agréablement surpris de voir la charge qui pouvait être supportée lors de pics (mise à jour de toutes leurs box une nuit par erreur, tout s’est bien passé sans avoir planifié quoique ce soit).
Ils centralisent les logs d’accès via varnish-ncsa qui leur sort des logs type Apache. Les logs sont analysées avec Analog (http://www.debianhelp.co.uk/analog.htm).
Des statistiques temps réels sont disponible, utilisation de Redis pour les stocker.

Varnish 4.xx
4.0 Sortie en avril dernier, la version 4.0.2 est sortie le 8 octobre dernier, considéré comme étant plus solide que les précédentes, beaucoup de bugs corrigés, notamment des fuites de mémoires lors de l’utilisation des ESI.
Fonctionnement interne modifié, utilisation de threads différents pour la partie backend (quand varnish va chercher les objets) et la partie receiver (le frontend). Varnish peut donc continuer à servir les clients pendant qu’il va interroger les backends. Cette modification change la façon d’écrire le VCL mais augmente les performances et a été faite en gardant à l’esprit l’arrivée de HTTP/2.0 qui utilisera les connexions multiplexées (un client = plusieurs requêtes simultanées).
La partie définition des backends est désormais présente sous forme de vmods. Ce qui permet éventuellement d’avoir des backends dynamiques ( un nouveau vmod peut être créé, interrogeant par exemple une base externe). Un cluster peut devenir vraiment dynamique en ajoutant/supprimant des serveurs sans avoir à modifier la configuraion de varnish.
Beaucoup de changement au niveau des logs, qui permmettent maintenant de tracer facilement toutes les requêtes d’un client, les données sont bien mieux organisées à l’affichage. Un language de requêtes à été ajouté pour filtrer aisément les logs.
L’utilisation de varnish pour le streaming est fonctionelle maintenant, ce qui n’était pas le cas dans la 3…
La 3 devrait être supportée pendant 18 mois encore environ.

Pour la suite:

L’implémentation de HTTP/2.0 devrait arriver en 2015 même si il ne sont pas très chaud, maintenant que le https n’est plus obligatoire dans les spécifications, ça les dérange un peu moins. Ils font un parallèle avec IPv6 qui doit arriver depuis 15 ans et qui n’a toujours pas un déploiement massif, à la différence que pour HTTP/2.0 les choses peuvent changer plus vite ( les navigateurs majeurs l’ont ou vont l’implémnter vite et gros acteurs du web pousssent pour).
Pour la partie SSL/TLS, ils ne veulent pas prendre le risque d’utiliser une bibliothèque existante car aucun n’est suffisament bonne et ne veulent pas prendre le risque d’implémenter la crypto. Ils envisagent juste d’implémenter une sorte de proxy pour que les frontends ssl puisse communiquer avec Varnish de façon plus performante. Actuellement, beaucoup de retrouve avec des solutions Nginx(TLS) -> Varnish -> Apache/Nginx, il faudra continuer à faire avec apparemment.

Nouveaux produits Varnish Plus
Présentation de 3 nouveaux produits faisant partie de la suite « plus » donc payante:
*Varnish Tuner, un petit outil qui permet d’analyser l’utilisation faite des ressources du système et, après avoir posé quelques questions, donne des conseils pratique pour l’optimisation (paramétrage kernel + varnish)
*Massive storage backend: un backend de storage de cache fichier, optimisé pour les gros volumes de données et les grosses données (vidéo)
*High Availability Varnish: réplication des caches entre deux serveurs, peut-être utilisé sur plus de 2 deux mais pas vraiment conseillé en l’état actuel. La réplication peut probablement être faite autrement sans avoir besoin de ça.

 

 

Vous aimerez aussi...

4 réponses

  1. un terrien dit :

    A propos du storage, est-ce que il y a moyen de répartir le volume ? Aussi est-ce qu’on peut configurer du Redis en backend ?

    Sinon, concernant le get à l’origine, ça a été évoqué ?

  2. neveu dit :

    Pour le storage si tu parles de celui présenté, je ne pense pas non, par contre tu peux avoir plusieurs storages, en ram ou fichier. Et pour Redis non. Tu peux avoir du redis sous forme de module mais c’est plutôt pour stocker retrouver des petites données, pour des stats ou pour récuperer des autorisations d’accès à des objets par exemple (cas des paywall).
    Pour le get a l’origin, non, mais on a prévu de retester pour voir si on ne peut vraiment pas avoir le comportement qu’on voudrait.

  3. dam75 dit :

    Super intéressant, merci Yann 🙂 notamment le cas de Cdiscount … vous comprenez pourquoi il est primordial d’avoir de la perf hors varnish / Akamai : on n’est jamais sûrs qu’une page soit cachée 😉

    Ceci étant, il faudrait réfléchir, car ce qu’ils font pour le SEO est loin d’être idiot (s’assurer que toutes les pages dont on veut que Google les crawle soient cachées) : même en gardant un CDN externe (j’ai pas vraiment compris le lien …) il suffirait de crawler les pages du sitemap souvent, pour obliger le CDN ou Varnish à les garder en cache 😉

  4. Sylvain dit :

    Merci pour le résumé 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *