Questo documento è utile se stai valutando di eseguire la migrazione da Apache Kafka autogestito a Pub/Sub, perché può aiutarti a esaminare e prendere in considerazione funzionalità, prezzi e 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. I servizi Pub/Sub disaccoppiano gli eventi che generano eventi dai servizi che elaborano gli eventi. Puoi utilizzare Pub/Sub come middleware orientato alla messaggistica o per l'importazione e la distribuzione di eventi per le pipeline di analisi dei flussi di dati. In entrambi gli scenari, un'applicazione di editore crea e invia messaggi a un argomento. Le applicazioni abbonati creano una sottoscrizione a un argomento per ricevere i propri 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 del publisher al data center di Google Cloud più vicino in cui è consentito l'archiviazione dei dati, come definito dal criterio restrizione della 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 da utilizzarli come origini dati che possono pubblicare messaggi in Pub/Sub o come sink di dati in grado di ricevere messaggi da Pub/Sub.
Panoramica di Kafka
Apache Kafka è una piattaforma di streaming di eventi open source distribuita e consente alle applicazioni di pubblicare, sottoscrivere, 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 gli eventi. Puoi utilizzare Kafka per disaccoppiare le applicazioni, inviare e ricevere messaggi, monitorare attività, aggregare dati di log ed elaborare flussi.
All'interno del cluster Kafka, alcuni nodi sono designati come broker. I broker ricevono messaggi dai producer e li archiviano su disco. I messaggi archiviati sono organizzati per argomento e suddivisi in vari broker diversi 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:
Nel diagramma precedente, ogni M rappresenta un messaggio. I broker Kafka gestiscono più partizioni di messaggi ordinate, rappresentate dalle righe orizzontali dei messaggi. I consumer leggono i messaggi provenienti da una particolare partizione che ha una capacità basata sulla macchina che ospita la partizione. Pub/Sub non ha partizioni e i consumer leggono invece da un argomento che scala automaticamente in base alla domanda. Configura ogni argomento Kafka con il numero di partizioni necessarie per gestire il carico del consumatore previsto. Pub/Sub scala automaticamente in base alla domanda.
Confronto tra le 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 |
| Deduplicazione di messaggi | Sì | Sì, utilizzando Dataflow |
| Sottoscrizioni push | No | SÌ |
| Coda di messaggi non recapitabili (coda di messaggi non elaborabile) |
A partire dalla versione 2.0 | SÌ |
| Transazioni | Sì | No |
| Archiviazione dei messaggi | Limitata solo dallo spazio di archiviazione disponibile | 31 giorni. Un argomento può conservare i messaggi pubblicati, inclusi i messaggi confermati, per un massimo di 31 giorni. Questa opzione è configurabile dalla proprietà `message_retention_duration` dell'argomento. |
| Riproduzione messaggio | Sì | SÌ |
| Località | La replica locale può essere replicata utilizzando MirrorMaker | Servizio distribuito 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 contiene i messaggi non confermati per un massimo di 7 giorni, ma puoi configurare le sottoscrizioni Pub/Sub in modo da conservare i messaggi confermati per un massimo di 7 giorni, a seconda dell'età del messaggio meno recente (confermato o non confermato) nella sottoscrizione. Se conservi i messaggi confermati, puoi replicare 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 sono contrassegnati come non riconosciuti. I messaggi non confermati vengono quindi recapitati nuovamente.
Puoi creare snapshot di singoli abbonamenti on demand senza dover configurare l'abbonamento in anticipo. Ad esempio, puoi creare uno snapshot durante il deployment di un nuovo codice abbonato perché potresti dover recuperare da conferme impreviste o errate.
Integrato nella sicurezza con argomenti non recapitabili
Pub/Sub fornisce funzionalità simili alla gestione degli errori di Kafka 2.0 e al modo in cui Kafka Connect gestisce gli argomenti non recapitabili. Per informare Pub/Sub che un messaggio è stato consegnato correttamente, i sottoscrittori di argomenti Pub/Sub possono confermare i messaggi che ricevono ed elaborano. 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 messaggi non recapitabili e archiviarli per accedervi in un secondo momento. Puoi configurare il numero di tentativi effettuati da Pub/Sub per consegnare i messaggi prima che inviino il messaggio all'argomento messaggi non recapitabili.
Deduplicazione di messaggi in Pub/Sub con Dataflow
Pub/Sub recapita ogni messaggio pubblicato almeno una volta per ogni sottoscrizione. In generale, l'implementazione 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 involontario, puoi incorporare Dataflow per deduplicare i messaggi. Se i tuoi iscritti visualizzano un elevato numero di messaggi duplicati, è possibile che i messaggi non vengano confermati correttamente o che la scadenza sia troppo breve.
Ordinamento dei messaggi in Pub/Sub
Se le applicazioni che utilizzano 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 area geografica. Per utilizzare l'ordinamento dei messaggi, assicurati che i publisher e i sottoscrittori utilizzino gli endpoint a livello di regione per instradare i tuoi messaggi alla regione corretta.
Capire le responsabilità del servizio self-hosted e delle funzionalità gestite
La tabella seguente mette a confronto la funzionalità ospitata autonomamente con Kafka e la funzionalità gestita da Google mediante Pub/Sub:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Disponibilità | Esegui manualmente il deployment di Kafka in località aggiuntive | Deployment in tutte le regioni di Google Cloud per disponibilità elevata e bassa latenza |
| Ripristino di emergenza | Progetta e mantieni i tuoi backup e la tua replica | Gestito da Google |
| Gestione dell'infrastruttura | Esegui il deployment e il funzionamento manuale di macchine virtuali (VM). Devi mantenere il controllo delle versioni e le patch coerenti. | Gestito da Google |
| Pianificazione della capacità | Pianificare manualmente le esigenze di archiviazione e calcolo in anticipo | Gestito da Google |
| Assistenza | Nessun elemento | Personale e assistenza 24 ore su 24 disponibili |
Soluzioni e limiti di dimensione dei messaggi Pub/Sub
Kafka e Pub/Sub offrono buoni risultati quando gestiscono grandi volumi di messaggi piccoli. Kafka non pone limiti rigidi 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 diagramma seguente:
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 da quello 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 dei dati e i costi generali per la gestione e la manutenzione di questi sistemi e della relativa infrastruttura correlata. Durante la gestione di un cluster Kafka, spesso è necessario eseguire manualmente l'upgrade e l'applicazione di patch delle macchine, pianificare spesso la capacità dei cluster e l'implementazione del ripristino di emergenza comporta una pianificazione e test approfonditi. Devi dedurre e aggregare tutti questi costi per determinare il costo totale di proprietà (TCO) effettivo.
I prezzi di Pub/Sub includono il trasferimento di dati dai publisher e ai sottoscrittori, nonché il costo dell'archiviazione temporanea dei messaggi non confermati. Paghi esattamente per le risorse che utilizzi, scalando automaticamente la sua capacità in base ai requisiti della tua applicazione e del tuo budget.
Architetto 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, ovvero sono visibili e accessibili da qualsiasi località Google Cloud. Tuttavia, qualsiasi messaggio viene archiviato in un'unica 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 in Google Cloud. Pub/Sub è resistente alle interruzioni di zona. Durante un'interruzione a livello di area geografica, i messaggi archiviati in quell'area geografica specifica potrebbero essere inaccessibili fino al ripristino del servizio. A seconda dei requisiti di disponibilità, puoi utilizzare gli endpoint di servizio a livello di regione per implementare un criterio di failover se si verifica un'interruzione a livello di regione.
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 dell'accesso granulare per gli argomenti e le sottoscrizioni Pub/Sub è regolato da Identifi and Access Management (IAM) in Google Cloud. Le operazioni Pub/Sub sono limitate a livello di frequenza quando si utilizzano account utente. Se hai bisogno di effettuare transazioni a volumi elevati, 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 mediante il connettore Kafka per Pub/Sub
Il connettore Kafka per 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 singole applicazioni dei sottoscrittori per ricevere messaggi su tali argomenti da Pub/Sub, mentre le applicazioni del tuo 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:
Nel diagramma precedente, i sottoscrittori attuali continuano a ricevere messaggi da Kafka e vengono aggiornati uno per uno per ricevere i 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 del publisher per quell'argomento per pubblicare messaggi in Pub/Sub. Successivamente, potrai testare e monitorare i flussi dei messaggi end-to-end per verificare la configurazione.
Il seguente diagramma mostra la configurazione dopo che tutti i sottoscrittori ricevono messaggi da Pub/Sub:
Nel tempo, tutti i publisher vengono aggiornati e pubblicati direttamente in Pub/Sub, quindi la migrazione è completa. Molti team utilizzano questo approccio per aggiornare le 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 tue applicazioni. Pub/Sub esporta le metriche utilizzando Cloud Monitoring, che possono aiutare a fornire visibilità su prestazioni, uptime e integrità complessiva delle tue applicazioni. Ad esempio, puoi assicurarti che i tuoi iscritti tengano il passo con il flusso dei messaggi monitorando il numero dei messaggi non recapitati. Per monitorare i messaggi non recapitati, puoi creare avvisi quando il timestamp del messaggio meno recente non confermato 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
- Analisi dei flussi con Pub/Sub.
- Riferimento API Pub/Sub.
- Documentazione di Monitoring per Pub/Sub.
- Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.