Utiliser et optimiser AWS Lambda en tant que consommateur pour Amazon Kinesis Data Stream

Beaucoup d’organisations analysent les flux de données issues des clicks générés en temps réel par les utilisateurs de leurs applications pour générer de nouvelles opportunités et identifier des incidents au fil de l’eau. Une pratique commune est de consolider et d’enrichir les journaux d’activités des applications et serveurs en temps réel pour proactivement identifier et résoudre des scénarios d’échecs et réduire significativement les temps d’arrêt. L’internet des objets ou IoT est aussi de plus en plus adopté afin de viabiliser l’analyse en temps réel dans des différents cas d’usage. Par exemple : des usines connectées, des voiture connectées, et des espaces intelligents, qui utilisent l’IoT pour pour permettre un partage d’informations sans friction entre les personnes, machines et capteurs.

Grâce à AWS Lambda et son intégration native avec Amazon Kinesis Data Stream en tant que consommateur, vous pouvez réduire et abstraire la complexité du polling, du checkpointing et de la gestion d’erreurs par rapport aux solutions classiques de consommation des données issues d’un flux de données. Cela permet aux développeurs de votre organisation de se concentrer sur la logique métier du traitement des données.

Cet article décrit comment opérer et optimiser cette intégration pour permettre un niveau de débit élevé, une faible latence de traitement avec un besoin de maintenance faible.

Pour en apprendre plus sur les concepts et la terminologie d’Amazon Kinesis, visitez cette page de documentation.

Vue d’ensemble

Vous pouvez attacher votre fonction AWS Lambda à un flux de données Kinesis pour traiter les données. Plusieurs fonctions AWS Lambda peuvent consommer un même flux de données Kinesis pour différentes tâches de traitement indépendantes. Elles peuvent être utilisées à côté d’autres consommateurs comme Amazon Kinesis Data Firehose.

Si un flux Kinesis a une capacité de ‘n’ partitions, il faudra une simultanéité de ‘n’ pour qu’une fonction AWS Lambda puisse traiter la donnée sans induire de délai. Une simultanéité inférieure à ‘n’ va engendrer un âge élevé de l’itérateur (indicateur de notre retard dans le traitement des enregistrements) dans le flux de données, mais aussi côté consommateur. Dans un système avec de multiples consommateurs, si l’âge de l’itérateur Kinesis connaît un pic, il y aura alors, au moins un consommateur qui reportera lui aussi un âge élevé.

Quand le facteur de parallélisation est plus grand que 1 pour un consommateur AWS Lambda, le traitement de la donnée va se faire en faisant du polling sur un nombre de clés de partition d’une partition égale au facteur de parallélisation. Imaginons que nous sommes dans un cas d’usage IoT, où dans une même partition, nous avons des enregistrements pour 3 objets connectés, avec une clé de partition différente pour chacun. Si nous avons un facteur de parallélisation de 3 nous sommes exactement dans le même cas d’usage que sur le schéma ci-dessus et chaque lambda va consommer une clé de partition donnée, donc, les données pour un seul objet connecté. Pour en apprendre plus, vous pouvez lire comment gérer un trafic avec un facteur de parallélisation.

Métriques au niveau des partitions Kinesis

Lorsque vous utilisez un flux Kinesis, c’est une bonne pratique d’activer la surveillance avancée au niveau des partitions. Ces métriques peuvent aider à détecter si la distribution des données se fait ou non de manière uniforme sur chaque partition.

Dans le cas d’usage avec une seule source et plusieurs consommateurs, la surveillance avancée au niveau des partitions peut aider à identifier la cause d’un âge d’itérateur élevé. Ça peut être dû au fait, qu’une seule partition reçoit les données de façon trop rapide, ou alors qu’un consommateur n’arrive pas à traiter la donnée.

Pour en apprendre plus sur la surveillance de Kinesis, visitez cette page de documentation. Si un traitement par clé de partition n’est pas un prérequis, distribuez la donnée de manière uniforme sur toutes les partitions. Pour en apprendre plus sur les clés de partition Kinesis, visitez cette page de documentation.

Délai dans le traitement causé par problème de configuration d’un consommateur

Kinesis reporte une métrique de l’âge de l’itérateur. Si cette valeur connaît un pic, le traitement de la donnée du stream peut-être retardé. La métrique est alors égale à la différence entre l’heure actuelle et l’heure de la lecture du dernier enregistrement sur une période de temps donnée. Ce délai retarde le pipeline de traitement des données. Cela se produit quand une partition reçoit de la donnée plus rapidement qu’un consommateur ne peut la traiter ou alors qu’il échoue à la traiter dû à des erreurs.

