Dépannage des applications consommateur Kinesis Data Streams - 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.

Dépannage des applications consommateur Kinesis Data Streams

Certains enregistrements Kinesis Data Streams sont ignorés lors de l'utilisation de la bibliothèque client Kinesis

La cause la plus courante des enregistrements ignorés est une exception non gérée émise par processRecords. La bibliothèque client Kinesis (Kinesis Client Library, KCL) s'appuie sur votreprocessRecordsafin de gérer toutes les exceptions générées par le traitement des enregistrements de données. Toute exception provenant deprocessRecordsest 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. Le KCL appelle ensuiteprocessRecordspour 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 (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 n'est plus en train de traiter des 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. Après l'appel actuel àprocessRecordsest terminé, la KCL appelle la méthode d'arrêt sur le processeur d'enregistrements avec la raison d'arrêt « ZOMBIE ». Vos processeurs d'enregistrements sont censés nettoyer toutes les ressources de façon appropriée, puis se fermer.

  2. Lorsque vous tentez d'effectuer un point de contrôle à partir d'une application de travail « zombie », la KCL émet l'exceptionShutdownException. 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 le 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'à un taux d'écriture total maximal 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 les lectures, jusqu'à un taux de lecture total maximal de données 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. Taille maximale de données queGetRecordspeut retourner 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.

GetRecordsRenvoie un tableau d'enregistrements vides même lorsque le flux contient des données

L'utilisation ou l'obtention d'enregistrements est un modèle d'extraction. Les développeurs sont censés appelerGetRecordsen 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 bibliothèque client Kinesis (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 de location pour suivre les partitions traitées par l'application Consumer 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'à365jours), il existe un risque de perte de données en raison de l'expiration de l'enregistrement. 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 quel est le retard de lecture de votre application consommateur sur chaque partition en utilisant une application personnaliséeCloudWatchla métrique émise par la bibliothèque client Kinesis (Kinesis Client Library, KCL),MillisBehindLatest. Pour plus d'informations, consultez Surveillance de la bibliothèque client Kinesis Client Library 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 l'autre application personnaliséeCloudWatchmesures que la KCL émet associées à l'optionprocessTaskopération, y comprisRecordProcessor.processRecords.Time,Success, etRecordsProcessed.

    • 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 des autorisations à une application afin qu'elle puisse accéder à une clé KMS, consultezUtilisation de stratégies de clé dansAWSKMSetUtilisation des stratégies IAM avecAWSKMS.

Problèmes courants, questions et idées de dépannage pour les consommateurs