Au cours des quelques années qui ont suivi son lancement, le service de streaming vidéo en ligne de Netflix s’est développé jusqu’à compter plus de 50 millions d’abonnés dans 40 pays. Nous avons déjà présenté certaines des meilleures pratiques adoptées par les ingénieurs en développement logiciel de Netflix lors de leur transition d’un processus de développement monolithique traditionnel vers la livraison continue et les microservices, dans « Adopter les microservices chez Netflix : enseignements pour la conception de l’architecture » et « Adopter les microservices chez Netflix : enseignements pour la conception des équipes et des processus ».
Gleb Smirnoff, développeur NGINX, à nginx.conf2014
Dans cet article, nous allons nous intéresser à un autre élément essentiel de la réussite de Netflix : son réseau de diffusion de contenu (CDN), Open Connect. Nous sommes fiers que NGINX soit utilisé sur chaque appliance de diffusion Open Connect, jouant ainsi un rôle clé dans la capacité de Netflix à suivre la croissance fulgurante de son service vidéo. Gleb Smirnoff, développeur chez NGINX, travaille aux côtés de l’équipe Open Connect depuis plus de deux ans. En octobre dernier, lors de notre conférence utilisateurs nginx.conf2014, il a expliqué pourquoi Netflix avait choisi NGINX (avec FreeBSD) pour faire fonctionner cette composante essentielle de son activité.
Pourquoi Netflix a créé son propre CDN
À l’origine, Netflix avait confié la diffusion de ses vidéos en streaming à trois grands fournisseurs de CDN (Akamai, Level3 et LimeLight). Face au succès croissant du service, Netflix a décidé qu’il était pertinent de créer et de gérer son propre CDN, et ce, pour plusieurs raisons :
- D’un point de vue pratique, les fournisseurs de CDN peinaient à développer leur infrastructure à un rythme correspondant à la croissance de la demande des clients pour le service de streaming vidéo de Netflix.
- D’un point de vue financier, le coût de l’externalisation devenait rapidement prohibitif à mesure que le volume de vidéos diffusées en streaming augmentait (une difficulté rencontrée par de nombreuses applications populaires et de nombreux sites web).
- D’un point de vue commercial, il était clair que le streaming vidéo remplaçait la location de DVD comme principale source de revenus de Netflix et qu’il n’était pas logique d’externaliser un élément essentiel de l’activité principale de l’entreprise.
Mais surtout, Netflix a créé son propre CDN afin de mieux maîtriser la diffusion de ses applications et l’expérience utilisateur. Pour offrir à ses clients une diffusion optimale des contenus multimédias en streaming, Netflix devait exercer un contrôle maximal sur les trois composants fondamentaux de la chaîne de diffusion :
- Le lecteur vidéo de l’utilisateur. Netflix maîtrisait déjà ce composant, car ses développeurs conçoivent toutes les applications propres à chaque appareil que les clients utilisent pour regarder les contenus Netflix.
- Le réseau entre l’utilisateur et les serveurs de Netflix. Il n’est pas possible de contrôler directement ce composant, mais Netflix réduit la distance réseau avec ses clients en fournissant gratuitement aux FAI des équipements de streaming vidéo, en échange d’un espace dans les baies de leurs centres de données pour les héberger. (Des équipements sont également installés dans des points d’échange Internet [IXP] afin de desservir les clients dont les FAI ne souhaitent pas héberger de matériel tiers.) Le streaming vidéo est particulièrement sensible aux retards et aux pertes de paquets, à leur arrivée dans le désordre ainsi qu’aux temps d’aller-retour imprévisibles (gigue) inhérents à TCP/IP. La réduction de la distance réseau limite donc l’exposition potentielle à ces anomalies.
- Le serveur vidéo (Open Connect lui-même). L’exploitation de son propre CDN permet à Netflix d’adapter librement le logiciel du CDN afin de compenser autant que possible les anomalies d’Internet. Netflix peut utiliser des algorithmes personnalisés de contrôle des connexions TCP et des modules HTTP. L’entreprise peut également détecter très rapidement les problèmes liés aux serveurs et au réseau, rediriger les clients vers d’autres serveurs, puis se connecter au matériel du serveur et effectuer un diagnostic « de l’intérieur ».
Netflix a pu optimiser Open Connect pour le streaming vidéo d’une manière impossible avec un CDN générique fourni par un prestataire. Open Connect permet à Netflix d’offrir une expérience utilisateur supérieure à moindre coût, tout en bénéficiant d’une meilleure visibilité sur les performances de l’application à travers le monde.
Pourquoi Netflix a choisi NGINX et FreeBSD
Dès le départ, l’objectif de Netflix était, comme le dit Gleb, de « tirer de plus en plus de gigabits par seconde d’une seule machine ». Plus précisément, Netflix devait maximiser le nombre d’abonnés que chaque appliance pouvait servir simultanément. Les ingénieurs d’Open Connect savaient qu’ils auraient besoin d’ajuster finement le logiciel pour atteindre cet objectif. Ils ont donc opté pour des logiciels open source, qui offrent des possibilités d’extension illimitées.
Comme indiqué précédemment, Netflix installe, lorsque cela est possible, ses équipements de streaming vidéo dans les centres de données des fournisseurs d’accès à Internet de ses clients. Comme les logiciels exécutés sur ces équipements seraient entre les mains de tiers, Netflix a choisi des projets utilisant une licence de type BSD plutôt que la licence publique générale GNU (GPL).
Les projets open source spécifiques choisis par Netflix étaient les suivants :
- FreeBSD comme système d’exploitation, car il est réputé pour sa rapidité et sa stabilité. La communauté des développeurs est solide et disposée à collaborer avec les fournisseurs.
- NGINX comme serveur de streaming multimédia. Sa rapidité et sa stabilité éprouvées étaient essentielles, car Netflix souhaitait lancer Open Connect le plus rapidement possible, sans avoir à effectuer de réglages pour le rendre opérationnel. Une fois le CDN en service, Netflix a pu analyser les schémas de trafic et affiner les paramètres de NGINX. Autre avantage de NGINX : bien que ce logiciel open source soit distribué sous une licence de type BSD, tous ses principaux développeurs sont employés à temps plein par NGINX, Inc., qui fournit une assistance de niveau entreprise pour son produit commercial, NGINX Plus. Il réunit ainsi le meilleur des logiciels open source et commerciaux. Le framework flexible de NGINX permettant d’exécuter des modules personnalisés a également séduit Netflix, et l’équipe Open Connect a créé des modules adaptés à ses besoins en matière de streaming vidéo.
L’association de FreeBSD et de NGINX offre des avantages supplémentaires :
- La conception événementielle de NGINX est l’une des clés de ses performances exceptionnelles, et l’appel système de notification d’événements kqueue de FreeBSD est l’une des meilleures API pour les E/S multiplexées.
- Sans qu’aucune modification soit nécessaire, NGINX peut utiliser l’appel système sendfile conjointement avec l’appel système aio_read. Ensemble, ces appels évitent les blocages liés aux entrées/sorties disque, ce qui permet d’obtenir des performances exceptionnelles.
NGINX Plus et NGINX peuvent également optimiser la diffusion de vos applications
Dès sa création, NGINX a été conçu pour s’adapter et prendre en charge tous les aspects de la mise à disposition d’applications. Afin de faciliter le déploiement d’applications similaires à Netflix pour nos clients professionnels, NGINX Plus réunit dans une solution simple d’utilisation les fonctions de serveur web, de répartition de charge, de mise en cache de contenu et de streaming multimédia. Consultez nos études de cas pour découvrir comment d’autres entreprises de premier plan utilisent NGINX Plus afin de proposer leurs applications de manière performante, sécurisée et évolutive.
Nous aimons travailler en étroite collaboration avec nos clients et les conseiller afin qu’ils tirent le meilleur parti de NGINX Plus dans leurs architectures spécifiques de mise à disposition d’applications. Nos équipes d’assistance et de services professionnels peuvent vous accompagner en matière d’architecture, d’installation, de configuration, de mises à jour et bien plus encore. Contactez-nous pour en savoir plus.
Enregistrement vidéo
À propos de l’auteur
Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.