DynamoDB Global Tables

Une global table est une unique table DynamoDB répliquée dans plusieurs régions AWS, où chaque réplica est inscriptible. DynamoDB les maintient synchronisées automatiquement — tu obtiens des lectures et écritures locales à faible latence dans chaque région, plus une reprise après sinistre inter-régions, sans gérer ta propre réplication.

Dans le scénario du journal d'audit, un client de l'UE exige que ses données vivent dans eu-west-1, tandis que le reste tourne dans us-east-1. Et en tant que journal critique pour la conformité, il doit survivre à une panne régionale complète. Une global table répond aux deux avec une seule fonctionnalité.

Que sont les DynamoDB Global Tables ?

Les DynamoDB Global Tables sont une unique table répliquée dans plusieurs régions AWS, où chaque réplica est lisible et inscriptible. DynamoDB les synchronise automatiquement via une réplication asynchrone en cohérence à terme, en résolvant les conflits en last-writer-wins. Tu obtiens des lectures et écritures locales à faible latence par région, plus une reprise après sinistre inter-régions, ce qui soutient le SLA de disponibilité de 99,999 % de DynamoDB.

• Multi-régions, active-active. Chaque réplica est entièrement lisible et inscriptible ; les écritures dans n'importe quelle région se propagent aux autres.
• La réplication est asynchrone et en cohérence à terme entre régions — généralement en moins d'une seconde, mais pas instantanée.
• Les conflits se résolvent en last-writer-wins. Des écritures concurrentes sur le même item dans deux régions se réconcilient vers la plus récente.
• Elle soutient le SLA de disponibilité de 99,999 % — une global table multi-régions est la configuration la plus disponible de DynamoDB.

Le problème : une seule région ne suffit pas

Une table mono-région a deux limites que le journal d'audit ne peut pas accepter. D'abord, la résidence des données : les événements d'un client de l'UE doivent être stockés dans l'UE, mais ton app tourne aux États-Unis. Ensuite, la reprise après sinistre : si us-east-1 a une panne, un journal d'audit mono-région est illisible et inscriptible pendant toute la durée — exactement au moment où tu as le plus besoin de l'enregistrement de ce qui s'est passé.

Construire l'un ou l'autre toi-même — réplication inter-régions, basculement, gestion des conflits — est un projet ambitieux et propice aux erreurs. Les global tables en font un choix de configuration.

Comment fonctionnent les global tables

Tu ajoutes une région réplica à la table ; DynamoDB y crée une copie et maintient tous les réplicas synchronisés. D'après les FAQ DynamoDB d'AWS, les global tables fournissent une réplication multi-régions avec jusqu'à 99,999 % de disponibilité, et le réplica de chaque région sert les lectures et écritures locales.

Deux règles de cohérence définissent le comportement :

• La réplication inter-régions est asynchrone. Une écriture dans us-east-1 est acquittée localement, puis propagée vers eu-west-1 — généralement en moins d'une seconde, mais une lecture dans l'autre région juste après une écriture peut ne pas encore la voir. (Les lectures fortement cohérentes fonctionnent toujours, mais uniquement au sein d'une même région.)
• Les conflits sont en last-writer-wins. Si le même item est écrit dans deux régions presque en même temps, DynamoDB conserve l'écriture au timestamp le plus récent et écarte l'autre.

Un exemple concret : un réplica UE qui sert aussi de DR

Tu ajoutes eu-west-1 comme réplica de la table audit-log. Maintenant :

L'app du client de l'UE écrit et lit depuis le réplica local eu-west-1 — faible latence et données résidentes en région. La même réplication qui satisfait la résidence fait aussi office de reprise après sinistre : si us-east-1 tombe, le réplica eu-west-1 détient toujours le journal complet et sert le trafic ; tu bascules dessus.

Parce que le journal d'audit est append-only et partitionné par tenant, le last-writer-wins n'est essentiellement pas un problème ici — les événements d'un tenant donné sont écrits depuis une seule région et les clés d'événement sont uniques, donc deux régions sont rarement en concurrence sur le même item. Ce n'est pas de la chance ; c'est pourquoi un journal append-only est l'un des cas les plus propres pour les global tables. Un compteur mutable, à l'inverse, demanderait de la prudence sous écritures concurrentes inter-régions.

Fais-le dans DynoTable

Après avoir ajouté un réplica, tu veux confirmer que les données ont bien atterri dans la nouvelle région et correspondent à la source — que le réplica UE détient vraiment les événements d'acme, avec les bons attributs, et n'est pas en retard.

DynoTable se connecte à n'importe quelle région avec ses propres identifiants, donc tu peux pointer une fenêtre sur us-east-1 et une autre sur eu-west-1 et comparer les items du même tenant côte à côte pour vérifier la réplication.

Tu peux prototyper les requêtes par région que tu lanceras contre chaque réplica dans le DynamoDB Expression Builder.

Pièges et étapes suivantes

• Ne lis pas ta propre écriture entre régions. Le délai de réplication signifie qu'une écriture dans une région peut ne pas apparaître dans une autre avant ~une seconde. N'écris pas aux US pour lire immédiatement depuis l'UE en t'attendant à la voir ; la cohérence forte est uniquement mono-région.
• Le last-writer-wins perd des données silencieusement. Pour des items mutables écrits concurremment dans deux régions, le perdant est écarté sans erreur. Les conceptions append-only ou single-writer-per-item (comme ce journal d'audit) évitent le problème ; un état mutable partagé nécessite une conception consciente des conflits.
• Chaque réplica coûte. Chaque région stocke une copie complète et facture sa propre capacité et son propre stockage — un réplica double grosso modo le coût. Ajoute des régions pour un vrai besoin de résidence ou de DR, pas par défaut.
• Les sauvegardes sont par réplica. Une global table restaurée devient une table indépendante — planifie la récupération par région. Voir sauvegarde et restauration à un instant donné.

Les global tables protègent contre la perte d'une région. La dernière préoccupation opérationnelle est de protéger contre la perte de données — un mauvais déploiement ou une suppression accidentelle — avec la sauvegarde et la restauration à un instant donné.

Télécharge DynoTable pour te connecter à plusieurs régions et vérifier que tes réplicas de global table détiennent les mêmes données.