Comment puis-je détecter et résoudre les exceptions ReadProvisionedThroughputExceeded dans Kinesis Data Streams ?

Brève description

L’erreur ReadProvisionedThroughputExceeded se produit lorsque Kinesis Data Streams limite les appels GetRecords pendant une certaine durée.

Si les quotas suivants sont dépassés, votre flux de données Amazon Kinesis peut être limité :

• Chaque partition prend en charge jusqu’à cinq transactions de lecture par seconde, ce qui correspond à cinq appels GetRecords par seconde pour chaque partition.
• Chaque partition prend en charge un taux de lecture maximal de 2 Mio par seconde.
• GetRecords extrait jusqu’à 10 Mio de données par appel à partir d’une seule partition et jusqu’à 10 000 enregistrements par appel. Si un appel à GetRecords renvoie 10 Mio de données, les appels suivants effectués dans les 5 secondes qui suivent génèrent une erreur.

Si vous rencontrez une erreur ReadProvisionedThroughputExceeded, effectuez l’une des tâches suivantes :

• Identifiez la cause racine de votre problème.
• Identifiez une éventuelle microrafale.
• Appliquez les bonnes pratiques Kinesis Data Streams.

Résolution

Identifiez la cause racine de votre problème

Pour identifier la cause racine de l’erreur ReadProvisionedThroughputExceeded dans Data Streams, surveillez le service Amazon Kinesis Data Streams avec Amazon CloudWatch.

Passez en revue les métriques suivantes dans CloudWatch :

• GetRecords.Bytes : le nombre d’octets extraits du flux de données, mesuré sur une période donnée.
• GetRecords.Records : le nombre d’enregistrements extraits du flux de données sur une période donnée.
• ReadProvisionedThroughputExceeded : le nombre d’appels GetRecords limités dans votre flux de données.

Configurez votre tableau de bord CloudWatch pour afficher vos statistiques sous forme de valeur Somme avec une période définie sur 1 minute. Divisez ensuite la valeur Somme par 60 secondes pour obtenir une valeur moyenne.

Par exemple, si vous utilisez la valeur de la métrique GetRecords.Records, divisez la valeur Somme par 60 secondes pour calculer le nombre moyen d’enregistrements envoyés par seconde. Vérifiez ensuite si la valeur moyenne est inférieure aux enregistrements envoyés par seconde pour la limite définie pour votre flux de données. Pour en savoir plus sur les quotas de partitions, consultez la page Quotas et limites.

Remarque : activez la fonction de surveillance améliorée pour vous assurer que la charge est répartie uniformément sur toutes vos partitions.

Vous pouvez également utiliser la métrique GetRecords.Records avec la statistique affichée sous forme de valeur Exemple de comptage et la période définie sur 1 minute. Divisez la valeur Exemple de comptage par 60 secondes pour calculer le nombre moyen d’appels GetRecords effectués par seconde pour chaque partition. Si la valeur moyenne est d’environ cinq appels GetRecords par seconde et que vous recevez un message d’erreur ReadProvisionedThroughputExceeded, passez en revue vos consommateurs et vos quotas de partitions. Si les consommateurs ne dépassent pas les limites de partitions, c’est que l’erreur ReadProvisionedThroughputExceeded peut être due au fait que vos consommateurs effectuent plus de cinq appels GetRecords par seconde.

Pour finir, vérifiez si la valeur ReadProvisionedThroughputExceeded varie au sein de vos partitions. Si la distribution des partitions est inégale, ou si une partition reçoit plus ou moins de données que l’autre, un déséquilibre de distribution peut se produire. Pour résoudre ce déséquilibre de distribution des partitions et éviter les partitions en excès, utilisez l’UUID comme clé de partition dans l’appel d’API putRecords.

Identifier une éventuelle microrafale

Bien que cela se produise rarement, il peut arriver que la valeur des métriques soit inférieure aux quotas de partitions et que cela provoque le ralentissement d’un flux de données en cours de lecture.

Par exemple, un appel GetRecords.Bytes Sum:1min représente 10 Mio de données lues pendant 1 minute. Au bout d’une seconde, l’appel GetRecords.Bytes lit 2 Mio de données sans aucune limitation. Ensuite, au bout de 2 secondes, l’appel GetRecords.Bytes lit 8 Mio de données. Au bout de 3 secondes, il se peut qu’il n’y ait aucune opération de lecture ou limitation. Bien que le quota de partitions pour la minute (2 Mio * 60 = 120 Mio de données) ne soit pas atteint, il se peut que vous receviez un message d’erreur ReadProvisionedThroughputExceeded. Si vous remarquez un pic soudain dans la valeur des métriques, recherchez la microrafale à l’origine de l’exception ReadProvisionedThroughputExceeded.

Appliquer les bonnes pratiques Kinesis Data Streams

Pour limiter les exceptions ReadProvisionedThroughputExceeded, appliquez les bonnes pratiques suivantes :

• Partitionnez à nouveau votre flux pour augmenter le nombre de partitions qu’il contient.
• Réduisez la taille des demandes GetRecords. Configurez le paramètre limite ou réduisez la fréquence des demandes GetRecords.
  Remarque : si le consommateur est Amazon Kinesis Data Firehose, le flux de données s’adapte à la fréquence des appels GetRecords effectués. Si le consommateur est une fonction AWS Lambda avec mappage des sources d’événements, le flux est interrogé une fois par seconde. Vous ne pouvez pas modifier la fréquence d’interrogation. Si le consommateur est une application Amazon Kinesis Client Library (KCL), ajustez la fréquence d’interrogation. Pour régler la fréquence d’interrogation, modifiez la valeur du paramètre DEFAULT_IDLETIME_BETWEEN_READS_MILLIS dans KinesisClientLibConfiguration. Vous pouvez définir cette valeur de manière dynamique dans le code. Pour en savoir plus sur la modification de cette valeur dans KCL, consultez la page amazon-kinesis-client du site Web GitHub.
• Répartissez les opérations de lecture et d’écriture de la manière la plus uniforme possible sur toutes les partitions dans Data Streams.
• Si votre flux de données exploite plus de cinq consommateurs, utilisez des consommateurs avec diffusion améliorée. 
• Si vous rencontrez des exceptions ReadProvisionedThroughputExceeded, utilisez un mécanisme de répétition d’erreur et de backoff exponentiel dans la logique du consommateur. Pour les applications grand public qui utilisent un kit de développement logiciel AWS, les demandes sont répétées par défaut.