Vue d'ensemble des tableaux globaux

Faits importants

• Il existe deux versions des tables globales : la version 2017.11.29 (ancienne) (parfois appelée v1) et la version 2019.11.21 (actuelle) (parfois appelée v2). Ce guide se concentre exclusivement sur la version actuelle.

• DynamoDB (sans tables globales) est un service régional, ce qui signifie qu'il est hautement disponible et intrinsèquement résilient aux défaillances de l'infrastructure, notamment à la défaillance d'une zone de disponibilité complète. Une table DynamoDB à région unique est conçue pour garantir une disponibilité de 99,99 %. Pour plus d'informations, consultez le contrat de niveau de service (SLA) DynamoDB.

• Une table globale DynamoDB réplique ses données entre deux régions ou plus. Une table DynamoDB multirégionale est conçue pour garantir une disponibilité de 99,999 %. Grâce à une planification appropriée, les tables globales peuvent aider à créer une architecture résiliente aux défaillances régionales.

• DynamoDB ne possède pas de point de terminaison global. Toutes les demandes sont adressées à un point de terminaison régional qui accède à l'instance de table globale locale à cette région.

• Les appels à DynamoDB ne doivent pas passer d'une région à l'autre. La meilleure pratique consiste à ce qu'une application hébergée dans une région accède directement uniquement au point de terminaison DynamoDB local de sa région. Si des problèmes sont détectés dans une région (dans la couche DynamoDB ou dans la pile environnante), le trafic de l'utilisateur final doit être acheminé vers un autre point de terminaison d'application hébergé dans une autre région. Les tables globales garantissent que l'application hébergée dans chaque région a accès aux mêmes données.

Modes de cohérence

Lorsque vous créez une table globale, vous configurez son mode de cohérence. Les tableaux globaux prennent en charge deux modes de cohérence : la cohérence finale multirégionale (MREC) et la cohérence forte multirégionale (MRSC), qui a été introduit en juin 2025.

Si vous ne spécifiez pas de mode de cohérence lorsque vous créez une table globale, la table globale prend par défaut la valeur MREC. Une table globale ne peut pas contenir de répliques configurées 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.

Informations clés sur le MREC

• Les tables globales qui utilisent MREC utilisent un modèle de réplication actif-actif. Du point de vue de DynamoDB, la table de chaque région dispose du même statut pour accepter les demandes de lecture et d'écriture. Après avoir reçu une demande d'écriture, la table de réplication locale réplique l'opération d'écriture dans les autres régions distantes participantes en arrière-plan.

• Les éléments sont répliqués individuellement. Les éléments mis à jour au cours d'une seule transaction risquent de ne pas être répliqués ensemble.

• Chaque partition de table de la région source réplique ses opérations d'écriture en parallèle avec toutes les autres partitions. La séquence des opérations d'écriture dans une région distante peut ne pas correspondre à la séquence des opérations d'écriture effectuées dans la région source. Pour plus d'informations sur les partitions de table, consultez le billet de blog Mise à l'échelle de DynamoDB : comment les partitions, les touches de raccourci et les divisions de chaleur ont un impact sur les performances.

• Un élément nouvellement écrit est généralement propagé à toutes les tables de réplica en une seconde. Les régions voisines ont tendance à se propager plus rapidement.

• Amazon CloudWatch fournit une ReplicationLatency métrique pour chaque paire de régions. Il est calculé en examinant les articles qui arrivent, en comparant leur heure d'arrivée avec leur heure d'écriture initiale et en calculant une moyenne. Les horaires sont enregistrés CloudWatch dans la région source. L'affichage des durées moyennes et maximales peut être utile pour déterminer le délai de réplication moyen et le plus défavorable. Il n'existe aucun SLA sur cette latence.

• Si un élément individuel est mis à jour à peu près au même moment (dans cette ReplicationLatency fenêtre) dans deux régions différentes et que la deuxième opération d'écriture a lieu avant que la première opération d'écriture ne soit répliquée, il existe un risque de conflit d'écriture. Les tables globales qui utilisent le MREC résolvent ces conflits en utilisant un mécanisme de victoire du dernier écrivain, basé sur l'horodatage des opérations d'écriture. La première opération « perd » face à la seconde opération. Ces conflits ne sont pas enregistrés dans CloudWatch ou AWS CloudTrail.

