Utilisation de tables globales DynamoDB - Amazon DynamoDB
Faits importantsFaits importants à propos de la MRECFaits importants à propos de la MRSCCas d’utilisationConclusion et ressources

Utilisation de tables globales DynamoDB

Les tables globales s’appuient sur l’étendue internationale d’Amazon DynamoDB pour vous fournir une base de données entièrement gérée, à régions multiples et à activités multiples, qui peut fournir des performances de lecture et d’écriture rapides et locales, pour des applications dimensionnées massivement et internationales. Les tables globales répliquent automatiquement vos tables DynamoDB dans les Régions AWS de votre choix. Aucune modification de l’application n’est requise, car les tables globales utilisent des API DynamoDB existantes. L’utilisation de tables globales n’entraîne ni frais initiaux ni engagement. Vous ne payez que les ressources que vous utilisez.

Ce guide explique comment utiliser efficacement les tables globales DynamoDB. Il fournit des informations clés sur les tables globales, explique les principaux cas d’utilisation de la fonctionnalité, décrit les deux modes de cohérence, présente une taxonomie de trois modèles d’écriture différents à prendre en compte, passe en revue les quatre principales options de routage des demandes que vous pourriez implémenter, explique comment évacuer une région active ou une région hors ligne, comment envisager la planification de la capacité de débit et fournit une liste des éléments à prendre en compte lors du déploiement de tables globales.

Ce guide s’inscrit dans le contexte plus large des déploiements AWS dans plusieurs régions, tel que décrit dans le livre blanc AWS Multi-Region Fundamentals et dans la vidéo Data resiliency design patterns with AWS.

Rubriques

Faits importants sur la conception d’une table globale DynamoDB

  • Il existe deux versions de tables globales : la version actuelle, Tables globales version 2019.11.21 (actuelle), parfois appelée « V2 », et Tables globales de la version 2017.11.29 (héritée) (parfois appelée « V1 »). 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ésistant aux défaillances de l’infrastructure, y compris à la défaillance de l’ensemble d’une zone de disponibilité. Une table DynamoDB à région unique est conçue pour offrir une disponibilité de 99,99 %. Pour plus d’informations, consultez DynamoDB service-level agreement (SLA).

  • Une table globale DynamoDB réplique ses données entre deux régions ou plus. Une table DynamoDB multi-région est conçue pour offrir une disponibilité de 99,999 %. Une planification adéquate permet aux tables globales d’aider à créer une architecture résiliente face 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 à une autre. Selon la bonne pratique, une application hébergée dans une région doit accéder directement et uniquement au point de terminaison DynamoDB local de cette région. Si des problèmes sont détectés dans une région (dans la couche DynamoDB ou la pile environnante), le trafic de l’utilisateur final doit être acheminé vers le point de terminaison d’une autre application qui est hébergée 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 tables globales prennent en charge deux modes de cohérence : la cohérence à terme multi-région (MREC) et la cohérence forte multi-région (MRSC) qui a été introduite en juin 2025.

Si vous ne spécifiez pas de mode de cohérence lorsque vous créez une table globale, celle-ci est définie par défaut sur 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.

Faits importants à propos de la MREC

  • Les tables globales qui utilisent la MRSC 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éplica locale réplique l’opération d’écriture vers les autres régions participantes distantes en arrière-plan.

  • Les éléments sont répliqués individuellement. Les éléments mis à jour au cours d’une même transaction ne peuvent pas être répliqués ensemble.

  • Chaque partition de table dans 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 métrique ReplicationLatency pour chaque paire de régions. Elle est calculée selon les éléments qui arrivent, la comparaison de leur heure d’arrivée avec leur temps d’écriture initial, et le calcul d’une moyenne. Les horaires sont stockés dans CloudWatch dans la région source. L’affichage des délais moyen et maximum peut aider à déterminer le délai de réplication moyen et celui dans le pire des cas. Il n’existe aucun SLA sur cette latence.

  • Si un élément est mis à jour à peu près au même moment (dans cette fenêtre de ReplicationLatency) dans deux régions différentes et que la deuxième opération d’écriture a lieu avant que la première ne soit répliquée, il existe un risque de conflit d’écriture. Les tables globales qui utilisent la MREC résolvent ces conflits grâce à un mécanisme de victoire du dernier auteur basé sur l’horodatage des opérations d’écriture. La première opération « perd » face à la seconde. Ces conflits ne sont pas enregistrés dans CloudWatch ni dans 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 de victoire du dernier auteur est mise en œuvre en utilisant une opération d’écriture conditionnelle qui exige que l’horodatage de l’élément entrant soit ultérieur à l’horodatage de l’élément existant.

  • Une table globale réplique tous les éléments dans toutes les régions participantes. Si vous souhaitez disposer de différentes étendues de réplication, vous pouvez créer plusieurs tables globales et attribuer à chacune des tables des régions participantes différentes.

  • Les régions locales acceptent les opérations d’écriture même si la région de réplica est hors ligne ou si ReplicationLatency augmente. 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 est complètement hors ligne, toutes les réplications sortantes et entrantes en attente sont retentées lors de sa reconnexion ultérieurement. Aucune action particulière n’est requise pour rétablir la synchronisation des tables. Le mécanisme de victoire du dernier auteur garantit que les données finiront par devenir cohérentes.

  • Vous pouvez ajouter une nouvelle région à une table MREC DynamoDB à tout moment. DynamoDB se charge de la synchronisation initiale et de la réplication en cours. Vous pouvez également supprimer une région (même celle d’origine), ce qui supprimera la table locale de cette région.

