Panoramica di Managed Service per Apache Kafka

Managed Service per Apache Kafka è un Google Cloud servizio che ti aiuta a eseguire cluster Apache Kafka open source sicuri, scalabili. Questa pagina fornisce una panoramica di ciò che il servizio automatizza e semplifica per te. Per saperne di più su Apache Kafka, consulta il sito web di Apache Kafka.

Dimensionamento e scalabilità semplici

Per dimensionare o scalare un cluster Managed Service per Apache Kafka, devi solo impostare il numero totale di vCPU e le dimensioni della RAM per il cluster. La gestione dei broker, incluso lo spazio di archiviazione, è completamente automatizzata. Per soddisfare le esigenze dei clienti, puoi monitorare l'utilizzo di vCPU e altre risorse e regolarle in base alle tue esigenze.

Quando imposti il numero di vCPU e le dimensioni della RAM, il servizio automatizza il ridimensionamento e il provisioning dei broker. Se l'aumento delle dimensioni del cluster richiede un nuovo broker, il servizio può ribilanciare automaticamente le partizioni tra i broker.

Provisioning dei broker

Quando configuri il numero totale di vCPU e le dimensioni della RAM per il cluster, il servizio esegue il provisioning di nuovi broker e la scalabilità di quelli esistenti. Per una configurazione tipica del cluster, il numero totale di vCPU e le dimensioni della RAM vengono suddivisi equamente tra tutti i broker. Ciò significa che sono consentiti conteggi di vCPU frazionari per broker, anche se è richiesta una singola vCPU per broker. Tutti i cluster sono distribuiti su tre zone. Ciò significa che sono richieste almeno 3 vCPU e 3 GiB di RAM per cluster.

Man mano che aumenti le dimensioni del cluster, i broker vengono scalati verticalmente fino a 15 vCPU per broker. Una volta raggiunto questo limite, il servizio crea nuovi broker. Quando riduci le dimensioni del cluster, i broker esistenti vengono ridimensionati a una singola vCPU, ma non vengono eliminati.

Le dimensioni massime del broker potrebbero cambiare in qualsiasi momento. Questo limite è stato scelto per mantenere la scalabilità lineare della velocità effettiva del broker con il numero di vCPU.

Algoritmo di scalabilità

Il numero di broker è determinato dalla capacità totale di vCPU o memoria del cluster. Il rapporto di scalabilità è di 1 broker per ogni 15 vCPU o 120 gibibyte (GiB) di risorse, a seconda di quale valore genera un numero maggiore di broker. Il rapporto tra vCPU e memoria (vCPU:GiB) deve rimanere compreso tra 1:1 e 1:8. I broker sono distribuiti equamente tra le 3 zone, con una differenza massima di uno.

Ad esempio, se configuri un cluster con 70 vCPU e 130 GiB di RAM, insieme a un fattore di replica di 3, il seguente calcolo determina il numero di broker:

  • Calcola il numero di broker necessari per tenere conto delle vCPU: ceiling(70 vCPUs / 15 vCPUs) = 5 broker

  • Calcola il numero di broker necessari per tenere conto della memoria: ceiling(130 GiB / 120 GiB) = 2 broker

In questo scenario, il cluster ha 5 broker, perché il numero di broker è determinato dal numero di vCPU. Due delle 3 zone hanno 2 broker assegnati ciascuna e l'ultima zona ha 1 broker.

Gestione dell'archiviazione

La gestione dello spazio di archiviazione è automatizzata. Nella maggior parte dei casi, è tua responsabilità impostare il tempo di conservazione dei singoli argomenti per controllare i costi o soddisfare le tue norme di conservazione dei dati. Non devi eseguire il provisioning e la gestione dei dischi permanenti.

Il servizio si basa sull'archiviazione a livelli (KIP-405). L'archiviazione a livelli combina volumi di disco permanente di cui è stato eseguito il provisioning collegati ai broker con uno spazio di archiviazione di oggetti virtualmente illimitato.

Il servizio alloca almeno 100 GiB di SSD dischi permanenti per ogni vCPU per bilanciare prestazioni, disponibilità e costi. Ti vengono addebitati 100 GiB per vCPU, anche se le dimensioni effettive del disco per broker potrebbero superare questo valore. Le dimensioni del disco per broker non vengono mai ridotte, anche se il cluster viene ridimensionato.

