Présentation de Managed Service pour Apache Kafka

Managed Service pour Apache Kafka est un service Google Cloud qui vous aide à exécuter des clusters Apache Kafka Open Source sécurisés et évolutifs. Cette page présente les tâches que le service automatise et simplifie pour vous. Pour en savoir plus sur Apache Kafka, consultez le site Web Apache Kafka.

Dimensionnement et scaling simples

Lorsque vous créez un cluster Managed Service pour Apache Kafka, vous spécifiez le nombre total de vCPU et la mémoire du cluster. Le service provisionne automatiquement un certain nombre de courtiers en fonction du nombre de vCPU.

Pour répondre aux demandes des clients, vous pouvez surveiller l'utilisation des ressources et, si nécessaire, faire évoluer votre cluster en mettant à jour le nombre de vCPU et la mémoire. La mise à l'échelle d'un cluster peut entraîner le provisionnement de courtiers supplémentaires. Si l'augmentation de la taille du cluster nécessite un nouvel agent, le service peut rééquilibrer automatiquement les partitions entre les agents.

Pour savoir comment choisir la taille d'un cluster, consultez Planifier la taille de votre cluster Kafka.

Gestion de l'espace de stockage

Managed Service pour Apache Kafka utilise le stockage hiérarchisé. Le stockage hiérarchisé combine deux niveaux de stockage :

  • Une quantité limitée de stockage local rapide, sous la forme de disques préprovisionnés associés aux courtiers.
  • Stockage à distance pratiquement illimité. Le stockage à distance est moins cher et n'a pas besoin d'être provisionné à l'avance.

Le système de stockage par niveaux vous permet de stocker de grands volumes de données en limitant le risque de manquer d'espace disque. Il peut également coûter moins cher que l'utilisation du stockage local seul.

Vous êtes responsable de la définition de la durée de conservation pour chaque thème afin de contrôler les coûts ou de respecter vos règles de conservation des données.

Mise en réseau flexible

Le service rend un cluster accessible de manière sécurisée depuis n'importe quel VPC. Cela inclut l'accès depuis plusieurs VPC, projets et régions.

Pour configurer la mise en réseau d'un cluster, vous devez fournir l'ensemble des sous-réseaux où le cluster est accessible. Le service provisionne des adresses IP privées pour les serveurs d'amorçage et les courtiers de chaque sous-réseau. Il configure également Cloud DNS privé avec des URL pour chaque adresse IP. Les serveurs d'amorçage disposent d'un équilibreur de charge. Il n'y a donc qu'une seule URL d'amorçage par cluster. Les URL sont les mêmes pour tous les VPC. Les configurations client peuvent donc être cohérentes dans tous les environnements.

Ce niveau de flexibilité est possible grâce à Private Service Connect (PSC). Chaque adresse IP allouée à un cluster nécessite un point de terminaison PSC. Les points de terminaison sont provisionnés automatiquement.

Clusters sécurisés

Le service propose les fonctionnalités suivantes pour la sécurité des clusters : authentification, autorisation, chiffrement, application de correctifs et isolation des ressources. Il interdit également les connexions et le stockage non authentifiés et non chiffrés.

Authentification

Le service est compatible avec deux méthodes d'authentification : SASL (Simple Authentication and Security Layer) et mTLS (mutual Transport Layer Security). L'authentification mTLS est disponible sur les clusters créés après le 24 juin 2025. Toutes les connexions aux clusters gérés s'authentifient avec un principal qui est une identité IAM à l'aide de SASL ou d'un certificat client à l'aide de mTLS. Les comptes humains, de service et fédérés sont acceptés comme comptes principaux lorsque vous utilisez SASL.

Le service n'est pas compatible avec d'autres protocoles, y compris SASL/GSSAPI, SASL/SCRAM-SHA-256 et SASL/SCRAM-SHA-512. Le service n'autorise pas non plus les connexions non authentifiées.

Autorisation

Le service utilise une approche par couches pour l'autorisation. IAM contrôle les actions de gestion des clusters, comme la création, la mise à jour et la suppression de ressources. L'autorisation des comptes principaux authentifiés dépend de la méthode utilisée :

  • SASL : les comptes principaux utilisant IAM sont autorisés par le biais d'associations de rôles IAMGoogle Cloud ou avec des LCA Kafka sur le cluster. Pour en savoir plus, consultez Configurer l'authentification SASL.

  • mTLS : les principaux qui s'authentifient avec mTLS sont autorisés via les LCA Kafka. Pour en savoir plus, consultez Configurer l'authentification mTLS.

