DynamoDB Global Tables : la réplication multi-région expliquée

Une table globale est une seule table DynamoDB répliquée sur plusieurs régions AWS, où chaque réplica est accessible en écriture. DynamoDB les garde synchronisées automatiquement — tu obtiens des lectures et des écritures locales à faible latence dans chaque région, plus une reprise après sinistre inter-régions, sans exécuter 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 table globale répond aux deux avec une seule fonctionnalité.

Comment fonctionnent les tables globales DynamoDB ?

Les tables globales DynamoDB sont une seule table répliquée sur plusieurs régions AWS, où chaque réplica est accessible en lecture et en écriture. DynamoDB les synchronise automatiquement via une réplication asynchrone à cohérence à terme, résolvant les conflits par « dernier rédacteur gagne ». Tu obtiens des lectures et des é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 pleinement accessible en lecture et en écriture ; les écritures dans n'importe quelle région se propagent aux autres.
• Dans le mode par défaut, la réplication est asynchrone et à cohérence à terme entre régions — généralement en moins d'une seconde, mais pas instantanée. (Un mode à cohérence forte existe aussi — voir ci-dessous.)
• Les conflits se résolvent par « dernier rédacteur gagne ». Des écritures concurrentes sur le même item dans deux régions se réconcilient sur la plus récente.
• Cela soutient le SLA de disponibilité de 99,999 % — une table globale multi-régions est la configuration la plus disponible de DynamoDB.

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

Une table à région unique a deux limites que le journal d'audit ne peut pas accepter. Premièrement, la résidence des données : les événements d'un client de l'UE doivent être stockés dans l'UE, mais ton application tourne aux États-Unis. Deuxièmement, la reprise après sinistre : si us-east-1 subit une panne, un journal d'audit à région unique est illisible et non modifiable pour toute la durée — exactement quand tu as le plus besoin de l'enregistrement de ce qui s'est passé.

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

Mécanique de la réplication

Tu ajoutes une région réplica à la table ; DynamoDB y crée une copie et garde tous les réplicas synchronisés.

Deux règles de cohérence définissent le comportement par défaut (MREC) :

• La réplication inter-régions est asynchrone. Une écriture dans us-east-1 est accusée réception 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 la voir encore. (Dans le mode MREC par défaut, les lectures fortement cohérentes fonctionnent toujours, mais seulement au sein d'une seule région.)
• Les conflits sont « dernier rédacteur gagne ». Si le même item est écrit dans deux régions à peu près en même temps, DynamoDB conserve l'écriture avec l'horodatage le plus récent et écarte l'autre.

Un exemple travaillé : un réplica UE qui sert aussi de reprise après sinistre

Tu ajoutes eu-west-1 comme réplica de la table du journal d'audit. Maintenant :

L'application du client de l'UE écrit dans 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 sert aussi 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.

Comme le journal d'audit est en ajout seul et partitionné par tenant, le « dernier rédacteur gagne » est essentiellement un non-problème ici — les événements d'un tenant donné sont écrits depuis une région et les clés d'événement sont uniques, donc deux régions se concurrencent rarement sur le même item. Ce n'est pas de la chance ; c'est pourquoi un journal en ajout seul est l'un des cas les plus propres pour les tables globales. Un compteur mutable, en revanche, demanderait du soin sous des écritures inter-régions concurrentes.

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 réellement 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, de sorte que 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 exécuteras sur chaque réplica dans le Générateur d'expressions DynamoDB.

Pièges et étapes suivantes

• Ne fais pas de lecture de ta propre écriture entre régions. Le décalage de réplication signifie qu'une écriture dans une région peut ne pas apparaître dans une autre pendant ~une seconde. N'écris pas aux États-Unis puis ne lis pas immédiatement depuis l'UE en t'attendant à la voir. Dans le mode MREC par défaut, les lectures fortement cohérentes ne fonctionnent qu'au sein d'une seule région ; MRSC étend les lectures fortes entre régions.
• Le « dernier rédacteur gagne » abandonne des données silencieusement. Pour des items mutables écrits de façon concurrente dans deux régions, le perdant est écarté sans erreur. Les conceptions en ajout seul ou à un seul rédacteur par 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 à peu près le coût. Ajoute des régions pour un vrai besoin de résidence ou de reprise après sinistre, pas par défaut.
• Les sauvegardes sont par réplica. Une table globale restaurée devient une table indépendante — planifie la récupération par région. Voir sauvegarde et récupération à un instant donné.

Les tables globales 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 déploiement défectueux ou une suppression accidentelle — avec sauvegarde et récupération à un instant donné.

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