Kinesis Data Streams pour le traitement d’événements en temps réel

Kinesis Data Streams (KDS) est un service durable et ordonné de diffusion de données en temps réel. Les données sont organisées dans un flux composé d'une ou plusieurs partitions. Chaque partition est une séquence ordonnée d'enregistrements de données. Les producteurs placent les enregistrements dans les partitions à l'aide d'une clé de partition qui détermine quelle partition reçoit l'enregistrement. Les consommateurs lisent les enregistrements des partitions et les traitent dans l'ordre de leur arrivée au sein de chaque partition.

Chaque partition prend en charge un débit d'écriture de 1 MB/s ou 1 000 enregistrements/s et un débit de lecture de 2 MB/s (partagé entre tous les consommateurs standard de cette partition). La capacité totale du flux évolue linéairement avec le nombre de partitions. Utilisez la formule suivante : shards_needed = max(write_MB_per_s / 1, read_MB_per_s / 2). Si les producteurs atteignent la limite d'écriture, des erreurs ProvisionedThroughputExceededException apparaissent : résolvez le problème en divisant les partitions ou en répartissant les clés de partition plus uniformément.

La clé de partition est une chaîne que Kinesis hache (MD5) pour déterminer quelle partition reçoit un enregistrement. Une clé de partition bien choisie répartit uniformément les enregistrements entre les partitions (prévention des partitions saturées). Pour l'IoT, utilisez l'ID de l'appareil. Pour les flux de clics, utilisez l'ID de session ou l'ID utilisateur. Évitez les clés à faible cardinalité (par exemple, le nom du pays avec seulement 5 valeurs), car elles provoquent des partitions saturées : une partition reçoit une part disproportionnée du trafic d'écriture tandis que les autres restent inactives.

Les consommateurs standard se partagent le débit de lecture de 2 MB/s par partition à l'aide de GetRecords et d'interrogations périodiques. Si vous avez 3 consommateurs sur une partition et que chacun nécessite 2 MB/s, ils seront limités et devront se partager un total de 2 MB/s. Enhanced Fan-Out (EFO) fournit à chaque consommateur enregistré son propre canal de lecture dédié de 2 MB/s au moyen d'une connexion persistante HTTP/2 avec transmission en continu (SubscribeToShard). EFO entraîne un coût par consommateur et par heure de partition, mais élimine entièrement la concurrence en lecture.

Lambda s'intègre nativement à Kinesis Data Streams grâce à un mappage de source d'événements. Lambda interroge le flux, lit des lots d'enregistrements et invoque votre fonction. Configurez BatchSize (1 à 10 000 enregistrements), StartingPosition (TRIM_HORIZON pour les plus anciens, LATEST pour les plus récents) et BisectBatchOnFunctionError pour diviser les lots ayant échoué. Le facteur de parallélisation (1 à 10) permet à Lambda de lancer plusieurs invocations simultanées par partition afin de suivre les flux rapides.

La Kinesis Client Library (KCL) est un framework applicatif permettant de créer des consommateurs Kinesis Java robustes (ou multilingues via MultiLangDaemon). KCL gère l'énumération des partitions, la gestion des baux (répartition des partitions entre les instances Worker), l'enregistrement des points de contrôle de la progression dans DynamoDB, ainsi que les divisions et fusions progressives des partitions. Chaque Worker KCL traite une ou plusieurs partitions, et KCL rééquilibre automatiquement les partitions lorsque les Workers sont ajoutés ou tombent en panne. KCL est préférable aux interrogations brutes du SDK pour les applications de consommation en production.

Kinesis Data Streams stocke les enregistrements pendant 24 heures par défaut (durée extensible à 7 jours ou jusqu'à 365 jours avec la conservation à long terme, moyennant un coût supplémentaire). Contrairement à SQS, les enregistrements consommés ne sont pas supprimés après leur consommation : ils restent disponibles jusqu'à l'expiration de la durée de conservation. Cela permet à plusieurs consommateurs de lire indépendamment les mêmes enregistrements et autorise le rejeu en réinitialisant le point de contrôle d'un consommateur sur un numéro de séquence antérieur, ce qui est particulièrement utile pour corriger des bogues ou alimenter de nouveaux services avec des données historiques.

Kinesis Data Streams prend en charge deux modes de capacité. Mode Provisioned : vous gérez manuellement le nombre de partitions et payez par partition-heure. Mode ON_DEMAND : Kinesis ajuste automatiquement la capacité des partitions en fonction du débit entrant (jusqu'à 200 MB/s en écriture et 400 MB/s en lecture par défaut), et vous payez par GB de données écrites et récupérées. Le mode à la demande est idéal pour les modèles de trafic variables ou imprévisibles lorsque vous ne souhaitez pas gérer la mise à l'échelle des partitions.

Kinesis garantit l'ordre au sein d'une partition : les enregistrements ayant la même clé de partition vont toujours dans la même partition et sont lus dans l'ordre où ils ont été écrits. En revanche, aucun ordre n'est garanti entre les partitions. Si votre application nécessite un ordre global pour tous les enregistrements, utilisez une seule partition (ce qui limite le débit à 1 MB/s) ou repensez votre conception afin que l'ordre ne soit nécessaire qu'au sein d'un groupe de clés de partition (par exemple, un ordre par appareil). Il s'agit d'une distinction fréquente à l'examen par rapport à SQS FIFO, qui fournit une déduplication et un ordre stricts.

Kinesis Data Streams chiffre les enregistrements côté serveur au repos à l'aide de AWS KMS (CMK ou clé gérée par AWS) lorsque le chiffrement côté serveur est activé. Toutes les données en transit sont chiffrées avec TLS. Pour les applications exécutées dans un VPC qui ne doivent pas envoyer les données du flux sur Internet public, utilisez un point de terminaison d'interface VPC (PrivateLink) pour Kinesis afin que le trafic reste entièrement au sein du réseau fédérateur AWS, ce qui est important pour les charges de travail réglementées.

Pour l'examen SAA-C03, comparez Kinesis Data Streams aux solutions alternatives. Kinesis par rapport à SQS : Kinesis préserve l'ordre au sein d'une partition et prend en charge plusieurs consommateurs lisant les mêmes données ; SQS supprime les messages après leur consommation. Kinesis par rapport à MSK (Kafka) : MSK est Apache Kafka géré : utilisez-le lorsque vous avez besoin de la compatibilité avec le protocole Kafka, de configurations avancées de rubriques ou que vous migrez depuis Kafka sur site. Utilisez Kinesis pour une diffusion propre à AWS, avec une intégration plus étroite à Lambda, Firehose et Flink. Choisissez Kinesis, sauf si la question mentionne spécifiquement Kafka ou des exigences de compatibilité avec Kafka.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que Kinesis Data Streams fournit des flux partitionnés, ordonnés et durables, avec une conservation par défaut de 24 heures et une capacité de rejeu, que Enhanced Fan-Out fournit à chaque consommateur un débit dédié de 2 MB/s par partition, éliminant ainsi la concurrence en lecture, et que le mode ON_DEMAND met automatiquement les partitions à l'échelle pour les trafics imprévisibles. Nous allons maintenant découvrir les modèles de chorégraphie et d'orchestration dans une architecture orientée événements.