Chaque fonction AWS Lambda va reporter sa propre métrique sur l’âge de son itérateur : dans le cas d’une seule source et plusieurs consommateurs AWS Lambda, nous serons en capacité d’identifier le consommateur avec un pic sur l’âge de son itérateur pour savoir quel consommateur présente du retard.

Changer la configuration pour optimiser l’âge des itérateurs

Il y a plusieurs options de mise au point disponibles lorsque l’âge d’un itérateur augmente pour une fonction AWS Lambda consommant un flux Kinesis.

1. Augmenter la taille des batches

Si la fonction AWS Lambda opère à une durée d’exécution maximum basse, une seule invocation peut traiter un nombre de messages inférieur à la taille des batchs. Vous pouvez augmenter la taille des batches (jusqu’à un maximum de 10,000 enregistrements) pour lire plus d’enregistrements d’une partition en un seul batch. Cela peut aider à normaliser l’âge de l’itérateur.

2. Changer le facteur de parallélisation

Augmenter le facteur de parallélisation d’une fonction AWS Lambda, va permettre à des invocations simultanées de consommer une seule partition. Plusieurs batchs d’enregistrements sont créés sur une partition basés sur les clés de partitions, ce qui va engendrer une accélération de la consommation de la donnée.

L’âge d’un itérateur peut connaître un pic lorsque la taille des batches est de 10,000 enregistrements et que le facteur de parallélisation est à 10. Cela peut se produire lorsque la donnée arrive plus rapidement que ce que le consommateur ne peut traiter, en sauvegardant la donnée par partition/par queues de partition. Pour réduire cet effet, vous pouvez subdiviser cette partition en plusieurs clés de partitions. Ce qui a pour effet comme dans le schéma ci-dessous, d’augmenter la cardinalité des clés de partitionnement et donc de distribuer la donnée de manière plus uniforme à travers plusieurs partitions.

3. Réduire la fenêtre de batch

Si la donnée est distribuée de manière inégale à travers les partitions, ou alors qu’il y a un volume bas d’écriture par les producteurs, le “poller” de la lambda peut attendre un batch entier. Vous pouvez réduire ce temps d’attente en réduisant la taille de la fenêtre de batch, ce qui peut résulter par une accélération du traitement de la donnée. Pour en apprendre plus sur la fenêtre de batch pour le “poller” de Lambda pour Kinesis, vous pouvez aller voir cette page de documentation.

4. Réduire la capacité d’un flux Kinesis s’il est surdimensionné

Si les métriques d’un flux Kinesis indiquent que le flux est surdimensionné, alors réduire sa capacité aide à rééquilibrer l’utilisation des partitions ce qui permet un meilleur débit par invocation de la fonction lambda.

Après la réduction de la capacité du flux, réduisez la concurrence de la lambda pour maintenir un ratio 1:1 par rapport au nombre de partitions et la simultanéité de lambda. Avec l’augmentation de la charge, augmentez le facteur de parallélisation pour garder la taille de la partition constante. Avec cette augmentation, la concurrence de Lambda devrait être au moins égale au nombre de partitions multiplié par le facteur de parallélisation. Pour en apprendre plus sur comment gérer le trafic avec le facteur de parallélisation consulter cette page de documentation.

5. Activer la diffusion améliorée pour vos consommateurs

La diffusion améliorée permet aux développeurs d’augmenter le nombre de consommateurs en offrant à chaque consommateur son propre débit en lecture. Pour en apprendre plus sur la diffusion améliorée, vous pouvez lire cette page de documentation.

Conclusion

Ce blog montre quelques bonnes pratiques pour utiliser AWS Lambda avec Amazon Kinesis. Il couvre les leviers opérationnels pour obtenir un débit plus élevé, une latence faible dans le cadre d’un flux avec une seule de source de données.

L’observation avancée des partitions aide à surveiller l’augmentation du délai de traitement par partition. Lorsque vous le corrélez avec la métrique de l’âge de l’itérateur de la fonction lambda, cela vous montre la performance de chaque consommateur.

La combinaison effective de la taille du batch, du facteur de parallélisation, de la fenêtre de batch et de la clé de partitionnement peut aboutir à un traitement plus efficace du flux.

Pour en apprendre plus sur Amazon Kinesis, visitez cette page.

Article Source rédigé par James Beswick, mis à jour et adapté en français par Kévin Polossat, Solutions Architect au sein des équipes AWS France.