Fonctionnement des tables globales DynamoDB

Les sections suivantes décrivent les concepts et les comportements des tables globales dans Amazon DynamoDB.

Concepts

La fonctionnalité Tables globales de DynamoDB réplique les données des tables entre les régions AWS.

Une table de réplica (ou réplica) est une table DynamoDB unique qui fonctionne comme une partie d’une table globale. Une table globale se compose d’au moins deux réplicas de tables réparties dans différentes régions AWS. Une table globale donnée ne peut avoir qu’une seule table de réplica par région AWS. Toutes les répliques d’une table globale partagent le même nom de table, le même schéma de clé primaire et les mêmes données d’élément.

Quand une application écrit des données dans une réplique d’une région, DynamoDB réplique automatiquement l’écriture aux autres réplicas dans la table globale. Pour en savoir plus sur la mise en route avec des tables globales, consultez Tutoriels : Création de tables globales.

Versions

Deux versions des tables globales DynamoDB sont disponibles : la version 2019.11.21 (actuelle) et la version 2017.11.29 (héritée). Vous devez utiliser la version 2019.11.21 (actuelle) dans la mesure du possible. Les informations contenues dans cette section de documentation concernent la version 2019.11.21 (actuelle). Pour plus d’informations, consultez Détermination de la version d’une table globale.

Disponibilité

Les tables globales contribuent à améliorer la continuité de votre activité en facilitant la mise en œuvre d’une architecture de haute disponibilité multirégionale. Si une charge de travail dans une région AWS vient à être perturbée, vous pouvez déplacer le trafic d’application vers une autre région et effectuer des lectures et écritures vers une table de réplique différente dans la même table globale.

Chaque table de réplica d’une table globale offre la même durabilité et la même disponibilité qu’une table DynamoDB à région unique. Les tables globales offrent un contrat de niveau de service (SLA) avec une disponibilité de 99,999 %, contre 99,99 % pour les tables à région unique.

Modes de cohérence

Lorsque vous créez une table globale, vous pouvez configurer son mode de cohérence. Les tables globales prennent en charge deux modes de cohérence : la cohérence à terme multirégionale (MREC) et la forte cohérence multirégionale (MRSC).

Si vous ne spécifiez pas de mode de cohérence lors de la création d’une table globale, la table globale est définie par défaut sur la cohérence à terme multirégionale (MREC). Une table globale ne peut pas contenir de réplicas configurés avec différents modes de cohérence. Vous ne pouvez pas modifier le mode de cohérence d’une table globale après sa création.

Cohérence à terme multirégionale (MREC)

La cohérence à terme multirégionale (MREC) est le mode de cohérence par défaut pour les tables globales. Les modifications d’éléments dans une réplique de table globale MREC sont répliquées de manière asynchrone sur toutes les autres répliques, généralement en une seconde ou moins. Dans le cas peu probable où une réplique d’une table globale MREC serait isolée ou altérée, toutes les données non encore répliquées dans d’autres régions seront répliquées lorsque la réplique sera saine.

Si le même élément est modifié simultanément dans plusieurs régions, DynamoDB résoudra le conflit en utilisant la modification avec le dernier horodatage interne sur une base par élément, ce que l’on appelle la méthode de résolution des conflits « victoire du dernier auteur ». Un élément finira par converger dans toutes les répliques vers la version créée lors de la dernière écriture.

Les opérations de lecture fortement cohérentes renvoient la dernière version d’un élément si cet élément a été mis à jour pour la dernière fois dans la région où la lecture a eu lieu, mais peuvent renvoyer des données périmées si l’article a été mis à jour pour la dernière fois dans une autre région. Les écritures conditionnelles évaluent l’expression de condition par rapport à la version de l’élément dans la région.

