Dépannage des applications consommateur Kinesis Data Streams - Amazon Kinesis Data Streams
Certains enregistrements Kinesis Data Streams sont ignorés lors de l'utilisation de la Kinesis Client LibraryLes enregistrements appartenant à la même partition sont traités simultanément par différents processeurs d'enregistrementsL'application consommateur lit à une vitesse inférieure à la vitesse prévueGetRecords Renvoie un tableau d'enregistrements vide même s'il y a des données dans le fluxL'itérateur de partition expire de façon inattendueTraitement des enregistrements consommateur en retardErreur d'autorisation Clé principale KMS non autoriséeProblèmes courants, questions et idées de résolution des problèmes pour les consommateurs

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.

Dépannage des applications consommateur Kinesis Data Streams

Certains enregistrements Kinesis Data Streams sont ignorés lors de l'utilisation de la Kinesis Client Library

La cause la plus courante des enregistrements ignorés est une exception non gérée émise par processRecords. La Kinesis Client Library (KCL) s'appuie sur votre code processRecords pour gérer toutes les exceptions qui surviennent lors du traitement des enregistrements de données. Toute exception lancée par processRecords est absorbée par la KCL. Pour éviter les tentatives infinies lors d'une défaillance récurrente, la KCL ne renvoie pas le lot d'enregistrements traité au moment de l'exception. La KCL appelle ensuite processRecords pour le lot suivant d'enregistrements de données sans redémarrer le processeur d'enregistrements. Il en résulte que des enregistrements sont ignorés dans les applications consommateur. Pour éviter d'avoir des enregistrements ignorés, gérez toutes les exceptions dans processRecords de manière appropriée.

Les enregistrements appartenant à la même partition sont traités simultanément par différents processeurs d'enregistrements

Une partition n'a qu'un seul propriétaire dans toute application Kinesis Client Library (KCL) en cours d'exécution. Toutefois, plusieurs processeurs d'enregistrements peuvent traiter temporairement la même partition. Dans le cas d'une instance de travail qui perd la connectivité réseau, la KCL suppose que l'application de travail inaccessible ne traite plus d'enregistrements lorsque le délai de basculement est dépassé. Elle passe alors le relais à d'autres instances de travail. Pendant une courte période, les nouveaux processeurs d'enregistrements et ceux de l'application de travail inaccessible peuvent traiter les données depuis la même partition.

Vous devez définir un délai de basculement qui est approprié pour votre application. Pour les applications à faible latence, la valeur par défaut de 10 secondes peut représenter l'intervalle de temps maximal pendant lequel vous voulez attendre. Cependant, dans les cas où vous prévoyez des problèmes de connectivité liés, par exemple lorsque les appels sont effectués dans des zones géographiques où la connectivité peut être perdue plus fréquemment, ce nombre peut être trop faible.

Votre application doit anticiper et gérer ce scénario, sachant notamment que la connectivité réseau est généralement restaurée pour l'application de travail précédemment inaccessible. Si un processeur d'enregistrements se voit prendre ses partitions par un autre processeur d'enregistrements, il doit gérer les deux cas suivants pour effectuer un arrêt approprié :

  1. Une fois que l'appel à processRecords est terminé, la KCL invoque la méthode de fermeture sur le processeur d'enregistrements avec le motif de fermeture « ZOMBIE ». Vos processeurs d'enregistrements sont censés nettoyer toutes les ressources de façon appropriée, puis se fermer.

  2. Lorsque vous tentez de créer un point de contrôle à partir d'une application de travail « zombie », la KCL lance l'exception ShutdownException. Après avoir reçu cette exception, votre code est censé fermer proprement la méthode en cours.

Pour plus d’informations, consultez Gestion des enregistrements en double.

L'application consommateur lit à une vitesse inférieure à la vitesse prévue

