Migrazione da Kafka a Pub/Sub

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

Panoramica di Pub/Sub

Pub/Sub è un servizio di messaggistica asincrono. Pub/Sub disaccoppia i servizi che producono eventi da quelli che elaborano eventi. Puoi utilizzare Pub/Sub come middleware orientato ai messaggi o per l'importazione e la distribuzione di eventi per pipeline di analisi dei flussi di dati. In entrambi gli scenari, un'applicazione del publisher crea e invia messaggi a un argomento. Le applicazioni del sottoscrittore creano una sottoscrizione a un argomento per riceverne i messaggi. Una sottoscrizione è un'entità denominata che rappresenta l'interesse a ricevere messaggi su un determinato argomento.

Pub/Sub viene eseguito in tutte le regioni di Google Cloud. Pub/Sub indirizza il traffico dell'editore al data center Google Cloud più vicino, dove è consentita l'archiviazione dei dati, in base a quanto definito nei criteri relativi alla limitazione sulla località delle risorse.

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

Panoramica di Kafka

Apache Kafka è una piattaforma per flussi di eventi distribuita e open source che consente alle applicazioni di pubblicare, sottoscrivere, archiviare ed elaborare flussi di eventi. Il server Kafka viene eseguito come 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, monitorare le attività, aggregare i dati di log ed elaborare i flussi.

All'interno del cluster Kafka, alcuni nodi sono designati come broker. I broker ricevono messaggi dai produttori e li archiviano su disco. I messaggi archiviati sono organizzati per argomento e partizionati tra 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 consumer.

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 le partizioni per Kafka e senza partizioni per Pub/Sub.

Nel diagramma precedente, ogni M rappresenta un messaggio. I broker Kafka gestiscono più partizioni ordinate dei messaggi, rappresentate da righe orizzontali di messaggi. I consumatori leggono i messaggi da una particolare partizione la cui capacità è basata sulla macchina che ospita quella partizione. Pub/Sub non ha partizioni e i consumatori leggono da un argomento con scalabilità automatica in base alla domanda. Puoi configurare ogni argomento Kafka con il numero di partizioni necessarie per gestire il carico previsto dei consumer. Pub/Sub scala automaticamente in base alla domanda.

Confronto di funzionalità

La tabella seguente confronta le funzionalità di Apache Kafka con le funzionalità di Pub/Sub:

Apache Kafka Pub/Sub
Ordinamento messaggi Sì all'interno delle partizioni Sì negli argomenti
Deduplicazione dei messaggi Sì Sì utilizzando Dataflow
Iscrizioni push No Yes
Coda di messaggi non recapitabili
(coda di messaggi non elaborabili)		 A partire dalla versione 2.0 Yes
Transazioni Sì No
Archiviazione dei messaggi Limitata solo dallo spazio di archiviazione della macchina disponibile 31 giorni.
Un argomento può conservare i messaggi pubblicati, inclusi i messaggi confermati, per un massimo di 31 giorni. È configurabile dalla proprietà `message_retention_duration` dell'argomento.
Ripetizione messaggio Sì Yes
Località Il cluster locale può essere replicato utilizzando MirrorMaker Servizio distribuito globale con località di archiviazione dei messaggi configurabili
Logging e monitoraggio Autogestito Automatico con Cloud Logging e Cloud Monitoring
Elaborazione dei flussi Sì con KSQL Sì con Dataflow

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

Per impostazione predefinita, Pub/Sub conserva i messaggi non confermati per un massimo di sette giorni, ma puoi configurare le sottoscrizioni Pub/Sub in modo da conservare i messaggi confermati anche per sette giorni, a seconda dell'età del messaggio meno recente (confermato o non confermato) nella sottoscrizione. Se mantieni i messaggi confermati, puoi riprodurre di nuovo alcuni o tutti i 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 confermati. I messaggi non confermati vengono quindi recapitati di nuovo.

Puoi creare snapshot di singoli abbonamenti on demand senza dover configurare l'abbonamento in anticipo. Ad esempio, puoi creare uno snapshot durante il deployment del codice di un nuovo abbonato perché potrebbe essere necessario eseguire un ripristino in seguito a conferme impreviste o errate.

Sicurezza integrata con argomenti messaggi non recapitabili

Pub/Sub offre funzionalità simili alla gestione degli errori di Kafka 2.0 e al modo in cui Kafka Connect gestisce gli argomenti messaggi non recapitabili. Per notificare a Pub/Sub che un messaggio è stato recapitato correttamente, i sottoscrittori agli argomenti Pub/Sub possono confermare i messaggi che ricevono ed elaborano. Se i tuoi sottoscrittori non sono in grado di elaborare i messaggi per un po' di tempo, Pub/Sub può inoltrare automaticamente questi messaggi a un argomento messaggi non recapitabili e archiviarli per accedervi in un secondo momento. Puoi configurare il numero di tentativi effettuati da Pub/Sub per recapitare i messaggi prima che il messaggio venga inviato all'argomento messaggi non recapitabili.

