Migrazione da Kafka a Pub/Sub

Questo documento è utile se stai valutando 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 li elaborano. 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 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 Google Cloud regioni. Pub/Sub indirizza il traffico dei publisher al data center Google Cloud più vicino in cui è consentita l'archiviazione dei dati, come definito nella policy Limitazione della località delle risorse.

Pub/Sub può essere integrato con molti Google Cloud servizi, 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 da destinazioni dati che possono ricevere messaggi da Pub/Sub.

Panoramica di Kafka

Apache Kafka è una piattaforma open source, distribuita e per la gestione di flussi di eventi 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 gli eventi. Puoi utilizzare Kafka per separare 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 del cluster sono designati come broker. I broker ricevono i messaggi dai producer e li archiviano su disco. I messaggi archiviati sono organizzati per argomento e partizionati su più broker diversi nel cluster. I nuovi eventi pubblicati in un argomento vengono aggiunti alla fine di una delle partizioni dell'argomento. I consumer possono quindi recuperare i messaggi dai broker, che vengono letti dal disco e inviati al consumer.

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

Nel diagramma precedente, ogni M rappresenta un messaggio. I broker Kafka gestiscono più partizioni ordinate di messaggi, rappresentate dalle righe orizzontali di messaggi. I consumer leggono i messaggi di una determinata partizione che ha una capacità basata sulla macchina che ospita la partizione. Pub/Sub non ha partizioni e i consumer leggono da un argomento che viene scalato automaticamente in base alla domanda. Configura ogni argomento Kafka con il numero di partizioni necessarie per gestire il carico previsto dei consumer. Pub/Sub viene scalato automaticamente in base alla domanda.

Confronto tra le funzionalità

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

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

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

Per impostazione predefinita, Pub/Sub conserva 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 più vecchio (confermato o non confermato) nella sottoscrizione. Se conservi i messaggi confermati, puoi riprodurre 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 inviati nuovamente.

Puoi creare snapshot delle singole sottoscrizioni on demand senza dover configurare la sottoscrizione in anticipo. Ad esempio, puoi creare uno snapshot quando implementi un nuovo codice abbonato perché potresti dover eseguire il ripristino in caso di riconoscimenti imprevisti o errati.

Fail-safe integrato 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 comunicare a Pub/Sub che un messaggio è stato consegnato correttamente, i sottoscrittori degli argomenti Pub/Sub possono riconoscere i messaggi che ricevono ed elaborano. Se i tuoi abbonati non riescono a 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 di consegna dei messaggi effettuati da Pub/Sub prima che il messaggio venga inviato all'argomento messaggi non recapitabili.

Rimozione dei duplicati dei messaggi in Pub/Sub utilizzando Dataflow

Pub/Sub recapita ogni messaggio pubblicato almeno una volta per ogni sottoscrizione. In generale, l'accettazione di più di una consegna richiede che il tuo abbonato sia idempotente durante l'elaborazione dei messaggi. Se i tuoi abbonati esistenti non sono in grado di operare in modo idempotente, puoi incorporare Dataflow per deduplicare i messaggi. Se i tuoi iscritti vedono un alto tasso di messaggi duplicati, ciò può indicare che non riconoscono correttamente i messaggi o che il termine di conferma è troppo breve.

Ordinamento dei messaggi in Pub/Sub

Se le tue applicazioni di sottoscrizione Kafka si basano sull'ordinamento dei messaggi, puoi supportare questo requisito in Pub/Sub quando utilizzi chiavi di ordinamento. Attualmente, l'ordine è garantito per i messaggi pubblicati in una determinata regione. Per usufruire dell'ordinamento dei messaggi, assicurati che i tuoi publisher e gli abbonati utilizzino endpoint basati sulla posizione per indirizzare i messaggi alla regione corretta.

Informazioni sulle responsabilità del servizio self-hosted rispetto a quello gestito

La tabella seguente mette a confronto le funzionalità self-hosted con Kafka e quelle gestite da Google utilizzando Pub/Sub:

Apache Kafka Pub/Sub
Disponibilità Esegui il deployment manuale di Kafka in altre località Deployment in tutte le Google Cloud regioni per alta affidabilità e bassa latenza
Disaster recovery Progettare e gestire il backup e la replica Gestito da Google
Gestione dell'infrastruttura Esegui il deployment e il funzionamento manuale di macchine virtuali (VM) o macchine. Devi mantenere versioni e patch coerenti. Gestito da Google
Pianificazione della capacità Pianificare manualmente in anticipo le esigenze di archiviazione e computing Gestito da Google
Assistenza Nessuno Personale e assistenza disponibili 24 ore su 24

