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 ce 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
Pour dimensionner ou mettre à l'échelle un cluster Managed Service pour Apache Kafka, il vous suffit de définir le nombre total de vCPU et la taille de la RAM pour le cluster. La gestion des courtiers, y compris du stockage, est entièrement automatisée. Pour répondre aux demandes des clients, vous pouvez surveiller l'utilisation des vCPU et d'autres ressources, et les ajuster à la hausse ou à la baisse.
Lorsque vous définissez le nombre de vCPU et la taille de la RAM, le service automatise le redimensionnement et le provisionnement des courtiers. Si l'augmentation de la taille du cluster nécessite un nouvel agent, le service peut rééquilibrer automatiquement les partitions entre les agents.
Provisionnement de l'agent
Lorsque vous configurez la taille totale des vCPU et de la RAM pour le cluster, le service provisionne de nouveaux courtiers et met à l'échelle les courtiers existants. Pour une configuration de cluster typique, la taille totale des processeurs virtuels et de la RAM est répartie de manière égale entre tous les courtiers. Cela signifie que les nombres fractionnaires de vCPU par courtier sont autorisés, bien qu'un minimum d'un vCPU par courtier soit requis. Tous les clusters sont répartis sur trois zones. Cela signifie qu'un minimum de trois processeurs virtuels et de trois Gio de RAM par cluster est requis.
À mesure que vous augmentez la taille du cluster, les courtiers sont mis à l'échelle verticalement jusqu'à 15 vCPU par courtier. Une fois cette limite atteinte, le service crée de nouveaux brokers. Lorsque vous réduisez la taille du cluster, les courtiers existants sont réduits à une seule vCPU, mais ne sont pas supprimés.
La taille maximale des courtiers peut changer à tout moment. Cette limite a été choisie pour maintenir une mise à l'échelle linéaire du débit du courtier avec le nombre de vCPU.
Algorithme de scaling
Le nombre de brokers est déterminé par la capacité totale de processeurs virtuels ou de mémoire du cluster. Le ratio de scaling est de 1 broker pour 15 processeurs virtuels ou 120 gibioctets (Gio) de ressources, selon le nombre de brokers le plus élevé. Le ratio entre les processeurs virtuels et la mémoire (processeur virtuel:Gio) doit rester compris entre 1:1 et 1:8. Les brokers sont répartis de manière égale entre les trois zones, avec une différence maximale d'un.
Par exemple, si vous configurez un cluster avec 70 processeurs virtuels et 130 Gio de RAM, ainsi qu'un facteur de réplication de 3, le calcul suivant détermine le nombre de courtiers :
Calculez le nombre de brokers requis pour tenir compte des vCPU :
ceiling(70 vCPUs / 15 vCPUs)= 5 brokersCalculez le nombre de brokers requis pour tenir compte de la mémoire :
ceiling(130 GiB / 120 GiB)= 2 brokers
Dans ce scénario, le cluster comporte cinq brokers, car leur nombre est déterminé par le nombre de processeurs virtuels. Deux des trois zones comportent chacune deux courtiers, et la dernière zone en comporte un.
Gestion de l'espace de stockage
La gestion de l'espace de stockage est automatisée. Dans la plupart des cas, vous êtes responsable de la définition de la durée de conservation des sujets individuels pour contrôler les coûts ou respecter vos règles de conservation des données. Vous n'avez pas besoin de provisionner ni de gérer des disques persistants.
Le service s'appuie sur le stockage hiérarchisé (KIP-405). Le stockage hiérarchisé combine des volumes Persistent Disk préprovisionnés associés à des courtiers avec un stockage d'objets pratiquement illimité.
Le service alloue au moins 100 Gio de disques persistants SSD pour chaque vCPU afin d'équilibrer les performances, la disponibilité et le coût. Vous êtes facturé 100 Gio par processeur virtuel, même si la taille réelle du disque par courtier peut dépasser cette valeur. La taille du disque par courtier n'est jamais réduite, même si le cluster est réduit.
Chaque leader de partition met en mémoire tampon les messages dans des fichiers de segment sur ces disques persistants. Une fois qu'un segment est déployé, il est déplacé vers un stockage d'objets persistant reposant sur Cloud Storage régional. La taille de ces fichiers de segment est définie par les paramètres log.roll.ms et log.segment.bytes.
Bien que ces informations soient utiles à comprendre, le stockage est géré par le service. Les configurations spécifiques, telles que la capacité de disque persistant par processeur virtuel, sont des détails d'implémentation qui peuvent changer. Vous n'avez pas d'accès direct aux buckets Cloud Storage utilisés pour le stockage persistant.
Rééquilibrage
Pour que les nouveaux courtiers provisionnés soient utiles au maintien des performances, une partie du trafic des courtiers existants doit être transférée vers ces nouvelles machines. Pour faciliter cette opération, vous pouvez activer le rééquilibrage automatique.
Lorsque le rééquilibrage automatique est activé, le service rééquilibre automatiquement les partitions des brokers existants lorsqu'un nouveau broker est provisionné. Le modèle de stockage par niveaux vérifie qu'une quantité relativement faible de données doit être copiée vers de nouveaux courtiers, ce qui accélère le rééquilibrage.
L'algorithme de rééquilibrage est basé sur le nombre de partitions. Elle ne tient pas compte du trafic réel diffusé par chaque partition.
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 dans 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 offre 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, telles que la création, la mise à jour et la suppression de ressources. L'autorisation pour les 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 IAM ou avec des LCA Kafka sur le cluster.Google Cloud Pour en savoir plus, consultez Configurer l'authentification SASL.
mTLS : les principaux qui s'authentifient avec mTLS sont autorisés par le biais des 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 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 d'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 du registre de schémas Confluent, 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 de 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 des services Google Cloud tels que BigQuery, Cloud Storage et Pub/Sub. Kafka Connect permet d'intégrer des données de manière évolutive et fiable, avec des frais opérationnels réduits, ainsi que des fonctionnalités de surveillance et de 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 thème par défaut nécessite au moins trois répliques. La reconnaissance des racks garantit 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 de santé 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 les 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 le travail interactif dans un navigateur.
- La gcloud CLI pour le travail interactif dans un shell.
- Bibliothèques clientes en Java, Python, Go et d'autres langages pour le développement et les scripts personnalisés.
Pour la surveillance et le dépannage, le service exporte les 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. Ils sont consultables et peuvent être utilisés 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.
Compatible, 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 acceptées.
La compression des thèmes avec
zstdn'est pas acceptée. Les valeurs acceptées pourcompression.typeincluentlz4,gzip,snappyetuncompressed.Bien que vous puissiez modifier les configurations de broker avec le mode de mise à jour
read-onlyà tout moment, 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.auto.create.topics.enableetbackground.threadssont des exemples de configurationsread-only. Les mises à jour des configurations avec le mode de mise à jourcluster-wide, commemessage.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.idet les paramètres liés au stockage, tels queremote.log.storage.system.enable.
Étape suivante
- Créez un cluster Managed Service pour Apache Kafka.
- Envoyez et recevez des messages à l'aide d'un cluster Managed Service pour Apache Kafka.
- Consultez les limites de Managed Service pour Apache Kafka.
- En savoir plus sur les tarifs de Managed Service pour Apache Kafka