Données en streaming

Développer des applications sur AWS

Ricardo Sueiras

Principal Technologist

Principes des données en streaming

 

• Enregistrements traités en continu à l'arrivée.
• Les producteurs écrivent dans un flux.
• Les consommateurs lisent de façon indépendante et en parallèle.
• Absorbe les pics de trafic sans attendre des traitements batch.

De quoi se composent les données en streaming ?

 

• Producteurs : applications qui émettent des enregistrements.
• Flux : tampons durables et ordonnés qui découplent producteurs et consommateurs.
• Consommateurs : applications qui lisent et traitent les enregistrements.
• Stockage et rétention : durée de disponibilité pour relecture.

Shards

 

 

• Les shards sont des unités de débit et de parallélisme.
• Les clés de partition répartissent les enregistrements entre shards.
• L'ordre n'est garanti qu'à l'intérieur d'un shard.
• Les consommateurs utilisent le pointage (« check-pointing ») pour suivre l'avancement et récupérer après panne.

Services AWS gérés pour le streaming de données

• Amazon Kinesis Data Streams.
• Amazon Data Firehose.
• Briques de base pour les applications de données en streaming.

 

Kinesis Data Streams

• Streaming à faible latence.
• Rétention configurable : 24 h (par défaut) jusqu'à 365 jours.
• Flux durables et relectibles.
• Plusieurs consommateurs peuvent lire en parallèle.
• Les développeurs gèrent la mise à l'échelle via les shards.

 

Quand utiliser Kinesis Data Streams

• À choisir quand vous avez besoin d'une latence temps réel.
• Vous devez pouvoir relire les enregistrements.
• Vous avez plusieurs consommateurs indépendants.
• Vous avez besoin de logique de transformation personnalisée.

 

Écrire des enregistrements

 

• Les clés de partition contrôlent le placement et l'ordre dans les shards.
• PutRecords regroupe jusqu'à 500 enregistrements ou 5 Mo par requête.
• Les échecs sont signalés par enregistrement.
• FailedRecordCount aide à identifier les enregistrements en échec.

Consommer des enregistrements : mode classique

 

 

• Les consommateurs interrogent à la demande l'API Kinesis.
• Limites d'écriture : 1 Mo/s ou 1 000 enregistrements/s.
• Limites de lecture : 2 Mo/s ou 5 appels GetRecords/s.

Consommer des enregistrements : point de départ

 

• Les consommateurs indiquent où commencer la lecture dans le flux.
• TRIM_HORIZON : plus ancien enregistrement disponible du shard.
• LATEST : le prochain nouvel enregistrement.
• AT_SEQUENCE_NUMBER ou AFTER_SEQUENCE_NUMBER : à partir d'un numéro de séquence donné.
• AT_TIMESTAMP : à ou après un horodatage spécifié.

Consommer des enregistrements : enhanced fan-out

• Chaque consommateur enregistré dispose de 2 Mo/s dédiés par shard.
• Livraison des enregistrements par push HTTP/2.
• À utiliser quand plusieurs consommateurs indépendants exigent une faible latence.
• Et un débit élevé vers le même flux.

 

Mappage de source d'événements Lambda

• Lambda interroge Kinesis et invoque par lots.
• BatchSize et MaximumBatchingWindow définissent la forme des lots.
• ParallelizationFactor : invocations simultanées par shard.
• BisectBatchOnFunctionError : scinde un lot en échec pour isoler les éléments « poison ».
• ReportBatchItemFailures : évite de relancer les enregistrements déjà réussis.
• OnFailure : envoie les lots non traitables vers une DLQ SQS ou SNS.

 

Data Firehose

• Service géré qui livre les données en streaming vers des destinations.
• Cibles : Amazon S3, Redshift et points de terminaison HTTP.
• Gère la mise en tampon, la conversion de format et les transformations Lambda.
• Latence plus élevée, mise en tampon de quelques secondes à minutes.
• Pas de relecture ni de rétention longue.
• Idéal pour acheminer simplement les données vers une destination.

 

Modèle : hot-cold

 

 

• Le modèle hot-cold combine Data Streams et Data Firehose.
• Data Streams permet le traitement en temps réel côté producteurs.
• Firehose archive les enregistrements de la même source dans S3.

Kinesis vs SQS

 

 

• Utilisez Kinesis pour des flux ordonnés, relectibles, avec plusieurs consommateurs.
• Kinesis convient aux séries temporelles et données ordonnées.
• Utilisez SQS pour la distribution de tâches.

Mise à l'échelle du streaming de données

 

• Les flux de données sont divisés en shards.
• Les clés de partition routent les enregistrements vers un shard précis.
• La même clé aboutit toujours sur le même shard, préservant l'ordre.
• Des clés de partition déséquilibrées créent des shards « chauds ».
• Atténuez avec des clés à forte cardinalité.
• Redimensionnez (reshard) pour augmenter ou réduire l'échelle.

Modes de capacité : provisionné

• Deux modes de capacité sont disponibles.
• Le mode provisionné utilise un nombre fixe de shards, géré manuellement.
• Coût et capacité prévisibles.
• Nécéssite une surveillance pour éviter bridage et surprovisionnement.

 

Modes de capacité : à la demande

• Le mode à la demande s'adapte automatiquement au trafic.
• Aucun gestion manuelle des shards.
• Simplifie l'exploitation pour des charges imprévisibles.
• Coût plus élevé en cas de trafic soutenu.

 

Kinesis Producer Library (KPL)

• Les bibliothèques AWS simplifient la création de producteurs et consommateurs évolutifs.
• Kinesis Producer Library (KPL) regroupe et agrège les enregistrements.
• Elle compresse aussi les enregistrements et retente en cas d'échec.
• Mise en tampon asynchrone pour maximiser le débit côté producteur.

 

Kinesis Consumer Library (KCL)

 

 

• Kinesis Consumer Library (KCL) gère la coordination des shards.
• Elle gère la location des workers et le pointage.
• L'état est stocké dans une table DynamoDB.
• Les consommateurs utilisent cet état pour savoir où reprendre.

Gestion des échecs : idempotence

 

 

• La livraison Kinesis est « au moins une fois » : des doublons sont possibles.
• Concevez des consommateurs idempotents.
• Dédupliquez via le numéro de séquence ou une clé métier dans DynamoDB.
• Les consommateurs peuvent relire les enregistrements retenus depuis un numéro de séquence ou un horodatage.

Gestion des échecs : erreurs de débit

 

 

• ProvisionedThroughputExceededException signale un bridage.
• Corrigez en augmentant le nombre de shards.
• Améliorez la répartition des clés de partition.
• Réessayez avec backoff.
• Changez de mode de capacité.

• Suivez IncomingBytes et IncomingRecords dans CloudWatch.
• Surveillez WriteProvisionedThroughputExceeded pour détecter le bridage.
• Le retard consommateur survient quand la lecture est plus lente que l'écriture.
• Suivez GetRecords.IteratorAgeMilliseconds : un âge élevé indique un retard.

 

Sécurité

• Chiffrement côté serveur au repos via AWS KMS.
• Chiffrement en transit via TLS.
• Les stratégies IAM contrôlent l'accès.

 

Passons à la pratique !

Développer des applications sur AWS