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.
# Optimisez les utilisateurs d'Amazon Kinesis Data Streams
Vous pouvez optimiser davantage votre client Amazon Kinesis Data Streams en fonction du comportement spécifique que vous observez.
Consultez les rubriques suivantes pour identifier des solutions.
**Topics**
+ [Améliorez le traitement à faible latence](kinesis-low-latency.md)
+ [Traitez les données sérialisées à l' AWS Lambda aide de la bibliothèque Amazon Kinesis Producer](kinesis-record-deaggregation.md)
+ [Utilisez le redécoupage, la mise à l'échelle et le traitement parallèle pour modifier le nombre de partitions](kinesis-record-processor-scaling.md)
+ [Gérer les enregistrements dupliqués](kinesis-record-processor-duplicates.md)
+ [Gérez le démarrage, l'arrêt et la régulation](kinesis-record-processor-additional-considerations.md)
# Améliorez le traitement à faible latence
Le *délai de propagation* est défini comme la end-to-end latence entre le moment où un enregistrement est écrit dans le flux et celui où il est lu par une application grand public. Ce délai varie en fonction d'un certain nombre de facteurs, mais il est surtout modifié par l'intervalle d'interrogation des applications consommateur.
Pour la plupart des applications, nous recommandons d'interroger chaque partition une fois par seconde par application. Ainsi, plusieurs applications consommateur peuvent traiter un flux simultanément sans atteindre les limites de 5 appels `GetRecords` par seconde de Amazon Kinesis Data Streams. En outre, traiter de gros lots de données a tendance à être plus efficace pour réduire les latences réseau et les autres latences en aval dans votre application.
Les valeurs par défaut de la KCL sont définies pour suivre les meilleures pratiques d'interrogation toutes les secondes. Elles génère des délais de propagation normalement inférieurs à 1 seconde.
Les enregistrements Kinesis Data Streams sont disponibles pour la lecture immédiatement après avoir été écrits. Il existe quelques cas d'utilisation qui ont besoin de tirer parti de cet avantage et d'utiliser les données du flux dès qu'elles sont disponibles. Vous pouvez réduire sensiblement le délai de propagation en remplaçant les paramètres KCL par défaut pour interroger plus fréquemment, comme le montrent les exemples ci-après.
Code de configuration KCL Java :
```
kinesisClientLibConfiguration = new
KinesisClientLibConfiguration(applicationName,
streamName,
credentialsProvider,
workerId).withInitialPositionInStream(initialPositionInStream).withIdleTimeBetweenReadsInMillis(250);
```
Paramètres du fichier de propriétés pour KCL Python et Ruby :
```
idleTimeBetweenReadsInMillis = 250
```
**Note**
Étant donné que Kinesis Data Streams est limité à 5 appels `GetRecords` par seconde et par partition, le fait de définir la propriété `idleTimeBetweenReadsInMillis` sur une valeur inférieure à 200 ms peut faire que votre application émet l'exception `ProvisionedThroughputExceededException`. Une trop grande partie de ces exceptions peuvent engendrer des interruptions exponentielles et provoquer ainsi des latences de traitement inattendues significatives. Si vous définissez cette propriété sur une valeur égale ou juste supérieure à 200 ms et que vous avez plusieurs applications de traitement, vous constaterez une limitation similaire.
# Traitez les données sérialisées à l' AWS Lambda aide de la bibliothèque Amazon Kinesis Producer
L'[Amazon Kinesis Producer Library](https://docs.aws.amazon.com/kinesis/latest/dev/developing-producers-with-kpl.html) (KPL) regroupe les petits enregistrements formatés par l'utilisateur en enregistrements plus volumineux d'une taille maximale de 1 Mo afin de mieux utiliser le débit d'Amazon Kinesis Data Streams. Bien que la KCL pour Java prenne en charge la désagrégation de ces enregistrements, vous devez utiliser un module spécial pour désagréger les enregistrements lorsque vous les utilisez en AWS Lambda tant que consommateur de vos flux. Vous pouvez obtenir le code de projet et les instructions nécessaires sur les modules de GitHub [désagrégation de la bibliothèque Amazon Kinesis Producer pour](https://github.com/awslabs/kinesis-deaggregation) Lambda. AWS Les composants de ce projet vous permettent de traiter des données sérialisées KPL dans AWS Lambda, en Java, Node.js et Python. Ces composants peuvent également être utilisés dans le cadre d'une [application KCL multi-lang](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client-multilang/src/main/java/software/amazon/kinesis/multilang/package-info.java).
# Utilisez le redécoupage, la mise à l'échelle et le traitement parallèle pour modifier le nombre de partitions
Le *repartitionnement* vous permet d'augmenter ou de diminuer le nombre de partitions dans un flux afin de faire face aux modifications de la vitesse de circulation des données dans le flux. En général, le repartitionnement est effectué par une application administrative qui surveille les métriques de traitement des données de partition. Bien que la KCL elle-même ne soit pas à l'origine des opérations de repartitionnement, elle est conçue pour faire face aux modifications du nombre de partitions que provoque le repartitionnement.
Comme indiqué dans [Utilisez une table de location pour suivre les partitions traitées par l'application client KCL](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable), la KCL assure le suivi des unités dans le flux à l'aide d'un tableau Amazon DynamoDB. Lorsque de nouvelles partitions sont créées à la suite du repartitionnement, la KCL les détecte et remplit et apporte de nouvelles lignes dans la table. Les applications de travail détectent automatiquement les nouvelles partitions et créent des processeurs pour traiter les données qu'elles contiennent. La KCL répartit aussi les partitions du flux entre toutes les applications de travail et processeurs d'enregistrements disponibles.
La KCL garantit que les données qui existaient dans les partitions avant le repartitionnement son traitées en premier. Une fois que les données ont été traitées, les données issues des nouvelle partitions sont envoyées aux processeurs d'enregistrements. De cette façon, la KCL conserve l'ordre dans lequel les enregistrements de données ont été ajoutés au flux pour une clé de partition spécifique.
## Exemple : repartage, mise à l'échelle et traitement parallèle
L'exemple suivant illustre comment la KCL vous permet de gérer la mise à l'échelle et le repartitionnement :
+ Par exemple, si votre application s'exécute sur une instance EC2 et traite un flux de données Kinesis qui contient quatre partitions. Cette instance a une application de travail KCL et quatre processeurs d'enregistrements (un seul processeur d'enregistrements pour chaque partition). Ces quatre processeurs d'enregistrements s'exécutent en parallèle dans le même processus.
+ Ensuite, si vous mettez à l'échelle l'application pour utiliser une autre instance, vous avez deux instances qui traitent un flux qui contient quatre partitions. Lorsque l"application de travail KCL démarre sur la seconde instance, elle équilibre la charge avec la première instance afin que chaque instance traite maintenant deux partitions.
+ Si vous décidez ensuite de fractionner les quatre partitions en cinq partitions. La KCL coordonne à nouveau le traitement entre les instances : une instance traite trois partitions et l'autre traite deux partitions. Une coordination similaire se produit lorsque vous fusionnez des partitions.
En règle générale, lorsque vous utilisez la KCL, vous devez vous assurer que le nombre d'instances ne dépasse pas le nombre de partitions (sauf en cas de reprise sur incident). Chaque partition est traitée par une seule application de travail KCL et a exactement un processeur d'enregistrements correspondant, de sorte que vous n'avez jamais besoin de plusieurs instances pour traiter une seule partition. Cependant, une seul application de travail peut traiter tout nombre de partitions, et il est donc approprié que le nombre de partitions dépasse le nombre d'instances.
Pour faire monter le traitement en puissance dans votre application, vous devez tester une combinaison des méthodes suivantes :
+ Augmentation de la taille de l'instance (car tous les processeurs d'enregistrements s'exécutent en parallèle dans un processus)
+ Augmentation du nombre d'instances jusqu'au nombre maximal de partitions ouvertes (car les partitions peuvent être traitées de façon indépendante)
+ Augmentation du nombre de partitions (ce qui augmente le niveau de parallélisme)
Notez que vous pouvez utiliser autoscaling pour mettre à l'échelle automatiquement vos instances sur la base des métriques appropriées. Pour plus d’informations, consultez le [Guide de l’utilisateur Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).
Lorsque le repartitionnement augmente le nombre de partitions du flux, l'augmentation correspondante du nombre de processeurs d'enregistrements augmente la charge sur les instances EC2 qui les hébergent. Si les instances font partie d'un groupe Auto Scaling et que la charge augmente suffisamment, le groupe Auto Scaling ajoute des instances pour gérer l'augmentation de la charge. Vous devez configurer vos instances pour lancer votre Amazon Kinesis Data Streams au démarrage, afin que les applications de travail et processeurs d'enregistrements supplémentaires deviennent actifs immédiatement sur la nouvelle instance.
Pour en savoir plus sur le repartitionnement, référez-vous à la section [Revisionner un stream](kinesis-using-sdk-java-resharding.md).
# Gérer les enregistrements dupliqués
Il y a deux raisons principales pour lesquelles les enregistrements peuvent être distribués plusieurs fois à votre Amazon Kinesis Data Streams : nouvelles tentatives de l'application producteur et nouvelles tentatives de l'application consommateur. Votre application doit anticiper et gérer adéquatement le traitement des enregistrements plusieurs fois.
## Réessaie le producteur
Prenez l'exemple d'une application producteur qui connaît un délai d'attente lié au réseau après avoir effectué un appel vers `PutRecord`, mais avant de recevoir un accusé de réception de Amazon Kinesis Data Streams. L'application producteur ne peut pas être sûre que l'enregistrement a été distribué à Kinesis Data Streams. En supposant que chaque enregistrement est important pour l'application, l'application producteur aura été écrite de façon à renouveler l'appel avec les mêmes données. Si les deux appels vers `PutRecord` sur ces mêmes données ont été validés avec succès pour Kinesis Data Streams, il y aura deux enregistrements Kinesis Data Streams. Même si les deux enregistrements comportent des données identiques, ils ont aussi des numéros de séquence uniques. Les applications qui ont besoin de garanties strictes doivent intégrer une clé primaire dans l'enregistrement pour supprimer les doubles ultérieurement lors du traitement. Notez que le nombre de doubles dû aux tentatives de l'application producteur est généralement faible par rapport au nombre de doubles dû aux tentatives de l'application consommateur.
**Note**
Si vous utilisez le AWS SDK`PutRecord`, découvrez le [comportement du SDK Retry](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) dans le guide de l'utilisateur de *AWS SDKs and Tools*.
## Réessaie par le consommateur
Les tentatives de l'application consommateur (l'application qui traite les données) ont lieu lorsque les processeurs d'enregistrements redémarrent. Les processeurs d'enregistrements d'une même partition redémarrent dans les cas suivants :
1. Une application de travail s'arrête de manière inattendue
1. Des instances de travail sont ajoutées ou supprimées
1. Des partitions sont fusionnées ou fractionnées
1. L'application est déployée
Dans tous ces cas, le mappage shards-to-worker-to -record-processor est continuellement mis à jour pour le traitement de l'équilibrage de charge. Les processeurs de partition qui ont été migrés vers d'autres instances recommencent à traiter les enregistrements depuis le dernier point de contrôle. Il en résulte un traitement double des enregistrements, comme l'illustre l'exemple ci-dessous. Pour plus d'informations sur l'équilibrage de charge, consultez [Utilisez le redécoupage, la mise à l'échelle et le traitement parallèle pour modifier le nombre de partitions](kinesis-record-processor-scaling.md).
### Exemple : une nouvelle tentative du client aboutit à une nouvelle livraison d'enregistrements
Dans cet exemple, vous avez une application qui lit continuellement les enregistrements à partir d'un flux, regroupe les enregistrements dans un fichier local et charge ce fichier dans Amazon S3. Pour simplifier, supposons qu'il y a une seule partition et une application de travail qui traite la partition. Prenons l'exemple de la séquence d'événements suivante, en supposant que le dernier point de contrôle était au numéro d'enregistrement 10 000 :
1. Une application de travail lit le prochain lot d'enregistrements à partir de la partition, soit les enregistrements 10 001 à 20 000.
1. L'application de travail passe le lot d'enregistrements au processeur d' enregistrements associé.
1. Le processeur d'enregistrements regroupe les données, crée un fichier Amazon S3 et charge ce fichier dans Amazon S3 avec succès.
1. L'application de travail s'arrête de façon inattendue avant l'arrivée d'un nouveau point de contrôle.
1. L'application, l'application de travail et le processeur d'enregistrements redémarrent.
1. L'application de travail commence maintenant à lire depuis le dernier point de contrôle, ici 10 001.
Donc les enregistrements 10 001 à 20 000 sont utilisés plusieurs fois.
### Faire preuve de résilience face aux nouvelles tentatives des consommateurs
Même si les enregistrements peuvent être traités plusieurs fois, votre application peut vouloir présenter les effets secondaires en indiquant que les enregistrements ont été traités une seule fois (traitement idempotent). Les solutions à ce problème varient en complexité et précision. Si la destination des données finales peut gérer les doubles correctement, nous vous recommandons de vous appuyer sur la destination finale pour effectuer un traitement idempotent. Par exemple, avec [Opensearch](https://www.opensearch.org/), vous pouvez utiliser une combinaison de versionnement et d'unicité IDs pour éviter le traitement dupliqué.
Dans l'exemple de la section précédente, l'application lit en permanence les enregistrements à partir d'un flux, regroupe les enregistrements dans un fichier local et charge ce fichier dans Amazon S3. Comme illustré, les enregistrements 10 001 à 20 000 sont utilisés plusieurs fois, ce qui donne plusieurs fichiers Amazon S3 contenant les mêmes données. Une façon d'atténuer les doubles constatés dans cet exemple est de faire en sorte que l'étape 3 utilise le schéma suivant :
1. Le processeur d'enregistrements utilise un nombre fixe d'enregistrements par fichier Amazon S3, par exemple 5 000.
1. Le nom de fichier utilise le schéma suivant : préfixe Amazon S3, id de partition et `First-Sequence-Num`. Dans ce cas, ce peut être quelque chose comme `sample-shard000001-10001`.
1. Une fois que vous avez chargé le fichier Amazon S3, effectuez un point de contrôle en spécifiant `Last-Sequence-Num`. Dans ce cas, vous effectuez le point de contrôle au numéro d'enregistrement 15 000.
Avec ce schéma, même si les enregistrements sont traités plusieurs fois, le fichier Amazon S3 résultant a le même nom et contient les mêmes données. Les tentatives se traduisent uniquement par l'écriture des mêmes données dans le même fichier plusieurs fois.
Dans le cas d'une opération de repartitionnement, le nombre d'enregistrements laissés dans la partition peut être inférieur au nombre fixe voulu. Dans ce cas, votre méthode `shutdown()` doit vider le fichier dans Amazon S3 et effectuer un point de contrôle sur le dernier numéro de séquence. Le schéma ci-dessus est aussi compatible avec les opérations de repartitionnement.
# Gérez le démarrage, l'arrêt et la régulation
Voici quelques éléments de réflexion supplémentaires à intégrer dans la conception de votre Amazon Kinesis Data Streams.
**Topics**
+ [Producteurs et consommateurs de données en démarrage](#kinesis-record-processor-producer-consumer-coordination)
+ [Arrêter une application Amazon Kinesis Data Streams](#developing-consumers-with-kcl-shutdown)
+ [Limitation de lecture](#kinesis-record-processor-read-throttling)
## Producteurs et consommateurs de données en démarrage
Par défaut, la KCL commence à lire les enregistrements à partir de l'extrémité du flux, là où se trouve le dernier enregistrement ajouté. Dans cette configuration, si une application productrice de données ajoute des enregistrements avant le démarrage des processeurs d'enregistrements, ces enregistrements ne sont pas lus par les processeurs d'enregistrements une fois qu'ils ont démarré.
Pour modifier le comportement des processeurs d'enregistrements afin qu'ils lisent toujours les données à partir du début du flux, définissez la valeur suivante dans le fichier de propriétés de votre application Amazon Kinesis Data Streams :
```
initialPositionInStream = TRIM_HORIZON
```
Par défaut, Amazon Kinesis Data Streams stocke toutes les données pendant 24 heures. Il prend également en charge la conservation étendue jusqu'à 7 jours et la conservation à long terme jusqu'à 365 jours. Ce laps de temps est appelé la *période de conservation*. Si vous définissez la position de début sur `TRIM_HORIZON`, le processeur d'enregistrements démarre par les données les plus anciennes du flux, telles quelles sont définies par la période de conservation. Même avec la valeur `TRIM_HORIZON`, si un processeur d'enregistrements démarre après un délai supérieur à la période de conservation, certains enregistrements du flux ne sont plus disponibles. C'est pourquoi vous devez toujours faire en sorte que les applications grand public lisent à partir du flux et utiliser la CloudWatch métrique `GetRecords.IteratorAgeMilliseconds` pour vérifier que les applications suivent le rythme des données entrantes.
Dans certains scénarios, il peut être très bien pour les processeurs d'enregistrements de manquer les quelques premiers enregistrements du flux. Par exemple, vous pouvez exécuter certains enregistrements initiaux dans le flux pour vérifier que le flux fonctionne end-to-end comme prévu. Après avoir fait cette vérification initiale, démarrez vos applications de travail et commencez à placer des données de production dans le flux.
Pour plus d'informations sur le paramètre `TRIM_HORIZON`, consultez [Utiliser des itérateurs de partitions](developing-consumers-with-sdk.md#kinesis-using-sdk-java-get-data-shard-iterators).
## Arrêter une application Amazon Kinesis Data Streams
Lorsque votre application Amazon Kinesis Data Streams a terminé la tâche qui lui était destinée, vous devez la fermer en arrêtant les instances EC2 sur lesquelles elle est exécutée. Vous pouvez arrêter les instances à l'aide de la [AWS Management Console](https://console.aws.amazon.com//ec2/home) ou de la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/index.html).
Après avoir fermé votre Amazon Kinesis Data Streams, vous devez supprimer le tableau Amazon DynamoDB que la KCL a utilisé pour suivre l'état de l'application.
## Limitation de lecture
Le débit d'un flux est configuré au niveau de la partition. Chaque partition a un débit de lecture allant jusqu'à 5 transactions par seconde pour les lectures, jusqu'à un taux total de lecture de données maximal de 2 Mo par seconde. Si une application (ou un groupe d'applications fonctionnant sur le même flux) tente d'extraire des données à partir d'une partition à une vitesse supérieure ; Kinesis Data Streams limite les opérations Get correspondantes.
Dans une application Amazon Kinesis Data Streams, si un processeur d'enregistrements traite les données plus vite que la limite, comme dans le cas d'un basculement, la limitation se produit. Étant donné que la KCL gère les interactions entre les applications et Kinesis Data Streams, les exceptions de limitation se produisent dans le code KCL plutôt que dans le code d'application. Cependant, comme la KCL consigne ces exceptions, vous les voyez dans les journaux.
Si vous trouvez que votre application est systématiquement limitée, vous devez penser à augmenter le nombre de partitions du flux.