• Chaque élément possède un horodatage de la dernière écriture conservé en tant que propriété système privée. L'approche « last writer wins » est mise en œuvre en utilisant une opération d'écriture conditionnelle qui exige que l'horodatage de l'élément entrant soit supérieur à l'horodatage de l'élément existant.

• Un tableau global reproduit tous les articles dans toutes les régions participantes. Si vous souhaitez avoir des étendues de réplication différentes, vous pouvez créer plusieurs tables globales et attribuer à chaque table différentes régions participantes.

• La région locale accepte les opérations d'écriture même si la région de réplication est hors ligne ou ReplicationLatency s'agrandit. La table locale continue de tenter de répliquer les éléments vers la table distante jusqu'à ce que chaque élément réussisse.

• Dans le cas peu probable où une région serait complètement déconnectée, toutes les réplications sortantes et entrantes en attente seront réessayées lorsqu'elle se reconnectera ultérieurement. Aucune action particulière n'est requise pour rétablir la synchronisation des tables. Le mécanisme du dernier rédacteur gagnant garantit que les données deviennent finalement cohérentes.

• Vous pouvez ajouter une nouvelle région à une table MREC DynamoDB à tout moment. DynamoDB gère la synchronisation initiale et la réplication continue. Vous pouvez également supprimer une région (même la région d'origine), ce qui supprimera la table locale de cette région.

Faits saillants sur le MRSC

• Les tables globales qui utilisent le MRSC utilisent également un modèle de réplication actif-actif. Du point de vue de DynamoDB, la table de chaque région dispose du même statut pour accepter les demandes de lecture et d'écriture. Les modifications d'éléments dans une réplique 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.

• Les opérations de lecture très cohérentes sur toute réplique MRSC renvoient toujours la dernière version d'un article. Les opérations d'écriture conditionnelle évaluent toujours l'expression de condition par rapport à la dernière version d'un élément. Les mises à jour s'appliquent toujours à la dernière version d'un élément.

• À terme, les opérations de lecture cohérentes sur une réplique MRSC peuvent ne pas inclure les modifications récemment survenues dans une autre région, et peuvent même ne pas inclure les modifications survenues très récemment dans la même région.

• Une opération d'écriture échoue avec une ReplicatedWriteConflictException exception lorsqu'elle tente de modifier un élément déjà en cours de modification dans une autre région. Les opérations d'écriture qui échouent, ReplicatedWriteConflictException sauf exception, peuvent être réessayées et seront couronnées de succès si l'élément n'est plus modifié dans une autre région.

• Avec MRSC, les latences sont plus élevées pour les opérations d'écriture et pour les opérations de lecture très cohérentes. Ces opérations nécessitent une communication interrégionale. Cette communication a tendance à ajouter une latence qui augmente en fonction de la latence aller-retour entre la région à laquelle on accède et la région la plus proche qui participe au tableau global. (Pour plus d'informations, consultez la présentation AWS re:Invent 2024, Multi-Region strong consistency with Amazon DynamoDB global tables.) Au final, les opérations de lecture cohérentes ne subissent aucune latence supplémentaire. Il existe un outil de test open source qui vous permet de calculer expérimentalement ces latences avec vos régions.

• Les éléments sont répliqués individuellement. Les tables globales qui utilisent MRSC ne prennent pas en charge la transaction. APIs

• Une table globale MRSC doit être déployée dans exactement trois régions. Vous pouvez configurer une table globale MRSC avec trois répliques ou avec deux répliques et un témoin. Un témoin est un composant d'une table globale MRSC qui contient des données récentes écrites dans des répliques de tables globales. Un témoin fournit une alternative optionnelle à une réplique complète tout en prenant en charge l'architecture de disponibilité du MRSC. Vous ne pouvez pas effectuer d'opérations de lecture ou d'écriture sur un témoin. Le témoin n'a pas à payer de frais de stockage ou d'écriture. Un témoin se trouve dans une région différente de celle des deux répliques.

• Pour créer une table globale MRSC, vous ajoutez une réplique et un témoin, ou vous ajoutez deux répliques à une table DynamoDB existante qui ne contient aucune donnée. Vous ne pouvez pas ajouter de répliques supplémentaires à une table globale MRSC existante. Vous ne pouvez pas supprimer une seule réplique ou un seul témoin d'une table globale MRSC. Vous pouvez supprimer deux répliques, ou supprimer une réplique et un témoin, d'une table globale MRSC. Le second scénario convertit le réplica restant en une table DynamoDB à région unique.

