le lab

J'ai écrit une petite application en Rails qui s'appelle "D'ici ça marche" et qui regarde si un serveur web fonctionne depuis l'application.

Souvent en effet on se demande si un serveur web est indisponible uniquement de chez soi ou pour tout le monde. L'idée est donc de se mettre ailleurs dans le réseau (en l'occurrence chez Dedibox, mon fournisseur) pour voir si le service fonctionne depuis cet endroit.

Alors j'ai fait simple et court. Je regarde exactement le nom de serveur qui est donné. Par exemple google.fr ça marche pas, mais www.google.fr marche.

Essayez le et dites moi si pour vous aussi ça marche.

Aujourd'hui, j'ai fait quelque chose que j'avais décidé il y a plusieurs semaines : j'ai mis mon deuxième e-book (Maximum performance) en téléchargement et consultation gratuite.

Comme je n'ai pas modifié le texte lui même, je tiens à dire que bien que le contenu de ce site et du livre soient offerts gratuitement, ils ne sont en aucune façon libres : j'accorde le droit de publier, de partager, mais pas de modifier le contenu. Que ce la ne vous empêche pas toutefois d'écrire un livre ou des articles sur le même sujet, ou d'essayer de me convaincre de rendre le livre libre.

J'ai un peu recommencé à faire du dev en Rails et j'ai notamment mis à niveau en Rails 2.0 une appli que j'ai pour un site. Et j'ai lu ensuite le mode d'emploi, c'est à dire la liste des changements. Elle est disponible ici.

Ce que j'ai particulièrement apprécié, ce sont ces deux paragraphes :

We’ve also made it much easier to structure your JavaScript and stylesheet files in logical units without getting clobbered by the HTTP overhead of requesting a bazillion files. Using javascript_include_tag(:all, :cache => true) will turn public/javascripts/.js into a single public/javascripts/all.js file in production, while still keeping the files separate in development, so you can work iteratively without clearing the cache.

Along the same lines, we’ve added the option to cheat browsers who don’t feel like pipelining requests on their own. If you set ActionController::Base.asset_host = “assets%d.example.com”, we’ll automatically distribute your asset calls (like image_tag) to asset1 through asset4. That allows the browser to open many more connections at a time and increases the perceived speed of your application.

Ce que cela signifie : une concaténation des fichiers javascripts en un seul entre le développement et la production, une excellente idée que je pousse à fond dès que je vois un site avec 5 js qui ralentissent son affichage. Rails prouve encore une fois à quel point c'est un framework agile en prenant en compte ce besoin.

L'autre partie, c'est l'usage de la parallélisation des fichiers de ressources pour essayer d'exploiter un maximum de connexions pour un navigateur donné ( et surtout IE).

Wow! Je ne pensais pas que des recommandations de performance pouvaient ainsi traverser l'ether et revenir directement dans un framework. Il faut croire qu'il y a des gens intelligents et qui écoutent.

J'aimerais que la notion de cache Http et de compression des ressources texte soient aussi bien intégrés, mais je pense qu'il faudrait que je m'y colle, ce qui n'est pas de mon niveau vraiment. On laissera ces problématiques aux serveurs web (qui sont certainement plus adaptés pour cett question).

Cet article est le troisième d'une série de quatre articles sur les réseaux de distribution de contenus, ou Content Delivery Network (CDN).

Je ne vais pas rentrer dans le détail du fonctionnement des CDN, mais juste effleurer les principes, éventuellement citer un ou deux exemples de fonctionnement dans des cas réels.

