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.
Dans le monde élastique du Cloud et plus précisément en ce qui concerne l’IaaS, nous nous heurtons souvent au problème : “quelle est l’adresse de telle machine, quel est son mode d’accès…”. A ces questions peuvent s’ajouter la problématique du tout automatique via un Capistrano par exemple. Vous me direz qu’il existe une console Web et des API. Oui mais la console n’est pas réellement exploitable pour l’automatisation et les API ont besoin de crédentials que l’on ne préfère pas disséminer partout sur les serveurs.
Le but de cet article est de montrer comment avoir un référentiel des instances disponibles sur un compte Amazon (ou autre) avec toutes les informations qui vont bien sans devoir utiliser la console web Amazon. Cette solution permet de pousser l’automatisation un cran plus loin en proposant une liste exhaustive que l’on peut automatiser et la possibilité d’avoir une liste des serveurs disponibles en une ligne de commande pour n’importe quel Devops allergique aux opérations sur navigateur web.
La PaaS Microsoft Windows Azure est l’une des plateformes « as a service » les plus abouties. Cependant, pour éviter les déceptions, il est important de bien comprendre les caractéristiques clés afin d’en faire le meilleur usage possible. Voici les éléments que je vais aborder :
o Que peut-on faire ou ne pas faire avec une instance de calcul ?
o Comment gérer la persistance des données ?
o Peut-on installer d’autres SGBD / Systèmes clé/valeur ?
Urbandive is an immersive view service launched by the French YellowPages which allows you to travel in cities in France thanks to a 360° view. Urbandive focuses on providing high definition pictures and accurate professional and social content. One of the biggest jobs was to enable a fast scalable architecture, because it was really difficult to forecast the traffic load at production time. Traffic load may be influenced if the service receives attention from users as a result of advertising.
Below you will find a summary of the goals we achieve by using a Ruby scheduler built on top of Puppet on AWS to create a complete infrastructure.
Workflow & XTR-Lucid
Our scalability combo is : a home-made Ruby scheduler (XTR-Lucid) to deal with AWS APIs + the Puppet Master to install services and configure EC2 instances and keep them up-to-date during all the production time. This leads to full automation.
Here is the workflow (for the creation step, there are other workflows for stop/reboot/health-check/…) of our automation tool. The dashboard allows you to select a template (which contains the following informations : AMI id, instance type, availability zone, key, list of security groups, list of EBS – from snapshots or not -, …) and to set a name for the instance in the « create » workflow.
Présent depuis quelques jours à Las Vegas à l’occasion du Mix 2011 de Microsoft, voici quelques informations intéressantes :
- Un KeyNote avec des annonces importantes le deuxième jour.
- Confirmation d’un nouveau service dans le Cloud Windows Azure : « Trafic Manager », un service en CTP (Community Technology Preview). Ce service permet par l’utilisation de plusieurs zones géographiques de répartir (loadbalancer) le trafic en fonction de la proximité de l’utilisateur. Ainsi, l’impact de la latence sur les applications est minimisé grâce à la prise en compte de la géolocalisation de l’internaute.
- Enrichissement de l’offre CDN CTP avec la gestion du streaming vidéo en avril 2011 pour les informations stockées dans Azure Blob Storage.
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.
Si vous avez déjà eu besoin de rajouter des fonctionnalités d’indexation ou de recherche full-text à l’un de vos projets, il se peut que vous connaissiez déjà Apache Lucene ou l’un de ses nombreux dérivés, par exemple PyLucene, Lucene.NET, Ferret (Ruby), ou Lucy (C port). Lucene, qui date du début des années 2000, est devenu l’une des librairies pour la récupération de données les plus complètes et riches en fonctionnalités et sert de support très largement pour des douzaines de tokenizers, analyseurs, parseurs de requêtes et algorithmes de scoring.
Lors de ma participation récente à la conférence Lucene Revolution à Boston, il m’était évident grâce aux présentations elles-même, ainsi qu’aux petits groupes de participants faisant du networking entre les séances, que ce projet a su se faire incorporer dans des applications couvrant une large gamme : usage intégré, recherche desktop ou entreprise, et même déploiements distribués à grande échelle. Avant tout, le nombre de projets autour de Lucene, ainsi que les améliorations principales prévues, continuent à impressionner - si vous recherchez une solution de recherche open source, Lucene vaut certainement le coup d’être regardé de près.
Je n’ai pu résister à l’envie de poster cette vidéo, publiée il y a déjà quelques temps sur highscalability.com et issue à l’origine du site MyNoSQL, que je ne peux m’empêcher de revoir avec plaisir et que je trouve toujours aussi drôle. Vous n’y apprendrez probablement pas comment scaler votre infrastructure, mais, en tout cas, elle n’est pas dénuée de sens. :o)
Je ne traduirai pas les termes fleuris issus de la langue de Shakespeare, mais je peux vous citer notamment cette perle : « You read the latest post on HighScalability.com and think you are a f*cking Google and architect and parrot slogans like Web Scale and Sharding but you have no idea what the f*ck you are talking about. ». Je trouve que cela résume bien les difficultés, qui ne sont pas d’ordre technique, que l’on peut rencontrer dans le domaine de l’architecture.
A noter également la solution qui consiste à écrire dans « /dev/null » : très intéressante ! :o) Encore plus efficace que l’écriture sur raw device !
Et si vous vous dites après cela que SQL et NoSQL ne peuvent résolument pas cohabiter, rassurez-vous et regardez SQL + NoSQL = Yes !. Vous verrez dans cet article que les 2 modèles peuvent être utilisés ensemble pour obtenir de très bonnes performances.
Data storage has always been one of the most difficult problems to address, especially as the quantity of stored data is constantly increasing. This is not simply due to the growing numbers of people regularly using the Internet, particularly with all the social networks, games and gizmos now available. Companies are also amassing more and more meticulous information relevant to their business, in order to optimize productivity and ROI (Return On Investment). I find the positioning of SQL and NoSQL (Not Only SQL) as opposites rather a shame: it’s true that the marketing wave of NoSQL has enabled the renewed promotion of a system that’s been around for quite a while, but which was only rarely considered in most cases, as after all, everything could be fitted into the « good old SQL model ». The reverse trend of wanting to make everything fit the NoSQL model is not very profitable either.
Le stockage des données est depuis toujours une des problématiques les plus difficiles à adresser, surtout depuis que les quantités de données enregistrées ne cessent d’augmenter. Cela n’est pas simplement dû à la population grandissante qui utilise de façon plus assidue le Net, notamment avec tous les réseaux/jeux/machins sociaux. Les sociétés amassent également de plus en plus d’informations précises sur leur métier dans des objectifs de productivité et de ROI. Je trouve l’opposition SQL et NoSQL (Not Only SQL) un peu dommage : il est vrai que la vague marketing sur le NoSQL a permis de remettre en valeur un système qui ne date pas d’aujourd’hui, mais qui n’était que très rarement envisagé dans la plupart des cas où, après tout, tout rentrait dans le « bon vieux modèle SQL ». La tendance inverse à vouloir tout faire rentrer dans le modèle NoSQL n’est pas très profitable non plus.
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.
Commentaires récents