Tables de métadonnées DynamoDB et équilibrage de charge dans KCL - Amazon Kinesis Data Streams

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.

Tables de métadonnées DynamoDB et équilibrage de charge dans KCL

KCL gère les métadonnées telles que les baux et les mesures d'utilisation du processeur fournies par les travailleurs. KCL assure le suivi de ces métadonnées à l'aide de tables DynamoDB. Pour chaque application Amazon Kinesis Data Streams, KCL crée trois tables DynamoDB pour gérer les métadonnées : table des baux, table des métriques des travailleurs et table de l'état des coordinateurs.

Note

KCL 3.x a introduit deux nouvelles tables de métadonnées : les métriques de travail et les tables d'état des coordinateurs.

Important

Vous devez ajouter les autorisations appropriées pour que les applications KCL puissent créer et gérer des tables de métadonnées dans DynamoDB. Pour plus de détails, consultez Autorisations IAM requises pour les applications grand public KCL.

L'application client KCL ne supprime pas automatiquement ces trois tables de métadonnées DynamoDB. Assurez-vous de supprimer ces tables de métadonnées DynamoDB créées par l'application client KCL lorsque vous mettez celle-ci hors service afin d'éviter des coûts inutiles.

Tableau des baux

Une table de location est une table Amazon DynamoDB unique utilisée pour suivre les partitions louées et traitées par les planificateurs de l'application client KCL. Chaque application client KCL crée sa propre table de location. KCL utilise le nom de l'application client comme nom de la table des baux par défaut. Vous pouvez définir un nom de table personnalisé à l'aide de la configuration. KCL crée également un index secondaire global sur la table des baux avec la clé de partition de LeaseOwner pour une découverte efficace des baux. L'index secondaire global reflète l'attribut LeaseKey de la table des baux de base. Si la table des baux de votre application client KCL n'existe pas au démarrage de l'application, l'un des travailleurs crée la table des baux pour votre application.

Vous pouvez consulter cette table à l'aide de la console Amazon DynamoDB lors que l'application est en cours d'exécution.

Important
  • Chaque nom d'application client KCL doit être unique afin d'éviter la duplication du nom de la table des baux.

  • Votre compte est facturé pour les coûts associés à la table DynamoDB, en plus des coûts associés au service Kinesis Data Streams lui-même.

Chaque ligne du tableau des baux représente une partition en cours de traitement par les planificateurs de votre application client. Les principaux champs sont les suivants :

  • LeaseKey : pour le traitement en flux unique, il s'agit de l'ID de partition. Pour le traitement multi-flux avec KCL, il est structuré comme suit : account-id:StreamName:streamCreationTimestamp:ShardId LeaseKey est la clé de partition de la table des baux. Pour plus d'informations sur le traitement multiflux, consultezTraitement multi-flux avec KCL .

  • checkpoint : le plus récent numéro de séquence de point de contrôle de la partition.

  • checkpointSubSequenceNuméro : lorsque vous utilisez la fonctionnalité d'agrégation de la bibliothèque Kinesis Producer, il s'agit d'une extension du point de contrôle qui permet de suivre les enregistrements utilisateur individuels au sein de l'enregistrement Kinesis.

  • LeaseCounter : utilisé pour vérifier si un travailleur traite actuellement activement le bail. LeaseCounter augmente si la propriété du bail est transférée à un autre travailleur.

  • LeaseOwner : le travailleur actuel titulaire de ce bail.

  • ownerSwitchesSincePoint de contrôle : combien de fois ce bail a changé de travailleurs depuis le dernier point de contrôle.

  • parentShardId: ID du parent de cette partition. Assurez-vous que la partition parent est entièrement traitée avant que le traitement ne commence sur les partitions enfants, en maintenant le bon ordre de traitement des enregistrements.

  • childShardId: Liste des fragments enfants IDs résultant de la division ou de la fusion de ce fragment. Utilisé pour suivre la lignée des partitions et gérer l'ordre de traitement lors des opérations de repartage.

  • startingHashKey: limite inférieure de la plage de clés de hachage pour cette partition.

  • endingHashKey: limite supérieure de la plage de clés de hachage pour cette partition.

Si vous utilisez le traitement multi-flux avec KCL, les deux champs supplémentaires suivants s'affichent dans le tableau des baux. Pour de plus amples informations, veuillez consulter Traitement multi-flux avec KCL .

  • shardID : ID de la partition.

  • StreamName : identifiant du flux de données au format suivant :account-id:StreamName:streamCreationTimestamp.

Tableau des indicateurs relatifs aux travailleurs

La table des métriques de travail est une table Amazon DynamoDB unique pour chaque application KCL et est utilisée pour enregistrer les métriques d'utilisation du processeur de chaque travailleur. Ces indicateurs seront utilisés par KCL pour effectuer des assignations de location efficaces afin d'assurer une utilisation équilibrée des ressources entre les travailleurs. KCL utilise le nom KCLApplicationName-WorkerMetricStats de la table des métriques de travail par défaut.

