Vous essayez de faire évoluer Apache Kafka ? Envisagez d'utiliser Apache Pulsar

Aujourd'hui, même les applications Web et mobiles les plus élémentaires consomment beaucoup de données. La clé pour échanger et agir sur ces données est un système de messagerie soutenu par une architecture événementielle.

Un système piloté par les événements permet aux solutions de messagerie et au traitement d'être évolutifs et asynchrones. Les systèmes asynchrones peuvent gérer plus de demandes, car chaque demande est traitée en arrière-plan.

Lorsqu'une demande est faite au serveur, elle est ajoutée à une file d'attente, où un processeur la lira. Cela permet aux organisations de créer des systèmes acceptant des centaines de milliers, voire des millions, de requêtes par seconde à grande échelle en traitant les requêtes dans un cluster séparé.

L'industrie a produit plusieurs systèmes de courtage de messages et plates-formes de publication-abonnement (pub-sub) axées sur les sujets qui suivent ce format axé sur les événements et les messages. Apache Kafka et Apache Pulsar sont deux exemples largement utilisés de systèmes distribués de diffusion et de diffusion de messages.

Kafka et Pulsar sont tous deux construits sur un modèle pub-sub que vous pouvez utiliser pour adapter la livraison des messages à des milliers de clients connectés. Les deux offrent un modèle de stockage persistant pour s'assurer que les messages ne sont pas perdus, et les deux utilisent des partitions pour stocker et traiter les messages.

Bien que Kafka et Pulsar soient similaires à bien des égards, ils présentent des différences notables de capacités, en particulier lors de la gestion de grandes quantités de données, de la création d'applications en temps réel et du développement à grande échelle.

Kafka offre de nombreux avantages, mais le support de Pulsar pour l'évolutivité et la croissance est inégalé. Et à un certain stade de la croissance, le choix optimal est de ne plus tenter d'optimiser Kafka, mais plutôt de s'en séparer. Ici, nous allons comparer les différences entre Kafka et Pulsar, en démontrant comment une prochaine étape logique pour l'évolutivité lors de l'utilisation de Kafka est de passer à Pulsar.

Défis avec les applications Apache Kafka

Kafka est le de facto des modèles de pub-sub distribués dans l'architecture logicielle. Une organisation utilisant Kafka est capable de gérer des milliers de messages et de diffuser les messages à plusieurs consommateurs en même temps.

Kafka présente plusieurs avantages , mais il présente également certaines limites lors de la mise à l'échelle. Explorons quelques défis auxquels vous serez confrontés lorsque vous essaierez de faire évoluer des applications créées avec Apache Kafka.

Limites de stockage

L'architecture de Kafka crée le premier défi auquel vous serez confronté lors de la mise à l'échelle de vos applications dans Kafka : le stockage.

Les courtiers avec état sont la première raison pour laquelle une organisation a du mal à évoluer. Les données de Kafka sont stockées dans le nœud leader , tandis que les partitions de données sont stockées sur le disque local. Les données sont liées aux nœuds et les courtiers de Kafka sont avec état. Cela signifie qu'une fois que le nœud principal a atteint la capacité de stockage maximale, le cluster ne peut plus accepter de messages à moins que le stockage de l'infrastructure ne soit augmenté. C'est un défi car, dans un environnement en constante évolution, un cluster nécessitera plusieurs mises à niveau.

Une façon de surmonter ce défi consiste à acheter un grand cluster de stockage, ce qui est très coûteux.

De plus, sur la base de cette architecture, une fois que la plate-forme a atteint la limite maximale de stockage ou de mémoire, elle ne peut plus accepter de nouveaux messages entrants. Cela peut entraîner une perte énorme pour les applications critiques pour l'entreprise. L'architecture de Kafka est conçue pour accepter et diffuser de nombreux messages. Le stockage de données à long terme n'est pas une priorité. Par conséquent, la mise à l'échelle d'une application Kafka est très difficile car elle ne peut pas fournir le stockage dont vous avez besoin, du moins pas sans un prix élevé.

Problèmes avec le traitement des messages

La gestion de Kafka est difficile car elle n'inclut pas les fonctionnalités nécessaires à la surveillance des activités, au traitement des messages et à la persistance des données.

Kafka brille pour les systèmes de diffusion de messages sans tête, où vous n'avez pas besoin de muter un message avant la livraison. Cependant, supposons que vous deviez traiter un message avant de le transmettre aux consommateurs ; cela nécessite de s'appuyer sur des plates-formes supplémentaires, ce qui rend plus difficile et complexe le traitement des messages avec Kafka.

De plus, l'implication d'autres plates-formes comme celles énumérées ci-dessus augmente considérablement la complexité de votre système de livraison de données, car chaque composant de la plate-forme de streaming nécessite une maintenance et a des limitations qui s'appliquent à l'ensemble du cluster. De plus, les clusters Kafka ont des données limitées et une persistance des messages à mesure que vos besoins en données augmentent avec le temps.

Bibliothèques client compliquées

Les entreprises utilisent principalement Kafka pour ses services de streaming fournis. L'API de diffusion en continu est écrite au-dessus de la diffusion des messages pub-sub pour prendre en charge une analyse de rentabilisation unique . L'API Kafka Streams est un produit autonome qui offre des fonctionnalités avancées destinées aux entreprises clientes. La fonctionnalité la plus notable de Kafka Streams, transactions , aide les entreprises à assurer la cohérence de la sortie générée par le flux de messages. Pour cette raison, Kafka dispose de deux API distinctes pour chaque cas d'utilisation.

Par exemple, la bibliothèque Kafka Streaming permet aux entreprises d'offrir une livraison «exactement une fois» pour les messages. La livraison garantit que les offres Kafka et Pulsar sont :

