Diffusion de données avec DynamoDB

Développer des applications sur AWS

Ricardo Sueiras

Principal Technologist

Principes des DynamoDB Streams

 

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

Période de rétention

 

• Les enregistrements de flux sont conservés 24 heures.
  • Période fixe, non configurable.
• Changer le type de vue implique 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 contient des métadonnées décrivant le changement.
• Les flux capturent trois types d'événements :
  • INSERT
  • MODIFY
  • REMOVE

 

• Les types de vue déterminent quelles données figurent dans chaque enregistrement.
  • KEYS_ONLY : uniquement 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 la référence pour l'audit.
• Requis pour les tables globales DynamoDB.

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

 

 

• Lambda est le consommateur de flux le plus courant.
• Utilise un mappage de source d'événements basé sur le polling.
• Lit les enregistrements depuis le flux.
• Déclenche votre fonction avec des lots d'enregistrements.

Modèle d'architecture

 

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

Mise à l'échelle

 

• Les flux sont divisés en shards internes.
  • Comme Kinesis Data Streams.
• Chaque shard autorise jusqu'à deux consommateurs simultanés.
  • Dépasser cette limite cause souvent une limitation des lectures.

• La concurrence Lambda s'adapte au nombre de shards.
• Réglez le traitement avec :
  • BatchSize : max d'enregistrements par invocation.
  • MaximumBatchingWindow : attente avant un lot partiel.
  • MaximumRetryAttempts : réessais avant la destination d'échec.
  • MaximumRecordAgeInSeconds : ignorer les enregistrements trop anciens.
  • ParallelizationFactor : traitements concurrents par shard (max 10).

Filtres et fenêtres cadencées

• Lambda prend en charge des filtres.
  • Écartez des enregistrements avant l'invocation.
  • Réduit les appels inutiles et le coût.
• Lambda prend en charge les fenêtres cadencées (tumbling).
  • Agréger l'état sur des lots dans un shard.

 

Gérer les enregistrements en double

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

 

Gérer les é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 « poison » après épuisement des réessais.

Intégration de DynamoDB vers Kinesis

 

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

Surveillance : problèmes courants

 

• Problèmes opérationnels courants à surveiller :
  • Partitions chaudes.
  • Réessais échoués.
  • Traitements en double.
  • Limitations et retard des consommateurs.

Surveillance : métriques CloudWatch

• Principales métriques CloudWatch à surveiller :
  • Lambda Errors : révèle des erreurs de code ou en aval.
  • IteratorAge : valeurs élevées = consommateurs lents.
  • Métriques de limitation : dépassement des limites de lecture.
  • Échecs de traitement de lot : enregistrements envoyés vers une DLQ.

 

Sécurité

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

 

Passons à la pratique !

Développer des applications sur AWS