Configuration des partitions et surveillance de la capture de données de modification avec Kinesis Data Streams dans DynamoDB - Amazon DynamoDB

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configuration des partitions et surveillance de la capture de données de modification avec Kinesis Data Streams dans DynamoDB

Considérations relatives à la gestion des partitions pour Kinesis Data Streams

Un flux de données Kinesis compte son débit dans les partitions. Dans Amazon Kinesis Data Streams, vous pouvez choisir entre un mode à la demande et un mode provisionné pour vos flux de données.

Nous vous recommandons d'utiliser le mode à la demande pour votre flux de données Kinesis si votre charge de travail d'écriture DynamoDB est très variable et imprévisible. Avec le mode à la demande, aucune planification des capacités n'est requise car Kinesis Data Streams gère automatiquement les partitions afin de fournir le débit nécessaire.

Pour des charges de travail prévisibles, vous pouvez utiliser le mode provisionné pour votre Kinesis Data Stream. En mode provisionné, vous devez spécifier le nombre de partitions pour le flux de données afin de prendre en charge les enregistrements de capture de données modifiés provenant de DynamoDB. Pour déterminer le nombre de partitions dont le flux de données Kinesis aura besoin pour prendre en charge votre table DynamoDB, vous avez besoin des valeurs d'entrée suivantes :

  • Taille moyenne de registre de votre table DynamoDB en octets (average_record_size_in_bytes).

  • Nombre maximum d'opérations d'écriture que votre table DynamoDB effectuera par seconde. Cela inclut les opérations de création, de suppression et de mise à jour effectuées par vos applications, ainsi que les opérations générées automatiquement, telles que les opérations de suppression générées par Time to Live (write_throughput).

  • Pourcentage d'opérations de mise à jour et de remplacement que vous effectuez sur votre table par rapport aux opérations de création ou de suppression (percentage_of_updates). N'oubliez pas que les opérations de mise à jour et de remplacement répliquent les anciennes et les nouvelles images de l'élément modifié dans le flux. Elles génèrent ainsi deux fois la taille de l'élément DynamoDB.

Vous pouvez calculer le nombre de partitions (number_of_shards) dont votre flux de données Kinesis a besoin en utilisant les valeurs d'entrée de la formule suivante :

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

Par exemple, vous pouvez avoir un débit maximal de 1 040 opérations d'écriture par seconde (write_throughput) avec une taille d'enregistrement moyenne de 800 octets (. average_record_size_in_bytes) Si 25 % de ces opérations d'écriture sont des opérations de mise à jour (percentage_of_updates), vous aurez besoin de deux partitions (number_of_shards) pour gérer le débit de streaming de DynamoDB :

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

Tenez compte des points suivants avant d'utiliser la formule pour calculer le nombre de partitions requises en mode provisionné pour les flux de données Kinesis :

  • Cette formule permet d'estimer le nombre de partitions qui seront nécessaires pour accueillir vos enregistrements de données de modification DynamoDB. Il ne représente pas le nombre total de partitions nécessaires dans votre flux de données Kinesis, par exemple le nombre de partitions nécessaires pour prendre en charge d'autres consommateurs de flux de données Kinesis.

  • Vous pouvez toujours rencontrer des exceptions de débit de lecture et d'écriture en mode provisionné si vous ne configurez pas votre flux de données pour gérer votre débit maximal. Dans ce cas, vous devez mettre à l'échelle manuellement votre flux de données pour l'adapter à votre trafic de données.

  • Cette formule prend en compte le surcroît de travail généré par DynamoDB avant de diffuser les enregistrements de données du journal des modifications vers Kinesis Data Stream.

Pour en savoir plus sur les modes de capacité de Kinesis Data Stream, voir Choix du mode de capacité du flux de données. Pour en savoir plus sur les différences de prix entre les différents modes de capacité, consultez la tarification d'Amazon Kinesis Data Streams.

Surveiller la récupération de données de modification avec Kinesis Data Streams

DynamoDB fournit plusieurs indicateurs CloudWatch Amazon pour vous aider à surveiller la réplication de la capture des données de modification vers Kinesis. Pour une liste complète des CloudWatch indicateurs, voirMétriques et dimensions DynamoDB.

Afin de déterminer si votre flux dispose d'une capacité suffisante, nous vous recommandons de contrôler les éléments suivants, tant pendant l'activation du flux qu'en production :

  • ThrottledPutRecordCount: nombre d'enregistrements limités par votre flux de données Kinesis en raison d'une capacité insuffisante du flux de données Kinesis. La valeur ThrottledPutRecordCount devrait rester aussi basse que possible, quoique vous pourriez rencontrer une certaine limitation lors de pics d'utilisation exceptionnels. DynamoDB réessaie d'envoyer des registres limités dans le flux de données Kinesis, mais cela peut engendrer une latence de réplication plus élevée.

    Si vous rencontrez une limitation excessive et régulière, il se peut que vous deviez augmenter le nombre de partitions de flux Kinesis en proportion du débit d'écriture observé de votre table. Pour en savoir plus sur la détermination de la taille d'un flux de données Kinesis, consultez Détermination de la taille initiale d'un flux de données Kinesis.

  • AgeOfOldestUnreplicatedRecord : temps écoulé depuis que la modification au niveau élément la plus ancienne restant à répliquer vers le flux de données Kinesis est apparue dans la table DynamoDB. Dans des conditions normales de fonctionnement, la valeur AgeOfOldestUnreplicatedRecord devrait être de l'ordre de quelques millisecondes. Ce nombre augmente en fonction des tentatives de réplication infructueuses, lorsque celles-ci sont causées par des choix de configuration contrôlés par le client.

    Si la AgeOfOldestUnreplicatedRecord métrique dépasse 168 heures, la réplication des modifications apportées au niveau des éléments depuis la table DynamoDB vers le flux de données Kinesis sera automatiquement désactivée.

    Les configurations contrôlées par le client qui peuvent entraîner des tentatives de réplication infructueuses sont, par exemple, une capacité de flux de données Kinesis sous-allouée causant une limitation excessive ou une mise à jour manuelle des stratégies d'accès de votre flux de données Kinesis empêchant DynamoDB d'ajouter des données à votre flux de données. Vous devrez peut-être allouer une capacité de flux de données Kinesis suffisante et vous assurer que les autorisations de DynamoDB sont inchangées pour que cette métrique reste aussi faible que possible.

  • FailedToReplicateRecordCount : nombre de registres que DynamoDB n'a pas pu répliquer sur votre flux de données Kinesis. Certains éléments de plus de 34 Ko peuvent augmenter en taille pour modifier les registres de données supérieurs à la limite de taille d'élément de 1 Mo de Kinesis Data Streams. Cette augmentation de taille se produit lorsque les éléments de plus de 34 Ko incluent un grand nombre de valeurs d'attribut booléennes ou vides. Les valeurs d'attribut booléennes et vides sont stockées sous forme de 1 octet dans DynamoDB, mais peuvent atteindre 5 octets lorsqu'elles sont sérialisées à l'aide de la norme de réplication Kinesis Data Streams. JSON DynamoDB ne peut pas répliquer de tels registres de modification dans votre flux de données Kinesis. DynamoDB ignore ces registres de données de modification et continue automatiquement la réplication des registres suivants.

Vous pouvez créer des CloudWatch alarmes Amazon qui envoient un message Amazon Simple Notification Service (AmazonSNS) pour notification lorsque l'une des mesures précédentes dépasse un seuil spécifique.