Stockage distribué : Project Voldemort

February 1, 2009

voldemortLa gestion d’un nombre de requête important nécessite toujours la mise en place de système de cache. En général il s’agit de système permettant de stocker une valeur pour un ID donné.

Dans cette gamme de logiciel je vous ai déjà présenté memcached, ou les solutions de montée en charge de Danga, aujourd’hui je vous propose de regarder le projet Voldemort.

Ce nouveau système est en fait une implémentation libre du système Dynamo d’Amazon (Dynamo est également expliqué ici): Lire la suite »


Communiquer via une file d’attente de message [3/3]

January 31, 2009

amazon-queue2Après avoir analysé les avantages de la communication par message pour l’envoi d’email massif et pour décharger le nombre de thread sur un serveur web, nous allons aujourd’hui nous intéresser à la répartition de charge.

Dans les cas ou plusieurs clients peuvent demander un traitement particulier la communication par message est souvent intéressante. En effet elle permet de découpler les demandes des clients et les traitements par les serveurs. Les services web peuvent être répartis facilement grâce à un load balancer HTTP, mais dans certains cas les traitements à effectuer sont plus importants que le simple calcul d’une page. Il est alors beaucoup plus intéressant de passer par une liste de tâches partagées par les clients et les serveurs. Lire la suite »


Communiquer via une file d’attente de message [2/3]

January 19, 2009

post_office1Après vous avoir présenté brièvement les avantages de la communication par message dans ce premier post. Je vous propose de continuer cette série mais en s’intéressant cette fois aux tâches longues, complexes et souvent gourmandes en ressource.

Dans ce deuxième exemple nous sommes toujours sur une application web, mais dans cette partie l’utilisateur souhaite obtenir un objet dynamique relativement long à générer. Cela peut-être un rapport à consolider, une analyse sur une grosse base de données, ou une sauvegarde à lancer et à télécharger.

En général dans les développements fait un peu trop rapidement, c’est la première demande qui va se charger de lancer le traitement, de suivre l’avancement, d’en informer le client jusqu’à la fin pour lui proposer finalement de télécharger son résultat. Le problème avec cette méthode c’est que pendant tout ce temps nous allons garder une connexion ouverte, et donc monopoliser un thread coté serveur. Cette monopolisation va naturellement réduire la disponibilité du serveur car le nombre de thread parallèles est physiquement limitée par la mémoire de la machine.

La technique consiste donc à séparer cette demande de traitement en deux partie associées par un identifiant stockée en base de données : Lire la suite »


Communiquer via une file d’attente de message [1/3]

January 16, 2009

boite-au-lettre-2Aujourd’hui la construction d’un service ou site web se fait généralement via l’appel de services et requêtes HTTP. Du coup la modélisation d’une architecture est souvent basée autour de ce protocole et toute l’architecture est basée sur ce principe.

Pourtant il existe d’autres techniques qui permettent à des systèmes de communiquer entre eux. Je vous propose donc via ces quelques pages de vous faire (re)-découvrir le principe de la communication par message asynchrone. La grande différence entre les messages asynchrones et les requêtes synchrones tient au fait que l’émetteur d’une requête va attendre sa réponse et il ne va pas interrompre la communication tant que le traitement ne sera pas terminé (get http par exemple).

Alors qu’avec un message, le récepteur va confirmer le bon enregistrement de la demande et la communication peut-être interrompue même si le traitement demandé dans le message n’est pas terminé.

Prenons l’exemple de l’inscription d’un utilisateur sur un site web, à la fin de l’inscription nous souhaitons lui envoyer un e-mail de confirmation/vérification :

Lire la suite »


Facebook héberge plus de 10 milliards de photos !

October 15, 2008

Avec plus de 10 000 serveurs, FaceBook continue sa progression. Aujourd’hui nous apprenons (via ce post) que le site gère plus de 10 milliards de photos ! Après le passage du cap des 100 millions d’utilisateurs actifs dans le monde (en Aout dernier) c’est un nouveau record qui vient d’être battu. Dans cette note nous apprenons également que le site gère désormais :

  • Plus d’un pétaoctet de stockage pour les photos.
  • La livraison de 15 milliards d’images par jour.
  • Et tous les jours plus de 2.3 téraoctets de photos sont téléchargées sur le site. Lire la suite »

Améliorer l’organisation de votre entreprise avec CMMI

October 2, 2008

Après avoir étudié les différentes étapes de la vie d’un site Web je vous invite aujourd’hui à découvrir le modèle CMMI. En effet maintenir la haute disponibilité d’un service c’est avant tout mettre en place une architecture et des procédures permettant de gérer les aléas de votre système. Il est composé, à minima, des deux éléments suivants :

  • Des équipes compétentes et expérimentées respectant un ensemble de bonnes pratiques.
  • Un système complètement redondant et automatique sur lequel les équipes n’agissent qu’en suivant une procédure validée.

Certes, présenté comme ça c’est un peu ‘froid et rigide’ mais l’expérience prouve tous les jours que les incidents ont souvent pour cause le non respect d’une procédure, ou un agissement imprévu et non étudié avant son exécution (souvent en réaction à un autre problème d’ailleurs).

