Esegui la migrazione da Kafka a Pub/Sub

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

Panoramica di Pub/Sub

Pub/Sub è un servizio di messaggistica asincrona. 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 ricevere i messaggi. Una sottoscrizione è un'entità denominata che rappresenta un interesse per la ricezione di messaggi su un determinato argomento.

Pub/Sub viene eseguito in tutte le regioni Google Cloud. Pub/Sub indirizza il traffico del publisher al data center Google Cloud più vicino in cui è consentita l'archiviazione dei dati, come definito nelle norme relative alla limitazione della località delle risorse.

Pub/Sub può essere integrato 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 su Pub/Sub o come destinazioni dati che possono ricevere messaggi da Pub/Sub.

Panoramica di Kafka

Apache Kafka è una piattaforma di streaming di eventi distribuita e open source che consente alle applicazioni di pubblicare, iscriversi, archiviare ed elaborare stream 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 disaccoppiare le applicazioni, inviare e ricevere messaggi, monitorare le attività, aggregare i dati dei log ed elaborare i flussi.

All'interno del cluster Kafka, alcuni nodi sono designati come broker. I broker ricevono i messaggi dai produttori e li archiviano su disco. I messaggi archiviati sono organizzati per argomento e suddivisi in più 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 vengonoletti dal disco e inviati al consumatore.

Informazioni sulle 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 di messaggi. I consumatori leggono i messaggi da una determinata partizione con una capacità in base alla macchina che la ospita. Pub/Sub non ha partizioni e i consumatori leggono da un argomento che si ridimensiona automaticamente in base alla domanda. Configura ogni argomento Kafka con il numero di partizioni necessario per gestire il carico del consumatore previsto. Pub/Sub si scala automaticamente in base alla domanda.

Confronto delle funzionalità

La seguente tabella 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
Deduplica dei messaggi Sì Sì utilizzando Dataflow
Sottoscrizioni push No Sì
Coda di messaggi non recapitabili
(coda di messaggi non elaborabili)		 A partire dalla versione 2.0 Sì
Transazioni Sì No
Archiviazione dei messaggi Limitato solo dallo spazio di archiviazione disponibile della macchina 31 giorni.
Un argomento può conservare i messaggi pubblicati, inclusi quelli confermati, per un massimo di 31 giorni. Questo valore è configurabile tramite la proprietà `message_retention_duration` dell'argomento.
Ripetizione dei messaggi Sì Sì
Località Il cluster locale può eseguire la replica 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 sulla 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 anche 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. Conservando i messaggi confermati, puoi riprodurli di nuovo in parte o del tutto 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 di nuovo.

Puoi creare snapshot di singoli abbonamenti on demand senza dover configurare il tuo abbonamento in anticipo. Ad esempio, puoi creare uno snapshot durante il deployment del nuovo codice degli abbonati perché potresti dover recuperare da acknowledgment imprevisti o errati.

Funzionalità di failsafe integrata con argomenti messaggi non recapitabili

Pub/Sub offre funzionalità simili alla gestione degli errori di Kafka 2.0 e a come Kafka Connect gestisce gli argomenti dead letter. Per notificare a Pub/Sub che un messaggio è stato consegnato correttamente, i sottoscrittori degli argomenti Pub/Sub possono confermare i messaggi che ricevono ed elaborano. Se i tuoi iscritti non sono in grado di elaborare i messaggi per un certo periodo di tempo, Pub/Sub può inoltrarli automaticamente a un argomento messaggi non recapitabili e archiviarli per consentirne l'accesso in un secondo momento. Puoi configurare il numero di tentativi di consegna dei messaggi da parte di Pub/Sub prima che il messaggio venga inviato all'argomento messaggi non recapitabili.

Deduplicazione dei messaggi in Pub/Sub utilizzando Dataflow

Pub/Sub consegna ogni messaggio pubblicato almeno una volta per ogni sottoscrizione. In generale, per consentire la consegna più volte è necessario che il sottoscrittore sia idempotente durante l'elaborazione dei messaggi. Se gli abbonati esistenti non sono in grado di operare in modo idempotente, puoi incorporare Dataflow per deduplicare i messaggi. Se i tuoi iscritti vedono un tasso elevato di messaggi duplicati, questo può indicare che non stanno confermando correttamente i messaggi o che la scadenza per la conferma è troppo breve.

