Migrazione da Kafka a Pub/Sub

Questo documento è utile se stai pensando di eseguire la migrazione da Apache Kafka autogestito a Pub/Sub, perché può aiutarti a esaminare e prendere in considerazione le funzionalità, i prezzi e i casi d'uso. Ogni sezione identifica un caso d'uso comune di Kafka e offre indicazioni pratiche per ottenere la stessa funzionalità in Pub/Sub.

Panoramica di Pub/Sub

Pub/Sub è un servizio di messaggistica asincrono. Servizi di disaccoppiamento Pub/Sub che producono eventi dai servizi che elaborano gli eventi. Puoi utilizzare Pub/Sub come middleware orientato alla messaggistica o per l'importazione e la pubblicazione di eventi per le pipeline di analisi dei flussi di dati. In entrambi gli scenari, un'applicazione dell'editore crea e invia messaggi a un argomento. Le applicazioni del sottoscrittore creano una sottoscrizione a un argomento per ricevere i relativi messaggi. Una sottoscrizione è un'entità denominata che rappresenta un interesse a ricevere messaggi su un determinato argomento.

Pub/Sub viene eseguito in tutte le aree geografiche Google Cloud. Pub/Sub indirizza il traffico del publisher al data center Google Cloud più vicino, dove è consentita l'archiviazione dei dati, come definito nel criterio Restrizione sulla località delle risorse.

Pub/Sub può integrarsi con molti servizi di Google Cloud come Dataflow, Cloud Storage e Cloud Run. Puoi configurare questi servizi in modo che vengano pubblicati come origini dati che possono pubblicare messaggi in Pub/Sub o sink di dati che possono ricevere messaggi da Pub/Sub.

Panoramica di Kafka

Apache Kafka è una piattaforma open source distribuita per il flusso di eventi e consente alle applicazioni di pubblicare, iscriversi, archiviare ed elaborare i flussi di eventi. Il server Kafka viene eseguito come un cluster di macchine con cui le applicazioni client interagiscono per leggere, scrivere ed elaborare eventi. Puoi utilizzare Kafka per disaccoppiare le applicazioni, inviare e ricevere messaggi, tenere traccia delle attività, aggregare i dati di log ed elaborare i flussi.

All'interno del cluster Kafka, alcuni nodi del cluster sono designati come intermediari. I broker ricevono i messaggi dai produttori e li archiviano su disco. I messaggi archiviati vengono organizzati per argomento e partizionati in diversi broker nel cluster. I nuovi eventi pubblicati in un argomento vengono aggiunti alla fine di una delle partizioni dell'argomento. I consumatori possono quindi recuperare i messaggi dai broker, che vengono letti dal disco e inviati al consumatore.

Differenze tra Kafka e Pub/Sub

Il seguente diagramma mostra le differenze nella strategia di scalabilità tra Kafka e Pub/Sub:

Strategia di scalabilità con partizioni per Kafka e nessuna partizione per Pub/Sub.

Nel diagramma precedente, ogni M rappresenta un messaggio. I broker Kafka gestiscono più partizioni ordinate di messaggi, rappresentate dalle righe orizzontali dei messaggi. I consumatori leggono i messaggi provenienti da una determinata partizione che ha una capacità basata sulla macchina che ospita tale partizione. Pub/Sub non ha partizioni e i consumatori leggono da un argomento che scala automaticamente in base alla domanda. Ogni argomento Kafka deve essere configurato con il numero di partizioni di cui hai bisogno per gestire il carico previsto del consumatore. Pub/Sub scala automaticamente in base alla domanda.

Confronto tra funzionalità

La tabella seguente mette a confronto le funzionalità di Apache Kafka con quelle di Pub/Sub:

Apache Kafka Pub/Sub
Ordinamento messaggi Sì all'interno delle partizioni Sì in topics
Decodifica dei messaggi Sì tramite Dataflow
Trasferisci abbonamenti No
Coda non recapitabile
(coda di messaggi non elaborabile)
A partire dalla versione 2.0
Transazioni No
Archiviazione dei messaggi Limitata solo dallo spazio di archiviazione disponibile sulla macchina 7 giorni
Ripetizione messaggio
Località Il cluster locale può essere replicato utilizzando MirrorMaker Servizio distribuito a livello globale con località di archiviazione dei messaggi configurabili
Logging e monitoraggio Gestione indipendente Automatiche con Cloud Logging e Cloud Monitoring
Elaborazione dei flussi Sì con KSQL Sì con Dataflow

Informazioni sull'archiviazione e sulla replica dei messaggi Pub/Sub

Per impostazione predefinita, Pub/Sub contiene i messaggi non confermati per un massimo di 7 giorni, ma puoi configurare le sottoscrizioni Pub/Sub per conservare i messaggi confermati per un massimo di 7 giorni, a seconda dell'età del messaggio meno recente (confermato o non confermato) nell'abbonamento. Conservando i messaggi confermati puoi ripetere alcuni o tutti questi messaggi in base a un timestamp. Quando riproduci i messaggi in base a un timestamp, tutti i messaggi ricevuti dopo il timestamp vengono contrassegnati come non riconosciuti. I messaggi senza conferma vengono nuovamente recapitati.