Tout d'abord, les différents fournisseurs n'expliquent pas tout le fonctionnement de leurs infrastructures (il y a une question d'avantage compétitif) et de leurs serveurs. Ce n'est pas encore un marché où l'offre est apparemment mature, et la technologie préside beaucoup à l'intérêt et à l'efficacité d'un CDN.

Ensuite, les différences vont souvent dans des niveaux techniques qui ne sont pas intéressants à mon propos : le but est de vous faire comprendre les concepts de base, nécessaires à l'évaluation de l'impact sur votre travail.

Plusieurs principes et gros mots sont utilisés dans le travail des CDN :

• redirection
• serveur surrogate
• routage des requêtes
• réplication
• synchronisation

Les besoins des fournisseurs de contenu

On l'a vu dans le post précédent, le CDN est là pour rendre le contenu plus accessible. Ce contenu a en effet une valeur (commerciale) car d'une manière ou d'une autre il est vendu aux visiteurs des sites, à travers de la publicité, de l'abonnement à un service, parce qu'il s'agit d'un besoin marketing de promotion d'un produit...

Ces fournisseurs de contenu veulent aussi garder le contrôle de leur contenu, être capables de comptabiliser le trafic, être capables de le mettre à jour de manière à ce qu'il soit bien frais. Des parties de sites sont personnalisées, avec gestion d'identification et de compte, d'autres sont sécurisées au niveau du protocole (https) , avec à la fois cryptage des données et identification confiante du fournisseur de l'information.

Les CDN vont répondre à ces différents besoins en mettant l'accent sur l'accessibilité.

Les serveurs surrogates

Ce qui fait l'extensibilité d'un réseau de CDN est le nombre de serveurs surrogate. Pardonnez l'anglicisme : un serveur surrogate est un serveur 'qui prend la place', qui se substitue. Il se substitue au serveur d'origine, celui qui détient véritablement l'information, fraîche.

Le nombre et la position des serveurs qui peuvent se substituer au serveur d'origine est un des éléments qui sont commercialisés par les CDN : plus leurs serveurs de substitution sont proches de tous vos visiteurs, plus vous avez de chance de servir vite les ressources.

Comment se fait la substitution?

Il y a un élément central dans le fonctionnement qui va contrôler la manière dont se fait la substitution des ressources à l'origine par celles qui sont dans les serveurs surrogate. Cet élément, l'algorithme sur lequel il repose va conditionner l'efficacité des serveurs de substitution.

La substitution d'un serveur d'origine par un serveur de CDN peut se faire par redirection ou par routage différent. La redirection implique qu'un serveur renvoie une réponse de type 307 temporary redirection et fournisse une nouvelle url pour une ressource. Cette redirection peut aussi être plus discrète, et ne pas comprendre de modification de l'adresse de la ressource (ce qui n'estjamais terrible pour le cache).

Le routage peut faire pointer la requête directement vers un serveur qui va la servir en se faisant passer pour le serveur d'origine.

J'ai essayé d'illustrer le fonctionnement des deux techniques dans les deux diagrammes illustrés et animés suivant. Le premier décrit une redirection, le deuxième un routage vers un serveur de substitution.

Ne vous laissez pas leurrer par la durée des représentations : il n'y a pas d'avantage chronomètre entre les deux techniques de manière systématique. La performance est le résultat d'un tel nombre de paramètres, tous fluctuants, que la performance réseau de ces deux techniques est comparable.

Comment ces mécanismes de redirection fonctionnent, c'est le problème des CDN. Ce qui est important pour vous c'est l'impact sur votre architecture et votre service. En l'occurrence, rien n'est à faire pour vous, tout se passant en amont de votre serveur d'origine.

La réplication

Ce qui peut avoir plus d'impact direct pour vous, c'est l'usage et le fonctionnement de la réplication. En effet, pour que les serveurs de substitution soient efficaces, il leur faut des données. Ces données peuvent être soit déposées soit cherchées. C'est soit du pull, soit du push.

Le push, c'est le fait d'aller déposer dans le CDN vos ressources. Vous les poussez dedans. Dans les cas concrets, cela correspond souvent à l'utilisation d'une zone de stockage externalisée : le coût de développement d'un système de duplication des ressources sur toute l'infrastructure de distribution est mutualisé chez le CDN. Celui traite dont les problèmes inhérents à ce mode de réplication : fiabilité, taille du stockage, surconsommation de la bande passante.

Le pull est généralement préféré par les CDN, car il implique un transfert des ressources en fonction du besoin, et donc pas de surconsommation de la bande passante ou du stockage. C'est totalement compatible avec une zone de stockage externalisée. Dans ce cas, les serveurs surrogates remplissent leur office de cache : ils vérifient qu'ils ont la ressource et qu'elle est fraîche, et sinon, il vont la tirer du serveur d'origine (pull).

Dans le cas où le système est en push, cela implique pour vous de publier les ressources soit directement dans le réseau de contenu, soit dans la zone de stockage tampon. Vous avez un travail important à faire.

Si le système est en pull, l'action se situe au niveau des serveurs surrogate. L'impact pour vous est nul, ou presque : vous n'avez pas besoinde déposer les fichiers dans une zone de stockage tampon, de changer leur url etc. Bien sûr il existe un ensemble de meilleures pratiques valables pour les services des CDN comme pour les web classiques.

Contrôle

Il est important pour les fournisseurs de contenu de pouvoir garder le contrôle des ressources qui sont servies. Par contrôle, j'entends d'abord contrôle pour dire si les ressources doivent être servies ou pas par le CDN, ensuite contrôle de la fraîcheur (un vieux problème avec les caches) et enfin contrôle de l'utilisation des ressources (statistiques etc).

Le contrôle de quels éléments sont servis ou pas par le CDN se fait souvent en choisissant un nom de domaine différent pour ces ressources. Cela va en général de pair avec une bonne gestion des noms de domaines pour les cookies, les directives de cache etc. Si on ne veut pas avoir le choix, on peut aussi mettre toutes les ressources dans le CDN, en lui confiant son nom de domaine. L'idée est que le CDN devient proxy pour toutes les requêtes qui sont adressées au serveur d'origine, et qu'il sert les ressources uniquement quand il les a en cache et qu'elles sont cachables, qu'il transmet la requête au serveur d'origine quand il n'est pas capable de le faire.

Le contrôle de la fraîcheur est un problème aussi vieux que le cache : en donnant l'autorisation à un cache de cacher une ressource, on lui délègue le pouvoir d'invalider la ressource. Il faudrait pour conserver le contrôle être capable de recenser tous les serveurs de cache qui ont enregistré une ressource, et quelle ressource. Un travail colossal, entraînant un trafic colossal quand on désire invalider... D'autres solutions sont en cours de définition, notamment grâce au travail de Mark Nottingham, mais elles doivent encore se répandre et prouver leur efficacité.

Dans le cas des serveurs des CDN, les fournisseurs de contenu, on un périmètre connu, recensé et simple à valider pour valider ou invalider la fraîcheur de certaines ressources. Il est alors possible de dire qu'une ressource ou un ensemble de ressources ne sont plus frais, et d'accéder à une interface de gestion qui permet de les invalider. Des API sont souvent disponibles pour invalider directement à partir de votre infrastructure les ressources que vous désirez.

Le monitoring et les statistiques font partie des questions que les CDN vont savoir gérer rapidement : il leur faut aussi être capable de stocker le volume et le type de requêtes et de ressources demandées pour pouvoir vous adresser une facture. Leurs outils pour faire ce calcul de facture sont disponibles aussi pour les clients. Ils servent aussi à mettre en exergue les problèmes qui peuvent exister (requêtes vers des ressources inexistantes, problèmes de connexions etc). Pour pouvoir récupérer des logs de trafic HTTP consolidés, il faut le demander. Vous urez intérêt à avoir un outil de statistiques de trafic extérieur en javascript pour continuer à observer votre trafic sans couture (un google analytics, un mint hébergé sur un domaine non CDN ou un Omniture).

Bien évidemment, chaque CDN a ses spécificités, ses avantages compétitifs, son réseau de serveurs et de caches, mais tous fontionneront aujourd'hui en mettant en œuvre le meilleur mix entre réplication, redirection, routage et contrôle. Une étude un peu datée a esayé de faire un suivi et une taxonomie des CDN. Cette taxonomie est très américanophile (ils ont plus de CDN que la France car la latence est un problème plus important dans leur pays).

Dans le dernier article, j'aborderai les meilleures règles à mettre en œuvre pour profiter pleinement d'un CDN, celles qui permettent de s'en passer le plus longtemps possible, et j'essaierai de mettre en avant les critères permettant de faire une taxonomie permanente des CDN disponibles pour la France.

A partir de lundi, j'ai la chance de travailler pour Witbe, un des pionniers de la supervision vision client sur internet, et le leader français.

Je vais travailler en tant que consultant au sein du groupe 'business solutions' qui a vocation à fournir des solutions orientées métier, prototypes ou non, à réaliser des audits complets et à faire des pilotes. Des activités qui étaient un peu dispersées au sein de l'entreprise, et qui s'appuient sur la structure existante, notamment l'entité professional services.

Comme le métier de Witbe est très proche du sujet de cette catégorie de blog, je ferai particulièrement attention au mélange des genres. Je tiens ainsi à préciser systématiquement que mes positions ne reflètent pas forcément celles de mon employeur, et qui est celui ci dans chacun des posts. Ce blog ne deviendra pas toutefois un moyen de communication de Witbe : le site de l'entreprise est là pour ça, et peut être les évolutions de ce site seront elles le moyen de développer ce blog avec plus d'études de cas, de livres blancs etc.

Vous voilà prévenus ;-)