Éliminer les réactions non planifiées est un des points permettant de passer au niveau supérieur du modèle CMMI. C’est pour cette raison que je vous parle de CMMI, parce qu’il regroupe un ensemble de méthodes et de bonnes pratiques vous permettant de passer : Lire la suite »


Planning des évolutions de votre architecture web

September 25, 2008

Lors de la dernière conférence LinuxWorld, John Engales le CTO de Rackspace a présenté les différentes étapes de la vie d’un site web. Et même si chaque site possède sa problématique il est toujours intéressant de voir qu’il existe un schéma général.

En quelques lignes voici donc les différentes versions d’une infrastructure web typique, j’ai simplement changé deux points (en gras et/ou barré) qui sont plus proches de la réalité des cas que je rencontre de ce coté de l’atlantique :

  • Etape 1 : Architecture simple, pas de redondance, pas de complexité. Un firewall, un serveur Web et une base de données avec stockage local (load balancer web, rare à ce niveau).
  • Etape 2 : La même chose mais avec un load balancer sur deux serveurs web et une base de données un peu plus puissante
  • Etape 3 : Mise en place d’un reverse proxy, d’un cache statique et de load balancers sur les bases de données (avec synchro master/slave par exemple). Il faudra prévoir quelques recodage à cette étape.
  • Etape 4 : La complexité commence : Ajouter du memcached (ou autre), les réplications entre les bases de données deviennent trop gourmandes en ressources et il va falloir commencer le split horizontal (partitionnement des données, nécessitant un re-design des BDD). A ce niveau la mise en place de serveurs dédiés en fonction du contenu a du sens.

A partir d’ici les choses commencent vraiment à devenir sérieuses, bonne nouvelle pour le trafic du site ou du service mais il va désormais falloir assurer une disponibilité sans faille. Lire la suite »


Le traitement des hautes volumétries

August 1, 2008

Deux articles intéressants de la part d’Amazon et de Microsoft Research aujourd’hui. Tous les deux sur la gestion et le traitement des hautes volumétries. Tout d’abord une petite bible à propos des possibilités d’Amazon. Ce document regroupe une description des différents services d’Amazon ainsi que quelques exemples d’utilisations. Tout le monde n’a pas besoin de traiter des Tera de données mais il est toujours intéressant de comprendre comment il est possible de traiter l’impossible

L’original se trouve directement chez Amazon (et vous pourrez lire une rapide description sur cet excellent résumé)

Le second concerne l’optimisation et le traitement parallèle. Lire la suite »


Croissance et économie d’échelle

July 20, 2008

croissance-serveurLa mise en place d’un service web reste un processus incrémental et la forte montée en charge est parfois incertaine. En effet les certitudes et les tests sur un échantillon de données ne sont pas forcément valables quand les volumétries sont multipliées par 10, 100 ou 1000.

Au delà des problèmes techniques, disposer d’une architecture solide est un véritable avantage concurrentiel. Car les coûts de croissance peuvent exploser si le design de base n’a pas été pensé correctement.

Dessiner les plans et les protocoles de mise à jour des informations demandent, dès la phase de conception, de se projeter vers des architectures distribuées. Le cas des sites web, de type média est aujourd’hui bien connu et il existe un certain nombre de techniques qui permettent de gérer la croissance de manière quasi linéaire.

Mais dans le cas des nouveaux applicatifs web les choses sont différentes car il ne s’agit pas simplement d’afficher une page web. Il s’agit de rendre un service, de manière immédiate et cela indépendamment de la charge de ce service et du nombre d’utilisateurs du service.

Le partitionnement des tâches et des services est ici indispensable. Car il permettra de calculer le coefficient de rendement de votre architecture.

A ce titre je vous conseille d’étudier la loi de Amdahl. Elle permet de prévoir le gain obtenu par l’ajout de ressource dans un système. Elle nous montre aussi que le design de l’application est LE composant le plus important.

Prenons un exemple : Lire la suite »


Gérer les interruptions de service

July 16, 2008

outage Garantir une disponibilité de 100% quelque soit le nombre d’utilisateurs d’un service et sans pouvoir être sûr de l’ensemble des ressources disponibles est impossible. Il convient donc de mettre en place des stratégies de communications et d’actions pour gérer les périodes d’interruptions.

L’actualité récente nous prouve que personne n’est à l’abri des incidents. En quelques jours ce en sont pas moins de cinq services qui sont tombés  : Le nouveau service d’Apple : Mobile Me, mais aussi de Facebook (de nouveau tombé cette semaine), Google Docs, 37signals et enfin LiveSide.

Personne n’est donc à l’abri de problème technique, dépendant ou non de sa volonté d’ailleurs (un incident sur un datacenter est très pénalisant et il est difficile de s’en prémunir)

C’est pour cette raison qu’il faut mettre en place un plan d’action permettant de communiquer rapidement avec vos utilisateurs. Cela vous permettra de leur montrer que même pendant l’incident vous maitrisez en partie la situation.

Voici un modèle, à adapter en fonction de votre service, qui vous permettra de bâtir un plan d’action : Lire la suite »