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

Questo argomento descrive alcune best practice da seguire quando si utilizza AmazonMSK. Per informazioni sulle best practice di Amazon MSK Replicator, consultaLe 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 SCRAM autenticazioneSASL/

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 MSK broker Amazon.

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

Per determinare il numero corretto di broker Standard per il tuo cluster MSK Provisioned e comprendere i costi, consulta il foglio di calcolo sulle MSKdimensioni e i prezzi. 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, EC2 autogestito e basato su Apache Kafka. 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 Provisioned. MSK Le prestazioni, le dimensioni e i costi del cluster dipendono dal caso d'uso e consigliamo di verificarli con test ad hoc.

Per capire 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 quali quando è necessario aumentare o ridurre la capacità e indicazioni su come verificare continuamente le dimensioni dei cluster di produzione.

Ottimizza la velocità effettiva 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 Provisioned ottimizzando le configurazioni num.io.threads e num.network.threads. MSK

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 CPU core 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 CPU core 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 --zookeeper per aumentare o riassegnare le partizioni degli argomenti per un cluster Provisioned utilizzando la versione 2.8.0 o successiva di Kafka. MSK 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.

  • Imposta un numero minimo di repliche sincronizzate (minISR) al massimo su RF - 1. Un minimo ISR uguale alla RF può impedire la produzione verso il cluster durante un aggiornamento continuo. Un minimo ISR di 2 consente di rendere disponibili argomenti replicati a tre vie quando una replica è offline.

Monitora l'utilizzo CPU

Amazon consiglia MSK vivamente di mantenere l'CPUutilizzo totale dei broker (definito comeCPU User + CPU System) al di sotto del 60%. Se disponi di almeno il 40% del totale CPU del cluster, Apache Kafka può ridistribuire il CPU carico tra i broker del cluster, se necessario. Un esempio di quando ciò è necessario è quando Amazon MSK rileva e recupera un guasto del broker; in questo caso, Amazon MSK esegue la manutenzione automatica, come 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 mettono 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 CPU spazio di crescita nel tuo 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 la metrica composita raggiunge un utilizzo medio del 60%. CPU 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 del broker nel cluster, Amazon MSK mette i broker offline 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, puoi utilizzare questa opzione se il CPU carico supera in modo significativo il 60%, poiché questa forma di scalabilità 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 non consiglia di utilizzare questa opzione quando l'CPUutilizzo è superiore al 70% perché la replica causa CPU carico e traffico di rete aggiuntivi. Amazon consiglia di utilizzare questa opzione MSK solo se le due opzioni precedenti non sono possibili.

Altre raccomandazioni:

Monitoraggio dello spazio su disco

Per evitare di esaurire lo spazio su disco per i messaggi, crea un CloudWatch allarme che controlli la metrica. KafkaDataLogsDiskUsed 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 delle MSK metriche di Amazon, consultaMonitora 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 MSKConfigurazioni Amazon 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. Puoi impostarlo sul numero di CPU core.

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 supera HeapMemoryAfterGC 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 non MSK broker

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

Abilitazione della crittografia dei dati in transito

Per informazioni sulla crittografia dei dati in transito e su come abilitarla, consulta MSKCrittografia Amazon 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 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 Provisioned, vedere. MSK Espandi il numero di broker in un cluster Amazon MSK Per informazioni su come rimuovere i broker da un cluster MSK Provisioned, vedere. Rimuovi un broker da un MSK cluster Amazon Per informazioni sullo strumento di riassegnazione delle partizioni, consulta la sezione relativa all'espansione del cluster nella documentazione di Apache Kafka.