Ordinamento dei messaggi in Pub/Sub

Se le applicazioni di abbonati Kafka si basano sull'ordinamento dei messaggi, puoi supportare questo requisito in Pub/Sub quando utilizzi le chiavi di ordinamento. Attualmente, l'ordinamento è garantito per i messaggi pubblicati in una determinata regione. Per sfruttare l'ordinamento dei messaggi, assicurati che i publisher e gli abbonati utilizzino gli endpoint geografici per instradare 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à Implementato in tutte le regioni Google Cloud per elevata disponibilità e bassa latenza
Ripristino di emergenza Progettare e gestire il backup e la replica Gestito da Google
Gestione dell'infrastruttura Esegui il deployment e gestisci manualmente macchine virtuali (VM) o macchine. Devi mantenere le versioni e le patch coerenti. Gestito da Google
Pianificazione della capacità Pianificare manualmente in anticipo le esigenze di archiviazione e calcolo Gestito da Google
Assistenza Nessuno Assistenza e personale di guardia disponibili 24 ore su 24

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

Sia Kafka che Pub/Sub hanno un buon rendimento per la gestione di grandi volumi di messaggi di piccole dimensioni. Kafka non impone limiti rigidi alle dimensioni dei messaggi e ti consente di configurare le dimensioni consentite, 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 l'abbonato 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 stime e gestisci i costi in Pub/Sub è diverso da quello in Kafka. I costi di un cluster Kafka on-premise o in cloud includono il costo di macchine, dischi, reti, 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 applicare le patch alle macchine manualmente, spesso è necessario pianificare la capacità del cluster e l'implementazione del ripristino di emergenza comporta una pianificazione e test estensivi. Devi dedurne e aggregare tutti questi vari costi per determinare il vero costo totale di proprietà (TCO).

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

Progettazione per l'affidabilità

Pub/Sub è un servizio gestito globale che viene eseguito in tutte le regioni Google Cloud. Gli argomenti Pub/Sub sono globali, il che significa che sono visibili e accessibili da qualsiasi località Google Cloud. Tuttavia, qualsiasi messaggio viene memorizzato in un'unica regione Google Cloud più vicina al publisher e consentita dal criterio di località delle risorse. Pertanto, un argomento può avere messaggi memorizzati in regioni diverse di Google Cloud. Pub/Sub è resistente alle interruzioni a livello di zona. Durante un'interruzione del servizio a livello di regione, i messaggi archiviati in quella regione specifica potrebbero non essere accessibili fino al ripristino del servizio. A seconda dei requisiti di disponibilità, puoi utilizzare gli endpoint dei servizi di geolocalizzazione per implementare un criterio di failover in caso di interruzione del servizio 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'utilizzo di elenchi di controllo dell'accesso (ACL) per determinare quali produttori e consumatori hanno accesso a quali 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 Identity and Access Management (IAM) in Google Cloud. Le operazioni Pub/Sub sono limitate in termini di frequenza quando si utilizzano account utente. Se devi effettuare transazioni ad alto volume, puoi utilizzare gli account di servizio 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 basi.

Migrazione graduale utilizzando il connettore Kafka Pub/Sub

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

Puoi configurare il connettore Pub/Sub in modo da inoltrare tutti i messaggi su argomenti specifici da Kafka a Pub/Sub. Poi, puoi aggiornare le singole applicazioni di abbonati in modo che ricevano messaggi su questi argomenti da Pub/Sub, mentre le applicazioni di publisher continuano a pubblicare messaggi in 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 tempo di riposo.

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:

Primo passaggio della migrazione.

Nel diagramma precedente, gli abbonati attuali continuano a ricevere messaggi da Kafka e li aggiorni uno per uno in modo che ricevano i messaggi da Pub/Sub.

Dopo aver aggiornato tutti gli iscritti a un determinato argomento in modo che ricevano i messaggi da Pub/Sub, puoi aggiornare le applicazioni di publisher per l'argomento in modo che pubblichino messaggi su Pub/Sub. Quindi, 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 publisher vengono aggiornati per pubblicare direttamente in Pub/Sub e la migrazione è 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 una migrazione riuscita.

Monitorare 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 assicurarti che i tuoi iscritti stiano al passo con il flusso di messaggi monitorando il numero di messaggi non recapitati. Per monitorare i messaggi non recapitati, crei 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