Vous pouvez gérer les LCA Kafka avec les outils Google Cloud ou des outils Kafka tiers. Pour en savoir plus sur la configuration des LCA IAM et Kafka, consultez Contrôle des accès avec les LCA IAM et Kafka.

Chiffrement

Le chiffrement est obligatoire. Toutes les connexions aux clusters doivent utiliser le protocole TLS. Les certificats TLS présentés par les courtiers sont signés par l'Public Certificate Authority. Les données stockées sont toujours chiffrées. Choisissez d'utiliser des clés de chiffrement gérées par Google ou des clés de chiffrement gérées par le client (CMEK) pour le chiffrement au repos.

Application de correctifs

L'équipe du service suit les failles de sécurité découvertes dans le code Open Source. Lorsque le service détecte des failles, il corrige automatiquement vos clusters.

Isolation des ressources

L'isolation des ressources est une autre fonctionnalité de sécurité du service. Le service géré déploie des clusters dans des projets locataires dans un VPC privé inaccessible via des adresses IP publiques. Chacun de vos projets dispose d'un projet locataire dédié, avec un compte agent de service dédié. Cela permet de limiter le champ d'accès accordé au service.

Registre de schémas

Pour simplifier la coordination entre les producteurs et les consommateurs, Managed Service pour Apache Kafka inclut une API de registre de schémas. Un registre fourni par le service sert de dépôt de schémas partagés entre les applications.

Le service implémente l'API REST Confluent Schema Registry, qui facilite l'intégration aux applications Kafka existantes. Les formats de schéma Apache Avro et Protocol Buffer (Protobuf) sont acceptés. Le format JSON n'est pas accepté.

Managed Service pour Apache Kafka propose également une API et un ensemble d'outils d'administration pour gérer les registres et les schémas. L'ensemble d'outils inclut la consoleGoogle Cloud , gcloud CLI et les bibliothèques clientes.

Pour en savoir plus sur le registre de schémas, consultez la présentation du registre de schémas.

Intégration de données avec Kafka Connect

Managed Service pour Apache Kafka simplifie l'intégration des données grâce à Kafka Connect. Kafka Connect propose plusieurs plug-ins de connecteur intégrés hébergés dans des clusters Connect. Ces connecteurs sont utilisés pour la migration, la sauvegarde, la reprise après sinistre, la haute disponibilité et l'intégration de données. Ces connecteurs vous permettent de connecter vos clusters Managed Service pour Apache Kafka à différents systèmes, y compris d'autres déploiements Kafka et services Google Cloud tels que BigQuery, Cloud Storage et Pub/Sub. Kafka Connect fournit une intégration de données évolutive et fiable avec des frais opérationnels réduits, ainsi qu'une surveillance et une journalisation intégrées.

Pour en savoir plus sur Kafka Connect, consultez la présentation de Kafka Connect.

Clusters à haute disponibilité

L'objectif du service est de fournir des clusters régionaux pour les applications critiques. Plus précisément, le service vous protège contre les défaillances de zones ou de courtiers individuels.

Pour ce faire, tous les clusters sont provisionnés dans une configuration à trois zones compatible avec les racks. La configuration de topic par défaut nécessite au moins trois répliques. La reconnaissance des racks permet de s'assurer que les réplicas sont créés dans différentes zones. Le nombre minimal par défaut d'instances répliquées synchronisées est de deux. Cela signifie que votre cluster peut tolérer la perte complète d'une zone ou d'un courtier.

Lorsqu'un courtier échoue en raison d'une défaillance logicielle, matérielle ou réseau, il est remplacé automatiquement. Lorsque le service détecte une défaillance du courtier, il le redémarre automatiquement, sur une autre machine si nécessaire. Une fois l'agent disponible, Apache Kafka l'intègre au cluster. En cas de défaillance complète d'une zone, il peut être impossible de créer un courtier. Toutefois, le cluster continue de fonctionner tant que les deux autres zones restent disponibles.

En plus de ces fonctionnalités spécifiques, une liste croissante d'outils et de processus internes maintiennent de manière proactive l'état du service, du code Apache Kafka et des mises à jour. Les sauvegardes de données et de métadonnées sont conservées à plusieurs niveaux, ce qui permet au service de se rétablir en cas d'erreur humaine ou de défaillance logicielle.

Le service ne protège pas contre les défaillances régionales ou birégionales. Pour les applications qui nécessitent ce niveau de protection, nous vous recommandons d'exécuter deux clusters régionaux distincts. Vous pouvez synchroniser les données entre deux clusters à l'aide d'outils tels que MirrorMaker 2.0 de Kafka Connect.

