Apache Kafka
Toute entreprise moderne tourne autour des données. C’est précisément pour cette raison que plusieurs technologies, plates-formes et frameworks ont vu le jour au fil des années pour prendre en charge une gestion avancée des données. L'une de ces solutions est Apache Kafka, une plate-forme de streaming distribuée conçue pour le traitement de données à grande vitesse et en temps réel.
À ce jour, Kafka a déjà été largement adopté par des milliers d’entreprises à travers le monde. Nous l’analysons en profondeur pour comprendre ce qui le rend spécial et comment différentes entreprises peuvent l’utiliser.
Qu’est-ce qu’Apache Kafka ?
Kafka est une plateforme de streaming distribuée open source qui vous permet de stocker, lire et analyser des données en temps réel. Il s'agit d'un outil puissant capable de gérer des milliards d'événements par jour tout en restant rapide, notamment grâce à sa nature distribuée.
Avant de rejoindre la communauté et la Fondation Apache en 2011, Kafka a été créé à l'origine sur LinkedIn, pour suivre le comportement de ses utilisateurs et créer des liens entre eux. À l’époque, il visait à résoudre un problème réel avec lequel les développeurs de LinkedIn étaient confrontés : l’ingestion à faible latence des données des grands événements. Il y avait un besoin évident de traitement en temps réel, mais aucune solution ne pouvait réellement y répondre.
C'est ainsi qu'est né Kafka. Depuis lors, il a parcouru un long chemin et a évolué pour devenir un système de messagerie distribué complet de publication-abonnement, fournissant l'épine dorsale de la création d'applications robustes.
Comment fonctionne Kafka ?
Fondamentalement, une plate-forme de streaming comme Kafka possède trois fonctionnalités de base : publier et s'abonner à des flux de journaux, stocker ces flux de journaux de manière tolérante aux pannes et les traiter au fur et à mesure qu'ils se produisent.
Avec Kafka spécifiquement, les applications (dans ce cas les producteurs) publient des messages (journaux) qui arrivent sur un nœud Kafka (courtier). Chaque enregistrement (constitué d'une clé, d'une valeur et d'un horodatage) est traité par ce que l'on appelle des consommateurs et stocké dans des catégories appelées sujets qui constituent les clusters Kafka.
Cependant, comme les sujets peuvent croître en taille, ils sont divisés en partitions plus petites pour améliorer les performances et l'évolutivité. Tous les messages de chaque partition sont classés dans l'ordre immuable dans lequel ils sont arrivés et sont continuellement ajoutés à un journal de validation structuré.
De plus, les enregistrements de partition se voient attribuer un numéro d'identification séquentiel (décalage) qui identifie de manière unique chaque enregistrement au sein de la partition. Les données des partitions sont également répliquées sur plusieurs courtiers pour préserver toutes les informations au cas où l'un d'entre eux décèderait.
Ce qui est également intéressant, c'est que Kafka ne se soucie pas des enregistrements consommés. Le cluster Kafka conserve durablement tous les journaux publiés en utilisant une période de conservation configurable. Ce sont les consommateurs eux-mêmes qui interrogent Kafka à la recherche de nouveaux messages et indiquent quels journaux ils souhaitent lire. Cependant, après la période définie, l'enregistrement est supprimé pour libérer de l'espace.
Quant aux API, il y a cinq composants clés dans Kafka :
- L'API Producer qui permet à l'application de publier un flux d'enregistrements vers des sujets (un ou plusieurs par exemple),
- L'API consommateur qui permet à l'application de s'abonner à des rubriques et de traiter le flux de log correspondant,
- L'API Flows qui facilite la transformation efficace des flux d'entrée en flux de sortie,
- L'API du connecteur qui vous permet de créer et d'exécuter des producteurs ou des consommateurs réutilisables qui connectent des sujets Kafka à des applications ou des systèmes de données existants,
- L'API d'administration qui vous permet de gérer et d'inspecter les sujets, les courtiers et autres objets Kafka.
L'API Producer qui permet à l'application de publier un flux d'enregistrements vers des sujets (un ou plusieurs par exemple),
L'API consommateur qui permet à l'application de s'abonner à des rubriques et de traiter le flux de log correspondant,
L'API Flows qui facilite la transformation efficace des flux d'entrée en flux de sortie,
L'API du connecteur qui vous permet de créer et d'exécuter des producteurs ou des consommateurs réutilisables qui connectent des sujets Kafka à des applications ou des systèmes de données existants,
L'API d'administration qui vous permet de gérer et d'inspecter les sujets, les courtiers et autres objets Kafka.
En conséquence, Kafka est capable d’ingérer et de déplacer rapidement de grandes quantités de données, facilitant ainsi la communication entre divers éléments des systèmes informatiques, même faiblement connectés.
Avantages et inconvénients d’Apache Kafka ?
Il y a plusieurs raisons pour lesquelles Kafka semble gagner en popularité. Premièrement, étant donné l’énorme quantité de données produites et consommées par différents services, applications et appareils, de nombreuses entreprises peuvent aujourd’hui bénéficier d’une architecture basée sur les événements. Une plateforme de streaming distribuée avec un stockage durable comme Kafka est considérée comme le moyen le plus propre de réaliser une telle architecture.
Kafka s'avère également fiable et rapide, notamment grâce à la livraison de messages à faible latence, aux E/S séquentielles, au principe zéro copie, ainsi qu'à un clustering et une compression efficaces des données. Tout cela fait de Kafka une alternative appropriée aux courtiers de messagerie traditionnels.
Mais d’un autre côté, Kafka est tout simplement compliqué. Pour commencer, vous devez planifier et calculer un nombre adéquat de courtiers, de sujets et de partitions. D’un autre côté, rééquilibrer le cluster Kafka peut également impacter les performances des producteurs et des consommateurs (et donc suspendre le traitement des données). En parlant de données, il est facile de supprimer les anciens journaux trop tôt (en cas de débit élevé et de faible consommation, par exemple) pour économiser de l'espace disque. Cela peut facilement être excessif si vous n'avez pas vraiment besoin des fonctionnalités de Kafka.
A quoi sert Apache Kafka ?
Selon l'équipe de développement de Kafka, il existe quelques cas d'utilisation clés pour lesquels il est conçu, notamment :
- pour les messages
- suivi de l'activité du site Web
- agrégation de journaux
- mesures opérationnelles
- traitement de flux
Chaque fois qu'il est nécessaire de créer des applications de streaming en temps réel qui doivent traiter ou réagir à des « morceaux » de données, ou transférer de manière fiable des données entre systèmes ou applications, Kafka vient à la rescousse.
C'est l'une des raisons pour lesquelles Kafka fonctionne bien avec les applications bancaires et financières, où les transactions doivent être traitées dans un ordre spécifique. Il en va de même pour le transport et la logistique, ainsi que pour le commerce de détail, notamment lorsque des capteurs IoT sont impliqués. Dans ces secteurs, une surveillance constante, des applications asynchrones et en temps réel (par exemple, contrôles des stocks), des analyses avancées et l'intégration de systèmes, pour n'en nommer que quelques-unes, sont souvent nécessaires.
En fait, toute entreprise souhaitant tirer parti de l’analyse des données et de l’intégration d’outils complexes (par exemple entre les applications CRM, POS et e-commerce) peut bénéficier de Kafka. C’est précisément là où cela s’intègre bien dans l’équation.
Qui utilise Apache Kafka ?
Il n'est pas surprenant que Kafka reste un élément essentiel de l'infrastructure de LinkedIn. Il est principalement utilisé pour le suivi des activités, le partage de messages et la collecte de métriques, mais la liste des cas d'utilisation ne s'arrête pas là. La plupart des communications de données entre les différents services de l'environnement LinkedIn utilisent dans une certaine mesure Kafka.
À l'heure actuelle, LinkedIn admet gérer plus de 100 clusters Kafka avec plus de 4 000 courtiers, desservant 100 000 sujets et des millions de partitions. En revanche, le nombre total de messages traités par les déploiements Kafka de LinkedIn a déjà dépassé les 7 milliards par jour.
Bien qu'aucun autre service n'utilise Kafka à l'échelle de LinkedIn, de nombreuses autres applications, entreprises et projets en profitent. Chez Uber, par exemple, de nombreux processus sont modélisés avec Kafka Streams, notamment la mise en correspondance des clients et des chauffeurs et les calculs d'ETA. Netflix a également adopté l'architecture multicluster Kafka pour le traitement des flux et gère désormais de manière transparente des milliards de messages chaque jour.
Chez Future Mind, nous avons également eu l’opportunité de mettre en œuvre Kafka. Pour Fleet Connect, un système de suivi des véhicules et de gestion de flotte, nous surveillons l'emplacement de chaque véhicule (ainsi que certains autres paramètres) grâce à des dispositifs dédiés à l'intérieur. Les données collectées par ces appareils atteignent la passerelle IoT, qui décode les messages et les envoie à Kafka. À partir de là, ils aboutissent dans IoT Collector, où ont lieu le traitement et l’analyse des données.
Curieusement, les trackers à l'intérieur des véhicules envoient les messages un par un et par ordre d'apparition, mais seulement après que le précédent ait été accepté et stocké correctement, afin que nous ne perdions aucune donnée pertinente. Pour cette raison, nous devons cependant « prendre en charge » tous ces messages rapidement, afin de ne pas surcharger les trackers et traiter les données en temps réel.
Dans ce cas, une mise à l'échelle horizontale avec l'utilisation de courtiers classiques, de systèmes de messagerie et de files d'attente « traditionnelles » ne suffirait pas en raison de la spécificité du projet et de la nécessité d'analyser les données en temps réel. Cependant, avec Kafka, nous pouvons diviser le flux d'entrée en partitions basées sur l'ID du véhicule et utiliser plusieurs courtiers qui garantissent une évolutivité horizontale presque illimitée, une sauvegarde des données en cas de panne, une vitesse opérationnelle élevée, une continuité et un traitement des données en temps réel dans un commande spécifique.
Dois-je utiliser Kafka pour mes projets ?
1. Déterminez si vous avez vraiment besoin de Kafka si certains des éléments suivants sont vrais :
- Pas besoin de traiter des milliers de messages par seconde
- Pas besoin de maintenir l'ordre spécifique dans lequel les données doivent être traitées
- Une éventuelle perte de certains logs en cas de basculement ne serait pas très problématique
2. Pensez aux différents composants du système.
- De combien de courtiers avez-vous besoin (c'est-à-dire dans quelle mesure le système doit-il être distribué), de combien d'instances ZooKeeper, de combien de serveurs et à quels emplacements ?
- Quels thèmes et partitions vous envisagez d'avoir - ceux-ci peuvent être modifiés ultérieurement, mais le changement en lui-même est assez problématique
- Combien de producteurs et de consommateurs différents utiliseront le système, et dans combien de cas (au sein d’un groupe de consommateurs) chacun d’eux sera-t-il parallélisé ?
3. Pensez à l'ensemble de la configuration, en particulier :
- Quel est le meilleur choix pour une clé de partition et quelle est la stratégie de partition qui la sous-tend ?
- Comment choisir la meilleure stratégie de regroupement des messages (aussi bien pour les producteurs que pour les consommateurs) pour maintenir un équilibre entre vitesse de traitement/acheminement et délais ?
- Quelle devrait être la politique de nouvelle tentative et les délais d'attente pour les messages transmis par les producteurs aux courtiers Kafka ?
4. Testez votre configuration et vérifiez si :
- Si l'un des courtiers est désactivé, les courtiers restants reprendront-ils les partitions qu'il gère (en d'autres termes, le rééquilibrage des partitions sera-t-il activé) ?
- Si l'une des instances de consommateur est désactivée, les instances restantes au sein du même groupe de consommateurs commenceront-elles à traiter les messages provenant des partitions de consommateur inactives ?
- Pouvez-vous gérer la politique de nouvelle tentative et les changements de validation, et n'avez-vous perdu aucun message ni traité de doublons en cours de route ?
5. Surveillez Kafka à l'aide des outils disponibles et vérifiez que :
- N'a aucune partition qui n'est pas utilisée
- Aucun des consommateurs n'a un filigrane trop élevé
- Tous les coureurs sont en bonne santé
- Tous les courtiers et consommateurs sont bien équilibrés