Le migliori pratiche per i broker standard - Amazon Managed Streaming per Apache Kafka
Considerazioni sul lato clientConsiderazioni sul lato server

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Le migliori pratiche per i broker standard

In questo argomento vengono illustrate alcune best practice da seguire quando si utilizza Amazon MSK. Per informazioni sulle best practice di Amazon MSK Replicator, consulta. Le migliori pratiche per l'utilizzo di MSK Replicator

Considerazioni sul lato client

La disponibilità e le prestazioni dell'applicazione dipendono non solo dalle impostazioni lato server ma anche dalle impostazioni client.

  • Configura i tuoi client per un'elevata disponibilità. In un sistema distribuito come Apache Kafka, garantire un'elevata disponibilità è fondamentale per mantenere un'infrastruttura di messaggistica affidabile e tollerante ai guasti. I broker andranno offline per eventi pianificati e non pianificati, ad esempio aggiornamenti, patch, guasti hardware e problemi di rete. Un cluster Kafka è tollerante nei confronti di un broker offline, pertanto i clienti Kafka devono anche gestire il failover dei broker con garbo. Vedi i dettagli completi su. Le migliori pratiche per i client Apache Kafka

  • Assicurati che le stringhe di connessione del client includano almeno un broker per ogni zona di disponibilità. La presenza di più broker nella stringa di connessione di un client consente il failover quando un broker specifico è offline a seguito di un aggiornamento. Per informazioni su come ottenere una stringa di connessione con più broker, consulta Ottieni i broker bootstrap per un cluster Amazon MSK.

  • Esegui test delle prestazioni per verificare che le configurazioni dei tuoi client ti consentano di raggiungere i tuoi obiettivi prestazionali.

Considerazioni sul lato server

Dimensioni corrette del cluster: numero di partizioni per broker Standard

La tabella seguente mostra il numero consigliato di partizioni (incluse le repliche leader e follower) per broker Standard. Il numero consigliato di partizioni non viene applicato e rappresenta una procedura ottimale per gli scenari in cui si invia traffico su tutte le partizioni tematiche assegnate.

Dimensioni del broker Numero consigliato di partizioni (incluse le repliche leader e follower) per broker Numero massimo di partizioni che supportano le operazioni di aggiornamento
kafka.t3.small 300 300
kafka.m5.large o kafka.m5.xlarge 1000 1500
kafka.m5.2xlarge 2000 3000
kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge oppure kafka.m5.24xlarge 4000 6000
kafka.m7g.large o kafka.m7g.xlarge 1000 1500
kafka.m7g.2xlarge 2000 3000
kafka.m7g.4xlarge, kafka.m7g.8xlargekafka.m7g.12xlarge, o kafka.m7g.16xlarge 4000 6000

Se si utilizzano partizioni elevate e un throughput ridotto in cui il numero di partizioni è più elevato, ma non si invia traffico su tutte le partizioni, è possibile comprimere più partizioni per broker, purché siano stati eseguiti test e test delle prestazioni sufficienti per verificare che il cluster rimanga integro con un numero di partizioni più elevato. Se il numero di partizioni per broker supera il valore massimo consentito e il cluster si sovraccarica, ti verrà impedito di eseguire le seguenti operazioni:

  • Aggiornamento della configurazione del cluster

  • Aggiorna il cluster a un broker di dimensioni inferiori

  • Associa un AWS Secrets Manager segreto a un cluster con autenticazione SASL/SCRAM

Un numero elevato di partizioni può inoltre comportare la mancanza delle metriche di Kafka CloudWatch su e sullo scraping di Prometheus.

Per informazioni sulla scelta del numero di partizioni, consulta Apache Kafka Supports 200K Partitions Per Cluster. Ti consigliamo inoltre di eseguire i tuoi test per determinare la dimensione giusta per i tuoi broker. Per ulteriori informazioni sulle diverse dimensioni dei broker, consultaTipi di broker Amazon MSK.

Dimensiona correttamente il tuo cluster: numero di broker Standard per cluster

Per determinare il numero corretto di broker Standard per il cluster MSK Provisioned e comprendere i costi, consultate il foglio di calcolo MSK Sizing and Pricing. Questo foglio di calcolo fornisce una stima del dimensionamento di un cluster MSK Provisioned e dei costi associati di Amazon MSK rispetto a un cluster Apache Kafka simile, autogestito e basato su Apache Kafka. EC2 Per ulteriori informazioni sui parametri di input nel foglio di calcolo, passare il mouse sulle descrizioni dei parametri. Le stime fornite da questo foglio sono conservative e forniscono un punto di partenza per un nuovo cluster MSK Provisioned. Le prestazioni, le dimensioni e i costi del cluster dipendono dal caso d'uso e consigliamo di verificarli con test ad hoc.