Deduplicazione dei messaggi in Pub/Sub mediante Dataflow

Pub/Sub recapita ogni messaggio pubblicato almeno una volta per ogni abbonamento. In generale, gestire la consegna "più di una volta" richiede che il sottoscrittore sia idempotente durante l'elaborazione dei messaggi. Se i tuoi abbonati esistenti non sono in grado di operare in modo indipendente, puoi incorporare Dataflow per deduplicare i messaggi. Se i tuoi sottoscrittori visualizzano un'elevata percentuale di messaggi duplicati, ciò può indicare che non stanno confermando correttamente i messaggi o che la scadenza di conferma è troppo breve.

Ordinamento dei messaggi in Pub/Sub

Se le applicazioni del sottoscrittore Kafka si basano sull'ordinamento dei messaggi, puoi supportare questo requisito in Pub/Sub quando utilizzi l'ordine delle chiavi. Attualmente, l'ordinamento è garantito per i messaggi pubblicati in una determinata regione. Per sfruttare al meglio l'ordinamento dei messaggi, assicurati che i publisher e i sottoscrittori utilizzino gli endpoint di località per instradare i messaggi alla regione corretta.

Informazioni sulle responsabilità del servizio in self-hosting e in quello gestito

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

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

Limiti di dimensione dei messaggi Pub/Sub e soluzioni alternative

Kafka e Pub/Sub hanno entrambi buone prestazioni per la gestione di grandi volumi di piccoli messaggi. Kafka non pone alcun limite fisso alle dimensioni dei messaggi e ti consente di configurare le dimensioni consentite per i messaggi, mentre Pub/Sub limita i messaggi a 10 MB. Puoi inviare indirettamente payload più grandi archiviando prima l'oggetto in Cloud Storage, come mostrato nel seguente diagramma:

Il publisher 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 dell'oggetto archiviato. Quando il sottoscrittore riceve il messaggio contenente l'URL, scarica il file da Cloud Storage e continua a elaborarlo come di consueto.

Confronto dei costi di Kafka e Pub/Sub

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

I prezzi di Pub/Sub includono il trasferimento di dati dagli editori ai sottoscrittori, nonché il costo dell'archiviazione temporanea dei messaggi non confermati. Paghi esattamente per le risorse che utilizzi, scalandone automaticamente la capacità in base ai requisiti dell'applicazione e del budget.

Progettare per l'affidabilità

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

Sicurezza e autenticazione

Apache Kafka supporta più meccanismi di autenticazione, tra cui l'autenticazione basata su certificati client, Kerberos, LDAP e nome utente e password. Per l'autorizzazione, Kafka supporta l'uso di elenchi di controllo dell'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 dell'accesso agli argomenti e agli abbonamenti Pub/Sub è regolato da Identifi and Access Management (IAM) in Google Cloud. Le operazioni Pub/Sub hanno una limitazione di frequenza quando si utilizzano gli account utente. Se hai bisogno di effettuare transazioni con volumi elevati, puoi usare 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 per fasi utilizzando il connettore Kafka Pub/Sub

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

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

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

Fase uno della migrazione.

Nel diagramma precedente, i sottoscrittori attuali continuano a ricevere messaggi da Kafka e vengono aggiornati uno alla volta per ricevere i messaggi da Pub/Sub.

Dopo che tutti i sottoscrittori a un determinato argomento sono stati aggiornati in modo da ricevere i messaggi da Pub/Sub, puoi aggiornare le applicazioni dell'editore per quell'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 ricevono messaggi da Pub/Sub:

Fase due della migrazione.

Nel corso del tempo, tutti i tuoi publisher vengono aggiornati per la pubblicazione direttamente in Pub/Sub, dopodiché la migrazione viene completata. Molti team utilizzano questo approccio per aggiornare le applicazioni in parallelo. Kafka può coesistere con Pub/Sub per tutto il tempo necessario per garantire il successo 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 può aiutarti a fornire visibilità su prestazioni, uptime e integrità complessiva delle tue applicazioni. Ad esempio, puoi fare in modo che i tuoi abbonati stiano al passo con il flusso dei messaggi monitorando il numero di messaggi non recapitati. Per monitorare i messaggi non recapitati, puoi creare avvisi quando il timestamp del messaggio non confermato meno recente supera una determinata soglia. Puoi anche monitorare l'integrità del servizio Pub/Sub stesso monitorando la metrica del conteggio delle richieste di invio ed esaminando i codici di risposta.

Passaggi successivi