Vous créez une table globale MREC en ajoutant une réplique à une table DynamoDB existante. L’ajout d’un réplica n’a aucun impact sur les performances des tables DynamoDB à région unique ou des réplicas de tables globales existantes. Vous pouvez ajouter des réplicas à une table globale MREC pour augmenter le nombre de régions dans lesquelles les données sont répliquées, ou supprimer des réplicas d’une table globale MREC si elles ne sont plus nécessaires. Une table globale MREC peut comporter un réplica dans n’importe quelle région dans laquelle DynamoDB est disponible, et elle peut comporter autant de réplicas que de régions dans la partition AWS.

Forte cohérence multirégionale (MRSC)

Vous pouvez configurer le mode MRSC (forte cohérence multirégionale) lorsque vous créez une table globale. Les modifications d’éléments dans un réplica de table globale MRSC sont répliquées de manière synchrone dans au moins une autre région avant que l’opération d’écriture ne renvoie une réponse réussie. Lorsque vous convertissez une table à région unique existante en table globale MRSC, vous devez vous assurer que la table est vide jusqu’à ce que la conversion soit terminée afin de garantir une initialisation et une configuration de réplication correctes.

Les opérations de lecture fortement cohérente sur tout réplica MRSC renvoient toujours la dernière version d’un élément. Les écritures conditionnelles évaluent toujours l’expression de condition par rapport à la dernière version d’un élément.

Une opération d’écriture échoue avec une ReplicatedWriteConflictException lorsqu’elle tente de modifier un élément déjà en cours de modification dans une autre région. Les écritures qui échouent avec le ReplicatedWriteConflictException peuvent être relancées. Elles réussissent si l’élément n’est plus modifié dans une autre région.

Vous pouvez configurer une table globale MRSC avec trois réplicas, ou avec deux réplicas et un témoin. Un témoin est un composant d’une table globale MRSC qui contient des données écrites dans des réplicas de tables globales. Il fournit une alternative facultative à un réplica complet tout en prenant en charge l’architecture de disponibilité de la MRSC. Vous ne pouvez pas effectuer d’opérations de lecture ou d’écriture sur un témoin. Un témoin se trouve dans une région différente de celle des deux réplicas.

Lorsque vous créez une table globale MRSC, vous choisissez les régions pour vos répliques et pour le déploiement témoin au moment de la création de la table MRSC. Vous pouvez déterminer si et dans quelle région une table globale MRSC comporte un témoin configuré à partir de la sortie de l’API DescribeTable. Le témoin est détenu et géré par DynamoDB et il n’apparaît pas dans votre compte AWS dans la région dans laquelle il est configuré.

Une table globale MRSC doit être déployée dans exactement trois régions. Vous créez une table globale MRSC en ajoutant un réplica et un témoin, ou deux réplicas à une table DynamoDB existante qui ne contient aucune donnée. Vous ne pouvez pas ajouter de réplicas supplémentaires à une table globale MRSC existante. Vous ne pouvez pas supprimer un seul réplica ou un seul témoin d’une table globale MRSC. Vous pouvez supprimer deux réplicas ou supprimer un réplica et un témoin d’une table globale MRSC, en convertissant le réplica restant en une table DynamoDB à région unique.

Les considérations suivantes s’appliquent aux tables globales MRSC :

Choix d’un mode de cohérence

Le critère clé pour choisir un mode de cohérence multirégional est de savoir si votre application privilégie les écritures à faible latence et les lectures fortement cohérentes, ou privilégie la cohérence globale.

Les tables globales MREC auront des temps d’écriture plus faibles et des latences de lecture fortement cohérentes par rapport aux tables globales MRSC. Les tables globales MREC prennent en charge un objectif de point de reprise (RPO) égal au délai de réplication entre les réplicas, généralement de quelques secondes selon les régions du réplica.

Vous devez utiliser le mode MREC lorsque :

Les tables globales MRSC auront des temps d’écriture plus élevés et des latences de lecture fortement cohérentes par rapport aux tables globales MREC. Les tables MRSC prennent en charge un objectif de point de reprise (RPO) de zéro.

Vous devez utiliser le mode MREC lorsque :

Surveillance des tables globales

