Haute-Disponibilite

On me pose souvent la question du coût des solutions de CDN Akamai pour gérer la disponibilité d’un site. Et en général le problème majeur avec cet acteur vient des frais de fonctionnement et de mise en service. En effet au delà de l’engagement contractuel sur la durée la mise en place d’une solution Akamai est relativement coûteuse pour des “petits” acteurs.

Cette annonce d’Amazon est donc une très bonne nouvelle pour le segment des sites de taille moyenne, trop petits pour négocier avec Akamai et gérant déjà un trafic suffisamment important pour être obligé de mettre en place des solutions de cache distribués, des CDN.

Concernant l’offre d’Amazon, elle ne m’étonne pas beaucoup et elle vient compléter les autres produits de la gamme. Pour les tarifs vous trouverez tout sur le site, mais voici un premier aperçu : Lire la suite »

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 »

Si vous devez gérer des pics ou des fortes charges sur vos serveurs la mise en place d’un cache est quasiment obligatoire. Il existe plusieurs techniques pour mettre en place du cache. Historiquement l’outil idéal pour ‘cacher’ une base c’est MemCache. En effet, Memcached est parfait pour aider une base de données sur laquelle les requêtes sont complexes ou dans le cas qu’une base non/mal optimisée.

Néanmoins si vos requêtes et/ou vos pages sont personnalisées la taille du cache va rapidement devenir un problème. Et pour ce type de problématique MySql peut être la solution.

En effet si vos données sont trop importantes ou trop diverses pour tenir en mémoire, vous aurez intérêt à modéliser votre base de manière optimale. Cela parait évident mais malheureusement le temps et les ajouts fonctionnels ne permettent pas toujours d’être dans une situation parfaite. C’est pour cette raison qu’il est parfois important de reposer les bases de votre modèle. Lire la suite »

Un message rapide pour vous signaler deux très bons articles de Patrice Bertrand sur des problématiques de performance. Le premier concerne la gestion du cache. Au niveau global avec des solutions comme Squid en reverse proxy mais aussi au niveau macro avec la mise en place de cache  sur des composants (cache par fragments). Vous trouverez également dans cette page une formule vous permettant de calculer le taux d’utilisation de votre cache (en fonction du nombre de page, de la taille des pages mais aussi de la fréquence de rafraîchissement du contenu).

Le second post concerne les temps de latence et leurs impacts sur la rapidité de chargement des pages. Cet article propose différentes solutions, comme la mise en place de CDN type Akamai mais aussi d’autres outils comme le Round Robbin DNS ou le GeoDNS.

Lire la suite »

La 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 »

La montée en charge d’un service web peut être traitée de multiple façons. Mise en place d’un CDN (pour les vidéos ou les contenus éditoriaux), ajout de serveurs (si les applicatifs ont été conçus pour pouvoir fonctionner sous forme de cluster), appel à un prestataire pour lui demander de gérer son trafic, etc…

Bref, il existe de multiples solutions, elles ont toutes comme point commun un coût de mise en place assez important. Mais attention il ne faut pas que les coûts progressent plus vite que le trafic…

Malgré tout il existe des solutions open source pour gérer en partie cette problématique. Je ne reviendrais pas ici sur les coûts d’intégration des logiciels open source (ils sont loin d’être nuls, surtout pour des utilisateurs non expérimentés). Mais quand les équipes sont compétentes ou que les logiciels sont simples à mettre en place ces outils peuvent être d’un grand secours, pour un coût relativement faibles.

C’est justement le cas des applicatifs distribués par DANGA Interactive.

Lire la suite »

L’architecture de DailyMotion est assez impressionnante. Les volumes de données, le nombre de requêtes simultanées ainsi que les upload et download continuels sont un véritable défit en terme de disponibilité.

Un post n’est pas suffisant pour décrire en détail cette architecture, mais esquissons déjà quelques contours.

Pour ce type de site les problématiques sont multiples :

- Tout d’abord la gestion d’un trafic réseau colossal : avec un backbone interne à 10Gb et des peering tout aussi impressionnant la structure du réseau et la communication entre les data center sont déjà un challenge.

- Les applicatifs : plusieurs serveurs, de l’apache pour les proxy vidéo et du lighttpd pour les images, style et contenus statique. Le tout, comme d’habitude, en cluster sous PHP et MySQL.

- La recherche est gérée sur des serveurs dédiés équipé de Sphinx (en version SE). Les performances de ce moteur full text sont bien plus impressionnantes que le moteur de MySql ou encore qu’un couple Lucene/Java. Mais même avec cette application ultra performante il faut plusieurs dizaines 9 serveurs pour traiter le flot de recherche permanent (tout en indexant les nouveautés rapidement)

- Le stockage est lui aussi gourmand, une vidéo c’est quelques dizaines de Mo, même avec la baisse drastique des coûts des disques des volumétries de cet ordre sont très couteuses. Lire la suite »

La vidéo à la demande nécessite des ressources importantes. Tant en terme de serveurs qu’en bande passante. L’expérience de TV5 est assez intéressante de ce point vue. Au départ quelques Mo de bande passante étaient suffisants pour délivrer les quelques millions de PV/mois.

Mais la demande en VOD se faisant de plus en plus pressante ces débits se sont vite révélés insuffisants. De plus l’architecture ne comprends qu’une petite dizaine de serveurs chez EastNet, reparti de cette manière :

Mais désormais avec des centaines de milliers de visiteurs regardant des vidéos (JT multi-langue en quasi temps réel) l’appel à un prestataire spécialisé est devenue incontournable. L’aspect international et les hautes volumétries ont obligé TV5 à choisir Akamai. Malgré le coût important cette solution Plug & Play a été choisi, d’autant que l’équipe et l’architecture technique n’était pas dimensionnée pour gérer de tels volumes. Lire la suite »

Pour qu’une application web fonctionne vite et bien, l’architecture et l’optimisation de la plate forme technique est important mais il faut que le code soit également optimisé (en fait les deux doivent l’être absolument, parfois même de manière dépendante).

En regardant la taille des fichiers nécessaires aux applications actuelles on comprend pourquoi elles sont parfois ‘longues au démarrage’ :

L’optimisation de ces temps de chargement a été étudié par Benjamin Livshits et Emre Kiciman du département Recherche de Microsoft. Ils viennent de publier un papier intéressant. Il s’agit de “Code Splitting for Network Bound Web 2.0 Applications“.

Comment cela fonctionne, les gains, les outils de Yahoo pour améliorer les temps en chargement… Lire la suite »

Pour gérer la haute disponibilité d’un service web il existe plusieurs techniques. Louer une prestation complète auprès d’un infogéreur, acheter et mettre en place sa propre architecture (datacenter, connectivité IP, serveur, load balancer, etc..) ou faire appel à un CDN (content delivery network ) comme Akamai.

L’avantage c’est qu’il s’agit d’une prestation clef en main, une interface web pour gérer les paramètres techniques, une autre pour voir la consommation et les statistiques en quasi temps réel, et enfin la facturation. Car cette prestation a un coût important.

Quel est le coût, est-ce rentable, les alternatives ?

Lire la suite »