• Vous pouvez déterminer si un témoin est configuré dans une table globale MRSC, et dans quelle région elle est configurée, à partir de la sortie de l'DescribeTableAPI. Le témoin est détenu et géré par DynamoDB et n'apparaît pas dans Compte AWS votre région dans laquelle il est configuré.

• Les tableaux globaux du MRSC sont disponibles dans les ensembles de régions suivants :

  • Ensemble de régions des États-Unis : USA Est (Virginie du Nord), USA Est (Ohio), USA Ouest (Oregon)

  • Ensemble de régions de l'UE : Europe (Irlande), Europe (Londres), Europe (Paris), Europe (Francfort)

  • Ensemble de régions AP : Asie-Pacifique (Tokyo), Asie-Pacifique (Séoul) et Asie-Pacifique (Osaka)

• Les tables globales MRSC ne peuvent pas couvrir des ensembles de régions. Par exemple, une table globale MRSC ne peut pas contenir de répliques provenant à la fois d'ensembles régionaux des États-Unis et de l'UE.

• Le temps de vie (TTL) n'est pas pris en charge pour les tables globales MRSC.

• Les index secondaires locaux (LSIs) ne sont pas pris en charge pour les tables globales MRSC.

• CloudWatch Les informations de Contributor Insights ne sont communiquées que pour la région dans laquelle une opération a eu lieu.

• La région locale accepte toutes les opérations de lecture et d'écriture tant qu'une deuxième région hébergeant une réplique ou un témoin est disponible pour établir le quorum. Si aucune deuxième région n'est disponible, la région locale ne peut proposer que des lectures cohérentes à terme.

• Dans le cas peu probable où une région serait complètement déconnectée, elle rattrapera automatiquement son retard lorsqu'elle reviendra en ligne ultérieurement. Jusqu'à ce que le problème soit rattrapé, les opérations d'écriture et les opérations de lecture très cohérentes renverront des erreurs. Cependant, des opérations de lecture cohérentes finiront par renvoyer les données qui ont été propagées jusqu'à présent dans la région, avec le comportement de cohérence local habituel entre le nœud principal et les répliques locales. Aucune action spéciale n'est requise pour rétablir la synchronisation des tables

Cas d’utilisation

Les tables globales MREC offrent les avantages suivants :

• Opérations de lecture à faible latence. Vous pouvez placer une copie des données plus près de l'utilisateur final afin de réduire la latence du réseau pendant les opérations de lecture. Les données sont conservées aussi fraîches que la ReplicationLatency valeur.

• Opérations d'écriture à faible latence. Un utilisateur final peut écrire dans une région voisine afin de réduire la latence du réseau et le temps nécessaire pour terminer l'opération d'écriture. Le trafic d'écriture doit être soigneusement acheminé pour éviter tout conflit. Les techniques de routage sont abordées dans une section ultérieure.

• Migration fluide entre les régions. Vous pouvez ajouter une nouvelle région, puis supprimer l'ancienne région pour migrer un déploiement d'une région à l'autre, sans aucune interruption de la couche de données.

Les tables mondiales MREC et MRSC offrent tous deux cet avantage :

• Résilience et reprise après sinistre accrues. Si une région présente une dégradation des performances ou une panne complète, vous pouvez l'évacuer (c'est-à-dire supprimer certaines ou toutes les demandes destinées à cette région). L'utilisation de tables globales augmente le SLA DynamoDB pour le pourcentage de disponibilité mensuelle de 99,99 % à 99,999 %. L'utilisation du MREC prend en charge un objectif de point de récupération (RPO) et un objectif de temps de restauration (RTO) mesurés en secondes. L'utilisation de MRSC permet un RPO de zéro.

  Par exemple, Fidelity Investments a présenté à re:Invent 2022 la façon dont elle utilise les tables globales DynamoDB pour son système de gestion des commandes. Leur objectif était d'obtenir un traitement fiable à faible latence à une échelle impossible à atteindre avec un traitement sur site, tout en préservant la résilience face aux défaillances des zones de disponibilité et des défaillances régionales.

Si votre objectif est la résilience et la reprise après sinistre, les tables MRSC présentent des latences d'écriture plus élevées et des latences de lecture fortement cohérentes plus élevées, mais supportent un RPO nul. Les tables globales MREC prennent en charge un RPO égal au délai de réplication entre les répliques, généralement quelques secondes selon les régions de réplication. Pour plus d'informations, consultez la section Modes de cohérence dans la documentation DynamoDB.