Les raisons principales les plus courantes liées au débit de lecture plus lent que prévu sont les suivantes :

  1. Plusieurs applications consommateur ont un nombre total de lectures qui dépasse les limites par partition. Pour plus d’informations, consultez Quotas et limites. Dans ce cas, augmentez le nombre de partitions dans votre flux de données Kinesis.

  2. Le nombre limite qui spécifie le nombre maximal de GetRecords par appel peut avoir été configuré avec une valeur faible. Si vous utilisez la KCL, vous avez peut-être configuré l'application de travail avec une valeur faible pour la propriété maxRecords. En général, nous recommandons d'utiliser les valeurs système par défaut pour cette propriété.

  3. La logique inhérente à votre appel de processRecords peut prendre plus longtemps que prévu pour un certain nombre de raisons possibles : la logique peut utiliser beaucoup d'UC, les E/S sont bloquées ou la synchronisation connaît un goulot d'étranglement. Pour tester si cela est vrai, testez les processeurs enregistrements vides et comparez le débit de lecture. Pour plus d'informations sur la façon de faire face aux données entrantes, consultez la page Repartitionnement, mise à l'échelle et traitement parallèle.

Si vous n'avez qu'une seule application consommateur, il est toujours possible de lire au moins deux fois plus vite que la vitesse de placement. En effet, vous pouvez écrire jusqu'à 1 000 enregistrements par seconde pour les écritures, jusqu'à une vitesse d'écriture totale des données maximale de 1 Mo par seconde (y compris les clés de partition). Chaque partition ouverte peut prendre en charge jusqu'à 5 transactions par seconde pour la lecture, jusqu'à une vitesse de lecture totale des données maximale de 2 Mo par seconde. Notez que chaque lecture (appel de GetRecords) extrait un lot d'enregistrements. La taille des données renvoyées par appel de GetRecords varie en fonction de l'utilisation de la partition. La taille maximale des données que GetRecords peut renvoyer est de 10 Mo. Si un appel retourne cette valeur limite, les appels suivants effectués dans les 5 secondes suivantes lèvent l'exception ProvisionedThroughputExceededException.

GetRecords Renvoie un tableau d'enregistrements vide même s'il y a des données dans le flux

L'utilisation ou l'obtention d'enregistrements est un modèle d'extraction. Les développeurs sont tenus d'effectuer GetRecordsdes appels en boucle continue, sans interruption. Chaque appel de GetRecords renvoie également une valeur ShardIterator, qui doit être utilisée dans la prochaine itération de la boucle.

L'opération GetRecords ne se bloque pas. Elle renvoie immédiatement un résultat : des enregistrements de données appropriés ou un élément Records vide. Un élément Records vide est renvoyé dans deux conditions :

  1. La partition ne contient plus de données pour le moment.

  2. Il n'y a pas de données près de la partie de la partition vers laquelle pointe le ShardIterator.

Cette dernière condition est subtile, mais constitue un compromis de conception nécessaire pour éviter un temps de recherche illimité (latence)lors de l'extraction des enregistrements. Ainsi, l'application qui utilise le flux doit être exécutée en boucle et appeler GetRecords, en traitant les enregistrements vides comme une évidence.

Dans un scénario de production, la seule fois où la boucle continue doit être fermée est lorsque la valeur NextShardIterator est NULL. Lorsque NextShardIterator est NULL, cela signifie que la partition actuelle a été fermée et que la valeur ShardIterator pointerait autrement après le dernier enregistrement. Si l'application consommateur n'appelle jamais SplitShard ou MergeShards, la partition reste ouverte et les appels de GetRecords ne renvoient jamais de valeur NextShardIterator égale à NULL.

Si vous utilisez la Kinesis Client Library (KCL), le modèle de consommation ci-dessus vous sera résumé. Cela inclut la gestion automatique d'un ensemble de partitions qui changent dynamiquement. Avec la KCL, le développeur ne fournit que la logique pour traiter les enregistrements entrants. Cela est rendu possible par le fait que la bibliothèque effectue des appels continus de GetRecords à votre place.

L'itérateur de partition expire de façon inattendue

Un nouvel itérateur de partition est renvoyé par chaque demande de GetRecords (en tant que NextShardIterator), que vous utilisez ensuite dans la demande GetRecords suivante (en tant que ShardIterator). En règle générale, cet itérateur de partition n'expire pas avant d'être utilisé. Cependant, vous pouvez constater que les itérateurs de partition expirent lorsque vous n'avez pas appelé GetRecords pendant plus de 5 minutes ou que vous avez redémarré votre application consommateur.

