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.
Comment scaler une infrastructure AWS (Amazon Web Services) ? C’est une réponse détaillée que va apporter cet article en 2 parties : les outils à utiliser pour tirer parti du dynamisme des services Amazon et le modèle d’architecture à adopter pour une infrastructure scalable. Je me base sur mes expériences tirées de plusieurs projets de production sur les AWS, à la fois dans le domaine du casual gaming (sur Facebook), dans celui des infrastructures e-commerce ou bien encore dans le cadre du SIG (Système d’Information Géographique) grand public. Il est vrai que l’expérience dans le domaine du jeu est celle qui est actuellement la plus représentative en termes de scalabilité, du fait du nombre d’utilisateurs (> 800K DAU – Daily Active User – et plus de 20M de pages vues par jour), cependant les expériences dans le e-commerce et le SIG (expérience en cours :o)) offrent également une autre vision de la scalabilité, prenant en compte des problématiques différentes de disponibilité et de gestion des données. Je vais donc tenter de brosser un tableau exhaustif des éléments à prendre en compte afin d’optimiser le dynamisme d’une infrastructure montée dans un environnement de Cloud Computing et en l’occurrence dans celui des AWS.
Comment scaler une application virale de Facebook qui a monté en flèche pour atteindre un total époustouflant de 65 millions d’installations (la population de la France) ? C’est l’heureux problème vécu par Dave Westwood, le co-fondateur de BuddyPoke, et il a parlé de sa solution chez Facebook Meetup mercredi. Les slides de la présentation complète se trouvent ici. Pour ceux qui ne connaissent pas tout à fait BuddyPoke, c’est une application de réseau social qui permet aux utilisateurs d’afficher leur humeur et d’envoyer à leurs amis des étreintes, des bisous et des « pokes » (les tapoter amicalement avec le doigt) par le biais d’avatars en ligne.
Le stockage de données en lui même n’est plus réellement un problème de nos jours. Nous pouvons facilement trouver des solutions qui permettent, selon les moyens techniques et financiers, de stocker un grand nombre de données. De son côté, Amazon, avec ses AWS, propose une solution « In the Cloud » permettant de créer un disque réseau de la taille désirée et de le raccrocher à une instance virtuelle. Cette solution, nommée EBS (Elastic Block Store), permet de créer à la volée des disques qui peuvent être attachés à chaud à une instance EC2 (Elastic Compute Cloud). Bien évidemment le coût financier de ce service est fonction de l’espace alloué. Trois solutions s’offrent alors à nous :
Allocation surestimée d’un disque permettant en théorie de subvenir aux besoins futurs du système ce qui occasionne un surcoût.
Allocation d’un disque pour assurer la pérennité à court ou moyen terme puis migration des données sur un disque plus grand quand le premier sera trop petit. Cette solution va demander un coût élevé en termes de maintenance et d’indisponibilité du système.
Utilisation de LVM2 (Logical Volume Manager, version 2) pour la gestion des disques. Elle permet de lisser l’augmentation de la quantité d’espace alloué en ajoutant des disques au fur et à mesure des besoins tout en assurant un minimum d’indisponibilité.
Si la vie des vrais agriculteurs était aussi douillette que dans FarmVille, le jeu phare de chez Zynga, alors ma famille n’aurait probablement jamais quitté les hivers rudes du North Dakota. A FarmVille, aucun des contes atroces que me racontait ma grand-mère n’est véridique. Les agriculteurs y prospèrent, les cultures fleurissent, et les animaux ne partent jamais au « red barn » (abattoir). A mon avis, c’est justement ce charme rustique d’un univers où l’on ne salit même pas ses souliers, qui a contribué à rendre FarmVille « le jeu le plus important au monde » dans un délai étonnamment court.
Comment FarmVille a-t-il réussi le scaling d’une application web pour accueillir 75 millions de joueurs par mois ? Luke Rajlich de FarmVille nous a gracieusement révélé quelques uns de leurs défis et de leurs secrets. Je passe la parole à Luke. [...]
Commentaires récents