Bonnes pratiques relatives à la conception d'une table globale DynamoDB

Il existe deux versions de tables globales : la version actuelle de Global Tables version 2019.11.21 (Current) (parfois appelée « V2 ») et Tableaux globaux version 2017.11.29 (ancienne version) (parfois appelée « V1 »). Ce guide se concentre exclusivement sur la version actuelle (V2).

Sans les tables globales, DynamoDB est un service régional. Il est hautement disponible et intrinsèquement résistant aux défaillances de l'infrastructure d'une région, y compris à la défaillance de l'ensemble d'une zone de disponibilité (AZ). Une table DynamoDB à région unique est soumise à un https://aws.amazon.com/dynamodb/sla/contrat de niveau de service (SLA) avec une disponibilité de 99,99 %.

Avec les tables globales, DynamoDB permet à une table de répliquer ses données entre deux régions ou plus. Une table DynamoDB à plusieurs régions est soumise à un SLA avec une disponibilité de 99,999 %. Une planification adéquate permet aux tables globales d'aider à créer une architecture résiliente qui résiste aux défaillances régionales.

Les tables globales 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'écriture vers les autres régions participantes 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 écritures en parallèle avec toutes les autres partitions. La séquence des écritures dans la région distante peut ne pas correspondre à la séquence des écritures 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. Elle est calculée sur la base de l'examen des éléments qui arrivent, de la comparaison de leur heure d'arrivée avec leur temps d'écriture initial et du calcul d'une moyenne. Les horaires sont enregistrés 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 le même é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 écriture a lieu avant que la première ne soit répliquée, il existe un risque de conflit d'écriture. Les tables globales résolvent ces conflits grâce à un mécanisme de victoire du dernier auteur basé sur l'horodatage des écritures. La première écriture « perd » au profit de la seconde écriture. 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 de victoire du dernier auteur est mise en œuvre en utilisant une é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 reproduira 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 différentes tables et attribuer à chacune des tables des régions participantes différentes.

Les écritures sont acceptées dans la région locale, même si la région de réplica est hors ligne ou si la 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. 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 DynamoDB à tout moment. DynamoDB se charge de la synchronisation initiale et de la réplication en cours. Si une région est supprimée, même s'il s'agit de la région d'origine, seule la table de cette région est supprimée.

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 ensuite à l'instance de table globale locale à cette région.

Les appels à DynamoDB ne doivent pas passer d'une région à une autre. Il est recommandé que la couche de calcul d'une région accède directement et uniquement au point de terminaison DynamoDB local de cette région. Si des problèmes sont détectés au sein d'une région, qu'ils concernent la couche DynamoDB ou la pile environnante, le trafic de l'utilisateur final doit être acheminé vers une autre couche de calcul hébergée dans une autre région. Grâce à la réplication des tables globales, les différentes régions disposent déjà d'une copie locale des mêmes données qu'elles peuvent utiliser localement. Dans certains cas, la couche de calcul d'une région peut transmettre la demande à la couche de calcul d'une autre région à des fins de traitement, mais celle-ci ne doit pas accéder directement au point de terminaison DynamoDB distant. Pour plus d'informations sur ce cas d'utilisation particulier, consultez Routage des demandes dans la couche de calcul.

Lectures à plus 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 lors des lectures. Le cache est conservé aussi longtemps que la valeur ReplicationLatency.

Écritures à plus 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 Routage des demandes avec les tables globales DynamoDB.

Résilience et reprise après sinistre accrues. Vous pouvez évacuer une région (déplacer une partie ou la totalité des demandes destinées à cette région) en cas de dégradation des performances de la région ou de panne complète, avec un objectif de point de reprise (RPO) et un objectif de délai de reprise (RTO) mesurés en secondes. L'utilisation de tables globales augmente également le SLA de DynamoDB de 99,99 % à 99,999 %.

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 interruption au niveau de la couche de données. Par exemple, vous pouvez utiliser les tables globales DynamoDB pour qu'un système de gestion des commandes réussisse un traitement fiable à faible latence à grande échelle tout en préservant sa résilience face aux pannes régionales et dans les zones de disponibilité.