Tableau des états des coordinateurs

Une table d'état des coordinateurs est une table Amazon DynamoDB unique pour chaque application KCL. Elle est utilisée pour stocker les informations d'état internes des travailleurs. Par exemple, la table d'état du coordinateur stocke les données concernant l'élection du leader ou les métadonnées associées à la migration sur place de KCL 2.x vers KCL 3.x. KCL utilise le nom KCLApplicationName-CoordinatorState de la table d'état du coordinateur par défaut.

Mode de capacité DynamoDB pour les tables de métadonnées créées par KCL

Par défaut, la bibliothèque cliente Kinesis (KCL) crée des tables de métadonnées DynamoDB telles que la table des baux, la table des métriques des travailleurs et la table d'état des coordinateurs en utilisant le mode de capacité à la demande. Ce mode adapte automatiquement la capacité de lecture et d'écriture pour s'adapter au trafic sans nécessiter de planification de la capacité. Nous vous recommandons vivement de conserver le mode capacité en mode à la demande pour un fonctionnement plus efficace de ces tables de métadonnées.

Si vous décidez de passer la table des baux en mode capacité provisionnée, suivez les meilleures pratiques suivantes :

  • Analysez les modèles d'utilisation :

    • Surveillez les modèles et les utilisations de lecture et d'écriture de votre application (RCU, WCU) à l'aide des métriques Amazon CloudWatch .

    • Comprenez les exigences de débit de pointe et de débit moyen.

  • Calculez la capacité requise :

    • Estimez les unités de capacité de lecture (RCUs) et les unités de capacité d'écriture (WCUs) en fonction de votre analyse.

    • Tenez compte de facteurs tels que le nombre de fragments, la fréquence des points de contrôle et le nombre de travailleurs.

  • Implémentez le dimensionnement automatique :

    • Utilisez le dimensionnement automatique DynamoDB pour ajuster automatiquement la capacité allouée et définir les limites de capacité minimale et maximale appropriées.

    • La mise à l'échelle automatique DynamoDB vous aidera à éviter que votre table de métadonnées KCL n'atteigne la limite de capacité et ne soit limitée.

  • Surveillance et optimisation régulières :

    • Surveillez en permanence CloudWatch les métriques pourThrottledRequests.

    • Ajustez la capacité en fonction de l'évolution de votre charge de travail.

Si vous rencontrez des tables DynamoDB intégrées aux métadonnées pour votre application client KCL, vous devez augmenter la capacité de débit allouée à la table DynamoDB. ProvisionedThroughputExceededException Si vous définissez un certain niveau d'unités de capacité de lecture (RCU) et d'unités de capacité d'écriture (WCU) lorsque vous créez votre application grand public pour la première fois, il se peut que cela ne soit pas suffisant à mesure que votre utilisation augmente. Par exemple, si votre application client KCL effectue des points de contrôle fréquents ou fonctionne sur un flux contenant de nombreux fragments, vous aurez peut-être besoin d'unités de capacité supplémentaires. Pour plus d'informations sur le débit alloué dans DynamoDB, consultez les sections Capacité de débit DynamoDB et mise à jour d'un tableau dans le manuel Amazon DynamoDB Developer Guide.

Comment KCL attribue les baux aux travailleurs et équilibre la charge

KCL collecte et surveille en permanence les indicateurs d'utilisation du processeur à partir des hôtes de calcul qui exécutent les travailleurs afin de garantir une répartition uniforme de la charge de travail. Ces mesures d'utilisation du processeur sont stockées dans le tableau des métriques de travail de DynamoDB. Si KCL détecte que certains travailleurs affichent des taux d'utilisation du processeur plus élevés que d'autres, elle réattribuera les baux entre les travailleurs afin de réduire la charge de travail des travailleurs très sollicités. L'objectif est d'équilibrer la charge de travail de manière plus uniforme au sein du parc d'applications grand public, afin d'éviter qu'un seul travailleur ne soit surchargé. À mesure que KCL répartit l'utilisation du processeur sur l'ensemble du parc d'applications grand public, vous pouvez ajuster la capacité de votre parc d'applications grand public en choisissant le bon nombre de travailleurs ou utiliser le dimensionnement automatique pour gérer efficacement la capacité de calcul afin de réduire les coûts.

Important

KCL peut collecter des métriques d'utilisation du processeur auprès des travailleurs uniquement si certaines conditions préalables sont remplies. Pour plus de détails, consultez Prérequis. Si KCL ne parvient pas à collecter les indicateurs d'utilisation du processeur auprès des travailleurs, KCL utilisera à nouveau le débit par travailleur pour attribuer des baux et équilibrer la charge entre les travailleurs du parc. KCL surveillera le débit reçu par chaque travailleur à un moment donné et réattribuera les baux pour s'assurer que chaque travailleur obtient un niveau de débit total similaire pour les baux qui lui ont été attribués.