Faits importants à propos de la MRSC

  • Les tables globales qui utilisent la MRSC 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. 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.

  • Les opérations de lecture fortement cohérente sur tout réplica MRSC renvoient toujours la dernière version d’un élément. 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.

  • Les opérations de lecture cohérente à terme sur un réplica 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 exception ReplicatedWriteConflictException 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 avec l’exception ReplicatedWriteConflictException peuvent être relancées. Elles réussissent si l’élément n’est plus modifié dans une autre région.

  • Avec la MRSC, les latences sont plus élevées pour les opérations d’écriture et pour les opérations de lecture fortement cohérente. Ces opérations nécessitent une communication interrégionale. Cette communication peut ajouter une latence qui augmente en fonction de la latence aller-retour entre la région à laquelle vous accédez et celle la plus proche figurant dans la table globale. Pour plus d’informations, consultez la présentation AWS re:Invent 2024, Multi-Region strong consistency with DynamoDB global tables. Les opérations de lecture cohérente à terme ne subissent aucune latence supplémentaire. Il existe un outil de test open source qui vous permet de calculer de manière expérimentale ces latences avec vos régions.

  • Les éléments sont répliqués individuellement. Les tables globales utilisant la MRSC ne prennent pas en charge les API de transaction.

  • Une table globale MRSC doit être déployée dans exactement trois régions. 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 récentes écrites dans des réplicas de table globale. Un témoin fournit une alternative optionnelle à 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 n’est pas soumis à des frais de stockage ni d’écriture. Un témoin se trouve dans une région différente de celle des deux réplicas.

  • Pour créer une table globale MRSC, ajoutez un réplica et un témoin, ou ajoutez 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. 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é pour une table globale MRSC, et dans quelle région il est configuré, à partir de la sortie de l’API DescribeTable. Le témoin est détenu et géré par DynamoDB et n’apparaît pas dans votre Compte AWS dans la région dans laquelle il est configuré.

  • Les tables globales MRSC sont disponibles dans les ensembles de régions suivants :

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

    • Groupe de régions UE : Europe (Francfort), Europe (Irlande), Europe (Londres), Europe (Paris)

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

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

  • La durée de vie (TTL) n’est pas prise en charge pour les tables globales MRSC.

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

  • Les informations de CloudWatch 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 à condition qu’une deuxième région héberge un réplica ou un témoin pour établir le quorum. Si une deuxième région n’est pas disponible, la région locale peut uniquement proposer des lectures cohérentes à terme.

  • Dans le cas peu probable où une région serait complètement hors ligne, elle rattrapera automatiquement son retard lorsqu’elle sera de nouveau en ligne. Les opérations d’écriture et de lecture fortement cohérente renverront des erreurs jusqu’à ce que le rattrapage soit terminé. Cependant, des opérations de lecture cohérente à terme renverront 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éplicas locaux. Aucune action particulière n’est requise pour rétablir la synchronisation des tables.

Cas d’utilisation de table globale MREC DynamoDB

Les tables globales MREC offrent les avantages suivants :

  • Opérations de lecture à faible latence. Placez une copie des données plus près de l’utilisateur final afin de réduire la latence du réseau lors des opérations de lecture. Les données sont conservées aussi longtemps que la valeur ReplicationLatency.

  • Opérations d’écriture à faible latence. Vous pouvez écrire dans une région voisine pour réduire la latence du réseau et le temps nécessaire à l’écriture. Le trafic d’écriture doit être acheminé avec soin pour éviter tout conflit. Les techniques de routage sont détaillées dans Stratégies de routage dans DynamoDB.

  • 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 vers une autre, le tout sans durée d’indisponibilité au niveau de la couche de données.

Les tables globales MREC et MRSC offrent toutes 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. Évacuer signifie rejeter une partie ou la totalité des demandes adressées à cette région. L’utilisation de tables globales augmente également le SLA de DynamoDB pour le pourcentage de durée de fonctionnement mensuel de 99,99 % à 99,999 %. L’utilisation de la MREC prend en charge un objectif de point de reprise (RPO) et un objectif de délai de reprise (RTO) mesurés en secondes. L’utilisation de la MRSC permet d’obtenir un RPO nul.

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

Si votre objectif est la résilience et la reprise après sinistre, les tables MRSC présentent des latences supérieures d’écriture et de lecture fortement cohérentes, mais elles atteignent un RPO nul. Les tables globales MREC prennent en charge un 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.

Conclusion et ressources

Les tables globales DynamoDB comportent très peu de contrôles, mais elles nécessitent tout de même un examen attentif. Vous devez déterminer votre mode d’écriture, votre modèle de routage et vos processus d’évacuation. Vous devez équiper votre application dans chaque région et être prêt à ajuster votre routage ou à effectuer une évacuation pour préserver l’état global. L’avantage est que vous disposez d’un jeu de données distribué dans le monde entier avec des opérations de lecture et d’écriture à faible latence, conçu pour une disponibilité de 99,999 %.

Pour plus d’informations sur les tables globales DynamoDB, consultez les ressources suivantes :