Les tables globales configurées pour la cohérence à terme multirégionale (MREC) publient la métrique ReplicationLatency sur CloudWatch. Cette métrique suit le temps écoulé entre le moment où un élément est écrit dans une table de réplicas et celui où il apparaît dans un autre réplica dans la table globale. ReplicationLatency est exprimé en millisecondes et est émis pour chaque paire région source/région de destination dans une table globale.

Les valeurs ReplicationLatency typiques dépendent de la distance entre les régions AWS que vous avez choisies, ainsi que d’autres variables telles que le type de charge de travail et le débit. Par exemple, un réplica source située dans la région USA Ouest (Californie du Nord) (us-west-1) a une ReplicationLatency inférieure dans la région USA Ouest (Oregon) (us-west-2) par rapport à la région Afrique (Le Cap) (af-south-1).

Une valeur croissante pour ReplicationLatency peut indiquer que les mises à jour d’un réplica ne sont pas propagées vers d’autres tables de réplica dans un délai raisonnable. Dans ce cas, vous pouvez rediriger temporairement les activités de lecture et d’écriture de votre application dans une autre région AWS.

Les tables globales configurées pour une forte cohérence multirégionale (MRSC) ne publient aucune métrique ReplicationLatency.

Test d’injection de pannes

Les tables globales MREC s’intègrent à AWS Fault Injection Service (AWS FIS) pour l’exécution d’expériences d’injection de pannes sur les charges de travail de votre table globale. Cela vous permet de tester la réponse de votre application à une simulation d’isolation de région en interrompant la réplication vers et depuis un réplica sélectionné. Pour plus d’informations, consultez la mise en pause de la réplication d’une table globale.

Durée de vie (TTL)

Les tables globales configurées pour le MREC prennent en charge la configuration de la suppression Time To Live (TTL). Les paramètres TTL sont automatiquement synchronisés pour tous les réplicas d’une table globale. Lorsque la TTL supprime un élément d’un réplica dans une région, la suppression est répliquée sur tous les autres réplicas de la table globale. La TTL n’utilise pas de capacité d’écriture. La suppression TTL ne vous est donc pas facturée dans la région où la suppression a eu lieu. Toutefois, vous êtes facturé pour la suppression répliquée dans chaque autre région avec un réplica dans la table globale.

La réplication de suppression TTL utilise de la capacité d’écriture sur les réplicas dans lesquels la suppression est répliquée. Les réplicas configurés pour la capacité allouée peuvent limiter les demandes si la combinaison du débit d’écriture et du débit de suppression TTL est supérieure à la capacité d’écriture allouée.

Les tables globales configurées pour une forte cohérence multirégionale (MRSC) ne prennent pas en charge la configuration de la suppression Time To Live (TTL).

Flux

Les tables globales configurées pour une cohérence à terme entre plusieurs régions (MREC) répliquent les modifications en lisant ces modifications à partir de flux DynamoDB sur une table de réplica et en appliquant cette modification à toutes les autres tables de réplica. Les flux sont donc activés par défaut sur tous les réplicas d’une table globale MREC et ne peuvent pas être désactivé sur ces réplicas. Le processus de réplication MREC peut combiner plusieurs modifications sur une courte période en une seule écriture répliquée, ce qui fait que le flux de chaque réplica contient des enregistrements légèrement différents. Les enregistrements de flux sur les réplicas MREC sont toujours classés par article, mais l’ordre entre les éléments peut différer selon les réplicas.

Les tables globales configurées pour une forte cohérence multirégionale (tables MRSC) n’utilisent pas les flux DynamoDB pour la réplication. Cette fonctionnalité n’est donc pas activée par défaut sur les réplicas MRSC. Vous pouvez activer les flux sur un réplica MRSC. Les enregistrements de flux sur les répliques MRSC sont identiques pour chaque réplica, y compris l’ordre des enregistrements de flux.

Si vous souhaitez écrire une application qui traite les enregistrements de flux pour les modifications survenues dans une région particulière mais pas dans d’autres régions d’une table globale, vous pouvez ajouter un attribut à chaque élément qui définit dans quelle région le changement pour cet élément s’est produit. Vous pouvez utiliser cet attribut pour filtrer les enregistrements de flux en fonction des modifications survenues dans d’autres régions, notamment en utilisant des filtres d’événements Lambda pour n’appeler les fonctions Lambda que pour les modifications dans une région spécifique.