Puoi creare snapshot on demand di singoli abbonamenti senza dover configurare in anticipo l'abbonamento. Ad esempio, puoi creare uno snapshot quando esegui il deployment di un nuovo codice abbonato perché potresti dover eseguire il ripristino da riconoscimenti imprevisti o errati.

Integrato non sicuro con argomenti non recapitabili

Pub/Sub fornisce funzionalità simili a Kafka 2.0 Management e al modo in cui Kafka Connect gestisce gli argomenti non recapitabili. Per informare Pub/Sub che un messaggio è stato recapitato, i sottoscrittori agli argomenti Pub/Sub possono accettarli. Se i tuoi abbonati non sono in grado di elaborare i messaggi per un determinato periodo di tempo, Pub/Sub può inoltrarli automaticamente a un argomento non recapitabile e archiviarli per l'accesso in un secondo momento. Puoi configurare il numero di tentativi eseguiti da Pub/Sub di recapitare i messaggi prima che invii il messaggio all'argomento messaggi non recapitabili.

Deduplica dei messaggi in Pub/Sub utilizzando Dataflow

Pub/Sub recapita ogni messaggio pubblicato almeno una volta per ogni iscrizione. In generale, la gestione di più di una consegna richiede che l'abbonato sia idempotente durante l'elaborazione dei messaggi. Se i tuoi abbonati esistenti non sono in grado di operare in modo tempestivo, puoi incorporare Dataflow per deduplicare i messaggi. Se i tuoi iscritti vedono un'elevata percentuale di messaggi duplicati, ciò può indicare che i messaggi non sono stati riconosciuti correttamente o che la scadenza è troppo breve.

Ordinamento dei messaggi in Pub/Sub

Se le tue applicazioni dell'abbonato Kafka si basano sull'ordinamento dei messaggi, puoi supportare questo requisito in Pub/Sub quando utilizzi le chiavi di ordinamento. Al momento, l'ordine è garantito per i messaggi pubblicati in una determinata area geografica. Per sfruttare l'ordinamento dei messaggi, assicurati che i tuoi publisher e i tuoi abbonati utilizzino gli endpoint a livello di area geografica per indirizzare i messaggi all'area geografica corretta.

Informazioni sulle responsabilità dell'hosting autonomo e del servizio gestito

La tabella seguente mette a confronto la funzionalità ospitata autonomamente con Kafka e quella gestita da Google tramite Pub/Sub:

Apache Kafka Pub/Sub
Disponibilità Esegui manualmente il deployment di Kafka in altre località Deployment in tutte le aree geografiche Google Cloud per l'alta disponibilità e la bassa latenza
Ripristino di emergenza Progetta e gestisci backup e replica Gestito da Google
Gestione dell'infrastruttura Esegui manualmente il deployment e il funzionamento di macchine virtuali (VM) o macchine. Devi mantenere un controllo delle versioni e delle patch coerenti. Gestito da Google
Pianificazione della capacità Pianificare manualmente in anticipo le esigenze di archiviazione e calcolo Gestito da Google
Assistenza Nessuna Personale sempre disponibile e assistenza 24 ore su 24

Limiti e soluzioni alternative per le dimensioni dei messaggi Pub/Sub

Kafka e Pub/Sub hanno un buon rendimento nella gestione di grandi volumi di piccoli messaggi. Kafka non imposta limiti per le dimensioni dei messaggi e ti consente di configurare le dimensioni consentite per i messaggi, mentre Pub/Sub limita i messaggi a 10 MB. Indirettamente puoi inviare payload più grandi memorizzando prima l'oggetto in Cloud Storage, come mostrato nel seguente diagramma:

L'editore archivia l'oggetto in Cloud Storage.

L'immagine precedente mostra che, quando l'editore archivia l'oggetto in Cloud Storage, pubblica un messaggio contenente l'URL per l'oggetto archiviato. Quando il sottoscrittore riceve il messaggio contenente l'URL, scarica il file da Cloud Storage e continua a elaborare normalmente.

Confronto tra costi Kafka e Pub/Sub

La modalità di stima e gestione dei costi in Pub/Sub è diversa da quella in Kafka. I costi di un cluster Kafka on-premise o nel cloud includono i costi di macchine, disco, networking, traffico in entrata e in uscita dai dati, nonché i costi generali di gestione e manutenzione di questi sistemi e della relativa infrastruttura. Quando si gestisce un cluster Kafka, spesso è necessario eseguire manualmente l'upgrade e l'applicazione di patch alle macchine, spesso è necessario pianificare la capacità del cluster e l'implementazione del ripristino di emergenza richiede una pianificazione e test approfonditi. Devi dedurre e aggregare tutti questi costi per determinare il tuo costo totale di proprietà (TCO) effettivo.

