Migrer de Kafka vers Pub/Sub

Ce document est utile si vous envisagez de migrer d'Apache Kafka autogéré vers Pub/Sub, car il peut vous aider à comprendre les fonctionnalités, la tarification et les cas d'utilisation. Chaque section identifie un cas d'utilisation courant de Kafka et offre des conseils pratiques pour obtenir les mêmes capacités dans Pub/Sub.

Présentation de Pub/Sub

Pub/Sub est un service de messagerie asynchrone. Pub/Sub dissocie les services qui produisent des événements de services qui traitent des événements. Vous pouvez utiliser Pub/Sub comme service de middleware de messagerie ou d'ingestion et de diffusion d'événements pour les pipelines d'analyse de flux. Dans les deux scénarios, une application d'éditeur crée et envoie des messages à un sujet. Les applications d'abonnés créent un abonnement associé à un sujet pour recevoir des messages de celui-ci. Un abonnement est une entité nommée qui représente un intérêt pour la réception de messages sur un sujet particulier.

Pub/Sub s'exécute dans toutes les régions Google Cloud. Pub/Sub dirige le trafic de l'éditeur vers le centre de données Google Cloud le plus proche autorisant le stockage de données, tel que défini dans la règle de restriction d'emplacement des ressources.

Pub/Sub peut s'intégrer à de nombreux services Google Cloud, tels que Dataflow, Cloud Storage. et Cloud Run. Vous pouvez configurer ces services pour qu'ils servent de sources de données pouvant publier des messages dans Pub/Sub ou de récepteurs de données pouvant recevoir des messages de Pub/Sub.

Présentation de Kafka

Apache Kafka est une plate-forme Open Source distribuée de streaming d'événements. Elle permet aux applications de publier, de s'abonner, de stocker et de traiter des flux d'événements. Le serveur Kafka est exécuté en tant que cluster de machines avec lesquelles les applications clientes interagissent pour lire, écrire et traiter les événements. Kafka vous permet de dissocier des applications, d'envoyer et de recevoir des messages, d'effectuer le suivi des activités, d'agréger les données des journaux et de traiter les flux.

Dans le cluster Kafka, certains nœuds du cluster sont désignés comme brokers. Les brokers reçoivent les messages des producteurs et les stockent sur un disque. Les messages stockés sont organisés par sujet et partitionnés entre plusieurs brokers différents dans le cluster. Les nouveaux événements publiés dans un sujet sont ajoutés à la fin de l'une des partitions du sujet. Les consommateurs peuvent ensuite récupérer des messages à partir des brokers, qui sont lus à partir du disque et envoyés au consommateur.

Comprendre les différences entre Kafka et Pub/Sub

Le diagramme suivant illustre les différences de stratégie de scaling entre Kafka et Pub/Sub :

Stratégie de scaling avec des partitions pour Kafka et sans partition pour Pub/Sub.

Dans le diagramme précédent, chaque M représente un message. Les brokers Kafka gèrent plusieurs partitions de messages ordonnées, représentées par les lignes horizontales de messages. Les utilisateurs lisent les messages d'une partition particulière dont la capacité est basée sur la machine qui héberge cette partition. Pub/Sub n'a pas de partitions, mais les consommateurs lisent à partir d'un sujet qui réalise un autoscaling en fonction de la demande. Configurez chaque sujet Kafka avec le nombre de partitions dont vous avez besoin pour gérer la charge de consommation attendue. Pub/Sub s'adapte automatiquement à la demande.

Comparer les fonctionnalités

Le tableau suivant compare les fonctionnalités d'Apache Kafka avec les fonctionnalités de Pub/Sub :

