Utilizzo di shard e metriche con DynamoDB Streams e Kinesis Data Streams

Considerazioni sulla gestione delle partizioni per Kinesis Data Streams

Un flusso dei dati Kinesis calcola il proprio throughput in partizioni. In Amazon Kinesis Data Streams, puoi scegliere tra una modalità on demand e una modalità provisioning per i tuoi flussi di dati.

Ti consigliamo di utilizzare la modalità on-demand per Kinesis Data Stream se il carico di lavoro di scrittura di DynamoDB è altamente variabile e imprevedibile. Con la modalità on-demand, non è richiesta la pianificazione della capacità poiché Kinesis Data Streams gestisce automaticamente gli shard per fornire il throughput necessario.

Per carichi di lavoro prevedibili, puoi utilizzare la modalità provisioning per Kinesis Data Stream. Con la modalità provisioned, è necessario specificare il numero di shard per il flusso di dati per contenere i record di acquisizione dei dati di modifica da DynamoDB. Per determinare il numero di shard necessari al flusso di dati Kinesis per supportare la tabella DynamoDB, sono necessari i seguenti valori di input:

• La dimensione media del record della tabella DynamoDB in byte (average_record_size_in_bytes).

• Il numero massimo di operazioni di scrittura che la tabella DynamoDB eseguirà al secondo. Ciò include le operazioni di creazione, eliminazione e aggiornamento eseguite dalle applicazioni, nonché le operazioni generate automaticamente come le operazioni di cancellazione generate da Time to Live (). write_throughput

• La percentuale di operazioni di aggiornamento e sovrascrittura eseguite sulla tabella, rispetto alle operazioni di creazione o eliminazione (percentage_of_updates). Tieni a mente che le operazioni di aggiornamento e sovrascrittura replicano nel flusso sia le vecchie che le nuove immagini dell'elemento modificato al flusso. Questo genera il doppio della dimensione dell'elemento DynamoDB.

È possibile calcolare il numero di shard (number_of_shards) necessari al flusso di dati Kinesis utilizzando i valori di input nella seguente formula:

number_of_shards = ceiling( max( ((write_throughput * (4+percentage_of_updates) * average_record_size_in_bytes) / 1024 / 1024), (write_throughput/1000)), 1)

Ad esempio, potresti avere un throughput massimo di 1040 operazioni di scrittura al secondo (write_throughput) con una dimensione media del record di 800 byte (. average_record_size_in_bytes) Se il 25 percento di queste operazioni di scrittura sono operazioni di aggiornamento (percentage_of_updates), allora avrai bisogno di due shard (number_of_shards) per gestire il throughput di streaming di DynamoDB:

ceiling( max( ((1040 * (4+25/100) * 800)/ 1024 / 1024), (1040/1000)), 1).

Considerate quanto segue prima di utilizzare la formula per calcolare il numero di shard necessari con la modalità provisioning per i flussi di dati Kinesis:

• Questa formula aiuta a stimare il numero di shard necessari per ospitare i record di dati di modifica di DynamoDB. Non rappresenta il numero totale di shard necessari nel flusso di dati Kinesis, ad esempio il numero di shard necessari per supportare ulteriori utenti Kinesis Data Stream.

• Nella modalità assegnata è possibile che si verifichino comunque eccezioni di velocità di trasmissione effettiva di lettura e scrittura se non si configura il flusso di dati per gestire i picchi di velocità di trasmissione effettiva. In questo caso, è necessario dimensionare manualmente il flusso di dati in modo da adattarlo al traffico di dati.

• Questa formula prende in considerazione il bloat aggiuntivo generato da DynamoDB prima di trasmettere i record di dati dei log delle modifiche a Kinesis Data Stream.

Per saperne di più sulle modalità di capacità su Kinesis Data Stream, consulta Scelta della modalità di capacità del flusso di dati. Per ulteriori informazioni sulla differenza di prezzo tra le diverse modalità di capacità, consulta i prezzi di Amazon Kinesis Data Streams.

Monitoraggio di Change Data Capture con Kinesis Data Streams

DynamoDB fornisce diversi parametri CloudWatch Amazon per aiutarti a monitorare la replica dell'acquisizione dei dati di modifica su Kinesis. Per un elenco completo delle metriche, consulta. CloudWatch Parametri e dimensioni di DynamoDB

Per determinare se il flusso dispone di capacità sufficiente, si consiglia di monitorare i seguenti elementi sia durante l'abilitazione del flusso che in produzione:

• ThrottledPutRecordCount: Il numero di record che sono stati limitati dal flusso di dati Kinesis a causa dell'insufficiente capacità del flusso di dati Kinesis. Potrebbe verificarsi una limitazione della larghezza di banda della rete durante i picchi di utilizzo eccezionali, ma il ThrottledPutRecordCount dovrebbe rimanere il più basso possibile. DynamoDB prova a inviare i record con limitazione sul flusso di dati Kinesis, ma ciò potrebbe comportare una maggiore latenza di replica.

  Se si verifica una limitazione eccessiva e regolare, potrebbe essere necessario aumentare il numero di partizioni del flusso Kinesis proporzionalmente alla velocità di scrittura osservata della tabella. Per ulteriori informazioni su come determinare le dimensioni di un flusso di dati Kinesis, consulta Determinazione delle dimensioni iniziali di un flusso di dati Kinesis.

• AgeOfOldestUnreplicatedRecord: il tempo trascorso dalla modifica a livello di elemento meno recente da replicare nel flusso di dati Kinesis è apparso nella tabella DynamoDB. In condizioni di funzionamento normale, AgeOfOldestUnreplicatedRecord dovrebbe essere nell'ordine dei millisecondi. Questo numero aumenta in base ai tentativi di replica non riusciti quando questi sono causati da scelte di configurazione controllate dal cliente.

  Se la AgeOfOldestUnreplicatedRecord metrica supera le 168 ore, la replica delle modifiche a livello di elemento dalla tabella DynamoDB al flusso di dati Kinesis verrà automaticamente disabilitata.

  Gli esempi di configurazioni controllate dal cliente che portano a tentativi di replica non riusciti sono una capacità del flusso dei dati Kinesis con provisioning insufficiente, che comporta una limitazione eccessiva o un aggiornamento manuale delle policy di accesso del flusso dei dati Kinesis, che impedisce a DynamoDB di aggiungere dati al flusso dei dati. Per mantenere questo parametro il più basso possibile, potrebbe essere necessario garantire il corretto provisioning della capacità del flusso di dati Kinesis e assicurarsi che le autorizzazioni di DynamoDB siano invariate.

• FailedToReplicateRecordCount: il numero di record che DynamoDB non è riuscito a replicare nel flusso dei dati Kinesis. Alcuni elementi di dimensioni superiori a 34 KB potrebbero espandersi per modificare i record di dati superiori al limite di dimensioni di 1 MB degli elementi di Kinesis Data Streams. Questo aumento delle dimensioni si verifica quando gli elementi più grandi di 34 KB includono un numero elevato di valori booleani o vuoti degli attributi. I valori degli attributi booleani e vuoti vengono archiviati come 1 byte in DynamoDB, ma si espandono fino a 5 byte quando vengono serializzati utilizzando lo standard per la replica Kinesis Data Streams. JSON DynamoDB non può replicare tali record di modifica nel flusso dei dati Kinesis. DynamoDB ignora questi record di dati di modifica e continua automaticamente a replicare i record successivi.

Puoi creare CloudWatch allarmi Amazon che inviano un messaggio Amazon Simple Notification Service (AmazonSNS) per la notifica quando una delle metriche precedenti supera una soglia specifica.