Limiti di dimensione dei messaggi Pub/Sub e soluzioni alternative

Kafka e Pub/Sub funzionano bene quando gestiscono grandi volumi di messaggi di piccole dimensioni. Kafka non impone limiti rigidi alle dimensioni dei messaggi e ti consente di configurare le dimensioni consentite dei messaggi, mentre Pub/Sub limita i messaggi a 10 MB. Puoi inviare indirettamente 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 dell'oggetto archiviato. Quando il sottoscrittore riceve il messaggio contenente l'URL, scarica il file da Cloud Storage e continua l'elaborazione come di consueto.

Confronto dei costi di Kafka e Pub/Sub

Il modo in cui stimi e gestisci i costi in Pub/Sub è diverso rispetto a Kafka. I costi di un cluster Kafka on-premise o nel cloud includono il costo di macchine, dischi, rete, messaggi in entrata e in uscita, nonché i costi generali di gestione e manutenzione di questi sistemi e della relativa infrastruttura. Quando si gestisce un cluster Kafka, spesso è necessario eseguire l'upgrade e l'applicazione di patch manuali alle macchine, pianificare la capacità del cluster e implementare il ripristino di emergenza richiede una pianificazione e test approfonditi. Devi dedurre e aggregare tutti questi vari costi per determinare il tuo vero costo totale di proprietà (TCO).

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

Progettare per l'affidabilità

Pub/Sub è un servizio gestito globale che viene eseguito in tutte le Google Cloud regioni. Gli argomenti Pub/Sub sono globali, il che significa che sono visibili e accessibili da qualsiasi località Google Cloud . Tuttavia, ogni messaggio viene memorizzato in una singola regione Google Cloud più vicina all'editore e consentita dal criterio di località delle risorse. Pertanto, un argomento può contenere messaggi archiviati in regioni diverse in tutto Google Cloud. Pub/Sub è resistente alle interruzioni a livello di zona. Durante un'interruzione regionale, 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 posizione per implementare una policy di failover in caso di interruzione regionale.

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'utilizzo di elenchi di controllo dell'accesso (ACL) per determinare quali producer e consumer hanno accesso a quali argomenti.

Pub/Sub supporta l'autenticazione per gli account utente e i service account Google Cloud . Il controllo dell'accesso granulare agli argomenti e alle sottoscrizioni Pub/Sub è regolato da Identity and Access Management (IAM) in Google Cloud. Le operazioni Pub/Sub sono limitate in base alla frequenza quando utilizzi account utente. Se devi effettuare transazioni di volume elevato, puoi utilizzare i service account per interagire con Pub/Sub.

Pianificare la migrazione a Pub/Sub

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

Migrazione graduale utilizzando il connettore Pub/Sub Kafka

Il connettore Kafka per Pub/Sub ti consente di eseguire la migrazione della tua 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. Dopodiché, puoi aggiornare le singole applicazioni di abbonati per ricevere messaggi su questi argomenti da Pub/Sub, mentre le applicazioni publisher continuano a pubblicare messaggi su Kafka. Questo approccio graduale ti 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:

Prima fase della migrazione.

Nel diagramma precedente, gli abbonati attuali continuano a ricevere messaggi da Kafka e aggiorni gli abbonati uno alla volta per ricevere messaggi da Pub/Sub.

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

Il seguente diagramma mostra la configurazione dopo che tutti gli abbonati ricevono messaggi da Pub/Sub:

Fase 2 della migrazione.

Nel tempo, tutti i tuoi editori vengono aggiornati per pubblicare direttamente su Pub/Sub e la migrazione viene completata. Molti team utilizzano questo approccio per aggiornare le proprie applicazioni in parallelo. Kafka può coesistere con Pub/Sub per tutto il tempo necessario per garantire una migrazione riuscita.

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ò contribuire a fornire visibilità su prestazioni, uptime e integrità complessiva delle tue applicazioni. Ad esempio, puoi assicurarti che i tuoi iscritti siano al corrente del flusso di messaggi monitorando il numero di messaggi non recapitati. Per monitorare i messaggi non consegnati, crea avvisi quando il timestamp del messaggio non confermato più vecchio 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