Transactions

Sur une table globale configurée pour MREC, les opérations de transaction DynamoDB ( TransactWriteItems et TransactGetItems) ne sont atomiques que dans la région où l’opération a été invoquée. Les écritures transactionnelles ne sont pas répliquées en tant qu’unité entre les régions, ce qui signifie que seules certaines des écritures d’une transaction peuvent être renvoyées par des opérations de lecture dans d’autres réplicas à un instant dans le passé donné.

Par exemple, si vous avez une table globale avec des réplicas dans les régions USA Est (Ohio) et USA Ouest (Oregon), et que vous réalisez une opération TransactWriteItems dans la région USA Est (Ohio), vous remarquerez peut-être des transactions partiellement incomplètes dans la région USA Ouest (Oregon) lorsque les changements sont répliqués. Les changements seront uniquement répliqués aux autres régions une fois validés dans la région source.

Les tables globales configurées pour une forte cohérence multirégionale (MRSC) ne prennent pas en charge les opérations de transaction et renvoient une erreur si ces opérations sont invoquées sur une réplique MRSC.

Débit de lecture et d’écriture

La réplication consomme de la capacité d’écriture. Les réplicas configurés pour la capacité allouée peuvent limiter les demandes si la combinaison du débit d’écriture et du débit de réplication est supérieure à la capacité d’écriture allouée. La capacité d’écriture en mode à la demande est synchronisée pour tous les réplicas d’une table globale. Les tables globales configurées pour la capacité provisionnée synchronisent les paramètres d’autoscaling entre les réplicas. Le paramètre de capacité d’écriture réellement provisionnée peut varier entre les réplicas en fonction du débit d’écriture utilisé.

Vous pouvez configurer indépendamment les paramètres de capacité de lecture pour chaque réplica dans une table globale. Lors de l’ajout d’un réplica à une table globale, la capacité de lecture de la table source ou du réplica est utilisée comme valeur initiale, sauf si une valeur de remplacement est spécifiée.

Synchronisation des paramètres

Les paramètres des tables globales DynamoDB sont des paramètres de configuration qui contrôlent divers aspects du comportement des tables et de la réplication. Ces paramètres sont gérés via les API du plan de contrôle DynamoDB et peuvent être configurés lors de la création ou de la modification de tables globales. Les tables globales synchronisent automatiquement certains paramètres entre tous les réplicas afin de maintenir la cohérence, tout en offrant une certaine flexibilité pour les optimisations spécifiques aux régions. Comprendre quels paramètres sont synchronisés et comment ils se comportent vous permet de configurer efficacement votre table globale. Les paramètres se répartissent en trois catégories principales en fonction de la façon dont ils sont synchronisés entre les réplicas.

Les paramètres suivants sont toujours synchronisés entre les réplicas d’une table globale :

Les paramètres suivants sont synchronisés entre les réplicas, mais peuvent être remplacés au cas par cas :

Les paramètres suivants ne sont jamais synchronisés entre les réplicas :

Tous les autres paramètres ne sont pas synchronisés entre les réplicas.

DynamoDB Accelerator (DAX)

Les écritures dans des réplicas de tables globales contournent DynamoDB Accelerator (DAX) et mettent directement DynamoDB à jour. Par conséquent, les caches DAX peuvent devenir obsolètes, car les écritures ne mettent pas à jour le cache DAX. Les caches DAX configurés pour les réplicas de tables globales ne seront actualisés que lorsque la TTL du cache expirera.

Considérations relatives à la gestion des tables globales

Vous ne pouvez pas supprimer une table utilisée pour ajouter un nouveau réplica de table globale avant que 24 heures ne se soient écoulées depuis la création du nouveau réplica.

Si vous désactivez une région AWS contenant des réplicas de tables globales, ces réplicas sont définitivement convertis en tables à région unique 20 heures après la désactivation de la région.