Utilizzo di shard e metriche con i flussi DynamoDB e il flusso di dati Kinesis - Amazon DynamoDB
Considerazioni sulla gestione delle partizioni per Kinesis Data StreamsMonitoraggio di Change Data Capture con Kinesis Data Streams

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à.

Utilizzo di shard e metriche con i flussi DynamoDB e il flusso di dati Kinesis

Considerazioni sulla gestione delle partizioni per Kinesis Data Streams

Un flusso dei dati Kinesis calcola il proprio throughput in partizioni. Nel flusso di dati Amazon Kinesis è possibile scegliere tra la modalità con capacità on demand e la modalità con provisioning per i flussi di dati.

Si consiglia di utilizzare la modalità on demand per il flusso di dati Kinesis se il carico di lavoro di scrittura di DynamoDB è altamente variabile e imprevedibile. Con la modalità on demand, non è richiesta pianificazione della capacità in quanto il flusso di dati Kinesis gestisce automaticamente gli shard per fornire il throughput necessario.

Per carichi di lavoro prevedibili è possibile utilizzare la modalità con provisioning per il flusso di dati Kinesis. Con la modalità con provisioning, è necessario specificare il numero di shard per il flusso di dati per ricevere i record di Change Data Capture da DynamoDB. Per determinare il numero di shard di cui il flusso di dati Kinesis avrà bisogno 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. Questo include le operazioni di creazione, eliminazione e aggiornamento eseguite dalle applicazioni, nonché le operazioni generate automaticamente come le eliminazioni generate dal Time to Live (TTL) (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) di cui il flusso di dati Kinesis ha bisogno utilizzando i valori di input nella formula seguente:

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

Ad esempio, si potrebbe avere un throughput massimo di 1040 operazioni di scrittura al secondo (write_throughput) con una dimensione media dei record di 800 byte (average_record_size_in_bytes). Se il 25% di queste operazioni di scrittura sono operazioni di aggiornamento (percentage_of_updates) allora saranno necessari due shard (number_of_shards) per supportare il throughput di streaming DynamoDB:

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

Considera quanto segue prima di utilizzare la formula per calcolare il numero di shard necessari con la modalità con provisioning per il flusso 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 gli shard necessari per supportare consumer del flusso di dati Kinesis aggiuntivi.

  • 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 ai flussi di dati Kinesis.

Per ulteriori informazioni sulle modalità di capacità sul flusso di dati Kinesis, consulta Scelta della modalità di capacità del flusso di dati. Per ulteriori informazioni sulla differenza di prezzo tra le diverse modalità di capacità, consulta Prezzi del flusso di dati Amazon Kinesis.

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 dei dati Kinesis a causa della capacità insufficiente 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 metrica AgeOfOldestUnreplicatedRecord 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 booleani e vuoti degli attributi vengono archiviati come 1 byte in DynamoDB, ma si espandono fino a 5 byte quando vengono serializzati utilizzando JSON standard per la replica di Kinesis Data Streams. 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 (Amazon SNS) per la notifica quando una delle metriche precedenti supera una soglia specifica.