Domande frequenti su Streaming gestito da Amazon per Apache Kafka

Per configurare un cluster e produrre e consumare a partire da esso, puoi seguire la Guida alle nozioni di base su Amazon MSK. In sintesi, puoi creare il primo cluster in pochi passaggi nella Console di gestione AWS oppure utilizzando i kit AWS SDK. Per prima cosa, nella console Amazon MSK, seleziona una regione AWS in cui creare un cluster Amazon MSK. Scegli il nome del cluster, il cloud privato virtuale (VPC) con cui desideri eseguire il cluster e le sottoreti per ciascuna zona di disponibilità. Se stai creando un cluster con provisioning, puoi anche scegliere un tipo di istanza del broker e il numero di broker per zona di disponibilità.

I cluster predisposti contengono istanze di broker e nodi di metadati astratti. I cluster serverless sono una risorsa a sé stante, che astrae tutte le risorse sottostanti.

In Apache Kafka, i broker sono i singoli server che compongono il cluster Apache Kafka. Sono responsabili dell'archiviazione e della replica dei dati pubblicati negli argomenti di Kafka, della gestione delle partizioni all'interno di tali argomenti, della gestione delle richieste dei client (produzione e consumo di messaggi) e del coordinamento reciproco per mantenere lo stato generale dell'implementazione di Kafka. I broker sono i componenti principali che abilitano l'architettura distribuita, scalabile e tollerante ai guasti di Kafka.

Per i cluster con provisioning, è possibile scegliere le istanze EC2 T3.small o quelle all'interno delle famiglie di istanze EC2 M7g ed M5. Per i cluster serverless, i broker sono completamente astratti. Inoltre, MSK offre tipi di broker Standard ed Express.

No, ciascun broker di cui viene effettuato il provisioning include l'archiviazione dei volumi di avvio gestito dal servizio Amazon MSK.

Alcune risorse, come le interfacce di rete elastiche (ENI), vengono mostrate nell'account Amazon EC2. Altre risorse Amazon MSK non vengono mostrate nell'account Amazon EC2 perché sono gestite dal servizio Amazon MSK.

Per i cluster con provisioning, è necessario effettuare il provisioning delle istanze per ciascun cluster creato. Sui broker Standard, è possibile effettuare il provisioning dell'archiviazione e, facoltativamente, abilitare il throughput dell'archiviazione fornito per i volumi di archiviazione, che può essere utilizzato per scalare l'I/O senza la necessità di effettuare il provisioning di broker aggiuntivi. Con i broker Express, non è necessario effettuare il provisioning o gestire l'archiviazione. Per tutti i tipi di cluster, non è necessario effettuare il provisioning di nodi di metadati come quelli di Apache ZooKeeper o di KRaft, perché queste risorse sono incluse senza costi aggiuntivi in ogni cluster creato. Per i cluster serverless, ti basterà creare un cluster come risorsa.

Amazon MSK usa la replica leader-follower di Apache Kafka per replicare i dati tra i broker. Amazon MSK semplifica l'implementazione dei cluster con la replica Multi-AZ. I broker Standard offrono la possibilità di utilizzare una strategia di replica personalizzata per argomento. I broker Express garantiscono una maggiore disponibilità replicando sempre i dati in tre zone di disponibilità. I broker leader e follower verranno implementati e isolati utilizzando il tipo di broker e la strategia di replica specificati. Ad esempio, selezionando broker Standard con una strategia di replica dei broker con tre zone di disponibilità e con un broker per cluster di zona di disponibilità, Amazon MSK creerà un cluster di tre broker (un broker in tre zone di disponibilità in una regione) e, per impostazione predefinita, anche il fattore di replica degli argomenti sarà uguale a tre, a meno che non si scelga di sovrascriverlo. Per saperne di più su cosa succede durante il failover del client, consulta la nostra documentazione sul failover del client.

Sì, Amazon MSK permette di creare configurazioni personalizzate e applicarle a cluster nuovi ed esistenti. I broker Express proteggono più configurazioni da valori non ottimali che possono influire su disponibilità e durata. Inoltre, offrono un'esperienza più semplice astraendo le configurazioni legate all'archiviazione, poiché Amazon MSK gestisce completamente il livello di archiviazione. Per ulteriori informazioni sulle configurazioni personalizzate, consulta la documentazione sulla configurazione.

Una volta creato il cluster Apache Kafka, è possibile usare le API Apache Kafka per creare argomenti. Tutte le operazioni e le configurazioni relative agli argomenti e ai livelli di partizione vengono eseguite utilizzando le API Apache Kafka. Il seguente comando è un esempio di creazione di un argomento tramite l'uso delle API di Apache Kafka e i dettagli di configurazione disponibili per il tuo cluster:

<path-to-your-kafka-installation>/bin/kafka-topics.sh --create — bootstrap-server <BootstrapBrokerString> --replication-factor 3 --partitions 1 -- topic TopicName

