Sortie de Varnish 4
Après deux Technological Previews et une beta, Varnish est finalement sorti en version 4. C'est à l'occasion du premier Varnish Summit que Per Buer, CTO de Varnish Software, l'a annoncé.
Cette première édition du Varnish Summit s'est tenue à Londres le 10 avril dernier. Pendant une demi-journée, plusieurs intervenants sont venus donner des présentations à propos de Varnish Cache et Varnish Plus (l'offre commerciale de Varnish Software). A noter qu'une des présentations ne parlait d'aucun des deux.
Attendu initialement pour l'été 2013, Varnish 4 arrive en grande pompe avec son lot de nouveautés.
13h - Introduction par Steve Raby
Après un déjeuner networking, Steve a rapidement présenté Varnish Software et le déroulement du Varnish Summit.
Les visiteurs ont reçu un chargeur portable et ont pu assister à un mélange de présentations techniques et commerciales.
13h15 - Roadmap for 2014-2015 par Per Buer
Per part du constat que le traffic web a explosé pendant cette dernière décennie, et que tout laisse penser que cela va continuer pour la suivante. Les CDN (Content Delivery Network) sont devenus une commodité. Il est facile aujourd'hui d'en créer un, en moins d'une journée, en provisionnant des machines chez Amazon par exemple.
Il prédit qu'Akamai, leader actuel du marché, va perdre des parts de marché relatives dans les années à venir. Il constate également que de plus en plus d'acteurs se mettent à servir de la vidéo.
Il annonce alors les objectifs de Varnish Software :
- Offrir une offre solide à destination des entreprises
- Créer une suite logicielle complète de distribution de contenu sur le web
Il annonce ensuite les nouveautés et sorties à venir chez Varnish Software :
- Varnish Cache 4.0 bien entendu
- Varnish Cache Plus 4.0, un fork de Varnish Cache
- VAC 3.0 (Varnish Administration Console)
- VCS 1.4 (Varnish Custom Statistics)
- Varnish Tuner 1.0
- Varnish High Availability 1.0
Il en profite pour nous informer de la sortie de Varnish 4, et l'annonce ensuite officiellement sur Twitter. Applaudissements, et la présentation reprend.
La VAC 3.0 est essentiellement un refactoring qui aura pris 18 mois pour abandonner GWT et exposer à la place une API ReST, et une interface utilisateur consommant l'API. Toutes les opérations d'administrations deviennent donc automatisables.
Le VCS 1.4 s'accompagne d'un tableau de bord web, qui vient s'ajouter à l'API exposée par le service. Le VCS permet de facilement exposer via une API Rest des statistiques métiers personnalisées.
Parmi les nouveaux outils, on trouve donc le Varnish Tuner et Varnish High Availability. Le premier ajuste l'OS (Linux) et le serveur Varnish en temps réel après avoir collecté quelques informations de la part de l'administrateur pour déterminer la stratégie de tuning. Le second permet une communication entre plusieurs serveurs Varnish et offre un vrai mode cluster avec de la réplication de cache.
Il termine enfin par une roadmap à court terme et à long terme de leur offre commerciale.
13h45 - Running with scissors par John Moylan
John est administrateur système senior et chef de projet chez RTÉ (service public de diffusion en Irlande). Il intervient en tant que client de Varnish Software et nous propose un retour d'expérience dans la durée.
Il commence par nous lister la liste très variée des terminaux auxquels ils ont à faire. Cela va du classique ordinateur de bureau, aux incontournables smartphones et tablettes, en passant par les télévisions connectées et les consoles de salon.
Retour en arrière, en 1999 avec un internet légèrement différent de celui qu'on connaît aujourd'hui. Leur problème principal se situe au niveau de la bande passante. Les 4 Mo/s qu'ils consomment leur coûtent une fortune.
Avance rapide, en 2001, l'année où le web s'écroule (en tout cas le leur) à cause de toutes ces images qui pèsent tellement lourd ! Ils adoptent Squid (l'ennemi juré de Varnish) et connaissent un grand succès. Le choix était relativement simple pour eux, car les alternatives étaient propriétaires et beaucoup trop onéreuses.
Il fait ensuite une comparaison rapide entre Squid et Varnish, expliquant que le premier est trop complexe contrairement au second qui reste simple et ne sait faire qu'une chose : cache HTTP. Le VCL est selon lui génial, il reviendra dessus plus tard. Il fait également référence à une tribune de l'architecte de Varnish et explique que Squid posait au final beaucoup de problèmes à cause de son modèle mémoire trop évolué.
Sur le terrain de la mémoire donc, les barrettes de 64 Mo sont une relique du passé. Ils utilisent actuellement 1 To rien qu'en cache SSD par machine Varnish.
Il revient sur la bande passante, et sa consommation qui semble progresser de façon exponentielle :
- 2001 : 10 Mo/s
- 2014 : 40 Go/s
Il précise que la bande passante de leurs CDN n'est pas incluse dans cette augmentation de plus de 400%.
Après avoir donc adopté Squid avec succès, puis migré vers Varnish lorsqu'ils ont atteint les limites de Squid, il évoque les problèmes rencontrés avec Varnish.
Il commence par taper sur Apache httpd avec une citation :
Ce qui est génial avec mod_rewrite, c'est qu'il apporte toutes les possibilités de configuration et la flexibilité de Sendmail. L'inconvénient de mod_rewrite, c'est qu'il apporte toutes les possibilités de configuration et la flexibilité de Sendmail.
-- Brian Behlendorf
Apache Group
Il se cite ensuite lui-même :
Ce qui est génial avec le VCL, c'est qu'il apporte toutes les possibilités de configuration et la flexibilité de Sendmail. L'inconvénient du VCL, c'est qu'il apporte toutes les possibilités de configuration et la flexibilité de Sendmail.
-- John Moylan
RTÉ Digital
Le VCL (Varnish Configuration Language) est un DSL (Domain Specific Language) qui permet de définir sa politique de cache dans Varnish. Il est transformé en C puis compilé nativement et offre donc d'excellentes performances. En contrepartie, le débogage s'avère très compliqué.
Le problème principal du VCL est l'absence d'isolation, et la difficulté de définir clairement le périmètre des différentes instructions. Il milite ensuite rapidement pour que les backends (les serveurs mis en cache par Varnish) se comportent de manière Restful (sans employer explicitement ce terme). Si le serveur ne se comporte pas de manière inattendue, il est plus facile de définir sa politique de Cache au niveau du VCL.
Une note positive sur la supervision pour contrebalancer les inconvénients du VCL. Alors qu'ils mesuraient essentiellement les erreurs de pages (pagefaults) et la consommation de mémoire de Squid, Varnish offre un outillage beaucoup plus sophistiqué (varnishlog, varnishstat...). Il mentionne également les possibilités avancées de supervision avec Varnish Plus (VAC et VCS).
Il termine en présentant PyVarnish, un outil maison de supervision qui pousse dans Graphite des statistiques sur Varnish.
14h30 - Technical advantages of Varnish Plus par Yves Wang
Dans cette présentation pleine d'humour, Yves nous propose les avantages de Varnish Plus en 12 étapes. C'est probablement un clin d'oeil à un article de Per.
Il commence donc par rapidement présenter Varnish Plus :
- Un abonnement
- Des outils propriétaires
- Des services professionnels
- Un accès via des dépôts YUM et APT
Il présente rapidement le détail des fonctionnalités des deux principaux outils : la VAC et le VCS.
Les 12 étapes sont caractérisées par une difficulté de mise en oeuvre qui varie et un bénéfice qui lui est toujours élevé. Après un Varnish Plus all the things il nous propose :
- Installer Varnish Cache Plus
- Installer la VAC
- Mettre en cache le contenu statique
- Ajuster son VCL
- Cacher le contenu semi-statique
- Automatiser la purge
- Composer le contenu (ESI)
- Faire de l'invalidation de cache avancée
- Utiliser Git (ou autre) pour versionner le VCL
- Déboguer la production en direct avec le VCS
- Gérer les performances de l'application
- Mesurer des indicateurs métiers avec le VCS
15h15 - From spikes to continuous throughput, epic scale as the new normal par James Governor
Encore une présentation pleine d'humour, à un niveau largement supérieur. La présentation était tellement captivante que je n'ai au final pas réussi à prendre de notes.
James nous parle de beaucoup de choses (mais pas de Varnish) avec en trame de fond le fait que ce qu'on considérait il y a encore peu comme des pics de charge est en train de devenir la norme.
Il prend entre autres l'exemple de Twitter qui connaît des pics de charge de plusieurs heures alors qu'ils duraient quelques secondes voire minutes il n'y a pas si longtemps. Ces pics sont également imprédictibles, et il arrive souvent que des tendances ne soient pas anticipées. Twitter a pu absorber cette transformation en migrant de Ruby vers Java et Scala.
15h45 - Using Varnish Plus to overcome web performance challenges par Lucas Patingre
Lucas est consultant Varnish chez Zaizi, partenaire de Varnish Software. Sa présentation porte sur le Varnish Paywall, un outil de limitation d'accès de l'offre commerciale. L'idée est de présenter un contenu partiel lorsque votre quota est atteint.
Lucas commence par poser la question suivante : pourquoi implémenter la limitation au niveau de Varnish ?
- Si on le fait au niveau du backend, on perd l'intérêt de Varnish puisque chaque requête doit traverser toute l'infrastructure.
- On augmente le risque de rendre (in)accessible le contenu partiel en le mettant en cache.
- Mettre en cache une copie (partielle ou totale) par client signifie une augmentation significative de la consommation du cache.
Pour un meilleur découplage du cache, il propose de marquer les contenus avec différents mots-clés, pour pouvoir appliquer des règles communes à plusieurs pages du site. Ce n'est qu'une suggestion, l'outil est très flexible et permet d'implémenter tout type de règles :
- Autoriser un accès illimité en provenance de certains réseaux sociaux en se basant sur le Referrer
- Faire varier la politique d'accès en fonction de la géolocalisation des visiteurs
- Proposer systématiquement un contenu partiel plutôt qu'un décompte des visites pour un client qui indique qu'il ne souhaite pas être pisté (Do Not Track)
Lucas nous présente alors un exemple d'utilisation avec un utilisateur accédant à un site Drupal via un Varnish équipé du Paywall qui limite l'accès à certaines pages en interrogeant SalesForce.
Le choix des briques logicielles est purement arbitraire, c'est surtout pour illustrer la flexibilité du Paywall. Le workflow se décompose de la façon suivante :
- Un visiteur accède à une ressource
- Varnish réceptionne la requête
- Varnish interroge Drupal pour obtenir la ressource [*]
- Drupal indique dans la réponse les conditions d'accès à la ressource
- Varnish interroge SalesForce
- SalesForce indique au module le quota du visiteur [*]
- Le module Paywall détermine si l'accès complet est autorisé
- Si oui, Varnish renvoie la réponse en cache
- Si non, Varnish demande une version partielle de la ressource à Drupal
- Drupal transmet une réponse avec la ressource partielle [*]
- Varnish renvoie la réponse en cache
Les étapes marquées d'une astérisque [*] peuvent être mises en cache pour conserver d'excellentes performances.
Il conclue avec la citation suivante :
Les hommes construisent trop de murs et pas assez de ponts.
-- Newton
16h15 - Varnish 4.0 - What's inside? par Federico Schwindt
La présentation commence par une rétrospective des nouveautés majeures de Varnish 3 sorti en 2011 :
- Ajout de modules
- Gestion de la compression gzip
- Support partiel du streaming
D'autres fonctionnalités sont arrivées avec Varnish 3, avec par exemple de nouvelles possibilités d'invalidation.
Varnish 4, par contre arrive avec beaucoup plus de nouveautés majeures dans les domaines suivants:
- La sécurité
- La gestion des threads
- Le streaming complet
- Un accès au journal avec un langage de requêtage avancé
- Un rafraîchissement plus intelligent du cache par Varnish
- De nouveaux points d'extension dans le VCL
- De nouveaux points d'extension pour les modules
Varnish 4 est bien plus ambitieux et apporte de nouvelles fonctionnalités tout en restant un outil spécialisé.
16h45 - Keeping London moving... with help from Varnish par Dan Mewett
Dan est senior manager chez Detica et intervient en tant que client de Varnish Software. Sa présentation est un retour d'expérience de l'intégration de Varnish chez TFL (Transport For London).
TFL gère tous les modes de transport Londoniens, et il insiste, tous ! Ils gèrent aussi bien le tube (métro) que les célèbres bus rouges, les trams, les taxis publics, les taxis privés, et même les vélos en location self service (Barclays Cycle Hire). TFL contrôle également les principales routes à l'intérieur et à l'extérieur de Londres.
Il mentionne également Oyster, le système de tickets électroniques pour les transports en commun (métro, bus, tram) et le service de congestion qui facture automatiquement l'accès en voiture à Londres en scannant les plaques d'immatriculation.
Cela représente beaucoup de données.
TFL a aussi une forte présence en ligne avec plus de 30 sous-domaines pour leur site web, et des services numériques variés pour connaître l'état du traffic de tous les modes de transport, faire des prédictions en temps réel ou planifier des trajets.
TFL s'inscrit également dans une démarche open data et distribue des fichiers statiques, une API accédée par plus de 5000 applications tierces.
Le principal défi de TFL, est le défi du "jour de neige". Certains événements génèrent des pics de charge jusqu'à 20 fois supérieurs à la normale. Un problème qui ne peut pas par exemple être adressé à l'aide d'un CDN puisque la grande majorité du traffic provient de Londres.
Un autre défi, celui des données. TFL reçoit ses données de plus de 20 sources différentes, toutes de natures différentes. Les formats en sortie sont moins variés (HTML, JSON, XML, RSS...) mais il y en a aussi plusieurs. Certaines données vont varier plus ou moins vite que d'autres sur des intervalles de l'ordre de la minute à la semaine.
Il faut en plus que ces données soient toujours pertinentes. Les données périmées peuvent devenir un problème sociétal.
Il donne ensuite plusieurs conseils et ne recommande pas de mise en cache des données du côté du navigateur. Du côté de Varnish en revanche, on met tout en cache pour absorber la charge, le backend invalidera le serveur dès que nécessaire. Il conseille également de communiquer un maximum d'informations à Varnish à l'aide d'entêtes HTTP plutôt que de traiter les cas particuliers URL par URL.
Il termine en expliquant qu'avec AWS (Amazon Web Services) et son Elastic Load Balancer, ils peuvent répondre au "syndrome du jour de neige" par de la scalabilité horizontale en provisionnant des noeuds Varnish ou des noeuds de leurs serveurs d'application en fonction de la charge.
17h15 - Discussions
La journée s'est achevée avec l'équipe de Varnish Software qui a répondu aux questions de l'assemblée. Un autre Varnish Summit est prévu en mai à New York.