Per comprendere in che modo l'infrastruttura sottostante influisce sulle prestazioni di Apache Kafka, consulta le migliori pratiche per il corretto dimensionamento dei cluster Apache Kafka per ottimizzare prestazioni e costi nel Big Data Blog. AWS Il post del blog fornisce informazioni su come dimensionare i cluster per soddisfare i requisiti di velocità di trasmissione effettiva, disponibilità e latenza. Fornisce inoltre risposte a domande, ad esempio quando è necessario scalare verso l'alto o verso l'alto, e indicazioni su come verificare continuamente le dimensioni dei cluster di produzione. Per informazioni sui cluster basati sullo storage su più livelli, consulta Best practice per l'esecuzione di carichi di lavoro di produzione utilizzando lo storage su più livelli Amazon MSK.

Ottimizza il throughput del cluster per istanze m5.4xl, m7g.4xl o più grandi

Quando si utilizzano istanze m5.4xl, m7g.4xl o più grandi, è possibile ottimizzare il throughput del cluster MSK Provisioned ottimizzando le configurazioni num.io.threads e num.network.threads.

num.io.Threads è il numero di thread utilizzati da un broker Standard per l'elaborazione delle richieste. L'aggiunta di più thread, fino al numero di core CPU supportati per la dimensione dell'istanza, può aiutare a migliorare il throughput del cluster.

num.network.threads è il numero di thread utilizzati dal broker Standard per ricevere tutte le richieste in arrivo e restituire le risposte. I thread di rete inseriscono le richieste in entrata in una coda di richieste per l'elaborazione da parte di io.threads. L'impostazione di num.network.threads sulla metà del numero di core CPU supportati per la dimensione dell'istanza consente l'utilizzo completo della nuova dimensione dell'istanza.

Importante

Non aumentare num.network.threads senza prima aumentare num.io.threads, in quanto ciò può causare una congestione legata alla saturazione della coda.

Impostazioni consigliate
Dimensioni istanza Valore consigliato per num.io.threads Valore consigliato per num.network.threads

m5.4xl

16

8

m5.8xl

32

16

m5.12xl

48

24

m5.16xl

64

32

m5.24xl

96

48

m7g.4xlarge

16

8

m7g.8xlarge

32

16

m7g.12xlarge

48

24

m7g.16xlarge

64

32

Usa l'ultima versione di Kafka per evitare problemi di mancata corrispondenza tra gli ID degli argomenti AdminClient

L'ID di un argomento viene perso (Errore: non corrisponde all'ID dell'argomento per la partizione) quando si utilizza una versione di Kafka AdminClient precedente alla 2.8.0 con il flag per aumentare o riassegnare le partizioni degli argomenti per un cluster MSK --zookeeper Provisioned utilizzando la versione 2.8.0 o successiva di Kafka. Nota che il flag --zookeeper è obsoleto in Kafka 2.5 ed è stato rimosso a partire da Kafka 3.0. Consulta la pagina Upgrading to 2.5.0 from any version 0.8.x through 2.4.x.

Per evitare la mancata corrispondenza degli ID degli argomenti, utilizza una versione del client Kafka 2.8.0 o successiva per le operazioni di amministrazione di Kafka. In alternativa, i client 2.5 e versioni successive possono utilizzare il flag --bootstrap-servers al posto del flag --zookeeper.

Creazione di cluster a disponibilità elevata

Utilizza i seguenti consigli in modo che i tuoi cluster MSK Provisioned possano essere altamente disponibili durante un aggiornamento (ad esempio quando aggiorni le dimensioni del broker o la versione di Apache Kafka, ad esempio) o quando Amazon MSK sostituisce un broker.

  • Configura un cluster con tre zone di disponibilità.

  • Assicurati che il fattore di replica (RF) sia almeno 3. Tieni presente che un valore di RF pari a 1 può portare a partizioni offline durante un aggiornamento in sequenza, mentre un RF pari a 2 può causare la perdita di dati.

  • Impostare le repliche in sinc minime (minISR) su al massimo RF - 1. Un minISR uguale a RF può impedire la produzione nel cluster durante un aggiornamento in sequenza. Un minISR di 2 consente di rendere disponibili argomenti replicati a tre vie quando una replica è offline.

Monitoraggio dell'utilizzo della CPU