Amazon MSK offre due opzioni di implementazione per i cluster Apache Kafka: Amazon MSK Provisioned e Amazon MSK Serverless. MSK Provisioned offre diversi livelli di controllo sul cluster eliminando al contempo la maggior parte del sovraccarico operativo derivante dalla gestione dei cluster Apache Kafka. Con MSK Provisioned, puoi scalare il cluster in unità di broker e scegliere tra vari tipi di broker, inclusi quelli Standard ed Express. Al contrario, MSK Serverless è un tipo di cluster che astrae completamente il dimensionamento e la gestione dei cluster. Con MSK Serverless, puoi eseguire le tue applicazioni senza dover fornire, configurare o ottimizzare i cluster, e paghi per il volume di dati che trasmetti e mantieni. Inoltre, Amazon MSK offre diverse opzioni per semplificare la connessione ai cluster MSK, come Amazon MSK Connect, il Replicatore Amazon MSK e altre integrazioni AWS native. Per maggiori dettagli, consulta le sezioni successive. 

MSK Provisioned è un'opzione di implementazione del cluster MSK che consente di configurare e scalare manualmente i cluster Apache Kafka, fornendo diversi livelli di controllo sull'infrastruttura che alimenta l'ambiente Apache Kafka.

Con MSK Provisioned, è possibile scegliere i tipi di istanza, i volumi di archiviazione sul tipo di broker Standard e il numero di nodi broker che compongono i cluster Kafka. Inoltre, è possibile scalare il cluster aggiungendo o rimuovendo broker seguendo l'evoluzione delle esigenze di elaborazione dei dati. Questa flessibilità consente di ottimizzare i cluster per i requisiti specifici del carico di lavoro, che si tratti di massimizzare il throughput, la capacità di conservazione o altre caratteristiche prestazionali.

Oltre alle opzioni di configurazione dell'infrastruttura, MSK Provisioned offre sicurezza, monitoraggio e vantaggi operativi di livello aziendale. Sono incluse funzionalità come aggiornamenti della versione di Apache Kafka, sicurezza integrata tramite crittografia e controllo degli accessi, nonché integrazione con altri servizi AWS come Amazon CloudWatch per il monitoraggio. MSK Provisioned offre due tipi di broker principali: Standard ed Express.

I broker Standard offrono la massima flessibilità per configurare i cluster, mentre i broker Express offrono maggiore elasticità, throughput, resilienza e facilità d'utilizzo per l'esecuzione di applicazioni di streaming ad alte prestazioni. Per maggiori dettagli su ciascuna offerta, consulta le sottosezioni seguenti. La tabella seguente evidenzia anche i principali confronti delle funzionalità tra i broker Standard ed Express.

Sì, Amazon MSK supporta le istanze M7g basate su AWS Graviton3 di dimensioni da .large a .16xlarge per eseguire tutti i carichi di lavoro Apache Kafka. Le istanze Graviton offrono gli stessi vantaggi di disponibilità e durata di Amazon MSK, con costi fino al 24% più bassi rispetto alle corrispondenti istanze M5. Le istanze Graviton offrono un throughput per istanza fino al 29% maggiore rispetto alle istanze M5 di Amazon MSK, il che consente ai clienti di eseguire cluster MSK con un minor numero di broker o istanze di dimensioni più piccole.

I broker Standard per MSK Provisioned offrono la massima flessibilità per configurare le prestazioni del cluster. È possibile scegliere tra un'ampia gamma di configurazioni di cluster, per ottenere le caratteristiche di disponibilità, durata, throughput e latenza richieste per le applicazioni. Inoltre, è possibile effettuare il provisioning della capacità di archiviazione e aumentarla se e quando necessario. Amazon MSK gestisce la manutenzione dell'hardware dei broker Standard e delle risorse di archiviazione collegate, risolvendo automaticamente eventuali problemi hardware.

I broker Express per MSK Provisioned rendono Apache Kafka più semplice da gestire, più conveniente da eseguire su larga scala e più elastico grazie alla bassa latenza prevista. Includono un'archiviazione con pagamento in base al consumo che si scala automaticamente e non richiede dimensionamento, provisioning o monitoraggio proattivo. A seconda della dimensione dell'istanza selezionata, ogni nodo del broker può fornire un throughput fino a 3 volte superiore per broker, aumentare verticalmente fino a 20 volte più velocemente e recuperare il 90% più velocemente rispetto ai broker Apache Kafka standard. I broker Express sono preconfigurati con le best practice predefinite di Amazon MSK e applicano le quote di throughput dei clienti per ridurre al minimo il conflitto di risorse tra i clienti e le operazioni in background di Kafka.

