CirruxCache : réduire la bande passante et augmenter la connectivité

Posté par  . Modéré par patrick_g.
Étiquettes :
9
12
mar.
2010
Python
CirruxCache est une solution de Content Delivery Network (CDN) développée en Python sur Google App Engine et distribuée sous licence GPL. Pour expliquer simplement, un CDN est un système de cache HTTP distribué permettant, d'une part, de réduire l'utilisation de la bande passante à l'origine (votre serveur) et, d'autre part, de permettre de localiser géographiquement le contenu de manière à optimiser le chargement des pages pour l'utilisateur final. Ceci peut s'appliquer, bien sûr, à un site web, mais plus généralement à toute application utilisant le protocole HTTP (WebServices par exemple).

CirruxCache permet d'utiliser la plate-forme Google App Engine comme un CDN. Ce projet est né de l'idée de réduire les coûts d'utilisation de la bande passante chez un fournisseur CDN professionnel. Les coûts d'utilisation d'App Engine n'étant pas excessifs. Cependant, un compte App Engine gratuit suffit amplement à une utilisation pour un blog personnel (sauf si vous vous appelez Korben ;-).

CirruxCache est utilisé en production notamment par la société Zoomorama. CirruxCache implémente aujourd'hui de nombreuses fonctionnalités souvent utilisés par les solutions de CDN professionnels, parmi lesquelles : gestion du TTL à partir du Cache-Control, configuration précise des points de présence (en fonction d'une base URL ou d'un virtual host), extensibilité (développement de WebServices sous forme de "module"), etc.

Vous trouverez une liste exhaustive, ainsi que de la documentation, sur le site officiel du projet.

