Avec Kafka et Flink, Netflix gère un système de streaming de données massif servant à personnaliser l’expérience des usagers et à sécuriser sa plateforme SVOD. La clé de son adoption ? Une approche simplifiée pour les développeurs.
« Tudum » [Son de démarrage de l’application, N.D.L.R.]. Plus de 300 millions d’utilisateurs, un milliard d’appareils, 190 pays. Voilà l’ampleur de Netflix, la célèbre plateforme de vidéo à la demande.
C’est aussi 14 000 milliards d’enregistrements traités tous les jours. « Comme vous pouvez le deviner, un système distribué à cette échelle pose des défis techniques uniques en leur genre que nous devons résoudre », commente Sujay Jain, ingénieur logiciel sénior chez Netflix. Son poste ne reflète pas véritablement son niveau de qualification. Sujay Jain est passé par Meta et Microsoft après avoir obtenu son diplôme à l’Université Carnegie Mellon.
« [Nos applications et de microservices] produisent énormément de données intéressantes sur lesquelles nous voulons nous appuyer pour des usages BI, [...] pour l’observabilité de la plateforme, etc. »
Sujay JainIngénieur logiciel sénior, Netflix
L’une des techniques phares pour l’éditeur de la plateforme n’est autre que le traitement de données en temps réel. « Contrairement au traitement batch, avec le streaming, vous traitez vos données comme un jeu de données infini », rappelle l’ingénieur.
Il s’agit de répondre à deux grands cas d’usage chez Netflix : le Change Data Capture (CDC) et le traitement de données en provenance de microservices et d’applications. Dans le premier cas, l’objectif est de rapatrier les changements d’un système source vers un système cible en temps réel ou presque. Dans le second, Netflix souhaite exploiter les données de ces services.
« Nous avons beaucoup d’applications et de microservices. Ils produisent énormément de données intéressantes sur lesquelles nous voulons nous appuyer pour des usages BI, la recommandation de contenus aux usagers, pour l’observabilité de la plateforme, etc. », relate Sujay Jain.
Pour ces deux grands cas d’usage, les ingénieurs de Netflix ont fait le choix de combiner Apache Flink et Apache Kafka.
« Kafka est notre couche de transport principal des données, tandis que Flink est utilisé pour la plupart des tâches de traitement et de transformation dans nos pipelines », distingue le spécialiste. Netflix opère ce qu’il appelle un « KaaS », une offre Kafka as a Service interne.
Les ingénieurs de données familiers avec Flink ont accès à une plateforme « SpaaS » (Streaming Platform as a Service) où ils peuvent écrire des jobs personnalisés en Java ou en Scala. Ils ont la main sur l’API DataStream, les états de données, marqueur temporel, et les éléments bas niveau. Toutefois, ils doivent gérer les mises à jour, la supervision et certains éléments de sécurité. Aussi la courbe d’apprentissage est réputée pour être abrupte.
Pour les utilisateurs plus néophytes, les architectes de Netflix ont bâti une plateforme nommée Data Mesh. « Dans notre cas, c’est une abstraction afin de faciliter la création de pipelines de streaming de données. Vous n’avez pas besoin de connaître les secrets de Flink, de SQL, des API pour y arriver », explique l’ingénieur logiciel.
Abstraire la complexité du couple Kafka-Flink
L’objectif était de rendre les capacités de streaming de données à un plus grand nombre de personnes. En même temps, il fallait pouvoir garder le contrôle sur ces fonctionnalités au risque de créer un plat de spaghetti, de faire exploser les coûts et d’exposer la plateforme à des problèmes de sécurité.
« Les membres de l’équipe Data Mesh écrivent des jobs Flink standardisés pour les usagers qui peuvent les infuser dans leurs pipelines ».
Ces pipelines, dans leurs formes les plus simples, sont composés de trois briques essentielles. Il y a une source (une application qui s’appuie sur une base de données PostgreSQL, MySQL ou Cockroach, un connecteur CDC) ; un mécanisme de transformation SQL Flink ou GraphQL ; et un sink vers une ou plusieurs destinations, à savoir vers un data store (c’est à dire un dépôt de données Iceberg sur S3, ElasticSearch, Cassandra via Data Gateway, Apache Druid, etc.) ou vers un autre topic Kafka. « Un autre job Flink peut aussi consommer les données d’un autre job source », ajoute l’ingénieur sénior.
À plus bas niveau, un topic Kafka est exploité avant et après l’étape de transformation de données. Le topic Kafka qui reçoit la transformation l’envoie vers un sink qui va lui-même écrire les données préparées dans la destination. À chaque transition dans le pipeline, un schéma prend place. « Le producteur crée son propre schéma qui devient celui manipulé en entrée par le mécanisme de traitement SQL. Après la modification, le schéma peut changer pour les données en sortie. Ce schéma modifié est celui utilisé en entrée par les sinks », explique-t-il.
« Nous pouvons échantillonner des données en provenance de topics Kafka, exécuter la requête et leur faire parvenir le résultat rapidement afin d’itérer sur la requête. »
Sujay JainIngénieur logiciel sénior, Netflix
Un système permet de vérifier l’évolution du schéma à chaque modification, d’interdire certaines opérations et de conserver un historique des schémas en entrée et en sortie.
Mais le cœur du système Data Mesh est un control plane qui orchestre les pipelines de données, les topics Kafka, les jobs Flinks, les schémas. « Sous le capot, il s’appuie sur nos control plane internes de nos plateformes Flink et Kafka », décrit Sujay Jain.
Les usagers ne voient rien de tout cela. Eux ont droit à un éditeur leur permettant d’écrire en SQL leur requête. Cette interface incorpore un mécanisme de vérification d’écriture des requêtes, de validation automatique des schémas afin de s’assurer qu’elles pourront s’exécuter. « Nous pouvons échantillonner des données en provenance de topics Kafka, exécuter la requête et leur faire parvenir le résultat rapidement afin d’itérer sur la requête ».
Pour ce faire, une instance Flink est réservée à l’exécution de ces plus petits calculs dont les résultats alimentent Mantis (une autre plateforme de streaming open source développée en interne) avant de les retourner aux utilisateurs à travers l’interface. Une fois la requête réellement prête, il est possible de la sauvegarder et de la déployer sous la forme d’un job Flink. « Notre planificateur allégé a été configuré pour bloquer certaines requêtes, trop gourmandes ou non autorisées », précise Sujay Jain.
« Data Mesh » : des usages à tous les étages
Cette architecture, qui évolue de manière incrémentale, aurait « réduit la barrière à l’entrée » pour les employés de Netflix qui ont besoin de traiter des données en temps réel. « Auparavant, chacun pouvait développer son pattern de traitement, ce qui impliquait beaucoup de travail de gestion pour l’équipe responsable de la plateforme », explique l’ingénieur logiciel. « La solution est accessible en libre-service et les garde-fous sont très utiles pour éviter les problèmes opérationnels ».
En à peine deux ans, la plateforme combinant Kafka et Flink propulse pas moins de 1 500 processeurs de traitement. Rappelons que chaque flux de transformation (et leurs étapes intermédiaires) peuvent devenir des sources pour d’autres processus de traitement. « L’un des avantages de cette plateforme, c’est que nous maintenons un large écosystème de connecteurs », assure Sujay Jain.
En mai 2025, l’équipe responsable de l’infrastructure Data Mesh administrait plus de 5 300 pipelines. Elle gérait plus de 20 000 jobs Flink et plus de 25 000 topics Kafka. La plateforme supporte au maximum 100 millions d’événements par seconde, environ 8 000 milliards d’événements par jour. « Ce sont exclusivement des workloads internes », souligne le responsable.
« Notre équipe de sécurité utilise l’architecture Data Mesh pour agréger des logs en provenance de différents systèmes, afin d’y exécuter des dépistages. »
Sujay JainIngénieur logiciel sénior, Netflix
Cette architecture de streaming de données est l’une des fondations sur lesquelles repose le système de personnalisation des contenus. L’ordre des films et séries proposés, les visuels et les synopsis affichés sur les différentes pages (et dans la barre de recherche) varient suivant les profils des usagers et le moment de la journée, selon l’ingénieur. « Chaque interaction avec ces éléments génère une grande quantité d’événements au sein de notre plateforme de traitement, qui sert de socle pour tenter d’interpréter vos goûts en fonction des clics et de votre historique de visionnage ». De même, l’architecture Data Mesh est utilisée pour garder à jour les index ElasticSearch servant à lister les films, les séries, les studios et les données sur les acteurs. Outre le fait de fournir aux usagers des informations à jour, Netflix se sert de ces données pour gérer son catalogue qui évolue ainsi de manière hebdomadaire.
En 2021, Netflix a lancé un service de jeux vidéo à la demande. Ici, la combinaison de Flink et de Kafka sert à analyser l’usage en temps réel des jeux et des fonctionnalités mises à disposition des clients.
Cet écosystème est également exploité pour la détection de menaces et la lutte contre la fraude en s’appuyant sur Iceberg et Druid. « Notre équipe de sécurité utilise l’architecture Data Mesh pour agréger des logs en provenance de différents systèmes, afin d’y exécuter des dépistages ».
L’automatisation, la clé de la mise à l’échelle
Maintenir un tel système à très large échelle réclame obligatoirement d’automatiser certaines tâches. « Nous avons beaucoup investi dans l’automatisation et nous continuons de le faire », affirme Sujay Jain. « Nous avons mis en place un système sophistiqué qui permet d’analyser et de remédier automatiquement aux problèmes d’exécution des jobs Flink », illustre-t-il. Celui-ci traite les difficultés les plus répandues, dont celles liées à la mise à l’échelle des traitements.
« Bien évidemment, ce n’est pas parfait, mais cela couvre la majorité des incidents de niveau 1, les problèmes les plus communs. Si le correctif ne suffit pas, c’est là que moi et mon équipe sommes appelés à la rescousse ».
Un dispositif d’autoscaling est bien entendu de la partie, car prévoir le besoin de ressources de calcul et de stockage demeure complexe.
La suite de supervision associée permet de surveiller la santé des jobs, la latence générée à chaque étape de transformation et aussi de diffuser des alertes. L’outil de suivi d’évolution des schémas est également utilisé à ce niveau, tout comme un outil de gestion de flottes des traitements Flink.
Propos recueillis en mai 2025 lors de l’événement Current London 2025 organisé par Confluent.
