Flux DynamoDB et tables globales

DynamoDB Streams capture une séquence chronologique des modifications apportées aux éléments d’une table DynamoDB. Chaque fois qu’un élément est créé, mis à jour ou supprimé, DynamoDB écrit un enregistrement de flux décrivant la modification. Les enregistrements de flux sont disponibles pendant 24 heures après leur écriture.

Les flux constituent la base des architectures pilotées par les événements avec DynamoDB. Ils servent notamment à déclencher des fonctions Lambda pour un traitement en temps réel, à tenir un journal d’audit, à répliquer les données vers un autre stockage ou à invalider un cache lorsque les données changent.

Lorsque vous activez un flux, vous choisissez un StreamViewType qui détermine les données contenues dans chaque enregistrement de flux :

• KEYS_ONLY : uniquement les attributs de clé primaire de l’élément modifié
• NEW_IMAGE : l’élément entier tel qu’il apparaît après la modification
• OLD_IMAGE : l’élément entier tel qu’il apparaissait avant la modification
• NEW_AND_OLD_IMAGES : l’état de l’élément avant et après la modification

Choisissez NEW_AND_OLD_IMAGES pour l’audit (afin de voir ce qui a changé), NEW_IMAGE pour la réplication ou la mise à jour du cache, et KEYS_ONLY lorsque vous avez seulement besoin de savoir quel élément a changé et que vous récupérerez séparément son état actuel.

La manière la plus courante de consommer un flux DynamoDB consiste à utiliser AWS Lambda. Lambda interroge le flux et invoque votre fonction avec un lot d’enregistrements de flux. Lambda gère automatiquement l’interrogation, l’enregistrement des points de contrôle et les nouvelles tentatives.

Paramètres de configuration principaux : taille du lot (nombre d’enregistrements par invocation, jusqu’à 10 000), division en cas d’erreur (diviser un lot ayant échoué pour isoler l’enregistrement problématique) et destination en cas d’échec (SQS ou SNS pour les enregistrements impossibles à traiter). Lambda lit chaque fragment en parallèle ; le parallélisme est donc égal au nombre de fragments du flux.

Cas pratiques d’utilisation de DynamoDB Streams pour l’examen SAA-C03 :

• Réplication entre régions : Lambda lit le flux et écrit les modifications dans une table située dans une autre Region (avant l’existence des Global Tables, il s’agissait du modèle standard)
• Invalidation d’ElastiCache : lorsqu’un élément DynamoDB est modifié, Lambda invalide ou met à jour la clé de cache correspondante
• Synchronisation d’un index de recherche : transmettre les modifications des éléments à OpenSearch Service pour permettre la recherche en texte intégral dans les données DynamoDB
• Journalisation d’audit : écrire chaque modification dans S3 ou dans un stockage de conformité à des fins réglementaires
• Microservices pilotés par les événements : déclencher les services en aval lorsque certains éléments sont modifiés

Les Global Tables DynamoDB fournissent une réplication entièrement gérée, multirégion et multimaître. Chaque Region reçoit une copie complète de la table, et toutes les copies peuvent être utilisées simultanément pour les écritures. Les écritures effectuées dans une Region sont répliquées de manière asynchrone vers toutes les autres Regions en environ 1 seconde.

Les Global Tables permettent deux scénarios essentiels : des lectures et écritures à faible latence pour les utilisateurs répartis dans le monde entier (chaque utilisateur écrit et lit depuis la Region la plus proche), ainsi qu’une reprise après sinistre active-active multirégion (l’application continue de fonctionner dans toute Region encore disponible, sans perte de données postérieure à la dernière réplication).

Pour créer une Global Table, vous créez d’abord une table avec DynamoDB Streams activé (NEW_AND_OLD_IMAGES est requis en interne pour les Global Tables). Vous ajoutez ensuite des Regions de réplica. AWS crée une table de réplica dans chaque Region ajoutée et commence à synchroniser les données dans les deux sens.

Les Global Tables (Version 2019.11.21) constituent la norme actuelle et prennent en charge la capacité à la demande ou provisionnée avec mise à l’échelle automatique. Chaque réplica par Region doit avoir le même nom de table. Vous pouvez ajouter ou supprimer des Regions d’une Global Table à tout moment.