• Nessuna gestione dell'archiviazione: i broker Express eliminano la necessità di fornire o gestire qualsiasi risorsa di archiviazione. Si ottiene un'archiviazione elastica, praticamente illimitata, con pagamento in base al consumo e completamente gestita. Per i casi d'uso ad alto throughput, non è necessario ragionare sulle interazioni tra istanze di calcolo e volumi di archiviazione e sui relativi colli di bottiglia di throughput. Queste funzionalità semplificano la gestione dei cluster ed eliminano il sovraccarico operativo della gestione dell'archiviazione.
• Scalabilità più rapida: i broker Express consentono di scalare il cluster e spostare le partizioni più velocemente rispetto ai broker Standard. Questa funzionalità è fondamentale quando è necessario aumentare orizzontalmente il cluster per gestire i picchi di carico imminenti o ridurre orizzontalmente il cluster per ridurre i costi. Per maggiori dettagli sulla scalabilità del cluster, consulta le sezioni sull'espansione del cluster, sulla rimozione dei broker, sulla riassegnazione delle partizioni e sulla configurazione del Cruise Control di LinkedIn per il ribilanciamento.
• Produttività più elevata: i broker Express offrono un throughput fino a 3 volte superiore per broker rispetto ai broker Standard. Ad esempio, è possibile scrivere dati in sicurezza fino a 500 MBps con ogni broker Express di dimensioni m7g.16xlarge rispetto ai 153,8 MBps del broker Standard equivalente (entrambi i numeri presuppongono un'allocazione di larghezza di banda sufficiente per le operazioni in background, come la replica e il ribilanciamento).
• Configurato per un'elevata resilienza: i broker Express offrono automaticamente varie best practice preconfigurate per migliorare la resilienza del cluster. Questi includono i guardrail sulle configurazioni critiche di Apache Kafka, le quote di throughput e la prenotazione della capacità per operazioni in background e riparazioni non pianificate. Queste funzionalità rendono più sicura e semplice l'esecuzione di applicazioni Apache Kafka su larga scala. Per maggiori dettagli, consulta le sezioni sulle configurazioni dei broker Express e sulla quota dei broker Amazon MSK Express.
• Nessuna finestra di manutenzione: non ci sono finestre di manutenzione per i broker Express. Amazon MSK aggiorna automaticamente l'hardware del cluster su base continuativa. Per maggiori dettagli, consulta i broker Amazon MSK Express.

I broker Express offrono un throughput maggiore per broker, quindi è possibile creare cluster con meno broker per lo stesso carico di lavoro. Inoltre, una volta che il cluster è attivo e funzionante, è possibile monitorare l'utilizzo delle risorse del cluster e le dimensioni corrette della capacità più velocemente rispetto ai broker Standard. È quindi possibile effettuare il provisioning di risorse adeguate alla capacità necessaria e scalare più rapidamente per soddisfare qualsiasi cambiamento della domanda.

I cluster con broker Express funzionano con le API e gli strumenti di Apache Kafka che utilizzano il client Apache Kafka standard.

I broker Express sono preconfigurati con le best practice predefinite di Amazon MSK che ottimizzano la disponibilità e la durata. È possibile personalizzare alcune di queste configurazioni per eseguire un ulteriore fine-tuning delle prestazioni dei cluster. Scopri di più sulle configurazioni dei broker Express nella Guida per gli sviluppatori di Amazon MSK.

Proprio come per i broker Standard, Amazon MSK si integra con il Servizio AWS di gestione delle chiavi (AWS KMS) per offrire una crittografia trasparente lato server per l'archiviazione nei broker Express. Quando crei un cluster MSK con i broker Express, puoi specificare la chiave AWS KMS che desideri che Amazon MSK utilizzi per crittografare i dati a riposo. Se non specifichi una chiave KMS, Amazon MSK crea una chiave gestita da AWS e la utilizza per tuo conto. Inoltre, Amazon MSK utilizza TLS per crittografare i dati in transito per i broker Express, così come per i broker Standard.

La maggior parte delle funzionalità e capacità di MSK Provisioned attive sui broker Standard funziona anche con i cluster che utilizzano broker Express. Alcune differenze includono: gestione dell'archiviazione, disponibilità del tipo di istanza e versioni supportate. La tabella di confronto tra i broker Standard ed Express nell'ambito di MSK Provisioned evidenzia alcune somiglianze e differenze chiave.

Sì, puoi migrare i dati del cluster Kafka in un cluster composto da broker Express utilizzando MirrorMaker 2 o il Replicatore Amazon MSK, che copia sia i dati che i metadati del cluster in un nuovo cluster. Per saperne di più sull'utilizzo di MirrorMaker 2 e del Replicatore MSK, consulta la Guida per gli sviluppatori di Amazon MSK.

I broker Express aumentano il rapporto prezzo/prestazioni, forniscono una maggiore resilienza e riducono i costi operativi, rendendoli la scelta ideale per tutti i carichi di lavoro Apache Kafka su MSK Provisioned. Tuttavia, puoi scegliere i tipi di broker Standard se desideri controllare più configurazioni e impostazioni dei broker. Con questi, puoi personalizzare un set più ampio di configurazioni di Kafka, tra cui fattore di replica, dimensione dei file di log e policy di elezione dei leader, il che offre una maggiore flessibilità sulle impostazioni del cluster.

MSK Serverless è un tipo di cluster per Amazon MSK che semplifica l'esecuzione di cluster Apache Kafka senza dover gestire la capacità di calcolo e archiviazione. Con MSK Serverless, puoi eseguire le tue applicazioni senza dover fornire, configurare o ottimizzare i cluster, e paghi per il volume di dati che trasmetti e mantieni. 

Sì, MSK Serverless gestisce interamente le partizioni, inclusi il loro monitoraggio e spostamento per uniformare il carico su un cluster.

MSK Serverless fornisce fino a 200 MBps di capacità di scrittura e 400 MBps di capacità di lettura per cluster. Inoltre, per assicurare una sufficiente disponibilità di velocità effettiva per tutte le partizioni in un cluster, MSK Serverless alloca fino a 5 MBps di capacità di scrittura istantanea e 10 MBps di capacità di lettura istantanea per partizione. 

MSK Serverless cripta tutto il traffico in transito e tutti i dati a riposo utilizzando chiavi gestite dal servizio emesse attraverso AWS KMS. I client si connettono a MSK Serverless su una connessione privata usando AWS PrivateLink senza esporre il tuo traffico alla rete internet pubblica. Inoltre, MSK Serverless offre il controllo degli accessi AWS Identity and Access Management (IAM), da utilizzare per gestire l'autenticazione e l'autorizzazione dei client a risorse di Apache Kafka come gli argomenti.

Quando crei un cluster MSK Serverless, fornisci sottoreti di uno o più Amazon Virtual Private Cloud (Amazon VPC) che ospitano i client del cluster, i quali sono in grado di connettersi al cluster MSK Serverless utilizzando la sua stringa di avvio del broker.

Per la disponibilità regionale, consulta la pagina dei prezzi di Amazon MSK.

Attualmente, MSK Serverless supporta Identity Access Management (IAM) per l'autenticazione e l'autorizzazione dei client. I client possono assumere un ruolo IAM per l'autenticazione ed è possibile imporre il controllo degli accessi utilizzando una policy IAM associata.

Puoi utilizzare qualsiasi strumento compatibile con Apache Kafka per elaborare i dati negli argomenti del cluster MSK Serverless. MSK Serverless si integra con il servizio gestito da Amazon per Apache Flink per l'elaborazione in streaming stateful e AWS Lambda per l'elaborazione degli eventi. Inoltre, puoi utilizzare i connettori sink Apache Kafka Connect per inviare dati a qualsiasi destinazione desiderata. 

Quando si crea una partizione, MSK Serverless ne crea due repliche e le colloca in diverse zone di disponibilità. Inoltre, MSK Serverless rileva e recupera automaticamente le risorse di backend non riuscite per mantenere una disponibilità elevata.

Sì, è possibile utilizzare strumenti di terze parti o open source come MirrorMaker2, supportato da Apache Kafka, per replicare i dati dai cluster in un cluster MSK. Dai un'occhiata a questo laboratorio di migrazione di Amazon MSK per capire come pianificare la migrazione.

Sì, Amazon MSK supporta gli aggiornamenti della versione di Apache Kafka completamente gestiti sul posto per i cluster con provisioning. Per ulteriori informazioni sull'aggiornamento della versione di Apache Kafka e sulle best practice per la disponibilità elevata, consulta la documentazione relativa agli aggiornamenti della versione.

Tutte le versioni di Apache Kafka sono supportate fino alla data di fine del supporto. Per maggiori dettagli sulla policy e sulle date di fine del supporto, consulta la nostra documentazione sulle versioni supportate.

Sì, Amazon MSK viene sempre eseguito all'interno di Amazon VPC gestito dal servizio Amazon MSK. Le risorse Amazon MSK saranno disponibili per l'Amazon VPC, la sottorete e il gruppo di sicurezza che selezionerai all'impostazione del cluster. Gli indirizzi IP del VPC vengono collegati alle risorse Amazon MSK tramite le interfacce ENI; il traffico di rete rimarrà nell'ambito della rete AWS e per impostazione predefinita non sarà accessibile da Internet.

I broker nel cluster vengono resi accessibili ai client nel VPC attraverso interfacce di rete elastiche (ENI), che appariranno nell’account. I gruppi di sicurezza nelle interfacce ENI determinano la fonte e il tipo di traffico in entrata e in uscita consentito sui broker.

Sì, Amazon MSK offre un'opzione per connettersi in modo sicuro ai broker dei cluster Amazon MSK che eseguono Apache Kafka versione 2.6.0 o successiva su Internet. Abilitando l'accesso pubblico, i client autorizzati esterni a un Amazon VPC privato possono trasmettere dati crittografati dentro e fuori da specifici cluster Amazon MSK. È possibile abilitare l'accesso pubblico per i cluster MSK dopo che un cluster è stato creato senza costi aggiuntivi, ma si applicano i costi standard di trasferimento dati di AWS per l'ingresso e l'uscita del cluster. Per maggiori informazioni su come attivare l'accesso pubblico, consulta la documentazione sull'accesso pubblico.

Per impostazione predefinita, i dati possono essere prodotti e utilizzati da un cluster Amazon MSK solo tramite una connessione privata tra i client nel VPC e il cluster Amazon MSK. Tuttavia, se attivi l'accesso pubblico per il cluster MSK e ti ci connetti utilizzando la stringa pubblica bootstrap-brokers, la connessione, anche se autenticata, autorizzata e criptata, non è più considerata privata. Si consiglia di configurare i gruppi di sicurezza del cluster perché abbiano regole TCP in entrata che permettano l'accesso pubblico dal proprio indirizzo IP di fiducia e di rendere queste regole il più restrittive possibile se si attiva l'accesso pubblico.

Puoi connetterti al cluster MSK da qualsiasi account VPC o AWS diverso da quello dell'Amazon VPC del tuo cluster MSK attivando la connettività privata multi-VPC per i cluster MSK che eseguono Apache Kafka versione 2.7.1 o successiva. Puoi attivare la connettività privata solo dopo la creazione del cluster per uno qualsiasi degli schemi di autenticazione supportati (autenticazione IAM, autenticazione SASL, SCRAM ed mTLS). Per abilitare la connettività privata bisogna configurare i client in modo che si connettano privatamente al cluster utilizzando connessioni VPC gestite da Amazon MSK, che utilizzano la tecnologia PrivateLink. Per saperne di più sull'impostazione della connettività privata, consulta la documentazione sull'accesso dall'interno di AWS.

Sì, Amazon MSK utilizza la crittografia lato server Amazon Elastic Block Store (Amazon EBS) e le chiavi AWS KMS per crittografare i volumi di archiviazione.

Sì, per impostazione predefinita, sui nuovi cluster è abilitata la crittografia in transito tramite TLS per la comunicazione tra i broker. Per i cluster con provisioning, è possibile scegliere di non utilizzare la crittografia in transito durante la creazione di un cluster.

Sì, per impostazione predefinita la crittografia in transito è impostata su TLS soltanto per i cluster creati dall'AWS CLI o dalla Console di gestione AWS. Occorre una configurazione ulteriore affinché i clienti possano comunicare con i cluster utilizzando la crittografia TLS. Per i cluster con provisioning, puoi cambiare l'impostazione di default della crittografia selezionando le impostazioni TLS/plaintext o plaintext. Scopri di più sulla crittografia di Amazon MSK.

Sì, i cluster MSK supportano la crittografia in transito TLS tra broker Kafka e nodi di metadati.

Per i cluster serverless, è possibile utilizzare il controllo degli accessi IAM sia per l'autenticazione che per l'autorizzazione. Per i cluster con provisioning, sono disponibili le seguenti opzioni:

• Controllo degli accessi IAM per AuthN/AuthZ (consigliato)
• Autenticazione con certificato TLS per AuthN e liste di controllo degli accessi per AuthZ
• SASL/SCRAM per AuthN e liste di controllo degli accessi per AuthZ

Amazon MSK consiglia l'utilizzo del controllo degli accessi IAM. È l'opzione più semplice da usare, perché prevede autorizzazioni agli accessi con privilegio minimo di default, che è l'opzione più sicura.

Se utilizzi il controllo degli accessi IAM, Amazon MSK applica le policy da te scritte e il suo authorizer per autorizzare le azioni. Se utilizzi TLS Certificate Authentication o SASL/SCRAM, Apache Kafka applica le liste di controllo degli accessi per l’autorizzazione. Per abilitare le ACL è necessario abilitare l'autenticazione client utilizzando i certificati TLS o SASL/SCRAM.

Se utilizzi il controllo degli accessi IAM, Amazon MSK si occuperà per conto tuo dell'autenticazione e dell'autorizzazione, senza ulteriori configurazioni. Se utilizzi l'autenticazione TLS del client, puoi utilizzare il Dname dei certificati TLS dei client come elemento ACL principale per autorizzare le richieste dei client. Se utilizzi SASL/SCRAM, puoi usare il nome utente come principale dell'ACL per autorizzare le richieste del client.

Puoi controllare le azioni delle API di servizio utilizzando IAM.

Sì, puoi abilitare il controllo di accesso IAM per un cluster esistente dalla Console di gestione AWS o utilizzando l'API UpdateSecurity.

No, il controllo degli accessi IAM è disponibile soltanto per i cluster MSK.

Puoi allegare una policy del cluster al tuo cluster Amazon MSK per fornire le autorizzazioni client Kafka su più account in modo da configurare la connettività privata al tuo cluster Amazon MSK. Quando si utilizza l'autenticazione del client IAM, è anche possibile utilizzare la policy del cluster per definire in modo granulare le autorizzazioni del piano dati Kafka per il client che si connette. Per ulteriori informazioni sulle politiche dei cluster, consulta la documentazione sulla policy dei cluster.

Puoi monitorare le prestazioni dei cluster utilizzando la console Amazon MSK, la console Amazon CloudWatch o attraverso JMX e le metriche host utilizzando Open Monitoring con Prometheus, una soluzione di monitoraggio open source.

Il costo per monitorare il cluster utilizzando CloudWatch dipende dal livello di monitoraggio e dalle dimensioni del cluster Apache Kafka. Il costo di CloudWatch si calcola per metrica al mese e include un piano gratuito AWS. Per ulteriori informazioni, consulta i prezzi di Amazon CloudWatch. Per dettagli sul numero di metriche esposte per ciascun livello di monitoraggio, consulta la documentazione sul monitoraggio con Amazon MSK.

Gli strumenti progettati per leggere dagli esportatori Prometheus sono compatibili con Open Monitoring, come Datadog, Lenses, New Relic, Sumo Logic o un server Prometheus. Per i dettagli sulla funzionalità Open Monitoring, consulta la documentazione su Amazon MSK Open Monitoring.

È possibile utilizzare qualsiasi tipo di monitoraggio lato client supportato dalla versione Apache Kafka in uso. 

Sì, puoi applicare dei tag ai cluster Amazon MSK tramite l'AWS CLI o la Console di gestione AWS.

Le metriche dei lag dei consumatori a livello di argomento sono disponibili come parte del set di metriche predefinite pubblicate da Amazon MSK su CloudWatch per tutti i cluster. Per ottenere questi parametri, non è richiesta alcuna impostazione aggiuntiva.

Le metriche a livello di argomento sono incluse nell'insieme di metriche predefinite di Amazon MSK, che sono gratuite. Le metriche a livello di partizione sono invece soggette alle tariffe di Amazon CloudWatch.

Per i cluster con provisioning, puoi abilitare la distribuzione dei registri dei broker. Puoi distribuire i log dei broker ad Amazon CloudWatch Logs, Amazon Simple Storage Service (Amazon S3) e Amazon Data Firehose. Firehose supporta il Servizio OpenSearch di Amazon tra le varie destinazioni. Per sapere come abilitare questa funzionalità, consulta la documentazione sulla registrazione di log di Amazon MSK. Per conoscere i prezzi, consulta le relative pagine per Amazon CloudWatch Logs e Amazon Data Firehose.

Amazon MSK offre log di livello INFO per tutti i broker all'interno di un cluster con provisioning.

Sì, se utilizzi il controllo degli accessi IAM, l'utilizzo delle API di risorsa di Apache Kafka è registrato su AWS CloudTrail.

Tratto da https://zookeeper.apache.org: "Apache ZooKeeper è un servizio centralizzato che consente di mantenere le informazioni di configurazione, dare un nome, fornire la sincronizzazione distribuita e servizi di gruppo. Tutti questi servizi vengono utilizzati in qualche modo dalle applicazioni distribuite,” compreso Apache Kafka.

Sì, Amazon MSK utilizza Apache ZooKeeper per la gestione dei metadati. Inoltre, a partire dalla versione 3.7 di Apache Kafka, è possibile creare cluster in modalità ZooKeeper o in modalità KRaft. Un cluster creato con la modalità KRaft utilizza i controller KRaft per la gestione dei metadati anziché i nodi ZooKeeper.

Apache KRaft è il protocollo di consenso che sposta la gestione dei metadati nei cluster Kafka dai nodi Apache ZooKeeper esterni a un gruppo di controller all'interno di Kafka. Questa modifica consente di archiviare e replicare i metadati come argomenti all'interno dei broker Kafka, con conseguente propagazione più rapida dei metadati. Per saperne di più, consulta la nostra documentazione su Apache KRaft.

Non sono necessarie modifiche all'API per utilizzare la modalità KRaft su Amazon MSK. Tuttavia, se i client utilizzano ancora la stringa di connessione --zookeeper, è necessario aggiornarli in modo che utilizzino la stringa di connessione --bootstrap-server per connettersi al cluster ed eseguire azioni di amministrazione. Il flag --zookeeper è obsoleto nella versione 2.5 di Apache Kafka e verrà rimosso a partire da Kafka 3.0. Si consiglia pertanto di utilizzare le versioni recenti del client Apache Kafka e la stringa di connessione --bootstrap-server.

Bisogna verificare che gli strumenti utilizzati supportino le API di amministrazione di Kafka senza connessioni ZooKeeper. Consulta la nostra documentazione aggiornata sull'utilizzo di Cruise Control per i cluster in modalità KRaft. Cruise Control ha anche pubblicato i passaggi da seguire per eseguire Kafka senza connessione ZooKeeper.

Il numero di partizioni per broker è lo stesso sui cluster basati su KRaft e ZooKeeper. Tuttavia, KRaft consente di ospitare un numero maggiore di partizioni per cluster fornendo più broker in un cluster.

Amazon MSK si integra con i seguenti servizi AWS:

• Amazon S3 che utilizza Firehose per inviare dati ad Amazon S3 da Amazon MSK in modalità senza codice
• Amazon VPC per l'isolamento e la sicurezza della rete
• Amazon CloudWatch per le metriche
• Amazon KMS per la crittografia del volume di archiviazione
• IAM per l'autenticazione e l'autorizzazione di Apache Kafka e per le API di servizio
• AWS Lambda per il sourcing di eventi Amazon MSK
• AWS IoT Core per il sourcing di eventi IoT
• AWS Glue Schema Registry per monitorare l'evoluzione degli schemi utilizzati dalle applicazioni Apache Kafka
• AWS CloudTrail per i log delle API AWS
• AWS Certificate Manager per le CA private impiegate per l'autenticazione TLS del client
• AWS CloudFormation per la descrizione e il provisioning dei cluster Amazon MSK tramite codice
• Il Servizio gestito da Amazon per Apache Flink per applicazioni Apache Flink completamente gestite che elaborano dati in streaming
• Il Servizio gestito da Amazon per Apache Flink per l'SQL dello streaming interattivo su Apache Kafka
• AWS Secrets Manager per le credenziali client utilizzate per l'autenticazione SASL/SCRAM

Amazon MSK Serverless si integra con i seguenti servizi AWS:

• Amazon S3 che utilizza Firehose per inviare dati ad Amazon S3 da MSK in modalità senza codice
• Amazon VPC per l'isolamento e la sicurezza della rete
• Amazon CloudWatch per le metriche
• IAM per l'autenticazione e l'autorizzazione di Apache Kafka e per le API di servizio
• AWS Glue Schema Registry per monitorare l'evoluzione degli schemi utilizzati dalle applicazioni Apache Kafka
• AWS CloudTrail per i log delle API AWS
• AWS PrivateLink per la connettività privata

Il Replicatore Amazon MSK è una funzionalità di Amazon MSK che aiuta i clienti a replicare i dati in modo affidabile tra cluster MSK in diverse regioni AWS (replica tra regioni) o all'interno della stessa regione AWS (replica nella stessa regione), senza scrivere codice o gestire l'infrastruttura. È possibile utilizzare la replica tra regioni per creare applicazioni di streaming multi-regione a disponibilità elevata e tolleranti ai guasti per una maggiore resilienza e per fornire un accesso a bassa latenza ai consumatori in diverse aree geografiche. È possibile utilizzare la replica nella stessa regione per distribuire i dati da un cluster a più cluster per condividerli con i partner e i team e aggregare i dati di più cluster in uno solo per l'analisi.

Per configurare la replica tra una coppia di cluster MSK di origine e di destinazione, è necessario creare un Replicatore nella regione di destinazione. Per farlo, è necessario specificare dettagli che includono il nome della risorsa Amazon (ARN) dei cluster MSK di origine e di destinazione e un ruolo IAM che il Replicatore MSK può utilizzare per accedere ai cluster. Se non esiste già, sarà necessario creare il cluster MSK di destinazione.

MSK Replicator supporta la replica solo tra cluster MSK. Sono supportati i cluster MSK Provisioned e Serverless. Inoltre, è possibile utilizzare il Replicatore MSK per passare da Provisioned a Serverless o viceversa con altri cluster Kafka non supportati.

Sì, è possibile specificare quali argomenti replicare utilizzando gli elenchi di consenso e negazione durante la creazione del Replicator. 

Il Replicatore MSK replica automaticamente i metadati Kafka necessari, come la configurazione degli argomenti, le liste ACL e gli offset dei gruppi di consumatori, in modo che le applicazioni che consumano possano riprendere l'elaborazione senza problemi dopo il failover. Puoi scegliere di disattivare una o più di queste impostazioni se desideri solo replicare i dati. È inoltre possibile specificare quali gruppi di consumer si desidera replicare utilizzando gli elenchi di consenso o negazione durante la creazione del Replicator.

No,il Replicatore MSK implementa, fornisce e scala automaticamente l'infrastruttura di replica sottostante per supportare le modifiche del throughput in ingresso.

No, MSK Replicator supporta solo la replica tra cluster MSK nello stesso account AWS.

Puoi utilizzare CloudWatch nella regione di destinazione per visualizzare i parametri per ReplicationLatency,
MessageLag e ReplicatorThroughput a livello di argomento e aggregato per ogni Replicatore senza costi aggiuntivi. I parametri sono visibili in ReplicatorName nello spazio dei nomi AWS/Kafka. Inoltre, per verificare se il Replicatore sta riscontrando problemi, puoi consultare le metriche ReplicatorFailure, AuthError e ThrottleTime.

Puoi utilizzare il Replicatore MSK per configurare topologie di cluster attive-attive o attive-passive per aumentare la resilienza dell'applicazione Kafka in tutte le regioni. In una configurazione attiva-attiva, entrambi i cluster MSK eseguono attivamente operazioni di lettura e scrittura. In confronto, in una configurazione attiva-passiva solo un cluster MSK alla volta serve attivamente i dati in streaming, mentre l'altro è in standby.

Sì. Creando un Replicatore diverso per ogni coppia di cluster di origine e destinazione, è possibile replicare i dati da uno a più cluster o replicare i dati da più cluster a uno.

Il Replicatore MSK utilizza il controllo degli accessi IAM per connettersi ai cluster di origine e di destinazione. È necessario attivare i cluster MSK di origine e di destinazione per il controllo degli accessi IAM per creare un Replicatore. Puoi continuare a utilizzare altri metodi di autenticazione tra cui SASL/SCRAM e MTL contemporaneamente per i tuoi clienti poiché Amazon MSK supporta più metodi di autenticazione contemporaneamente.

Il Replicatore MSK replica i dati in modo asincrono. La latenza di replica varia in base a molti fattori, tra cui la distanza di rete tra le regioni dei cluster MSK, la capacità effettiva di trasmissione dei cluster di origine e di destinazione e il numero di partizioni sui cluster di origine e destinazione.

No, MSK Replicator crea nuovi argomenti nel cluster di destinazione con un prefisso generato automaticamente aggiunto al nome dell'argomento. Ad esempio, il Replicatore MSK replicherà i dati nell'argomento dal cluster di origine a un nuovo argomento nel cluster di destinazione chiamato <sourceKafkaClusterAlias>.topic. Questa operazione serve a distinguere gli argomenti che contengono dati replicati dal cluster di origine da altri argomenti nel cluster di destinazione ed evitare che i dati vengano replicati in modo circolare tra i cluster. È possibile trovare il prefisso che verrà aggiunto ai nomi degli argomenti nel cluster di destinazione nel campo sourceKafkaClusterAlias utilizzando l'API DescribeReplicator o la pagina dei dettagli del Replicatore sulla console Amazon MSK.

Sì. Per impostazione predefinita, quando si crea un nuovo Replicator, inizia a replicare i dati dall'estremità del flusso (ultimo offset) sul cluster di origine. In alternativa, per replicare i dati esistenti, puoi configurare un nuovo Replicator per iniziare a replicare i dati dal primo offset nelle partizioni dell'argomento del cluster di origine.

Poiché MSK Replicator funge da consumatore per il cluster di origine, è possibile che la replica causi la limitazione di altri consumatori sul cluster di origine. Ciò dipende dalla capacità di lettura disponibile nel cluster di origine e dalla velocità di trasmissione effettiva dei dati da replicare. Si consiglia di fornire una capacità identica per i cluster di origine e di destinazione e tenere conto del throughput di replica calcolando al contempo la capacità necessaria. È inoltre possibile impostare quote Kafka per il Replicator sui cluster di origine e di destinazione per controllare la capacità che il Replicator può utilizzare.

Sì, è possibile specificare il codec di compressione preferito durante la creazione del Replicatore tra None, GZIP, Snappy, LZ4 e ZSTD.

Sì, è possibile specificare il codec di compressione preferito durante la creazione del Replicatore tra None, GZIP, Snappy, LZ4 e ZSTD.

Puoi aumentare verticalmente lo spazio di archiviazione in un cluster con provisioning in esecuzione su broker Standard utilizzando la Console di gestione AWS o l'AWS CLI. Inoltre, puoi creare una policy di dimensionamento automatico per l'archiviazione utilizzando la Console di gestione AWS o creando una policy AWS Application Auto Scaling utilizzando l'AWS CLI o le API AWS. L'archiviazione su più livelli su broker Standard consente di archiviare virtualmente dati illimitati sul cluster senza la necessità di aggiungere broker per l'archiviazione. Con i broker Express, non è necessario effettuare il provisioning o gestire lo spazio di archiviazione e, inoltre, hai accesso a uno spazio di archiviazione praticamente illimitato. Nei cluster serverless, l'archiviazione viene dimensionata fluidamente, in base all'utilizzo.

Apache Kafka archivia i dati in file detti segmenti di log. Quando ogni segmento è completo, in base alle dimensioni configurate a livello di cluster o argomento, viene copiato nel livello di archiviazione a basso costo. I dati vengono conservati in uno spazio di archiviazione ottimizzato per le prestazioni per un periodo di conservazione o una dimensione specificati, dopodiché vengono eliminati. Esiste un'impostazione di limite di tempo e dimensione separata per lo spazio di archiviazione a basso costo, che è più lunga del livello di archiviazione principale. Se i client richiedono dati da segmenti archiviati nel livello a basso costo, il broker leggerà i dati da esso e li servirà come se venissero serviti dallo spazio di archiviazione principale.

È possibile scegliere di aumentare o diminuire il numero di broker per i cluster MSK con provisioning esistenti.

Sì, è possibile scegliere di scalarlo in un tipo di broker più piccolo o più grande sui cluster MSK con provisioning.

Puoi utilizzare Cruise Control per bilanciare automaticamente le partizioni I/O heat. Per ulteriori informazioni, consulta la documentazione di Cruise Control. In alternativa, puoi utilizzare l'API Kafka Admin kafka-reassign-partitions.sh per riassegnare le partizioni tra i broker. Nei cluster serverless, Amazon MSK bilancia le partizioni automaticamente.

I prezzi dipendono dalle risorse create. Per saperne di più, consulta i prezzi di Amazon MSK.

No, i trasferimenti dati in-cluster sono inclusi nel servizio senza costi aggiuntivi.

Per informazioni sulle regioni in cui è disponibile Amazon MSK, consulta la tabella delle regioni AWS. 

Con i cluster con provisioning, saranno addebitate le tariffe standard di trasferimento dati di AWS per i dati trasferiti da e verso un cluster MSK. Non saranno addebitati costi per il trasferimento di dati all'interno del cluster in una regione, compreso il trasferimento dati tra broker e tra broker e nodi di gestione dei metadati.

Con i cluster serverless, pagherai le tariffe standard di trasferimento dati di AWS per i dati trasferiti da o verso un'altra regione e per i dati trasferiti verso l'internet pubblico.

Al momento no.

Amazon MSK è conforme o soggetto ai seguenti programmi:

• Soggetto allo standard HIPAA

• PCI

• ISO

• SOC 1, 2 e 3

Per un elenco completo dei servizi AWS e dei programmi per la conformità, consulta Servizi AWS coperti dal programma di conformità.

Lo SLA di Amazon MSK garantisce una percentuale di tempo di attività mensile di almeno il 99,9% per Amazon MSK (incluso MSK Serverless ed MSK Connect). 

Se le implementazioni multi-AZ su Amazon MSK presentano tempi di attività mensili inferiori al 99,9% durante qualsiasi ciclo di fatturazione mensile, hai diritto a un credito SLA per Amazon MSK secondo quanto previsto dallo SLA di Amazon MSK.

Per dettagli completi su tutti i termini e le condizioni dello SLA, nonché per dettagli su come presentare un reclamo, consulta la pagina sullo SLA di Amazon MSK.