Utilisation de partitions et de métriques avec DynamoDB Streams et Kinesis Data Streams - 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.

Utilisation de partitions et de métriques avec DynamoDB Streams et Kinesis Data Streams

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 le mode à la demande et le 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. En mode à la demande, aucune planification de la capacité n’est nécessaire, car Kinesis Data Streams gère automatiquement les partitions afin de fournir le débit nécessaire.

En cas de charges de travail prévisibles, vous pouvez utiliser le mode provisionné pour votre flux de données Kinesis. En mode provisionné, vous devez spécifier le nombre de partitions du flux de données nécessaires pour accueillir les enregistrements de capture des données de modification 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 devez disposer des valeurs d’entrée suivantes :

  • Taille moyenne d’enregistrement 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. Ce nombre 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, comme 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 à l’aide des 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 accueillir votre débit de streaming DynamoDB :

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

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

  • Cette formule permet d’estimer le nombre de partitions nécessaires pour accueillir vos enregistrements de données de modification DynamoDB. Elle ne représente pas le nombre total de partitions dont votre flux de données Kinesis a besoin, comme le nombre de partitions requises pour prendre en charge des consommateurs de flux de données Kinesis supplémentaires.

  • 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 gonflement supplémentaire généré par DynamoDB avant de diffuser les enregistrements de données du journal des modifications à Kinesis Data Streams.

Pour en savoir plus sur les modes de capacité de Kinesis Data Streams, consultez Choix du mode de capacité du flux de données. Pour en savoir plus sur les différences tarifaires 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 de 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 enregistrements 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 métrique AgeOfOldestUnreplicatedRecord dépasse 168 heures, la réplication des modifications apportées au niveau des éléments de la table DynamoDB dans le flux de données Kinesis est 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 d’enregistrements 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 enregistrements 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 la forme d’un octet dans DynamoDB. Toutefois, elles peuvent atteindre 5 octets lorsqu’elles sont sérialisées à l’aide de JSON standard pour la réplication Kinesis Data Streams. DynamoDB ne peut pas répliquer de tels enregistrements de modification dans votre flux de données Kinesis. DynamoDB ignore ces enregistrements de données de modification et continue automatiquement la réplication des enregistrements suivants.

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