Diffusion de données avec DynamoDB

Développer des applications sur AWS

Ricardo Sueiras

Principal Technologist

Principes de base de DynamoDB Streams

 

• Réagir aux changements de base de données quasi en temps réel.
• Fondé sur des modèles axés sur les événements.
• Chaque insertion, modification ou suppression génère un enregistrement de flux.
• Créez des applis réactives sans interroger la table.
• Désactivé par défaut : activer avec StreamSpecification.
• Chaque flux a son propre ARN, distinct de l'ARN de la table.

Période de rétention

 

• Les enregistrements de flux sont conservés 24 heures.
  • Rétention fixe et non configurable.
• Changer le type de vue exige de recréer le flux.
  • Un nouveau flux génère un nouvel ARN de flux.

Flux et unités de capacité de lecture DynamoDB

 

• Les lectures de flux NE consomment PAS vos unités de capacité de lecture (RCU).
• Activer les flux n'affecte pas le débit alloué.

Enregistrements de flux

• Chaque enregistrement de flux porte des métadonnées décrivant le changement.
• Les flux saisissent trois types d'événements :
  • INSERT
  • MODIFY
  • REMOVE

 

• Les types de vue contrôlent quelles données figurent dans chaque enregistrement.
  • KEYS_ONLY : seulement la clé de partition et de tri.
  • NEW_IMAGE : l'élément complet après le changement.
  • OLD_IMAGE : l'élément complet avant le changement.
  • NEW_AND_OLD_IMAGES : l'élément avant et après.
• NEW_AND_OLD_IMAGES est l'option privilégiée pour l'audit.
• Requis pour les tables globales DynamoDB.

• Les flux préservent l'ordre par clé de partition.
• Lambda traite les enregistrements en lots.
  • Pointe la progression après chaque lot réussi.
  • Les lots en échec sont réessayés.
  • Les réessais continuent jusqu'au succès ou à l'expiration des enregistrements.

 

 

• Lambda est le consommateur de flux le plus courant.
• Utilise un mappage de source d'événements basé sur l'interrogation.
• Lit les enregistrements du flux.
• Appelle votre fonction avec des lots d'enregistrements.

Modèle d'architecture

 

• Un modèle de bout en bout courant :
  • Une mise à jour d'élément arrive dans DynamoDB.
  • Le changement génère un enregistrement de flux.
  • L'enregistrement déclenche Lambda pour le traitement.

Mise à l'échelle

 

• Les flux sont divisés en fragments internes.
  • À l'instar de Kinesis Data Streams.
• Chaque fragment permet jusqu'à deux consommateurs simultanés.
  • Dépasser cette limite cause souvent un étranglement des lectures.

• La concurrence Lambda évolue avec le nombre de fragments.
• Réglez le traitement avec :
  • BatchSize : nombre max d'enregistrements par appel.
  • MaximumBatchingWindow : attente avant un lot partiel.
  • MaximumRetryAttempts : réessais avant la destination d'échec.
  • MaximumRecordAgeInSeconds : ignorer les enregistrements trop âgés.
  • ParallelizationFactor : traitement parallèle par fragment (max 10).

Filtrage et fenêtres à pas fixe

• Lambda prend en charge des critères de filtrage.
  • Écarte des enregistrements avant l'appel de la fonction.
  • Réduit les appels inutiles et les coûts.
• Lambda prend en charge les fenêtres à pas fixe.
  • Agréger l'état entre les lots d'un fragment.

 

Gérer les enregistrements en double

• Les flux capturent chaque changement exactement une fois.
• Lambda traite avec une sémantique « au moins une fois ».
  • Les réessais peuvent retraiter le même enregistrement.
• Concevez des consommateurs idempotents.
• Modèle courant : stocker eventID ou SequenceNumber traités.
  • Ignorer les enregistrements déjà traités.
  • Les deux restent stables lors des réessais.
  • Clés d'idempotence fiables.

 

Gestion des échecs

 

• ReportBatchItemFailures ne réessaie que les enregistrements en échec.
• Gérer les échecs Lambda avec :
  • BisectBatchOnFunctionError pour bissection de lot.
  • Contrôles de réessai.
  • Destinations d'échec pour les lots « empoisonnés » après épuisement des réessais.

Intégration de DynamoDB à Kinesis

 

• Les tables peuvent pousser les changements directement vers Kinesis Data Streams.
  • Via la fonction Kinesis Data Streams for DynamoDB.
  • Une capacité distincte et parallèle, non en chaîne.
  • Les événements ne passent PAS par DynamoDB Streams.
• Les deux peuvent fonctionner sur la même table en parallèle.
  • Ils opèrent indépendamment.
  • Alimente des architectures de diffusion et d'analytique plus larges.

Surveillance : problèmes courants

 

• Problèmes opérationnels courants à surveiller :
  • Partitions « chaudes ».
  • Réessais échoués.
  • Traitement en double.
  • Étranglement et retard des consommateurs.

Surveillance : indicateurs CloudWatch

• Indicateurs CloudWatch clés à surveiller :
  • Lambda Errors : signale des bogues ou problèmes en aval.
  • IteratorAge : valeurs élevées = consommateurs lents.
  • Indicateurs d'étranglement : dépassement des limites de lecture.
  • Échecs de traitement par lot : enregistrements envoyés à une DLQ.

 

Sécurité

• L'accès aux flux est contrôlé par des autorisations IAM.
• Les flux héritent des paramètres de chiffrement de la table.
  • Y compris le chiffrement côté serveur au repos avec KMS.
• Appliquez des politiques du moindre privilège aux consommateurs et aux processeurs en aval.

 

Passons à la pratique !

Développer des applications sur AWS