Aller plus loin

  • # Répartition Géographique ?

    Posté par  . Évalué à 2.

    Moi j'aimerais bien savoir où vous avez lu que App Engine permet de faire de la répartition géographique...

    Je n'ai jamais vu une seule preuve que c'était effectivement le cas. Si vous en avez une je suis preneur.

    Et si ce n'est pas le cas, un sous domaine static.example.com avec un un serveur léger du genre ngnx ou lighttpd ne ferait-il pas tout aussi bien l'affaire ?

    • [^] # Re: Répartition Géographique ?

      Posté par  . Évalué à 2.

      En fait le service Appengine de Google est reparti sur plusieurs datacenters. L'accès à ces «point de présence» s'effectue en fonction de la localisation de l'utilisateur. C'est le principe d'une application distribuée sur un cloud, ou plus généralement de l'accès a une donnée depuis un CDN.

      Je vous invite à lire les liens à la fin de l'article pour mieux comprendre l'intérêt d'un cloud provider comme Appengine pour ce genre d'application. Ainsi vous comprendrez comment la donnée est localisée géographiquement.

      • [^] # Re: Répartition Géographique ?

        Posté par  . Évalué à 6.

        J'ai compris en quoi consiste la répartition géographique, j'aimerais juste des preuves que l'on bénéficie de ce mécanisme en utilisant App Engine.

        Le fait que l'architecture de Google soit généralement géographiquement distribuée ne constitue pas une preuve que les applications sur App Engine le soit.

      • [^] # Re: Répartition Géographique ?

        Posté par  . Évalué à 3.

        je suis d'accord avec lrbabe

        je commence à travailler sur les techno de cloud.

        j'ai pu m'apercevoir que quelque soit l'application appspot que tu traceroute ca retombe toujours dans le meme datacenter en californie. apres c'est vrai, je sais pas si c'est forwarder autre part ( le nom de domaine ne fait pas tout dans ces solutions) ...
        bref comme le dit lrbabe "ca reste a prouver" (en s'y mettant dedans jusque au cou ^^)
        mais GAE est deja une solution SaaS il devrait deja regler ce genre de techno sur leur solution !

        par contre, chez Amazon il affiche clairement la couleur. tu choisie l'endroit de ton cloud (plusieurs datacenter par continent) et tu peux gérer toi meme ce CDN ... et la c'est normal c'est une solution IaaS/PaaS. (je parle d'amazon car avec AppScale tu pourrais réintegrer ce CDN sur EC2)

    • [^] # Re: Répartition Géographique ?

      Posté par  . Évalué à 2.

      Wikipedia: AnyCast

      • [^] # Re: Répartition Géographique ?

        Posté par  . Évalué à 1.

        Hmm, de l'anycast transparent sur des protocoles connectés (on parle de HTTP là) ?

        A moins que les applis hébergées chez google apps utilisent leurs DNS (auquel cas ils peuvent faire effectivement de l'anycast sur leurs serveurs DNS, comme ils font pour d'ailleurs pour leurs 8.8.8.8 et 8.8.4.4, et dispatcher à partir de là la résolution géographiquement).

        Ce qui me fait douter de la répartition effective, c'est que le récent (et excellent) rapport de panne de Google Apps semble signifier qu'il n'y a que deux datacenters :
        https://groups.google.com/group/google-appengine/browse_thre(...)

        "The oncall engineer discusses performing a failover to our alternate datacenter"
        "the oncall engineer attempts to move all traffic into a read-only state in our alternate datacenter"
        etc

        Mais ça n'enlève pas grand chose à l'interét de l'appli : celui de pouvoir décharger le service de fichiers statiques vers un hébergeur bon marché et tout de même assez bien connecté, quand bien même il ne serait pas particulièrement physiquement proche des utilisateurs finaux.

        Aux développeurs: est-ce que le support de ESI est prévu ?

        • [^] # Re: Répartition Géographique ?

          Posté par  . Évalué à 2.

          Aux développeurs: est-ce que le support de ESI est prévu ?

          Intéressant comme suggestion. Ça n'est pas prévu pour le moment mais je vais me pencher sur la question.

  • # Pub indirecte pour la boîte de l'auteur

    Posté par  . Évalué à -1.

    Dans l'article,
    dans les liens (qui n'apporte absolument rien à l'article),
    et sur la page du projet (normal): ça fait un peu beaucoup.

    • [^] # Re: Pub indirecte pour la boîte de l'auteur

      Posté par  . Évalué à 10.

      Salut,

      Pour clarification, je suis le manager de l'auteur (dans la société dont je ne répéterais pas le nom afin de ne pas lui faire plus de pub indirecte :-)).

      C'est moi qui ai pris la décision il y a quelques mois d'open-sourcer CirruxCache, ET d'en céder la propriété intellectuelle à Sam.

      Je ne l'ai pas fait pour faire de la pub à notre boîte, mais parce que je pense que cette application pourrait être utile à d'autres et qu'elle présente un intérêt qui dépasse notre seul usage.

      Le fait que Sam indique la provenance et l'usage actuel de l'appli relève pour moi:
      1. de la courtoisie la plus élémentaire de sa part
      2. de la promotion de *CirruxCache* (et non de la société en question)

      J'espère que cela clarifie les choses et répond à votre question.

      Quant à la pertinence des liens et ce qu'ils apportent (ou non) à l'article (en particulier les blog-posts), je suppose que les lecteurs sont seuls juges - il me semble à moi intéressant de fournir un peu de matière sur le sujet CDN.

      • [^] # Re: Pub indirecte pour la boîte de l'auteur

        Posté par  . Évalué à -1.

        Déjà discuté sur d'autres articles où la même problématique se posait. (de mémoire, le plus récent: l*nagora)

        Quand on poste un news redhat, on donne le lien de la page projet, pas redhat.com/. Pareil pour ubuntu, on link vers la page projet, pas vers canonical.

  • # Corps benne

    Posté par  (site web personnel) . Évalué à -10.

    Je sais qu'on est vendredi mais est-on vraiment oblige de faire des references aussi douteuses ?

    - Ca n'apporte rien
    - Ca lui fait de la pub et y'en a bien assez sur son site.
    - Et puis c'est nul

    ps: desole, j'ai perdu mes accents

    • [^] # Re: Corps benne

      Posté par  . Évalué à 3.

      On est d'accord sur ce point.
      Il y a une différence entre mentionner un projet open source d'une société, et un communiqué de presse sur la release d'un projet.

  • # Utilité d'un tel cache sur les applis dynamiques ?

    Posté par  (Mastodon) . Évalué à 3.

    Les caches sont un peu nébuleux pour moi. Est-ce qu'un tel cache a une utilité dès lors qu'on héberge un site dynamique ?

    Merci pour les pécisions (-:

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.