I prezzi di Pub/Sub includono il trasferimento di dati da publisher e abbonati e il costo di archiviazione temporanea dei messaggi non confermati. Paghi esattamente le risorse che utilizzi e scala automaticamente la sua capacità in base ai requisiti della tua applicazione e del tuo budget.

Architecting per l'affidabilità

Pub/Sub è un servizio gestito globale che viene eseguito in tutte le aree geografiche Google Cloud. Gli argomenti Pub/Sub sono globali, ovvero sono visibili e accessibili da qualsiasi località Google Cloud. Tuttavia, un determinato messaggio viene archiviato in un'unica area geografica Google Cloud più vicina al publisher e consentita dal criterio di località delle risorse. Pertanto, un argomento può avere messaggi archiviati in aree geografiche diverse di Google Cloud. Pub/Sub è resistente alle interruzioni a livello di zona. Durante un'interruzione a livello di area geografica, i messaggi archiviati in quella particolare area geografica potrebbero essere inaccessibili fino al ripristino del servizio. A seconda dei requisiti di disponibilità, puoi utilizzare gli endpoint di servizio a livello di area geografica per implementare un criterio di failover in caso di interruzione di un'area geografica.

Sicurezza e autenticazione

Apache Kafka supporta più meccanismi di autenticazione tra cui autenticazione basata su certificati client, Kerberos, LDAP e nome utente e password. Per l'autorizzazione, Kafka supporta l'utilizzo di elenchi di controllo di accesso (ACL) per determinare quali produttori e consumatori hanno accesso a determinati argomenti.

Pub/Sub supporta l'autenticazione per gli account utente e gli account di servizio Google Cloud. Il controllo granulare degli accessi agli argomenti Pub/Sub e alle iscrizioni è regolato da Identifi and Access Management (IAM) in Google Cloud. Le operazioni Pub/Sub sono limitate quando utilizzano gli account utente. Se devi effettuare transazioni di volume elevato, puoi utilizzare gli account di servizio per interagire con Pub/Sub.

Pianificazione della migrazione a Pub/Sub

Qualsiasi migrazione a Google Cloud inizia con la valutazione dei carichi di lavoro e la creazione delle basi.

Migrazione a fasi con il connettore Kafka Pub/Sub

Il connettore Kafka Pub/Sub ti consente di eseguire la migrazione dell'infrastruttura Kafka in Pub/Sub in più fasi.

Puoi configurare il connettore Pub/Sub in modo che inoltri tutti i messaggi su argomenti specifici da Kafka a Pub/Sub. Successivamente, puoi aggiornare le applicazioni dei singoli iscritti per ricevere messaggi su questi argomenti da Pub/Sub, mentre le applicazioni dell'editore continuano a pubblicare messaggi su Kafka. Questo approccio graduale consente di aggiornare, testare e monitorare le applicazioni degli abbonati in modo iterativo, riducendo al minimo il rischio di errori e tempi di inattività.

Questa sezione include due diagrammi che possono aiutarti a visualizzare questo processo in due fasi distinte. Il seguente diagramma mostra la configurazione durante la fase di migrazione:

Fase 1 della migrazione.

Nel diagramma precedente, i sottoscrittori correnti continuano a ricevere i messaggi da Kafka e li aggiorni uno per uno per ricevere i messaggi da Pub/Sub.

Dopo che tutti i sottoscrittori a un determinato argomento sono stati aggiornati per ricevere messaggi da Pub/Sub, puoi aggiornare le applicazioni dell'editore per l'argomento in modo da pubblicare messaggi in Pub/Sub. Successivamente, puoi testare e monitorare i flussi di messaggi end-to-end per verificare la configurazione.

Il seguente diagramma mostra la configurazione dopo che tutti i sottoscrittori stanno ricevendo messaggi da Pub/Sub:

Fase due della migrazione.

Nel tempo, tutti i tuoi publisher vengono aggiornati e pubblicati direttamente su Pub/Sub, quindi la migrazione è completa. Molti team utilizzano questo approccio per aggiornare le loro applicazioni in parallelo. Kafka può coesistere insieme a Pub/Sub per tutto il tempo necessario a garantire la riuscita della migrazione.

Monitoraggio di Pub/Sub

Durante e dopo la migrazione da Kafka a Pub/Sub, è importante monitorare le applicazioni. Pub/Sub esporta le metriche utilizzando Cloud Monitoring, che possono aiutarti a comprendere le prestazioni, il tempo di attività e lo stato generale delle tue applicazioni. Ad esempio, puoi assicurarti che i tuoi abbonati continuino a seguire il flusso dei messaggi monitorando il numero di messaggi non recapitati. Per monitorare i messaggi non recapitati, crea avvisi quando il timestamp del messaggio non riconosciuto più vecchio supera una determinata soglia. Puoi anche monitorare l'integrità del servizio Pub/Sub stesso monitorando la metrica di conteggio delle richieste di invio ed esaminando i codici di risposta.

Passaggi successivi