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.
Tableaux de métadonnées DynamoDB et équilibrage de charge dans KCL
KCL gère les métadonnées telles que les contrats de location et les mesures d'utilisation du processeur des employés. KCL assure le suivi de ces métadonnées à l'aide de tables DynamoDB. Pour chaque application Amazon Kinesis Data Streams, KCL 3.x crée trois tables DynamoDB par défaut afin de gérer les métadonnées : table des baux, tableau des métriques des travailleurs et table des états des coordinateurs. À partir de KCL 3.5, vous pouvez utiliser le format de tableau unique pour consolider toutes les métadonnées dans la table de bail. Pour de plus amples informations, veuillez consulter Format de tableau unique pour KCL.
Note
KCL 3.x a introduit deux nouvelles tables de métadonnées : les métriques des travailleurs et les tables d'état des coordinateurs. À partir de KCL 3.5, vous pouvez consolider ces tableaux dans le tableau des baux en utilisant le format de tableau unique.
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 en savoir plus, consultez Autorisations IAM requises pour les applications grand public KCL.
L'application grand public 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 hors service votre application client 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 grand public KCL. Chaque application KCL destinée aux consommateurs crée sa propre table de location. KCL utilise le nom de l'application client pour le 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 contrats de location. L'indice secondaire global reflète l'attribut LeaseKey du tableau des baux de base. Si la table de location de votre application KCL grand public n'existe pas au démarrage de l'application, l'un des opérateurs crée la table de location 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
-
Le nom de chaque application client KCL doit être unique pour éviter la duplication du nom de la table de location.
-
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 un fragment 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 multiflux avec KCL, il est structuré comme suit
account-id:StreamName:streamCreationTimestamp:ShardId. LeaseKey est la clé de partition de la table de location. Pour plus d'informations sur le traitement multiflux, consultezMulti-stream traitement avec KCL. -
checkpoint : le plus récent numéro de séquence de point de contrôle de la partition.
-
checkpoint SubSequenceNumber : lorsque vous utilisez la fonction d'agrégation de la bibliothèque Kinesis Producer, il s'agit d'une extension de checkpoint qui permet de suivre les enregistrements individuels des utilisateurs dans 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.
-
propriétaire SwitchesSinceCheckpoint : Combien de fois ce bail a-t-il changé de travailleur depuis le dernier point de contrôle ?
-
parent ShardId : identifiant du parent de ce fragment. S'assure que la partition parent est entièrement traitée avant que le traitement ne commence sur les partitions enfants, en maintenant l'ordre de traitement des enregistrements correct.
-
enfant ShardId : liste des ID de partition enfant résultant de la division ou de la fusion de cette partition. Utilisé pour suivre le lignage des fragments et gérer l'ordre de traitement lors des opérations de repartage.
-
début HashKey : limite inférieure de la plage de clés de hachage pour ce fragment.
-
fin HashKey : limite supérieure de la plage de clés de hachage pour ce fragment.
Si vous utilisez le traitement multiflux avec KCL, les deux champs supplémentaires suivants apparaissent dans le tableau des baux. Pour de plus amples informations, veuillez consulter Multi-stream traitement 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 mesures d'utilisation du processeur de chaque travailleur. Ces indicateurs seront utilisés par KCL pour effectuer des attributions de baux efficaces afin de parvenir à une utilisation équilibrée des ressources entre les travailleurs. KCL utilise KCLApplicationName-WorkerMetricStats le nom du tableau des métriques du travailleur par défaut.
Tableau d'état des coordonnateurs
Une table d'état des coordinateurs est une table Amazon DynamoDB unique pour chaque application KCL et est utilisée pour stocker des informations d'état internes pour les travailleurs. Par exemple, la table d'état des coordinateurs stocke des données concernant l'élection du leader ou des métadonnées associées à la migration sur place de KCL 2.x vers KCL 3.x. KCL utilise comme 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 contrats de location, la table des indicateurs du personnel 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 en fonction du trafic sans nécessiter de planification des capacités. 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 ces bonnes pratiques :
-
Analysez les modèles d'utilisation :
-
Surveillez les modèles de lecture et d'écriture et les utilisations (RCU, WCU) de votre application à l'aide des métriques Amazon CloudWatch .
-
Comprenez les exigences en matière de débit de pointe et de débit moyen.
-
-
Calculez la capacité requise :
-
Estimez les unités de capacité de lecture (RCU) et les unités de capacité d'écriture (WCU) 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 la mise à l'échelle automatique de DynamoDB pour ajuster automatiquement la capacité provisionnée et définir les limites de capacité minimale et maximale appropriées.
-
La mise à l'échelle automatique de DynamoDB vous aidera à éviter que votre table de métadonnées KCL n'atteigne la limite de capacité et ne soit ralentie.
-
-
Surveillance et optimisation régulières :
-
Surveillez en permanence CloudWatch les métriques pour
ThrottledRequests. -
Ajustez la capacité en fonction de l'évolution de votre charge de travail dans le temps.
-
Si vous rencontrez un problème ProvisionedThroughputExceededException dans les métadonnées des tables DynamoDB pour votre application grand public KCL, vous devez augmenter la capacité de débit provisionnée de la table DynamoDB. Si vous définissez un certain niveau d'unités de capacité de lecture (RCU) et d'unités de capacité d'écriture (WCU) lors de la création de votre application grand public, il se peut qu'il ne soit pas suffisant à mesure que votre utilisation augmente. Par exemple, si votre application grand public KCL effectue des contrôles 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 provisionné dans DynamoDB, consultez la section Capacité de débit de DynamoDB et mise à jour d'un tableau dans le guide du développeur Amazon DynamoDB.
Comment KCL attribue des baux aux travailleurs et équilibre la charge
KCL collecte et surveille en permanence les mesures d'utilisation du processeur provenant des hôtes de calcul qui exécutent les serveurs 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 présentent des taux d'utilisation du processeur plus élevés que d'autres, elle réattribuera les contrats de location entre les travailleurs afin de réduire la charge de travail des travailleurs les plus sollicités. L'objectif est d'équilibrer la charge de travail de manière plus uniforme sur l'ensemble du parc d'applications grand public, afin d'éviter qu'un seul travailleur ne soit surchargé. Alors 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 la mise à l'échelle automatique pour gérer efficacement la capacité informatique 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 sont remplies. Pour en savoir plus, consultez Conditions préalables. Si KCL ne peut pas collecter les mesures d'utilisation du processeur auprès des employés, KCL utilisera à nouveau le débit par travailleur pour attribuer des contrats de location et équilibrer la charge entre les employés de la flotte. KCL surveillera le débit que reçoit chaque travailleur à un moment donné et réattribuera les contrats de location pour s'assurer que chaque travailleur obtient un niveau de débit total similaire pour les contrats de location qui lui sont attribués.