Comme les Global Tables permettent des écritures simultanées dans plusieurs Regions, des conflits d’écriture peuvent survenir lorsque deux Regions mettent à jour le même élément presque au même moment. DynamoDB résout les conflits selon une approche du dernier écrivain gagnant, basée sur les horodatages enregistrés dans les enregistrements de flux.

En pratique, deux mises à jour conflictuelles presque simultanées aboutissent à la conservation de l’une et au remplacement de l’autre. Les applications doivent être conçues de manière à éviter les écritures concurrentes sur un même élément depuis différentes Regions. Lorsque les conflits sont fréquents, envisagez d’acheminer toutes les écritures concernant un utilisateur ou une entité donnée vers une seule Region principale.

Avec les Global Tables, les écritures effectuées dans une Region sont automatiquement répliquées vers toutes les autres Regions. Chaque écriture répliquée consomme des unités de capacité d’écriture dans les Regions de destination ; si vous avez 3 Regions, une seule écriture coûte environ 3 fois les unités de capacité d’écriture au total. Planifiez la capacité en conséquence.

Les lectures dans chaque Region consomment les unités de capacité de lecture du réplica local. Les lectures à cohérence éventuelle (valeur par défaut) utilisent les données locales, tandis que les lectures fortement cohérentes ne sont pas prises en charge entre les Regions. Pour la plupart des applications mondiales, une cohérence éventuelle entre les Regions, dans un délai d’environ 1 seconde, est acceptable.

Une distinction importante pour l’examen SAA-C03 : les Global Tables DynamoDB sont multimaîtres (toutes les Regions acceptent les lectures ET les écritures), tandis que les réplicas en lecture interrégionaux RDS sont en lecture seule (vous pouvez uniquement promouvoir un réplica pour le rendre accessible en écriture, ce qui interrompt la réplication).

Utilisez les Global Tables DynamoDB lorsque vous avez besoin d’écritures actives-actives multirégion, d’un accès mondial inférieur à 100 ms ou d’une reprise après sinistre multirégion avec un RPO nul pour des données NoSQL. Utilisez les réplicas interrégionaux RDS lorsque vous avez besoin d’une capacité de lecture mondiale pour une base de données relationnelle ou d’un serveur de secours de reprise après sinistre que vous pouvez promouvoir en cas de basculement.

Modèles d’architecture courants combinant Streams et Lambda :

• Distribution en éventail : Lambda lit le flux et publie les données dans SNS, qui les distribue à plusieurs files SQS pour des consommateurs indépendants
• Agrégation : Lambda accumule les modifications et met à jour les totaux agrégés dans une table DynamoDB distincte (par exemple, le nombre quotidien de commandes)
• Cache à écriture différée : à chaque événement du flux, Lambda met à jour ElastiCache afin que les lectures puissent être servies depuis le cache
• Notification : le flux déclenche Lambda, qui envoie un e-mail SES ou une notification push SNS lorsqu’une condition donnée change

Comme alternative à DynamoDB Streams, vous pouvez diriger les modifications au niveau des éléments vers un flux de données Amazon Kinesis. Cette solution est utile lorsque vous avez besoin d'une conservation plus longue (jusqu'à 1 an, contre 24 heures pour DynamoDB Streams natif), de davantage de consommateurs ou d'une intégration avec des services qui lisent les données depuis Kinesis.

L'intégration à Kinesis Data Streams est activée table par table et ne remplace pas DynamoDB Streams : vous pouvez activer les deux simultanément. Il s'agit d'une fonctionnalité plus récente (2021) qui étend le pipeline d'événements de modification de DynamoDB sans nécessiter de logique de réplication personnalisée.

Évaluez votre compréhension des concepts AWS d'architecte de solutions (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : DynamoDB Streams capture les modifications au niveau des éléments pendant 24 heures et s'intègre à Lambda pour un traitement piloté par les événements ; Global Tables assure une réplication multimaître et multirégion avec une résolution des conflits selon la règle du dernier écrit ; et l'intégration à Kinesis Data Streams prolonge la conservation au-delà de la fenêtre de flux de 24 heures. Nous allons maintenant découvrir les zones hosted de Route 53 et les types d'enregistrements DNS.