Managed Service per Apache Kafka è un servizio Google Cloud che ti aiuta a eseguire cluster Apache Kafka open source sicuri e scalabili. Questa pagina offre una panoramica di ciò che il servizio automatizza e semplifica per te. Per maggiori informazioni su Apache Kafka, visita 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 la dimensione della RAM per il cluster. La gestione dei broker, incluso lo spazio di archiviazione, è completamente automatizzata. Per soddisfare le richieste dei clienti, puoi monitorare l'utilizzo di vCPU e altre risorse e regolarlo di conseguenza.
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 del broker
Quando configuri le dimensioni totali di vCPU e RAM per il cluster, il servizio esegue il provisioning di nuovi broker e scala quelli esistenti. Per una configurazione tipica del cluster, la dimensione totale di vCPU e RAM è suddivisa equamente tra tutti i broker. Ciò significa che sono consentiti conteggi di vCPU frazionari per broker, anche se è richiesto un minimo di una vCPU per broker. Tutti i cluster sono distribuiti in tre zone. Ciò significa che sono necessari 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, viene eseguito lo scale down dei broker esistenti a una singola vCPU, ma non vengono eliminati.
La dimensione massima del broker potrebbe cambiare in qualsiasi momento. Questo limite è stato scelto per mantenere la scalabilità lineare della velocità effettiva del broker con il conteggio delle 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 ogni 15 vCPU o 120 gibibyte (GiB) di risorse, a seconda di quale genera un numero maggiore di broker. Il rapporto vCPU/memoria (vCPU:GiB) deve rimanere compreso tra 1:1 e 1:8. I broker sono distribuiti equamente tra le tre 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 pari a 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 brokerCalcola 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 tre zone hanno due broker assegnati ciascuna, mentre l'ultima zona ne ha uno.
Gestione dell'archiviazione
La gestione dello spazio di archiviazione è automatizzata. Nella maggior parte dei casi, sei responsabile dell'impostazione del periodo di conservazione dei singoli argomenti per controllare i costi o soddisfare le tue norme di conservazione dei dati. Non è necessario eseguire il provisioning e gestire i dischi permanenti.
Il servizio si basa sull'archiviazione a livelli (KIP-405). L'archiviazione a livelli combina volumi disco permanente di cui è stato eseguito il provisioning in anticipo collegati ai broker con spazio di archiviazione degli oggetti praticamente illimitato.
Il servizio alloca almeno 100 GiB di dischi permanenti SSD per ogni vCPU per bilanciare prestazioni, disponibilità e costi. Ti vengono addebitati 100 GiB per vCPU, anche se la dimensione effettiva del disco per broker potrebbe superare questo valore. Le dimensioni del disco per broker non vengono mai ridotte, anche se il cluster viene ridotto.
Ogni leader di partizione memorizza i messaggi nei file di segmento su questi dischi
permanenti. Una volta eseguito il roll, il segmento viene spostato nell'archiviazione di oggetti persistente
supportata da Cloud Storage regionale. Le dimensioni di questi file di segmento sono
impostate dalle impostazioni log.roll.ms e log.segment.bytes.
Sebbene questi dettagli siano utili da comprendere, lo spazio di archiviazione è gestito dal servizio. Le configurazioni specifiche, ad esempio 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 l'archiviazione permanente.
Ribilanciamento
Affinché i broker di cui è stato eseguito il provisioning di recente siano utili per mantenere il rendimento, parte del traffico dei broker esistenti deve essere spostato su queste nuove macchine. Per semplificare questa operazione, puoi attivare il ribilanciamento automatico.
Se 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à relativamente piccola di dati venga copiata nei nuovi broker, velocizzando il ribilanciamento.
L'algoritmo di ribilanciamento si basa sul conteggio delle partizioni. Non tiene conto del traffico effettivo pubblicato da ciascuna 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 solo 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. Gli endpoint vengono sottoposti a provisioning 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 archiviazione non autenticate e non criptate.
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 più livelli per l'autorizzazione. IAM controlla le azioni di gestione del 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 associazioni di ruoli IAM o con ACL Kafka sul cluster. Per saperne di più, consulta Configura l'autenticazione SASL.
mTLS: i principal che eseguono l'autenticazione con mTLS vengono autorizzati tramite le ACL di Kafka. Per saperne di più, consulta Configura l'autenticazione mTLS.
Puoi gestire gli ACL Kafka con gli Google Cloud strumenti o con strumenti Kafka di terze parti. Per saperne di più sulla configurazione di IAM e delle 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'Public Certificate Authority. I dati archiviati sono sempre criptati. Scegli se utilizzare chiavi di crittografia gestite da Google o dal cliente (CMEK) per la crittografia at-rest.
Applicazione patch in corso…
Il team di assistenza tiene traccia delle vulnerabilità di sicurezza scoperte nel codice open source. Quando il servizio rileva vulnerabilità, applica automaticamente patch ai tuoi cluster.
Isolamento delle risorse
Un'altra funzionalità di sicurezza del servizio è l'isolamento delle risorse. Il servizio gestito deploya i cluster nei progetti tenant in un VPC privato inaccessibile tramite indirizzi IP pubblici. Ogni progetto ha un progetto tenant dedicato, con un account service agent dedicato. Ciò contribuisce a limitare l'ambito dell'accesso concesso al servizio.
Registro di schema
Per semplificare il coordinamento tra produttori e consumatori, Managed Service per Apache Kafka include un'API del registro di schemi. Un registro fornito dal servizio funge da repository di schemi condivisi tra le applicazioni.
Il servizio implementa l'API REST Confluent Schema Registry 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 gestire i registri di schema e gli schemi. Il set di strumenti include la consoleGoogle Cloud , gcloud CLI e le librerie client.
Per saperne di più sul registro di schemi, consulta la panoramica del registro di schemi.
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 incorporati ospitati nei cluster di connessione. Questi connettori vengono utilizzati per la migrazione, il backup, ripristino di emergenza, l'alta affidabilità e l'integrazione dei dati. Questi connettori ti consentono di connettere i cluster Managed Service per Apache Kafka a vari sistemi, tra cui altri deployment Kafka e servizi come BigQuery, Cloud Storage e Pub/Sub. Google Cloud Kafka Connect fornisce un'integrazione dei dati scalabile e affidabile con un overhead 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 applicazioni mission critical. In particolare, il servizio ti protegge da errori di singole zone o singoli broker.
Per raggiungere questo obiettivo, tutti i cluster vengono sottoposti al provisioning in una configurazione a tre zone consapevole del rack. La configurazione predefinita dell'argomento richiede almeno tre repliche. La consapevolezza del rack assicura che le repliche vengano create in zone diverse. Il numero minimo predefinito di repliche sincronizzate è due. Ciò significa che il tuo cluster può tollerare la perdita completa di una zona o di un broker.
Quando un broker non funziona a causa di un guasto al software, all'hardware o alla rete, viene sostituito automaticamente. Quando il servizio rileva un errore del broker, lo riavvia automaticamente, su una macchina diversa, se necessario. Una volta disponibile, Apache Kafka integra il broker nel cluster. Un errore 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 errori regionali o a due zone. Per le applicazioni che richiedono questo livello di protezione, 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
Il servizio mira a offrire un set completo di strumenti per la gestione e la risoluzione dei problemi del cluster. Ciò include strumenti per l'amministrazione, il monitoraggio e la registrazione.
Managed Service per Apache Kafka è esposto come API Google Cloud. Ciò significa che puoi gestire i cluster e le risorse del cluster utilizzando le API REST e gRPC. Per queste API vengono forniti diversi client e interfacce, tra cui
- Provider Terraform se preferisci l'approccio Infrastructure as Code.
- UI nella console Google Cloud 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 del 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 patch alle vulnerabilità di sicurezza critiche.
Gli aggiornamenti dell'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 prezzo per Managed Service per Apache Kafka è simile agli addebiti che visualizzi quando esegui Apache Kafka autonomamente su Compute Engine. Paghi 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). L'archiviazione permanente e il costo delle vCPU sono più elevati con Managed Service per Apache Kafka rispetto alla configurazione autonoma di un sistema simile. Al contrario, i prezzi del trasferimento dei dati e dell'archiviazione locale sono simili tra Managed Service per Apache Kafka e Kafka autogestito. Per ulteriori informazioni 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 una o 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.
La compressione degli argomenti con
zstdnon è supportata. I valori supportati percompression.typeincludonolz4,gzip,snappyeuncompressed.Anche se puoi modificare le configurazioni dei broker con la modalità di aggiornamento
read-onlyin qualsiasi momento, queste modifiche hanno effetto solo al riavvio dei broker. I riavvii si verificano periodicamente nell'ambito dei processi di manutenzione e upgrade di Google, ma non esiste una pianificazione prestabilita o un modo per attivarli manualmente. Di conseguenza, non puoi controllare quando queste modifiche diventano effettive. Esempi di configurazioniread-onlyincludonoauto.create.topics.enableebackground.threads. Gli aggiornamenti alle configurazioni con la modalità di aggiornamentocluster-wide, ad esempiomessage.max.bytes, non richiedono riavvii e hanno effetto immediato.Alcuni parametri di configurazione del broker sono gestiti dal servizio e non possono essere aggiornati. Sono incluse
broker.ide le impostazioni relative allo spazio di archiviazione, ad esempioremote.log.storage.system.enable.
Passaggi successivi
- Crea un cluster Managed Service per Apache Kafka.
- Invia e ricevi messaggi utilizzando un cluster Managed Service per Apache Kafka.
- Esamina le limitazioni di Managed Service per Apache Kafka.
- Scopri di più sui prezzi di Managed Service per Apache Kafka.