Outils adaptés à votre style d'administration

Le service vise à offrir un ensemble complet d'outils pour la gestion et le dépannage de vos clusters. Cela inclut des outils d'administration, de surveillance et de journalisation.

Managed Service pour Apache Kafka est exposé en tant qu'API Google Cloud. Cela signifie que vous pouvez gérer les clusters et les ressources de cluster à l'aide des API REST et gRPC. Plusieurs clients et interfaces sont fournis pour ces API, y compris

  • Fournisseurs Terraform si vous préférez l'approche Infrastructure as Code.
  • Interface utilisateur dans la console Google Cloud pour un travail interactif dans un navigateur.
  • La gcloud CLI pour le travail interactif dans un shell.
  • Bibliothèques clientes en Java, Python, Go et dans d'autres langages pour le développement et les scripts personnalisés.

Pour la surveillance et le dépannage, le service exporte des métriques vers Cloud Monitoring. Certaines métriques sont disponibles dans l'UI du service. Un ensemble complet est disponible dans Cloud Monitoring pour le travail interactif, la configuration des alertes et l'exportation vers d'autres systèmes.

Le service exporte également les journaux du courtier vers Cloud Logging. Vous pouvez les rechercher et les utiliser pour créer des métriques et des alertes basées sur les journaux.

Mises à niveau et correctifs

Les clusters Managed Service pour Apache Kafka s'exécutent sur la version 3.7.1 d'Apache Kafka. Le service corrige automatiquement les failles de sécurité critiques.

Les mises à jour de l'infrastructure sous-jacente, y compris du système d'exploitation et des couches d'orchestration, sont continues et automatiques. Les courtiers sont mis à jour avec un redémarrage progressif, sans temps d'arrêt pour le cluster.

Le service ne met pas automatiquement à niveau le code Apache Kafka exécuté sur les courtiers vers de nouvelles versions mineures.

Coût transparent

Le modèle de tarification de Managed Service pour Apache Kafka est semblable aux frais que vous voyez lorsque vous exécutez Apache Kafka vous-même sur Compute Engine. Vous payez les ressources que vous provisionnez (processeur virtuel, RAM et stockage local) et que vous consommez (stockage persistant et transfert de données). Le stockage persistant et les vCPU coûtent plus cher avec Managed Service pour Apache Kafka qu'avec la configuration d'un système similaire par vous-même. En revanche, les prix du transfert de données et du stockage local sont similaires entre Managed Service pour Apache Kafka et Kafka autogéré. Pour en savoir plus sur les tarifs, consultez Tarifs de Managed Service pour Apache Kafka.

Compatibilité, car nous exécutons Apache Kafka

Enfin, Managed Service pour Apache Kafka exécute le même logiciel Open Source que vous utilisez peut-être déjà dans votre environnement. Vous n'avez pas besoin de modifier le code de votre application pour la migrer vers le service.

Limites

Managed Service pour Apache Kafka présente les limites suivantes :

  • Chaque cluster doit disposer de ressources égales dans chacune des trois zones. Les clusters Managed Service pour Apache Kafka à une ou deux zones ne sont pas compatibles.

  • Vous ne pouvez pas choisir les zones lorsque vous créez le cluster.

  • Vous ne pouvez pas configurer le volume de stockage local sur un cluster.

  • Managed Service pour Apache Kafka s'exécute en mode KRaft. Le mode Zookeeper n'est pas pris en charge.

  • Les API JMX pour les métriques ne sont pas prises en charge.

  • Vous pouvez modifier les configurations de broker avec le mode de mise à jour read-only à tout moment, mais ces modifications ne prennent effet que lorsque les brokers redémarrent. Les redémarrages ont lieu périodiquement dans le cadre des processus de maintenance et de mise à niveau de Google, mais il n'existe pas de calendrier défini ni de moyen de les déclencher manuellement. Vous ne pouvez donc pas contrôler le moment où ces modifications prennent effet. Les configurations read-only incluent auto.create.topics.enable et background.threads. Les mises à jour des configurations avec le mode de mise à jour cluster-wide, telles que message.max.bytes, ne nécessitent pas de redémarrage et prennent effet immédiatement.

  • Certains paramètres de configuration du courtier sont gérés par le service et ne peuvent pas être mis à jour. Cela inclut broker.id et les paramètres liés au stockage, tels que remote.log.storage.system.enable.

Étape suivante

Apache Kafka® est une marque déposée d'Apache Software Foundation ou de ses sociétés affiliées aux États-Unis et/ou dans d'autres pays.