Si l'itérateur de partition expire immédiatement avant d'être utilisé, cela peut indiquer que la table DynamoDB utilisée par Kinesis n'a pas suffisamment de capacité pour stocker les données de bail. Cette situation est plus susceptible de se produire si vous avez un grand nombre de partitions. Pour résoudre ce problème, augmentez la capacité d'écriture attribuée à la table de partition. Pour plus d’informations, consultez Utilisation d'une table des baux pour suivre les partitions traitées par l'application consommateur KCL.

Traitement des enregistrements consommateur en retard

Dans la plupart des cas d'utilisation, les applications consommateur lisent les données les plus récentes dans le flux. Dans certains cas, les lectures de l'application consommateur peuvent être en retard, ce qui n'est pas souhaitable. Une fois que vous avez identifié quel est le retard dans les lectures des applications consommateur, examinez les motifs les plus courants du retard des applications consommateur.

Commencez par la métrique GetRecords.IteratorAgeMilliseconds, qui suit la position de lecture dans toutes les partitions et les applications consommateur dans le flux. Notez que si l'ancienneté de l'itérateur dépasse 50 % de la période de conservation (par défaut 24 heures, configurable jusqu'à 365 jours), il y a un risque de perte de données suite à l'expiration des enregistrements. Une solution rapide provisoire consiste à augmenter la période de conservation. Cela arrête la perte de données importantes pendant que vous continuez à résoudre le problème. Pour plus d’informations, consultez Surveillance du service Amazon Kinesis Data Streams avec Amazon CloudWatch. Identifiez ensuite le retard pris par votre application client pour lire chaque partition à l'aide d'une CloudWatch métrique personnalisée émise par la Kinesis Client Library (KCL). MillisBehindLatest Pour plus d’informations, consultez Surveillance de la bibliothèque cliente Kinesis avec Amazon CloudWatch.

Voici les raisons les plus courantes pour lesquelles les applications consommateur sont en retard :

  • De fortes augmentations soudaines de GetRecords.IteratorAgeMilliseconds ou MillisBehindLatest indiquent généralement un problème temporaire, telles que des défaillances d'opération d'API sur une application en aval. Vous devez examiner ces augmentations soudaines si l'une des métriques affiche systématiquement ce comportement.

  • Une augmentation progressive de ces métriques indique qu'une application consommateur est en retard sur le flux, car elle ne traite pas les enregistrements assez vite. Les causes les plus courantes de ce comportement proviennent de ressources physiques insuffisantes ou d'une logique de traitement des enregistrements qui n'a pas été mise à l'échelle après une augmentation du débit du flux. Vous pouvez vérifier ce comportement en examinant les autres CloudWatch métriques personnalisées émises par la KCL associées à l'processTaskopération, notamment RecordProcessor.processRecords.TimeSuccess, et. RecordsProcessed

    • Si vous constatez une augmentation de la métrique processRecords.Time qui correspond à un débit plus élevé, vous devez analyser votre logique de traitement des enregistrements afin de déterminer pourquoi elle n'est pas mise à l'échelle alors que le débit augmente.

    • Si vous constatez une hausse des valeurs processRecords.Time qui n'est pas liée à l'augmentation du débit, vérifiez si vous effectuez des appels bloquants dans le chemin critique, lesquels sont souvent responsables des ralentissements du traitement des enregistrements. Une autre approche consiste à augmenter votre parallélisme en augmentant le nombre de partitions. Enfin, vérifiez que vous avez une quantité suffisante de ressources physiques (mémoire, UC, etc.) sur les nœuds de traitement sous-jacents pendant les pics de demandes.

Erreur d'autorisation Clé principale KMS non autorisée

Cette erreur se produit lorsqu'une application consommateur procède à une lecture à partir d'un flux chiffré sans disposer d'autorisation sur la clé principale KMS. Pour attribuer à une application des autorisations d'accès à une clé KMS, consultez les rubriques Utilisation des politiques de clés dans AWS KMS et Utilisation des politiques IAM avec AWS KMS.

Problèmes courants, questions et idées de résolution des problèmes pour les consommateurs