Les réseaux de distribution de contenu (CDN) part 3 - Comment ça marche
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.
diagramme 1
diagramme 2
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.