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.
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.
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.
How do you scale an AWS (Amazon Web Services) infrastructure? In Part Two of the article, I describe the architecture model and the underlying technical components you should use in order to implement a scalable infrastructure. We will look in particular at the optimisation of data access in scale-out-type architectures suitable for implementation as a distributed system, as much at the data model level as the lower layers for I/O optimisation. We will also examine the recommended development concepts such as Stateless, in the finest REST tradition. I will end the article with some tips and tricks. My aim is to help you set up and optimise your infrastructure by understanding how Amazon tools operate and to get the most benefit from them.
How do you scale an AWS (Amazon Web Services) infrastructure? This article will give you a detailed reply in two parts: the tools you can use to make the most of Amazon’s dynamic approach, and the architectural model you should adopt for a scalable infrastructure. I base my report on my experience gained in several AWS production projects in casual gaming (Facebook), e-commerce infrastructures and within the mainstream GIS (Geographic Information System). It’s true that my experience in gaming (IsCool, The Game) is currently the most representative in terms of scalability, due to the number of users (over 800 thousand DAU – daily active users – at peak usage and over 20 million page views every day), however my experiences in e-commerce and GIS (currently underway :o)) provide a different view of scalability, taking into account the various problems of availability and data management. I will therefore attempt to provide a detailed overview of the factors to take into account in order to optimise the dynamic nature of an infrastructure constructed in a Cloud Computing environment, and in this case, in the AWS environment.
Comment scaler une infrastructure AWS (Amazon Web Services) ? Je vais décrire dans cette deuxième partie de l’article le modèle de l’architecture et les composants techniques sous-jacents à adopter afin de mettre en place une infrastructure scalable. Nous aborderons tout particulièrement le sujet de l’optimisation de l’accès aux données dans les architectures de type scale-out propices à la distribution, autant au niveau du modèle de données que des couches basses pour l’optimisation des I/O. Nous verrons également les concepts de développement à privilégier tel que le stateless dans la plus pure tradition REST. Je terminerai par quelques trucs et astuces en fin d’article. Le but est de vous permettre de constituer et d’optimiser votre infrastructure en comprenant le fonctionnement des outils proposés par Amazon pour en tirer le meilleur parti.
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