Amazon MSK consiglia vivamente di mantenere l'utilizzo totale della CPU per i broker (definito come CPU User + CPU System) al di sotto del 60%. Quando hai a disposizione almeno il 40% della CPU totale del cluster, Apache Kafka può ridistribuire il carico della CPU tra i broker del cluster, se necessario. Ad esempio, ciò si rende necessario quando Amazon MSK rileva e ripristina un errore del broker; in questo caso, Amazon MSK esegue la manutenzione automatica, ad esempio l'applicazione di patch. Un altro esempio è quando un utente richiede una modifica delle dimensioni del broker o un aggiornamento di versione; in questi due casi, Amazon MSK implementa flussi di lavoro continui che portano offline un broker alla volta. Quando i broker con partizioni leader vanno offline, Apache Kafka riassegna la leadership delle partizioni per ridistribuire il lavoro agli altri broker del cluster. Seguendo questa best practice, puoi assicurarti di avere abbastanza margine nella CPU nel cluster per tollerare eventi operativi come questi.

Puoi utilizzare Amazon CloudWatch Metric Math per creare una metrica composita. CPU User + CPU System Imposta un allarme che si attiva quando il parametro composito raggiunge un utilizzo medio della CPU del 60%. Quando viene attivato questo allarme, dimensiona il cluster utilizzando una delle seguenti opzioni:

  • Opzione 1 (consigliata): aggiorna la dimensione del broker alla dimensione successiva più grande. Ad esempio, se la dimensione corrente èkafka.m5.large, aggiorna il cluster da utilizzarekafka.m5.xlarge. Tieni presente che quando aggiorni le dimensioni dei broker nel cluster, Amazon MSK disconnette i broker in modo continuativo e riassegna temporaneamente la leadership delle partizioni ad altri broker. Un aggiornamento delle dimensioni richiede in genere 10-15 minuti per broker.

  • Opzione 2: se ci sono argomenti in cui tutti i messaggi sono stati acquisiti da produttori che utilizzano scritture ininterrotte (in altre parole, i messaggi non sono codificati e l'ordinamento non è importante per i consumatori), espandi il cluster aggiungendo altri broker. Inoltre, aggiungi partizioni agli argomenti esistenti con la velocità di trasmissione effettiva più elevata. Successivamente, utilizza kafka-topics.sh --describe per assicurarti che le partizioni appena aggiunte vengano assegnate ai nuovi broker. Il vantaggio principale di questa opzione rispetto alla precedente è la possibilità di gestire risorse e costi in modo più granulare. Inoltre, è possibile utilizzare questa opzione se il carico della CPU supera in modo significativo il 60%, poiché questa forma di dimensionamento in genere non comporta un aumento del carico per i broker esistenti.

  • Opzione 3: espandi il cluster MSK Provisioned aggiungendo broker, quindi riassegna le partizioni esistenti utilizzando lo strumento di riassegnazione delle partizioni denominato. kafka-reassign-partitions.sh Tuttavia, se utilizzi questa opzione, il cluster dovrà spendere risorse per replicare i dati da broker a broker dopo la riassegnazione delle partizioni. Rispetto alle due opzioni precedenti, questa opzione può inizialmente aumentare in modo significativo il carico sul cluster. Di conseguenza, Amazon MSK sconsiglia di utilizzare questa opzione quando l'utilizzo della CPU è superiore al 70%, perché la replica causa un carico aggiuntivo della CPU e del traffico di rete. Amazon MSK consiglia di utilizzare questa opzione solo se le due opzioni precedenti non sono percorribili.

Altre raccomandazioni:

  • Monitora l'utilizzo totale della CPU per broker come proxy per la distribuzione del carico. Se i broker hanno un utilizzo della CPU costantemente irregolare, potrebbe essere un segno che il carico non è distribuito uniformemente all'interno del cluster. Si consiglia di utilizzare Cruise Control per gestire continuamente la distribuzione del carico tramite l'assegnazione delle partizioni.

  • Monitora la latenza di produzione e utilizzo. La latenza di produzione e utilizzo può aumentare linearmente con l'utilizzo della CPU.

  • Intervallo di scrape JMX: se si abilita il monitoraggio aperto con la funzionalità Prometheus, si consiglia di utilizzare un intervallo di scrape di 60 secondi o superiore (scrape_interval: 60s) per la configurazione dell'host Prometheus (prometheus.yml). La riduzione dell'intervallo di scrape può comportare un utilizzo elevato della CPU sul cluster.

Monitoraggio dello spazio su disco

Per evitare di esaurire lo spazio su disco per i messaggi, crea un CloudWatch allarme che controlli la KafkaDataLogsDiskUsed metrica. Quando il valore di questo parametro raggiunge o supera l'85%, esegui una o più delle seguenti operazioni:

Per informazioni su come configurare e utilizzare gli allarmi, consulta Using Amazon CloudWatch Alarms. Per un elenco completo di parametri di Amazon MSK, consulta la sezione Monitora un cluster Amazon MSK Provisioned.

Regolazione dei parametri di conservazione dei dati

Il consumo di messaggi non li rimuove dal log. Per liberare regolarmente spazio su disco, puoi specificare in modo esplicito un periodo di conservazione, ovvero il periodo di permanenza dei messaggi nel log. Puoi inoltre specificare una dimensione del log di conservazione. Quando viene raggiunto il periodo di conservazione o la dimensione del log di conservazione, Apache Kafka inizia a rimuovere i segmenti inattivi dal log.

Per specificare una policy di conservazione a livello di cluster, imposta uno o più dei seguenti parametri: log.retention.hours, log.retention.minutes, log.retention.ms o log.retention.bytes. Per ulteriori informazioni, consulta Configurazioni Amazon MSK personalizzate.

Puoi anche specificare i parametri di conservazione a livello di argomento:

  • Per specificare un periodo di conservazione per argomento, utilizza il comando seguente.

    kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.ms=DesiredRetentionTimePeriod

  • Per specificare una dimensione del log di conservazione per argomento, utilizza il comando seguente.

    kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.bytes=DesiredRetentionLogSize

I parametri di conservazione specificati a livello di argomento hanno la precedenza sui parametri a livello di cluster.

Accelerazione del ripristino dei log dopo un arresto non corretto

Dopo un arresto non corretto, un broker può impiegare del tempo per riavviarsi poiché esegue il ripristino dei log. Per impostazione predefinita, Kafka utilizza solo un thread per directory di log per eseguire questo ripristino. Ad esempio, se si dispone di migliaia di partizioni, il completamento del ripristino dei log può richiedere ore. Per velocizzare il ripristino dei log, si consiglia di aumentare il numero di thread utilizzando la proprietà di configurazione num.recovery.threads.per.data.dir. È possibile impostarlo sul numero di core CPU.

Monitoraggio della memoria di Apache Kafka

Ti consigliamo di monitorare la memoria utilizzata da Apache Kafka. In caso contrario, il cluster potrebbe diventare non disponibile.

Per determinare la quantità di memoria utilizzata da Apache Kafka, puoi monitorare il parametro HeapMemoryAfterGC. HeapMemoryAfterGC è la percentuale di memoria heap totale utilizzata dopo la rimozione di oggetti inutili (garbage collection). Ti consigliamo di creare un CloudWatch allarme che agisca quando un HeapMemoryAfterGC aumento supera il 60%.

Le operazioni che è possibile eseguire per ridurre l'utilizzo della memoria variano. Dipendono dal modo in cui si configura Apache Kafka. Ad esempio, se si utilizza la consegna transazionale dei messaggi, è possibile ridurre il valore transactional.id.expiration.ms nella configurazione di Apache Kafka da 604800000 ms a 86400000 ms (da 7 giorni a 1 giorno). Ciò riduce l'ingombro di memoria di ciascuna transazione.

Non aggiungere broker non MSK

Per i cluster MSK Provisioned ZooKeeper basati su MSK, se si utilizzano ZooKeeper i comandi Apache per aggiungere broker, questi broker non vengono aggiunti al cluster MSK Provisioned e ZooKeeper Apache conterrà informazioni errate sul cluster. Ciò potrebbe comportare la perdita di dati. Per le operazioni supportate del cluster MSK Provisioned, vedere. Caratteristiche e concetti chiave di Amazon MSK

Abilitazione della crittografia dei dati in transito

Per informazioni sulla crittografia dei dati in transito e su come abilitarla, consulta Crittografia Amazon MSK in transito.

Riassegnazione delle partizioni

Per spostare le partizioni su broker diversi sullo stesso cluster MSK Provisioned, è possibile utilizzare lo strumento di riassegnazione delle partizioni denominato. kafka-reassign-partitions.sh Si consiglia di non riassegnare più di 10 partizioni in una singola chiamata per operazioni sicure. kafka-reassign-partitions Ad esempio, dopo aver aggiunto nuovi broker per espandere un cluster o aver spostato le partizioni per rimuovere i broker, è possibile ribilanciare il cluster riassegnando le partizioni ai nuovi broker. Per informazioni su come aggiungere broker a un cluster MSK Provisioned, vedere. Espandi il numero di broker in un cluster Amazon MSK Per informazioni su come rimuovere broker da un cluster MSK Provisioned, vedere. Rimuovere un broker da un cluster Amazon MSK Per informazioni sullo strumento di riassegnazione delle partizioni, consulta la sezione relativa all'espansione del cluster nella documentazione di Apache Kafka.