Ogni leader di partizione memorizza i messaggi nei file di segmento su questi dischi permanenti. Dopo il roll over di un segmento, questo viene spostato nello spazio di archiviazione di oggetti permanenti supportato da Cloud Storage regionale. Le dimensioni di questi file di segmento sono impostate dalle impostazioni log.roll.ms e log.segment.bytes.

Anche se questi dettagli sono utili da comprendere, lo spazio di archiviazione viene gestito dal servizio. Le configurazioni specifiche, come la quantità di capacità del disco permanente per vCPU, sono dettagli di implementazione che potrebbero cambiare. Non hai accesso diretto ai bucket Cloud Storage utilizzati per lo spazio di archiviazione permanente.

Ribilanciamento

Affinché i broker di cui è stato eseguito il provisioning siano utili per mantenere le prestazioni, è necessario spostare parte del traffico dai broker esistenti a queste nuove macchine. Per semplificare questa operazione, puoi attivare il ribilanciamento automatico.

Con il ribilanciamento automatico attivato, quando viene eseguito il provisioning di un nuovo broker, il servizio ribilancia automaticamente le partizioni dai broker esistenti. Il modello di archiviazione a livelli verifica che una quantità di dati relativamente piccola debba essere copiata nei nuovi broker, velocizzando il ribilanciamento.

L'algoritmo di ribilanciamento si basa sul conteggio delle partizioni. Non tiene conto del traffico effettivo gestito da ogni partizione.

Networking flessibile

Il servizio rende un cluster accessibile in modo sicuro da qualsiasi VPC. Ciò include l'accesso da più VPC, progetti e regioni.

Per configurare il networking per un cluster, fornisci l'insieme di subnet in cui il cluster è accessibile. Il servizio esegue il provisioning degli indirizzi IP privati per i server di bootstrap e i broker in ogni subnet. Configura anche Cloud DNS privato con URL per ogni indirizzo IP. I server di bootstrap hanno un bilanciatore del carico, quindi esiste un singolo URL di bootstrap per cluster. Gli URL sono gli stessi in tutti i VPC, quindi le configurazioni client possono essere coerenti tra gli ambienti.

Questo livello di flessibilità è possibile grazie a Private Service Connect (PSC). Ogni indirizzo IP allocato per un cluster richiede un endpoint PSC. Il provisioning degli endpoint viene eseguito automaticamente.

Cluster sicuri

Il servizio offre le seguenti funzionalità per la sicurezza dei cluster: autenticazione, autorizzazione, crittografia, applicazione di patch e isolamento delle risorse. Inoltre, non consente connessioni e spazio di archiviazione non autenticati e non criptati.

Autenticazione

Il servizio supporta due metodi di autenticazione: Simple Authentication and Security Layer (SASL) e mutual TLS (mTLS). L'autenticazione mTLS è disponibile sui cluster creati dopo il 24 giugno 2025. Tutte le connessioni ai cluster gestiti vengono autenticate con un'entità che è un' identità IAM utilizzando SASL o un certificato client utilizzando mTLS. Gli account utente, di servizio e federati sono supportati come entità quando si utilizza SASL.

Il servizio non supporta altri protocolli, tra cui SASL/GSSAPI, SASL/SCRAM-SHA-256 e SASL/SCRAM-SHA-512. Il servizio non consente inoltre connessioni non autenticate.

Autorizzazione

Il servizio utilizza un approccio a livelli per l'autorizzazione. IAM controlla le azioni di gestione dei cluster, come la creazione, l'aggiornamento e l'eliminazione delle risorse. L'autorizzazione per le entità autenticate dipende dal metodo utilizzato:

  • SASL: le entità che utilizzano IAM vengono autorizzate tramite Google Cloud i binding di ruolo IAM o con gli ACL Kafka nel cluster. Per saperne di più, consulta Configurare l'autenticazione SASL.

  • mTLS: le entità che eseguono l'autenticazione con mTLS vengono autorizzate tramite gli ACL Kafka. Per saperne di più, consulta Configurare l'autenticazione mTLS.

Puoi gestire gli ACL Kafka con gli strumenti Google Cloud o gli strumenti Kafka di terze parti. Per saperne di più sulla configurazione di IAM e degli ACL Kafka, consulta Controllo dell'accesso con IAM e ACL Kafka.

Crittografia

