Decrypt

Varnish est un outil fabuleux à bien des égards. C’est une boite à outils qui permet de simplifier, harmoniser, sécuriser et accélérer les architectures web. Nous allons aborder dans cet article certaines fonctionnalités de Varnish pour commencer à en tirer le maximum. Il se positionne comme un reverse proxy cache. En gros nous allons le placer en amont des serveurs Web pour intercepter les requêtes, mettre en cache ce qui est généré par les backends et resservir le contenu généré depuis son cache. Mais son fonctionnement peut aller plus loin.

Le fonctionnement
Varnish se configure simplement grâce à deux types de fichiers. Le fichier de configuration de Varnish où nous allons définir certains paramètres internes et les fichiers VCL qui permettent de configurer le comportement de Varnish via une sorte de langage de programmation.

[...]

J’ai écrit une première version de cet article au sujet des modèles de cohérence il y a environ un an, mais je n’en étais jamais très content, car il a été rédigé à la hâte, et le sujet est suffisamment important pour mériter un traitement plus approfondi. ACM Queue m’a demandé de réviser l’article afin de le publier dans leur revue, et j’ai profité de cette occasion pour l’améliorer. La nouvelle version suit :

Finalement Cohérent – Construire des systèmes distribués et fiables à l’échelle mondiale exige des compromis entre la cohérence et la disponibilité.

À la base du Cloud Computing de Amazon se trouvent des services d’infrastructure tels S3 (Simple Storage Service) de Amazon, SimpleDB, et EC2 (Elastic Compute Cloud), qui fournissent des ressources pour la construction de plateformes de calcul à l’échelle d’Internet et d’une large gamme d’applications. Les exigences imposées aux dits services en infrastructure sont très strictes : ils doivent afficher de bonnes notes dans les domaines de la sécurité, la scalabilité, la disponibilité, la performance et la rentabilité, et ils doivent satisfaire ces besoins tout en desservant des millions de clients dans le monde, de façon continue.

Sous les couvertures, ces services sont des systèmes distribués colossaux qui opèrent à l’échelle mondiale. Cette échelle crée des défis supplémentaires, car quand un système traite des trillions et des trillions de requêtes, des évènements qui ont habituellement une probabilité d’occurrence faible sont désormais certains de se produire, ce qu’il faut prendre en compte dès le début lors de la conception et dans l’architecture du système. Etant donné l’étendue mondiale de ces systèmes, nous utilisons des techniques de réplication partout afin de garantir une performance cohérente et une haute disponibilité. Bien que la réplication nous rapproche de nos objectifs, elle ne peut les atteindre de façon parfaitement transparente ; sous plusieurs conditions, les clients de ces services seront confrontés avec les conséquences d’avoir utilisé des techniques de réplication au sein des services.

[...]

Décidemment, encore un article sur les AWS (Amazon Web Services). Au-delà du fait, que ce sont de bons composants dans le cadre de la mise en place d’une infrastructure, il faut noter qu’ils couvrent un scope complet de ce que l’on peut trouver dans une infrastructure en termes de fonctionnalités (gestionnaire de files de messages -SQS-, base de données non relationnelle -SimpleDB- et relationnelle -RDS- depuis peu, traitement massif de données -MapReduce, bonjour BI ?-, instances virtuelles -EC2-, VPN -VPC-, …), mais également en termes de « background technique ». Je m’explique : prenons l’exemple de S3, qui sera notre sujet d’étude dans cet article d’ailleurs, quoi de plus simple qu’un système de stockage d’objets ? Ca se résume à « PUT », « GET » et « DELETE ». Et pourtant derrière cette apparente simplicité, se cache une complexité technique sous-jacente étonnante, qui reprend bons nombres de concepts « standards », mais que l’on implémente rarement soi-même, parceque complexes à mettre en place. On laisse donc cela aux outils que l’on utilise ou tout simplement on fait l’impasse dessus. Tout cela pour introduire les 9 principes sous-jacents au service S3 d’Amazon qui font de ce service apparemment succint, un bel exemple technique.

[...]

Il m’arrive souvent chez les clients de rencontrer la même confusion autour de ce triptyque, ce qui peut mener à de sérieux problèmes, surtout quand le client se base sur l’idée que « dans le doute on prend toutes les options, c’est forcément mieux ! ». C’est faux !
Une explication de chacune de ces notions s’impose.

[...]