Le 29 juil. 2014 à 00:40, Vincent Bernat <ber...@luffy.cx> a écrit :
>> Tout a fait d’accord. C’est un problème a géométrie hautement >> variable, je te le concede volontiers. Par contre, si une chose est >> sure a 100% c’est qu’il est impossible de faire mieux que l’offload >> que Netflix offre a travers ses appliances en passant par un >> quelconque CDN traditionnel. > > Netflix tombe à 0% quand la seule vidéo regardée dans la journée n'est > pas dans le cache et représente 1000 vues. Un CDN traditionnel tombe à > presque 99.9% dans le même cas. Juste pour dire qu'un CDN avec cache > infini peut sans problème faire mieux que Netflix. Si le rapatriement > initial de Netflix compte comme une vue (parce que ça prend quand même > de la BP), un CDN avec cache infini fait toujours mieux. > > J'ai pas d'avis dessus, mais sur NANOG, ils se sont bien étripés sur > quelle méthode est plus efficace entre provisionner par avance et cacher > au fil de l'eau. On peut comprendre que pour un petit provider, bouffer > 1Gbps de sa BP sans vraiment être sûr que cela serve vraiment, ça peut > faire douter. Tandis que cacher au fil de l'eau, on est au moins sur > qu'il y a du monde qui regarde. Sur de la « moyen-tail » (i.e. <= 1 à 2 vues / heure glissante sur une zone donnée), on peut facilement atteindre 88-90% sur un CDN du commerce (Akamai, Edgecast, Level3, …), et ce sur un catalogue de 40M+ vidéos encodées chacune en 4 à 9 qualités (suivant la qualité de la vidéo en entrée), en mode « fil de l’eau », avec une garantie de time-to-first-frame inférieure à 300ms. En interne (équivalent de NFLX OC sur des PoP au « cul » des IX), on atteint des efficacités de cache supérieures (ratio 1/30 à 1/40), car on contrôle mieux l’heuristique de mise en cache. Un cache du commerce va chercher à cacher tout ce qui bouge, ce qui n’est pas forcément la meilleure stratégie, et c’est bien pour cela qu’on envoie pas de la long-tail sur ce genre de solutions (ça exploserait les coûts de feed pour une efficacité proche de 0 sur ~85% des contenus). Pour les boitiers au sein des réseaux d’opérateurs, le deal est win-win, surtout là où le transit coûte 3 bras (Asie par ex.). Exemple : chez un opérateur qui pompe 20-30Gbps vers ses eyeballs, on place 3-4 boitiers à 5-6k$ chacun (dans notre cas cela donne à peu près ~30To de cache), ça divise par 10 les besoins en feed et c’est rentabilisé en 2 mois. Les boitiers (appro, livraison, télé-adminstration & maintenance) sont généralement à la charge du fournisseur de contenu, le hosting (électricité/frigorie) et la bande passante « interne » au réseau opérateur sont à la charge de l’opérateur. Believe it or not, de très nombreux opérateurs sont prêts à « sauter le pas » : ça garantit qu’un service populaire sera mieux délivré à leurs abonnés (qui auraient été le consulter de toute manière), et ce pour un coût extrêmement faible (ce ne sont généralement pas les mètres carrés qui manquent). Mais comme quelqu’un l’a évoqué plus haut, c’est « chacun pour sa g. » au niveau des déploiements (pas de mutualisation entre les services, chacun gère son cache et son load-balancing applicatif comme il l'entend). Brave world … ;-) Cordialement, Pierre-Yves --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