La crittografia è obbligatoria. Tutte le connessioni ai cluster devono utilizzare TLS. I certificati TLS presentati dai broker sono firmati dall'autorità di certificazione pubblica. I dati archiviati vengono sempre criptati. Scegli se utilizzare chiavi di crittografia gestite da Google o gestite dal cliente (CMEK) per la crittografia dei dati inattivi.

Applicazione patch

Il team del servizio monitora le vulnerabilità della sicurezza rilevate nel codice open source. Quando il servizio rileva vulnerabilità, applica automaticamente le patch ai cluster.

Isolamento delle risorse

Un'altra funzionalità di sicurezza del servizio è l'isolamento delle risorse. Il servizio gestito esegue il deployment dei cluster nei progetti tenant in un VPC privato inaccessibile tramite indirizzi IP pubblici. Ogni progetto ha un progetto tenant dedicato, con un agente di servizio account dedicato. Ciò consente di limitare l'ambito dell'accesso concesso al servizio.

Registro di schema

Per semplificare il coordinamento tra produttori e consumer, Managed Service per Apache Kafka include un'API del registro di schema. Un registro fornito dal servizio funge da repository di schemi condivisi tra le applicazioni.

Il servizio implementa l' API REST del registro di schema Confluent che facilita l'integrazione con le applicazioni Kafka esistenti. Sono supportati i formati di schema Apache Avro e Protocol Buffer (Protobuf). JSON non è supportato.

Managed Service per Apache Kafka offre anche un'API amministrativa e un set di strumenti per la gestione dei registri di schema e degli schemi. Il set di strumenti include la Google Cloud console, gcloud CLI e le librerie client.

Per saperne di più sul registro di schema, consulta la panoramica del registro di schema.

Integrazione dei dati con Kafka Connect

Managed Service per Apache Kafka semplifica l'integrazione dei dati tramite Kafka Connect. Kafka Connect offre diversi plug-in dei connettori integrati ospitati nei cluster Connect. Questi connettori vengono utilizzati per la migrazione, il backup, il ripristino di emergenza, l'alta disponibilità e l'integrazione dei dati. Questi connettori ti consentono di connettere i cluster Managed Service per Apache Kafka a vari sistemi, tra cui altre implementazioni di Kafka e Google Cloud servizi come BigQuery, Cloud Storage e Pub/Sub. Kafka Connect fornisce un'integrazione dei dati scalabile e affidabile con un sovraccarico operativo inferiore e monitoraggio e logging integrati.

Per saperne di più su Kafka Connect, consulta la panoramica di Kafka Connect.

Cluster ad alta disponibilità

L'obiettivo del servizio è fornire cluster regionali per le applicazioni mission-critical. In particolare, il servizio ti protegge da guasti di singole zone o broker.

A questo scopo, il provisioning di tutti i cluster viene eseguito in una configurazione a tre zone con riconoscimento del rack. La configurazione predefinita dell'argomento richiede almeno tre repliche. Il riconoscimento del rack garantisce che le repliche vengano create in zone diverse. Il numero minimo predefinito di repliche sincronizzate è due. Ciò significa che il cluster può tollerare la perdita completa di una zona o di un broker.

Quando un broker non funziona, a causa di un guasto software, hardware o di rete, viene sostituito automaticamente. Quando il servizio rileva un guasto del broker, lo riavvia automaticamente, su una macchina diversa, se necessario. Una volta che il broker è disponibile, Apache Kafka lo integra nel cluster. Un guasto completo della zona potrebbe rendere impossibile la creazione di un nuovo broker. Tuttavia, il cluster continua a funzionare finché le altre due zone rimangono disponibili.

Oltre a queste funzionalità specifiche, un elenco crescente di strumenti e processi interni mantiene in modo proattivo l'integrità del servizio, del codice Apache Kafka e degli aggiornamenti. I backup di dati e metadati vengono mantenuti a più livelli, consentendo al servizio di recuperare da molti errori umani e guasti software.

Il servizio non fornisce protezione da guasti regionali o a due zone. Per le applicazioni che richiedono questo livello di protezione, ti consigliamo di eseguire due cluster regionali separati. Puoi sincronizzare i dati tra due cluster utilizzando strumenti come MirrorMaker 2.0 di Kafka Connect.

Strumenti per il tuo stile di amministrazione

L'obiettivo del servizio è offrire un set completo di strumenti per la gestione e la risoluzione dei problemi dei cluster. Sono inclusi strumenti per l'amministrazione, il monitoraggio e il logging.

