Concetti relativi allo streaming con Apache Kafka
Per comprendere meglio OCI Streaming con Apache Kafka, esamina alcuni termini e concetti.
Condizioni
- Apache Kafka
- Apache Kafka è una piattaforma di streaming di eventi open source. Funziona come un sistema distribuito composto da server e client. OCI Streaming con Apache Kafka ti consente di eseguire cluster Kafka completamente gestiti in una tenancy con compatibilità al 100% con Apache Kafka.
Puoi utilizzare OCI Console, API o CLI per creare e aggiornare il cluster e il broker.
- Cluster
- Sistema distribuito di server o broker Apache Kafka che memorizzano e gestiscono i dati di streaming. In OCI Streaming con Apache Kafka, puoi creare due tipi di cluster: il cluster iniziale o il cluster ad alta disponibilità.
- Broker
- Server Kafka che memorizza i dati ed elabora le richieste del client. A seconda del carico di lavoro, è possibile creare da 1 a 30 broker in ogni cluster. Ogni broker in un cluster è un nodo di calcolo utilizzato per memorizzare gli argomenti.
È possibile utilizzare l'interfaccia API o CLI Apache Kafka per creare e aggiornare argomenti, partizioni, record e operazioni producer e consumer.
- Argomento
- Categorie definite dall'utente in un broker in cui vengono memorizzati i dati. Ogni argomento può avere molte partizioni per la distribuzione dei dati e l'elaborazione parallela.
- Partizioni
- Gli argomenti vengono suddivisi in un numero specificato dall'utente di partizioni in cui sono memorizzati i record. I record vengono ordinati all'interno di ciascuna partizione e a ogni record viene assegnato un offset univoco e in sequenza.
- Record
- Coppie di dati di valore chiave che vengono scritte e lette da argomenti.
- Producer
- Applicazione che scrive i record negli argomenti.
- Consumer
- Applicazione che legge i record dagli argomenti.
- Cluster coordinatori
- Istanza di coordinatore interno all'interno di ogni cluster che tiene traccia delle attività in un cluster, ad esempio le partizioni. Un cluster con 2 o meno broker ottiene un cluster di coordinatori a nodo singolo. I cluster più grandi ottengono un cluster di coordinatori a 3 nodi. Impossibile visualizzare i dettagli del cluster coordinatore.
Limiti del servizio
| Limitato | Value |
|---|---|
| Cluster per tenancy | 5 |
| Broker per cluster | 30 |
| Broker per tenancy | 150 |
| Storage |
Minimo da 50 GB a massimo 5 TB per broker Massimo 150 TB per cluster |
| Configurazione cluster | 100 |
| In entrata per cluster | nessun limiti |
| In uscita per cluster | nessun limiti |
| In entrata per partizione | nessun limiti |
| In uscita per partizione | nessun limiti |
| Partizioni | nessun limiti |
| Numero massimo di connessioni client | nessun limiti |
| Numero massimo tentativi di connessione | nessun limiti |
| Numero massimo di richieste (al secondo) | nessun limiti |
| Dimensione massima messaggi (MB) | nessun limiti |
| Dimensione massima richiesta (MB) | nessun limiti |
| Numero massimo byte di recupero (MB) | nessun limiti |
| Chiavi API | Non applicabile |
| ACL | nessun limiti |
| Configurazioni | 100 per tenancy |
| Aggiornamenti della configurazione | nessun limiti |
Limiti funzione
| Funzione | Supporto |
|---|---|
| Esattamente una volta semantica | Sì |
| Storage compatto basato su chiave | Sì |
| Connettori personalizzati | N |
| Supporto nativo ksqlDB | N |
| Networking pubblico | N |
| Networking privato | Sì |
| OAuth | N |
| Log di audit | Sì |
| Chiavi di cifratura autogestite | N |
| Ridimensionamento elastico automatico | N |
| Condivisione streaming | N |
| Quote dei clienti | Sì |
Tipi di cluster
In OCI Streaming con Apache Kafka, puoi creare due tipi di cluster.
- Cluster iniziale
- Progettato per scopi di test e sviluppo in cui l'alta disponibilità non è un requisito fondamentale. Un ammasso iniziale offre un set-up flessibile in cui i cluster possono avere da 1 a 30 broker.
- Cluster High Availability
- Destinato ad ambienti di produzione in cui l'alta disponibilità è essenziale. Questi cluster sono configurati con un minimo di 3 broker distribuiti su più domini di disponibilità o di errore per garantire ridondanza e tolleranza agli errori. Il cluster può scalare fino a un massimo di 30 broker, fornendo affidabilità e resilienza per carichi di lavoro mission-critical.
Opzioni predefinite cluster
Esaminare le opzioni predefinite riportate di seguito per un cluster Kafka.
- Connettività
- Per impostazione predefinita, tutti i cluster Kafka vengono creati con connettività privata ed è possibile accedervi dall'interno della VCN e della subnet specificate durante la creazione del cluster. Se più reti VCN devono accedere al cluster Kafka, configurare il peering VCN.
- Quote disco broker
- Per impostazione predefinita, le quote del disco del broker vengono applicate per garantire la stabilità e prevenire l'uso eccessivo delle risorse del disco. Quando un disco broker raggiunge il 97% di capacità, le operazioni del producer sono limitate alla tariffa, mentre le operazioni del consumer non sono interessate e continuano a funzionare come previsto. Quando un disco broker raggiunge la capacità del 98%, tutte le operazioni del produttore vengono bloccate mentre le operazioni del consumatore possono continuare a consumare eventi e a commettere offset senza interruzioni. È possibile modificare questo comportamento predefinito e definire quote di memorizzazione personalizzate in un file di configurazione del cluster.
- File di configurazione del cluster
- Quando si crea un cluster Kafka, il file di configurazione del cluster viene creato con le proprietà predefinite a seconda del tipo di cluster. Le impostazioni delle proprietà sono progettate per bilanciare affidabilità, durata e facilità d'uso. È possibile utilizzare il file predefinito o creare un file personalizzato. Per un elenco delle proprietà configurabili e non configurabili, vedere Gestione delle configurazioni cluster.
Cluster High Availability
allow.everyone.if.no.acl.found=true auto.create.topics.enable=false leader.imbalance.per.broker.percentage=1 default.replication.factor=3 offsets.topic.replication.factor=3 min.insync.replicas=2 transaction.state.log.min.isr=2 transaction.state.log.replication.factor=3Property Valore predefinito Scopo allow.everyone.if.no.acl.foundvero Se non viene trovata alcuna ACL per una risorsa, a tutti gli utenti è consentito l'accesso al cluster. auto.create.topics.enablefalso Gli argomenti non vengono creati automaticamente, ma devono essere creati in modo esplicito per un migliore controllo. leader.imbalance.per.broker.percentage1 Controlla la soglia di squilibrio leader per broker per il ribilanciamento. default.replication.factor3 Vengono creati nuovi argomenti con 3 repliche per garantire elevata durabilità. offsets.topic.replication.factor3 L'argomento degli offset interni viene replicato 3 volte per la resilienza. min.insync.replicas2 Almeno 2 repliche devono confermare la durabilità del processo di scrittura. transaction.state.log.min.isr2 Numero minimo di repliche in-sync per il log dello stato della transazione. transaction.state.log.replication.factor3 Fattore di replica per il log dello stato della transazione. Cluster starter
allow.everyone.if.no.acl.found=true auto.create.topics.enable=false leader.imbalance.per.broker.percentage=1 default.replication.factor=1 offsets.topic.replication.factor=1 min.insync.replicas=1 transaction.state.log.min.isr=1 transaction.state.log.replication.factor=1Property Valore predefinito Scopo allow.everyone.if.no.acl.foundvero Se non viene trovata alcuna ACL per una risorsa, a tutti gli utenti è consentito l'accesso al cluster. auto.create.topics.enablefalso Gli argomenti non vengono creati automaticamente, ma devono essere creati in modo esplicito per un migliore controllo. leader.imbalance.per.broker.percentage1 Controlla la soglia di squilibrio leader per broker per il ribilanciamento. default.replication.factor1 I nuovi argomenti vengono creati con 1 replica (nessuna ridondanza). offsets.topic.replication.factor1 L'argomento degli offset interni contiene una singola replica. min.insync.replicas1 Solo 1 replica deve riconoscere una scrittura. transaction.state.log.min.isr1 Numero minimo di repliche in-sync per il log dello stato della transazione. transaction.state.log.replication.factor1 Fattore di replica per il log dello stato della transazione.
Pianificare la dimensione e lo storage del cluster
Esamina le linee guida sul dimensionamento dei cluster per ottimizzare e ottenere il massimo da uno streaming OCI con il cluster Apache Kafka.
Linee guida generali
Se è necessario un throughput maggiore, è possibile implementare le azioni riportate di seguito.
- Aumenta il numero di broker nel cluster
- Aumentare il numero di partizioni nel cluster
- Aumenta OCPU per broker
Se è necessaria una latenza inferiore, è possibile implementare le azioni riportate di seguito.
- Usa broker più grandi con memoria più elevata
- Utilizza batch più piccoli,
linger.mspiù breve e ottimizza il percorso di rete
Se la durata è più importante della latenza, considerare la possibilità di impostare il parametro di configurazione del producer acks impostato su all.
La mancata pianificazione e configurazione del cluster influisce sulle prestazioni del cluster.
- La configurazione di meno broker comporta un throughput ridotto, un'elevata latenza e un sovraccarico di broker.
- La configurazione di un numero inferiore di partizioni comporta un parallelismo insufficiente e un uso ridotto del consumatore.
- La configurazione di broker non alimentati comporta un recupero elevato o una latenza elevata, problemi GC e broker instabili.
- La configurazione di troppe partizioni su broker più piccoli determina un uso elevato della memoria, un blocco dei metadati e un ribilanciamento instabile.
Benchmark prestazioni
Esaminare le metriche delle prestazioni nei cluster Kafka con processori basati su Arm, il fattore di replica impostato su 3 e il parametro di configurazione del producer acks impostato su 1.
| Configurazione broker | Partizioni | Throughput massimo producer | Throughput massimo consumer | Latenza |
|---|---|---|---|---|
3 broker, ognuno con la seguente configurazione:
|
1.000 | 161.21 MB al secondo | 394.38 MB al secondo | 50,70 ms |
3 broker, ognuno con la seguente configurazione:
|
2.000 | 368.76 MB al secondo | 678.39 MB al secondo | 27,79 ms |
3 broker, ognuno con la seguente configurazione:
|
2.000 | 505.13 MB al secondo | 710.82 MB al secondo | 21,11 ms |
18 broker, ognuno con la seguente configurazione:
|
2.000 | 379.39 MB al secondo | 690.27 MB al secondo | 80,18 ms |
18 broker, ognuno con la seguente configurazione:
|
4.000 | 788.73 MB al secondo | 998.11 MB al secondo | 74,53 ms |
18 broker, ognuno con la seguente configurazione:
|
4.000 | 1.08 GB al secondo | 1.15 GB al secondo | 71,29 ms |
30 broker, ognuno con la seguente configurazione:
|
4.000 | 617.60 MB al secondo | 1.02 GB al secondo | 98,27 ms |
30 broker, ognuno con la seguente configurazione:
|
6.000 | 1.65 GB al secondo | 1.34 GB al secondo | 65,81 ms |
30 broker, ognuno con la seguente configurazione:
|
6.000 | 2.41 GB al secondo | 2.09 GB al secondo | 56,82 ms |
Le metriche delle prestazioni dipendono da diversi fattori e i miglioramenti in una configurazione potrebbero portare a compromessi in altri.
Ad esempio, i numeri di throughput variano a seconda di fattori quali la dimensione del messaggio, il tipo di compressione, la dimensione del batch e linger.ms. Una dimensione batch più elevata può aumentare il throughput, ma può anche portare a una latenza più elevata.
L'aumento del numero di partizioni in genere migliora il throughput e le prestazioni del producer. Tuttavia, aumenta anche l'uso delle risorse di produttori e consumatori e introduce un maggiore sovraccarico di metadati. Ciò può rallentare l'elezione dei leader e la gestione della replica in-sync (ISR), aumentando potenzialmente la latenza delle richieste di produzione e recupero.
È necessario eseguire il tuning dei parametri in base ai requisiti.
- Per ottimizzare la latenza inferiore, ridurre
batch.sizeelinger.msed evitare una compressione elevata. - Per massimizzare il throughput, aumentare
batch.size, abilitare la compressione e utilizzare più partizioni e broker per ridimensionarsi orizzontalmente.
Monitora sempre attentamente le metriche di latenza e throughput e ottimizza il cluster in modo iterativo in base ai modelli di carico di lavoro reali.
Esegui migrazione
È possibile eseguire la migrazione dei dati da un cluster Apache Kafka autogestito a un OCI Streaming con un cluster Apache Kafka.
La soluzione consigliata per questo caso d'uso della migrazione consiste nel creare un connettore MirrorMaker 2.0 in un cluster di connessione.
Di seguito è riportata una configurazione di esempio di
client.properties.security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
ssl.truststore.location=</path/to/truststore.jks>
ssl.truststore.password=<truststore-password>
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="<username>" password="<password>";