• Au moins une fois
• Au plus une fois
• Exactement une fois

La livraison "exactement une fois" garantit que pour chaque message, il y aura une sortie associée, ce qui garantit que le message est traité en cas de plantage d'un consommateur. Cependant, cela est impossible avec l' API Consumers , qui permet aux applications de lire des flux de données à partir de sujets dans le cluster Kafka, ce qui vous oblige à écrire la plupart des fonctionnalités de la plate-forme. Cela rend difficile l'utilisation d'une seule bibliothèque cliente pour toutes les fonctionnalités dont vous avez besoin pour votre entreprise, ce qui n'est pas durable lorsque vous travaillez à grande échelle.

Entrez Pulsar

Pour chaque limitation de Kafka soulignée ci-dessus, Pulsar a une solution. Les sections suivantes décrivent certains des avantages de Pulsar.

Stockage de données persistant

Pulsar fournit les fonctionnalités de diffusion de messages et de publication de Kafka, mais ajoute la possibilité de conserver les données pendant de plus longues périodes.

Pulsar offre la persistance du stockage des données à l'aide d'Apache Bookkeeper. Bookkeeper gère les données et aide à décharger la persistance des données en dehors du cluster. Vous pouvez utiliser d'autres supports de stockage de données tels qu'AWS S3 pour stocker des données et évoluer au-delà des limites d'un disque local, ce qui signifie que vous pouvez facilement étendre vos applications sans problèmes de stockage.

De plus, Pulsar inclut une fonctionnalité de stockage hiérarchisé qui permet de déplacer les données entre les options de stockage à chaud et à froid ; les données peuvent ensuite être stockées en chambre froide aussi longtemps que l'entreprise en a besoin. Le cluster ne nécessite pas de modification continue de la taille de l'infrastructure pour les options de stockage.

Pulsar déplace également automatiquement les anciens messages de Bookkeeper vers une option de stockage à froid moins chère en rendant un segment des données immuable. Le segment immuable peut être déplacé vers un stockage moins cher, permettant ainsi à Pulsar d'accepter des quantités infinies de données.

Expérience développeur

Du point de vue du développeur, Pulsar propose une bibliothèque client intégrée et simple pour tous les principaux langages (Java, Python, Go et C#). Les bibliothèques aident les développeurs à démarrer rapidement avec la plate-forme, ce qui est essentiel lors du développement et de la publication d'applications à grande échelle. Le protocole binaire de Pulsar étend les fonctionnalités de la bibliothèque client selon les besoins, rendant la bibliothèque adaptée à la croissance. (Voici la liste des bibliothèques client Pulsar disponibles et officiellement prises en charge. )

Fonctions Pulsars

Pulsar Functions est une fonctionnalité prête à l'emploi qui permet aux développeurs d'écrire du code personnalisé capable de traiter les messages dans le flux de messages sans avoir besoin de déployer un système comme Apache Heron, Apache Flink ou Apache Storm.

Les fonctions Pulsar sont utilisées dans un cadre de connecteur sans serveur Pulsar IO, ce qui facilite le déplacement des données depuis et vers Pulsar. Ce système prêt à l'emploi permet à Pulsar d'être connecté à des bases de données SQL et NoSQL externes, telles qu'Apache Cassandra.

De plus, ce traitement des messages est natif du flux, ce qui signifie que les messages sont traités et transformés à l'intérieur du cluster avant d'être livrés aux consommateurs. Parce que les fonctions Pulsar sont l'infrastructure informatique du système de messagerie Pulsar, elles prennent en charge les objectifs au niveau de l'entreprise, y compris la productivité des développeurs, la facilité de dépannage et la simplicité opérationnelle - des qualités cruciales pour les performances des applications et des équipes lorsque vous travaillez à grande échelle.

Évolutivité

Outre les fonctionnalités et services mentionnés ci-dessus et leur influence sur l'évolutivité, Pulsar propose diverses fonctionnalités qui en font une option évolutive pour les besoins de diffusion et de publication de messages de votre entreprise.

La fonction de géo-réplication de Pulsar permet à Pulsar d'être hautement évolutif. Le cluster réplique les données vers plusieurs emplacements à travers le monde pour les utiliser en cas de sinistre entraînant l'arrêt de l'application. La réplication est prise en charge pour être synchrone et asynchrone. La réplication asynchrone est plus rapide mais offre moins de garanties de cohérence des données que la réplication synchrone.

Pulsar utilise un concept de courtier par sujet, garantissant que le même courtier gère toutes les demandes pour un sujet. L' architecture Pulsar montre comment l'approche basée sur le courtier améliore les performances du système par rapport à un cluster Kafka.

Emballer

Kafka et Pulsar présentent certaines similitudes, mais certaines différences fondamentales méritent d'être prises en compte lors de la sélection de la plate-forme à utiliser, en particulier lorsque vous avez besoin d'évolutivité.

L'architecture, les capacités de stockage et la convivialité de Kafka présentent de nombreux défis qui peuvent entraver la capacité d'une organisation à se développer. Essayer de faire évoluer vos clusters Kafka au-delà d'un point devient coûteux et pose souvent plus de problèmes que cela n'en vaut la peine. De la manière dont il stocke les données à la manière dont il prend en charge la transformation des messages, Pulsar est le challenger unifié de nouvelle génération de Kafka, conçu pour l'évolutivité.

Découvrez DataStax Astra Streaming , basé sur Apache Pulsar et fourni en tant que service entièrement géré.

Par Mary Grygleski. Mary est une avocate des développeurs de streaming chez DataStax. Elle se concentre sur le développement de la sensibilisation et de la sensibilisation de la communauté pour Java, la technologie open source et cloud, y compris les architectures cloud natives, sans serveur, pilotées par les événements, les microservices et réactives.