Apache Kafka Pub/Sub
Tri des messages Oui, dans les partitions Oui, dans les sujets
Déduplication des messages Oui Oui, avec Dataflow
Abonnements Push Non Oui
File d'attente de lettres mortes
(file d'attente de messages impossibles à traiter)		 À partir de la version 2.0 Oui
Transactions Oui Non
Stockage des messages Limité uniquement par le stockage disponible 31 jours.
Un sujet peut conserver les messages publiés, y compris les messages confirmés, pendant 31 jours maximum. Pour ce faire, utilisez la propriété "message_retention_duration" du sujet.
Relecture des messages Oui Oui
Localité Le cluster local peut être dupliqué à l'aide de MirrorMaker Service distribué à l'échelle mondiale avec des emplacements de stockage de messages configurables
Journalisation et surveillance Service autogéré Automatisée avec Cloud Logging et Cloud Monitoring
Traitement par flux Oui avec KSQL Oui avec Dataflow

Comprendre le stockage et la relecture des messages Pub/Sub

Par défaut, Pub/Sub conserve les messages non confirmés pendant sept jours maximum, mais vous pouvez configurer les abonnements Pub/Sub pour les conserver pendant sept jours maximum également, en fonction de l'âge du message le plus ancien (confirmé ou non) dans l'abonnement. En conservant les messages confirmés, vous pouvez rouvrir certains ou tous ces messages en fonction d'un horodatage. Lorsque vous rouvrez des messages en fonction d'un horodatage, tous les messages reçus après l'horodatage sont marqués comme non confirmés. Les messages non confirmés sont ensuite renvoyés.

Vous pouvez créer des instantanés d'abonnements individuels à la demande sans avoir à configurer votre abonnement à l'avance. Par exemple, vous pouvez créer un instantané lors du déploiement du nouveau code d'abonné, car vous devrez peut-être récupérer des accusés de réception inattendus ou incorrects.

Sécurité intégrée avec des sujets de lettres mortes

Pub/Sub fournit des fonctionnalités semblables à celles de la gestion des erreurs Kafka 2.0 et à la façon dont Kafka Connect gère les sujets de lettres mortes. Pour informer Pub/Sub qu'un message a bien été distribué, les abonnés aux sujets Pub/Sub peuvent accuser réception des messages qu'ils reçoivent et traitent. Si vos abonnés ne peuvent pas traiter les messages pendant un certain temps, Pub/Sub peut transférer automatiquement ces messages vers une file d'attente de lettres mortes et les stocker pour pouvoir y accéder ultérieurement. Vous pouvez configurer le nombre de tentatives effectuées par Pub/Sub pour distribuer les messages avant de les envoyer à la file d'attente de lettres mortes.

Dédupliquer des messages dans Pub/Sub à l'aide de Dataflow

Pub/Sub distribue chaque message publié au moins une fois pour chaque abonnement. En général, l'application d'une distribution de type "plusieurs fois" nécessite que votre abonné soit idempotent lors du traitement des messages. Si vos abonnés existants ne peuvent pas fonctionner de manière idempotente, vous pouvez intégrer Dataflow à la déduplication des messages. Si vos abonnés voient un taux élevé de messages en double, cela peut indiquer qu'ils ne confirment pas correctement les messages ou que le délai d'accusé de réception est trop court.

Trier des messages dans Pub/Sub

Si vos applications d'abonnés Kafka se basent sur l'ordre des messages, vous pouvez appliquer cette exigence avec Pub/Sub lorsque vous utilisez des clés de tri. Actuellement, l'ordonnancement est garanti pour les messages publiés dans une région donnée. Pour tirer parti de l'ordre des messages, assurez-vous que vos éditeurs et vos abonnés utilisent des points de terminaison de localisation pour acheminer vos messages vers la bonne région.

Comprendre les responsabilités des services auto-hébergés et des services gérés

Le tableau suivant compare les fonctionnalités auto-hébergées avec Kafka et celles gérées par Google à l'aide de Pub/Sub:

Apache Kafka Pub/Sub
Qui peut en bénéficier ? Déployer Kafka manuellement dans des emplacements supplémentaires Déploiement dans toutes les régions Google Cloud pour une haute disponibilité et une faible latence
Reprise après sinistre Concevoir et gérer votre propre sauvegarde et réplication Géré par Google
Gestion des infrastructures Déployez et exploitez manuellement des machines virtuelles (VM) ou des machines. Vous devez maintenir une gestion des versions et des correctifs cohérents. Géré par Google
Planification des capacités Planifier manuellement les besoins de stockage et de calcul à l'avance Géré par Google
Assistance Aucun Personnel d'astreinte téléphonique et assistance disponibles 24h/24

Limites de taille des messages Pub/Sub et solutions alternatives

Kafka et Pub/Sub fonctionnent tous deux pour gérer de grands volumes de petits messages. Kafka ne limite pas la taille des messages et vous laisse configurer la taille des messages autorisés, alors que Pub/Sub limite les messages à 10 Mo. Pour envoyer indirectement des charges utiles plus importantes, stockez d'abord l'objet dans Cloud Storage, comme indiqué dans le schéma suivant :

L'éditeur stocke un objet dans Cloud Storage.

L'image précédente montre que lorsque l'éditeur stocke l'objet dans Cloud Storage, il publie un message contenant l'URL de cet objet stocké. Lorsque l'abonné reçoit le message contenant l'URL, il télécharge le fichier depuis Cloud Storage et continue le traitement comme d'habitude.

Comparaison des coûts de Kafka et Pub/Sub

La manière dont vous estimez et gérez les coûts dans Pub/Sub est différente de celle de Kafka. Les coûts d'un cluster Kafka sur site ou dans le cloud incluent le coût des machines, du disque, de la mise en réseau, des messages entrants et sortants, ainsi que les frais généraux liés à la gestion et à la maintenance de ces systèmes et de leur infrastructure associée. Lors de la gestion d'un cluster Kafka, les machines doivent souvent être mises à niveau et corrigées manuellement, la capacité du cluster doit souvent être planifiée, et la mise en œuvre de la reprise après sinistre implique une planification et des tests étendus. Vous devez déduire et agréger tous ces coûts pour connaître le coût total de possession réel (TCO).

Les tarifs de Pub/Sub incluent le transfert de données des éditeurs et des abonnés, ainsi que le coût du stockage temporaire des messages non confirmés. Vous payez en fonction des ressources que vous consommez, en ajustant automatiquement sa capacité en fonction des exigences de votre application et de votre budget.

Concevoir des solutions fiables

Pub/Sub est un service géré mondial qui s'exécute dans toutes les régions Google Cloud. Les sujets Pub/Sub sont mondiaux, ce qui veut dire qu'ils sont visibles et accessibles depuis n'importe quel emplacement Google Cloud. Chaque message n'est toutefois stocké que dans une seule région Google Cloud : la plus proche de l'éditeur et celle autorisée par la règle d'emplacement des ressources. Ainsi, un sujet peut contenir des messages stockés dans différentes régions Google Cloud. Pub/Sub résiste aux pannes de zone. Lors d'une panne régionale, les messages stockés dans cette région peuvent être inaccessibles jusqu'à la restauration du service. En fonction de vos exigences de disponibilité, vous pouvez utiliser des points de terminaison de service de localisation pour mettre en œuvre une règle de basculement en cas de panne régionale.

Sécurité et authentification

Apache Kafka est compatible avec plusieurs mécanismes d'authentification, tels que l'authentification par certificat client, Kerberos, LDAP, ainsi que le nom d'utilisateur et le mot de passe. Pour l'autorisation, Kafka permet d'utiliser des listes de contrôle d'accès (LCA) pour déterminer quels producteurs et consommateurs ont accès à quels sujets.

Pub/Sub est compatible avec l'authentification des comptes utilisateur Google Cloud et des comptes de service. Le contrôle d'accès précis aux sujets et aux abonnements Pub/Sub est régi par la gestion de l'authentification et des accès (IAM) dans Google Cloud. Les opérations Pub/Sub ont un débit limité lors de l'utilisation de comptes utilisateur. Si vous devez effectuer des transactions en grand nombre, vous pouvez utiliser des comptes de service pour interagir avec Pub/Sub.

Planifier votre migration vers Pub/Sub

Toute migration vers Google Cloud commence par l'évaluation de vos charges de travail et la construction de vos fondations.

Migration en plusieurs phases à l'aide du connecteur Pub/Sub Kafka

Le connecteur Pub/Sub Kafka vous permet de migrer votre infrastructure Kafka vers Pub/Sub en plusieurs phases.

Vous pouvez configurer le connecteur Pub/Sub pour transférer tous les messages sur des sujets spécifiques de Kafka vers Pub/Sub. Vous pouvez ensuite mettre à jour des applications d'abonné individuelles pour recevoir des messages sur ces sujets depuis Pub/Sub, pendant que vos applications d'éditeur continuent à publier des messages dans Kafka. Cette approche par phases vous permet de mettre à jour, de tester et de surveiller les applications de vos abonnés de manière itérative, afin de réduire les risques d'erreur et de temps d'arrêt.

Cette section inclut deux diagrammes qui peuvent vous aider à visualiser ce processus en deux phases distinctes. Le schéma suivant illustre la configuration pendant la phase de migration:

Étape 1 de la migration.

Dans le diagramme précédent, les abonnés actuels continuent à recevoir les messages de Kafka et vous mettez à jour les abonnés un par un pour recevoir plutôt les messages de Pub/Sub.

Une fois que tous les abonnés à un sujet particulier ont été mis à jour pour recevoir les messages de Pub/Sub, vous pouvez mettre à jour les applications de l'éditeur pour ce sujet afin de publier des messages dans Pub/Sub. Vous pouvez ensuite tester et surveiller les flux de messages de bout en bout afin de vérifier la configuration.

Le schéma suivant illustre la configuration après que tous les abonnés reçoivent des messages de Pub/Sub :

Étape 2 de la migration

Au fil du temps, tous vos éditeurs sont mis à jour pour publier directement sur Pub/Sub, puis votre migration est terminée. De nombreuses équipes utilisent cette approche pour mettre à jour leurs applications en parallèle. Kafka peut coexister avec Pub/Sub aussi longtemps que nécessaire pour garantir la réussite de la migration.

Surveiller Pub/Sub

Pendant et après votre migration de Kafka vers Pub/Sub, il est important de surveiller vos applications. Pub/Sub exporte les métriques à l'aide de Cloud Monitoring, ce qui permet de fournir une visibilité sur les performances, le temps d'activité et l'état général de vos applications. Par exemple, vous pouvez vous assurer que vos abonnés suivent le flux des messages en surveillant le nombre de messages non distribués. Pour surveiller les messages non distribués, vous créez des alertes lorsque l'horodatage du plus ancien message non confirmé dépasse le seuil autorisé. Vous pouvez également surveiller l'état du service Pub/Sub lui-même en surveillant la métrique du nombre de requêtes d'envoi et en examinant les codes de réponse.

Étapes suivantes