Bonnes pratiques relatives à la conception d'une table globale 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 fournit des performances de lecture et d'écriture rapides et locales, pour des applications dimensionnées massivement et internationales. Avec les tables globales, vos données se répliquent automatiquement sur l'ensemble de votre choix AWS Régions. Dans la mesure où les tables globales utilisent APIs DynamoDB existant, aucune modification de votre application ne sera nécessaire. L'utilisation de tables globales n'entraîne ni frais initiaux ni engagement. Vous ne payez que les ressources que vous utilisez.

Rubriques

• Conseils prescriptifs pour la conception de tables globales DynamoDB
• Faits importants sur la conception d'une table globale DynamoDB
• Cas d’utilisation
• Modes d'écriture avec des tables globales
• Routage des demandes avec des tables globales
• Évacuation d'une région avec des tables globales
• Planification de la capacité de débit pour les tables globales
• Liste de contrôle pour la préparation des tableaux globaux et des questions fréquemment posées

Conseils prescriptifs pour la conception de tables globales DynamoDB

L'utilisation efficace des tables globales nécessite une prise en compte attentive de facteurs tels que votre mode d'écriture préféré, votre modèle de routage et les 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. Votre récompense est de disposer d'un jeu de données distribué dans le monde entier avec une faible latence de lecture et d'écriture et un contrat de niveau de service de 99,999 %.

Faits importants sur 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 possède un accord de niveau de service de https://aws.amazon.com/dynamodb/sla/ disponibilité de 99,99 % (). SLA

• Avec les tables globales, DynamoDB permet à une table de répliquer ses données entre deux régions ou plus. La disponibilité d'une table DynamoDB multirégionale est de 99,999 %. SLA 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'y a rien SLA à voir avec 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 dans 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 région différente. 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.

Cas d’utilisation

Les tables globales offrent les avantages courants suivants :

• 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 des tables globales.

• Résilience et reprise après sinistre accrues. Vous pouvez évacuer une région (supprimer 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 temps de restauration (RTO) mesurés en secondes. L'utilisation de tables globales augmente également le DynamoDB de 99,99 SLA % à 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é.