Managed Service per Apache Kafka è esposto come API Google Cloud. Ciò significa che puoi gestire i cluster e le risorse dei cluster utilizzando le API REST e gRPC. Per queste API sono forniti diversi client e interfacce, tra cui

  • Provider Terraform, se preferisci l'approccio Infrastructure as Code.
  • Interfaccia utente in Google Cloud console per il lavoro interattivo in un browser.
  • gcloud CLI per il lavoro interattivo in una shell.
  • Librerie client in Java, Python, Go e altri linguaggi per lo sviluppo e lo scripting personalizzati.

Per il monitoraggio e la risoluzione dei problemi, il servizio esporta le metriche in Cloud Monitoring. Alcune metriche sono disponibili nell'interfaccia utente del servizio. Un set completo è disponibile in Cloud Monitoring per il lavoro interattivo, la configurazione degli avvisi e l'esportazione in altri sistemi.

Il servizio esporta anche i log dei broker in Cloud Logging. Questi sono ricercabili e possono essere utilizzati per creare metriche e avvisi basati sui log.

Upgrade e patch

I cluster Managed Service per Apache Kafka vengono eseguiti sulla versione 3.7.1 di Apache Kafka. Il servizio applica automaticamente le patch alle vulnerabilità della sicurezza critiche.

Gli aggiornamenti all'infrastruttura sottostante, inclusi il sistema operativo e i livelli di orchestrazione, sono continui e automatici. I broker vengono aggiornati con un riavvio in sequenza, senza tempi di inattività per il cluster.

Il servizio non esegue automaticamente l'upgrade del codice Apache Kafka in esecuzione sui broker alle nuove versioni secondarie.

Costo trasparente

Il modello di prezzi per Managed Service per Apache Kafka è simile agli addebiti visualizzati quando esegui Apache Kafka in autonomia su Compute Engine. Paghi per le risorse di cui esegui il provisioning (vCPU, RAM e spazio di archiviazione locale) e che utilizzi (spazio di archiviazione permanente e trasferimento di dati). Lo spazio di archiviazione permanente e il costo della vCPU sono più elevati con Managed Service per Apache Kafka rispetto alla configurazione di un sistema simile in autonomia. Al contrario, i prezzi del trasferimento di dati e dello spazio di archiviazione locale sono simili tra Managed Service per Apache Kafka e Kafka autogestito. Per saperne di più sui prezzi, consulta Prezzi di Managed Service per Apache Kafka.

Compatibile perché eseguiamo Apache Kafka

Infine, Managed Service per Apache Kafka esegue lo stesso software open source che potresti già eseguire nel tuo ambiente. Non devi modificare il codice dell'applicazione per eseguirne la migrazione al servizio.

Limitazioni

Managed Service per Apache Kafka presenta le seguenti limitazioni:

  • Ogni cluster deve avere risorse uguali in ciascuna delle tre zone. I cluster Managed Service per Apache Kafka a zona singola o a due zone non sono supportati.

  • Non puoi scegliere le zone quando crei il cluster.

  • Non puoi configurare il volume dello spazio di archiviazione locale su un cluster.

  • Managed Service per Apache Kafka viene eseguito in modalità KRaft. La modalità Zookeeper non è supportata.

  • Le API JMX per le metriche non sono supportate.

  • Anche se puoi modificare le configurazioni dei broker con la modalità di aggiornamento read-only in qualsiasi momento, queste modifiche diventano effettive solo al riavvio dei broker. I riavvii vengono eseguiti periodicamente nell'ambito dei processi di manutenzione e upgrade di Google, ma non esiste una pianificazione impostata o un modo per attivarli manualmente. Di conseguenza, non puoi controllare quando queste modifiche diventano effettive. Esempi di configurazioni read-only includono auto.create.topics.enable e background.threads. Gli aggiornamenti alle configurazioni con la modalità di aggiornamento cluster-wide, come message.max.bytes, non richiedono riavvii e diventano effettivi immediatamente.

  • Alcuni parametri di configurazione dei broker sono gestiti dal servizio e non possono essere aggiornati. Sono inclusi broker.id e le impostazioni relative allo spazio di archiviazione, come remote.log.storage.system.enable.

Passaggi successivi

Apache Kafka® è un marchio registrato di The Apache Software Foundation o delle sue affiliate negli Stati Uniti e/o in altri paesi.