La plateforme de streaming d'événements complète pour Apache Kafka®

L’un des principaux enjeux de l’exploitation d’une plateforme de streaming événementielle telle qu’Apache Kafka réside dans son intégration avec les autres systèmes. La genèse de la solution Kafka est là pour nous rappeler l’importance de l’intégration. En 2009, l’équipe LinkedIn en charge de l’adoption d’Hadoop cherchait un outil capable de centraliser et intégrer les données en provenance des nombreux systèmes de l’entreprise. Il leur fallait un système capable de supporter la consommation des flux de données par de multiples intervenants, d’assurer un découplage des systèmes producteurs et consommateurs de données mais aussi permettre la consommation des messages en temps réel. Plutôt que de faire appel aux outils existants, LinkedIn a développé sa propre solution. Kafka était né.

Utilisé comme une plateforme complète d’échange de données, Kafka agit comme une plateforme distribuée centralisant l’ensemble des messages qui transitent entre les applications. Alors que dans une architecture classique, plusieurs services sont chargés de recevoir des messages et de les transmettre à d’autres services, Kafka permet de les centraliser afin de les redistribuer facilement, simplifiant l’architecture applicative.

Solution positionnée au dessus d’Apache Kafka, la plateforme de streaming d’évènements proposée par Confluent permet d’exploiter pleinement cette technologie. « Notre plateforme permet d’accéder aux données en temps réel dans de nombreux secteurs d’activité critiques : mise à jour en temps réel, agrégation de données géographiques, analyse prédictive, intégration de microservices, projets IoT » précise Eric Carlier, Solutions engineer chez Confluent. Mais Kafka n’arrive jamais seul, il prend place dans un legacy. « La plateforme de streaming de données va nécessairement s’intégrer aux applications existantes » souligne Eric Carlier. Cette intégration d'Apache Kafka avec d'autres systèmes de manière fiable et évolutive est un élément clé d'une plateforme de streaming événementielle. Mais l’exercice est souvent perçu comme difficile, les sources de données d’évènements étant répartis entre de nombreuses applications, on premises et dans le cloud, et micro services, dans des environnements de plus en plus distribués. Dès lors, une question va émerger au sein de toute organisation désireuse de s’appuyer sur ces systèmes : comment faire entrer et sortir des flux de données au sein de la plateforme de streaming ? Quelles solutions pour simplifier ces processus ?

Déployer des connecteurs avec le Framework Kafka Connect

Kafka Connect est un framework permettant de développer des connecteurs qui vont soit injecter la donnée issue de systèmes externes dans Kafka, soit lire des topics Kafka et injecter les données dans les systèmes tiers. « Il fournit une architecture hautement scalable et résiliente et présente l’avantage de pouvoir préserver le schéma de données entre des systèmes externes et ce que vous avez défini dans Kafka » commente Eric Carlier. Pour les utilisateurs de Confluent, le déploiement de ces connecteurs se gère directement depuis le control center. Pour synthétiser, le but est de fournir un framework avec une API permettant de développer assez simplement des connecteurs en langage Java. « Concrètement, le développeur va pouvoir se focaliser sur les aspects de connectivité entre ce système tiers et kafka, tout en s’affranchissant des problématiques complexes de Fault tolerance, de scalabilité ou encore de résilience » poursuit Eric Carlier.

On applique en quelque sorte les formats ETL à l’univers du streaming en temps réel :

• Le « E » de Extract correspond aux connecteurs source qui vont récupérer la donnée depuis un système tiers pour l’injecter dans Kafka
• Le « L » de Load correspond au connecteur sink qui injecte la donnée depuis kafka vers des systèmes tiers.
• le « T » de Transform, qui intervient entre l’extract et le load, se fait au travers de l’application Kafka Streams ou ksqlDB. 

Kafka Connect est un Framework très puissant sur la base duquel une large bibliothèque de connecteurs est proposée, avec un enrichissement constant. Confluent supporte plus de 80 connecteurs au travers de ses contrats de souscription et a tissé des partenariats avec une vingtaine d’acteurs qui ont développé leurs propres connecteurs. On trouve donc des connecteurs pour la plupart des systèmes courants, tels que S3, JDBC ou Cassandra, par exemple.

Outre les connecteurs, l’autre option envisageable est le REST Proxy, qui permet d’exposer une interface Rest pour communiquer avec le cluster Kafka. L’avantage du langage REST est qu’il est largement pratiqué et s’intègre très facilement. Avec le Rest Proxy, on expose simplement un endpoint REST pour communiquer avec Kafka. En plus d’être extrêmement scalable, le REST Proxy est beaucoup plus facile à externaliser que ne peuvent l’être les protocoles natifs de Kafka.

Garantir la compatibilité des formats de données avec Schema Validation

Si Kafka est une excellente solution pour échanger des données entre différents systèmes, il est néanmoins essentiel de s’assurer que les formats de données soient maintenus et restent compatibles entre-eux au fil des évolutions. « Si un producer fait évoluer son schéma de données, comment garantir que la centaine de consommateurs impactés par ce changement ne vont pas être mis en échec ? » interroge Eric Carlier, rappelant les spécificités de ces processus de gouvernance. « Il serait impensable de valider au cas par cas le bon fonctionnement de centaines d’applications utilisant la donnée en question. C’est pour cette raison que nous avons mis en place un système central, le Schema Validation, afin de piloter la gouvernance et éviter ces problèmes de compatibilité entre producteurs et consommateurs de la donnée. » Ce système agit comme un catalogue des formats de données qui transitent dans les topics, avec un système de publication. En lisant le topic, les consommateurs peuvent prendre connaissance du schéma, externaliser correctement la donnée présente dans kafka, et gérer les compatibilités ascendantes et descendantes des schémas.

Ces enjeux de compatibilité sont essentiels car les users qui produisent une nouvelle version du schéma de données peuvent potentiellement mettre à mal l’ensemble de la chaîne... « Il faut bien s’assurer que les consommateurs qui attendent les données dans un certain format puissent tout de même les lire si elles arrivent dans un autre format. On parle de « forward compatibility » et de « backward compatibility » lorsque l’on évoque la possibilité de lire les événements dans l’ancien format.

Le Stream Processing : de Kafka Streams à ksqlDB

Reste à évoquer la possibilité de construire des applications pour traiter en temps réel les données injectées dans Kafka. Kafka streams est une API Java dédiée au développement d’applications streaming. Il fournit un langage d’abstraction pour facilement créer des topologies de stream processing sur les topics. « Le plus intéressant est qu’il s’agit d’une simple API Java que l’on peut déployer sur n’importe quel framework d’application et que l’on peut gérer au travers de multiples systèmes différents, comme kubernetes par exemple » précise Eric Carlier.

On peut également monter d’un niveau d’abstraction en ayant recours à ksqlDB, une application Kafka Streams permettant d’éviter les phases de développement et de déploiement. Elle permet de s’appuyer sur des requêtes proches du langage SQL, maîtrisé par la plupart des data analyst, ce qui permet de se passer d’une expertise spécifique en développement Java. « Le tout en bénéficiant du même niveau de qualité, de scalabilité et de robustesse que Kafka Streams » conclut Eric Carlier.