Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # 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 parmi celles de votre choix. Régions AWS Aucune modification d'application n'est requise car les tables globales utilisent DynamoDB APIs existant. 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 multirégionaux, tel que décrit dans le livre blanc sur les [principes fondamentaux du AWS multirégional](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) et dans les modèles de conception relatifs à la [résilience des données](https://www.youtube.com/watch?v=7IA48SOX20c) avec vidéo. AWS **Topics** + [Faits importants sur la conception d’une table globale DynamoDB](#bp-global-table-design.prescriptive-guidance.facts) + [Faits importants à propos de la MREC](#bp-global-table-design-MREC-facts) + [Faits importants à propos de la MRSC](#bp-global-table-design-MRSC-facts) + [Cas d’utilisation de table globale MREC DynamoDB](#bp-global-table-design.prescriptive-guidance.usecases) + [Modes d’écriture avec des tables globales DynamoDB](bp-global-table-design.prescriptive-guidance.writemodes.md) + [Stratégies de routage dans DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) + [Processus d’évacuation](bp-global-table-design.prescriptive-guidance.evacuation.md) + [Planification de la capacité de débit pour les tables globales DynamoDB](bp-global-table-design.prescriptive-guidance.throughput.md) + [Liste de vérification pour la préparation des tables globales DynamoDB](bp-global-table-design.prescriptive-guidance.checklist-and-faq.md) + [Conclusion et ressources](#bp-global-table-design.prescriptive-guidance-resources-conclusion) ## 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)](GlobalTables.md), parfois appelée « V2 », et [Tables globales de la version 2017.11.29 (héritée)](globaltables.V1.md) (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](https://aws.amazon.com/dynamodb/sla/) (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](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/). + 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 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 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 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 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 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](https://www.youtube.com/watch?v=R-nTs8ZD8mA). Les opérations de lecture cohérente à terme ne subissent aucune latence supplémentaire. Il existe un [outil de test](https://github.com/awslabs/amazon-dynamodb-tools/tree/main/tester) 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 MRSC ne prennent pas en charge la transaction. APIs + 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é dans une table globale MRSC, et dans quelle région elle est configurée, à partir de la sortie de l' DescribeTable API. Le témoin est détenu et géré par DynamoDB et n'apparaît pas dans Compte AWS votre 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 (LSIs) ne sont pas pris en charge pour les tables globales MRSC. + CloudWatch Les informations de 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. Jusqu'à ce que le problème soit rattrapé, les opérations d'écriture et les opérations de lecture très cohérentes effectuées *uniquement* dans la région de rattrapage renverront des erreurs tandis que les demandes adressées aux autres régions continueront de fonctionner normalement. À terme, des opérations de lecture cohérentes vers la région de rattrapage 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épliques locales. 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](bp-global-table-design.prescriptive-guidance.request-routing.md). + **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](https://aws.amazon.com/dynamodb/sla/) 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. # Modes d’écriture avec des tables globales DynamoDB Les tables globales sont toujours actives-actives au niveau de la table. Toutefois, en particulier pour les tables MREC, vous pouvez les traiter comme actives-passives en contrôlant la façon dont vous acheminez les demandes d’écriture. Par exemple, vous pouvez décider d’acheminer les demandes d’écriture vers une seule région afin d’éviter les éventuels conflits d’écriture qui peuvent se produire dans les tables MREC. Il existe trois principaux modèles d’écriture gérés, comme l’expliquent les trois sections suivantes. Vous devez déterminer quel modèle d’écriture correspond à votre cas d’utilisation. Ce choix affecte la manière dont vous acheminez les demandes, évacuez une région et gérez la reprise après sinistre. Les instructions dans les sections suivantes dépendent du mode d’écriture de votre application. ## Mode Écrire dans n’importe quelle région (non primaire) Le mode *Écrire dans n’importe quelle région*, illustré dans le diagramme suivant, est entièrement actif-actif et n’impose aucune restriction quant à l’endroit où une écriture peut avoir lieu. Toute région peut accepter une écriture à tout moment. Il s’agit du mode le plus simple, mais il ne peut être utilisé qu’avec certains types d’applications. Ce mode convient à toutes les tables MRSC. Il convient également pour les tables MREC lorsque tous les rédacteurs sont idempotents et peut donc être répété en toute sécurité afin que les opérations d’écriture simultanées ou répétées entre les régions ne soient pas en conflit. Par exemple, lorsqu’un utilisateur met à jour ses coordonnées. Ce mode fonctionne également bien dans un cas particulier d’idempotent, à savoir un jeu de données à ajout uniquement où toutes les écritures sont des insertions uniques sous une clé primaire déterministe. Enfin, ce mode convient pour la MREC lorsque le risque d’écritures conflictuelles est acceptable. ![\[Schéma du fonctionnement des écritures du client vers n’importe quelle région.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/gt-client-read-write-to-any-region2.png) Le mode *Écrire dans n’importe quelle région* est l’architecture la plus simple à implémenter. Le routage est plus facile car n’importe quelle région peut être la cible d’écriture à tout moment. Le basculement est plus facile, car avec les tables MRSC, les éléments sont toujours synchronisés et toutes les écritures récentes peuvent être rejouées autant de fois que vous le souhaitez dans n’importe quelle région secondaire. Dans la mesure du possible, votre conception doit suivre ce mode d’écriture. Par exemple, plusieurs services de streaming vidéo utilisent des tables globales pour suivre les favoris, les avis, les indicateurs du statut des visionnages, etc. Ces déploiements utilisent des tables MREC, car ils ont besoin de réplicas dispersés dans le monde entier, chaque réplica fournissant des opérations de lecture et d’écriture à faible latence. Ces déploiements peuvent utiliser l’*écriture dans n’importe quelle région*, à condition de s’assurer que chaque opération d’écriture est idempotente. C’est le cas si chaque mise à jour (par exemple, la définition d’un nouveau code horaire, l’attribution d’un nouvel avis ou la définition d’un nouveau statut de surveillance) attribue directement le nouvel état à l’utilisateur, et si la prochaine valeur correcte pour un article ne dépend pas de sa valeur actuelle. Si les demandes d’écriture de l’utilisateur sont acheminées vers différentes régions, la dernière opération d’écriture persiste et l’état global est réglé en fonction de la dernière attribution. Les opérations de lecture dans ce mode finissent par devenir cohérentes, après avoir été retardées par la dernière valeur de `ReplicationLatency`. Autre exemple : une entreprise de services financiers utilise des tables globales dans le cadre d’un système visant à tenir à jour le décompte des achats par carte de débit pour chaque client, afin de calculer les remises en argent de ce client. Elle veut conserver un article `RunningBalance` par client. Ce mode d’écriture n’est pas naturellement idempotent, car au fur et à mesure que les transactions entrent, elles modifient l’équilibre en utilisant une expression `ADD` dans laquelle la nouvelle valeur correcte dépend de la valeur actuelle. En utilisant les tables MRSC, elles peuvent toujours *écrire dans n’importe quelle région*, car chaque appel `ADD` fonctionne toujours en fonction de la toute dernière valeur de l’article. Un troisième exemple concerne une entreprise qui fournit des services de placement d’annonces en ligne. Cette entreprise a décidé qu’un faible risque de perte de données serait acceptable pour simplifier la conception du mode *Écrire dans n’importe quelle région*. Lorsqu’elle diffuse des publicités, elle ne dispose que de quelques millisecondes pour extraire suffisamment de métadonnées afin de déterminer la publicité à diffuser, puis enregistrer l’impression publicitaire afin que celle-ci ne soit pas répétée trop rapidement. Elle utilise des tables globales pour obtenir à la fois des opérations de lecture à faible latence pour les utilisateurs finaux du monde entier et des opérations d’écriture à faible latence. Elle enregistre toutes les impressions publicitaires d’un utilisateur au sein d’un seul élément, qui est représenté sous la forme d’une liste croissante. Elle utilise un seul élément au lieu de l’ajouter à une collection d’éléments, car elle peut ainsi supprimer les anciennes impressions publicitaires à chaque opération d’écriture sans avoir à payer une opération de suppression. Cette opération d’écriture n’est pas idempotente : si le même utilisateur final voit des publicités diffusées dans plusieurs régions à peu près au même moment, il est possible qu’une opération d’écriture pour une impression publicitaire remplace l’autre. Le risque est qu’un utilisateur voie une publicité se répéter de temps en temps. L’entreprise a décidé que cette situation était acceptable. ## Écrire dans une région (primaire unique) Le mode *Écrire dans une région*, illustré dans le diagramme suivant, est actif-passif et achemine toutes les écritures de table vers une seule région active. Notez que DynamoDB n’a pas la notion de région active unique ; le routage des applications en dehors de DynamoDB gère cela. Le mode *Écrire dans une région* est efficace pour les tables MREC qui doivent éviter les conflits d’écriture, en garantissant que les opérations d’écriture ne circulent que vers une région à la fois. Ce mode d’écriture est utile lorsque vous souhaitez utiliser des expressions conditionnelles et que vous ne pouvez pas utiliser la MRSC pour une raison quelconque, ou lorsque vous devez effectuer des transactions. Ces expressions ne sont possibles que si vous savez que vous agissez sur la base des données les plus récentes. Elles nécessitent donc d’envoyer toutes les demandes d’écriture vers une seule région disposant des données les plus récentes. Lorsque vous utilisez une table MRSC, vous pouvez choisir d’écrire généralement vers une région pour des raisons de commodité. Par exemple, cela peut aider à minimiser le développement de votre infrastructure au-delà de DynamoDB. Le mode d’écriture resterait l’écriture dans n’importe quelle région, car avec la MRSC, vous pouvez écrire en toute sécurité dans n’importe quelle région à tout moment sans vous soucier de la résolution des conflits, ce qui obligerait les tables MREC à choisir d’*écrire dans une région*. Les lectures éventuellement cohérentes peuvent aller vers n’importe quelle région de réplica pour réduire les latences. Les lectures fortement cohérentes doivent aller dans la seule région principale. ![\[Schéma du fonctionnement de l’écriture dans une région.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/gt-client-writes-one-region2.png) Il est parfois nécessaire de modifier la région active en réponse à une défaillance régionale. Certains utilisateurs modifient régulièrement la région actuellement active, par exemple en mettant en œuvre un follow-the-sun déploiement. Cela place la région active à proximité de la zone géographique la plus active (généralement là où il fait jour, d’où son nom), ce qui se traduit par les opérations de lecture et d’écriture avec le plus faible temps de latence. Cela présente également l’avantage d’appeler quotidiennement le code de la région qui change, afin de s’assurer qu’il est bien testé avant toute reprise après sinistre. La ou les régions passives peuvent conserver un ensemble réduit d’infrastructures autour de DynamoDB, qui ne se développe que si la région devient active. Ce guide ne couvre pas les modèles veilleuse et secours semi-automatique. Pour plus d'informations, voir [Architecture de reprise après sinistre (DR) activée AWS, partie III : veilleuse et mode veille](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). L’utilisation du mode *Écrire dans une région* fonctionne bien lorsque vous utilisez des tables globales pour des opérations de lecture distribuées à l’échelle mondiale à faible latence. Prenons l’exemple d’une grande entreprise de médias sociaux qui doit disposer des mêmes données de référence dans toutes les régions du monde. Elle ne met pas souvent à jour les données, mais lorsqu’elle le fait, elle n’écrit que dans une seule région afin d’éviter tout conflit d’écriture potentiel. Les opérations de lecture sont toujours autorisées dans toutes les régions. Autre exemple : le client du secteur des services financiers dont nous avons parlé précédemment, et qui a mis en œuvre le calcul de remise en argent quotidien. Il a utilisé le mode *Écrire dans n’importe quelle région* pour calculer le solde, mais aussi le mode *Écrire dans une région* pour suivre les paiements. Ce travail nécessite des transactions, qui ne sont pas prises en charge dans les tables MRSC. Il fonctionne donc mieux avec une table MREC séparée et le mode *Écrire dans une région*. ## Écrire dans votre région (primaire mixte) Le mode d’écriture *Écrire dans votre région*, illustré dans le schéma suivant, fonctionne avec les tables MREC. Il attribue différents sous-ensembles de données aux différentes régions d’origine et autorise les opérations d’écriture sur un élément uniquement via sa région d’origine. Ce mode est actif-passif, mais assigne la région active en fonction de l’élément. Chaque région est primaire pour son propre jeu de données qui ne se chevauche pas et les opérations d’écriture doivent être protégées pour garantir une localisation correcte. Ce mode est similaire à *Écrire dans une région*, sauf qu’il permet des opérations d’écriture à faible latence, car les données associées à chaque utilisateur peuvent être placées dans un réseau plus près de cet utilisateur. Cela permet également de répartir l’infrastructure environnante de manière plus uniforme entre les régions et de réduire le travail de construction de l’infrastructure lors d’un scénario de basculement, car une partie de l’infrastructure de toutes les régions est déjà active. ![\[Schéma du fonctionnement de l’écriture pour chaque élément d’un client dans une seule région.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/get-client-writes-each-item-single-region2.png) Vous pouvez déterminer la région d’origine des objets de plusieurs manières : + **Intrinsèque :** certains aspects des données, tels qu’un attribut spécial ou une valeur vectorisée dans leur clé de partition, indiquent clairement leur région d’origine. Cette technique est décrite dans l’article de blog [Utiliser l’épinglage des régions pour définir une région d’origine pour les éléments d’une table globale Amazon DynamoDB](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/). + **Négocié :** la région d’origine de chaque jeu de données est négociée de manière externe, par exemple avec un service global distinct qui gère les attributions. La mission peut avoir une durée limitée, après laquelle elle peut faire l’objet d’une renégociation. + **Orienté vers les tables :** au lieu de créer une seule table globale de réplication, vous créez le même nombre de tables globales que de régions de réplication. Le nom de chaque table indique sa région d’origine. Dans les opérations standard, toutes les données sont écrites dans la région d’origine tandis que les autres régions conservent une copie en lecture seule. Lors d’un basculement, une autre région adopte temporairement des fonctions d’écriture pour cette table. Imaginons que vous travaillez pour une entreprise de jeux vidéo. Vous avez besoin d’opérations de lecture et d’écriture à faible latence pour tous les joueurs du monde entier. Vous attribuez à chaque joueur la région la plus proche de lui. Cette région prend en charge toutes ses opérations de lecture et d'écriture, garantissant ainsi une forte read-after-write cohérence. Toutefois, lorsqu’un joueur voyage ou si sa région d’origine est en panne, une copie complète de ses données est disponible dans d’autres régions. Le joueur peut alors être attribué à une autre région d’origine. Autre exemple, imaginez que vous travaillez pour une entreprise de visioconférence. À chaque téléconférence, des métadonnées sont attribuées à une région particulière. Les participants peuvent utiliser la région la plus proche d’eux pour minimiser la latence. En cas de panne d’une région, les tables globales permettent une restauration rapide, car le système peut déplacer le traitement de l’appel vers une autre région où il existe déjà une copie répliquée des données. **Récapitulatif** + Le mode Écrire dans n’importe quelle région convient aux tables MRSC et aux appels idempotents vers les tables MREC. + Le mode Écrire dans une région convient aux appels non idempotents vers les tables MREC. + Le mode Écrire dans votre région convient aux appels non idempotents vers les tables MREC, où il est important que les clients écrivent dans une région proche d’eux. # Stratégies de routage dans DynamoDB La partie la plus complexe d’un déploiement de tables globales est peut-être la gestion du routage des demandes. Les demandes doivent d’abord aller d’un utilisateur final vers une région choisie et acheminée d’une manière ou d’une autre. La demande rencontre une pile de services dans cette région, notamment une couche de calcul qui consiste peut-être en un équilibreur de charge soutenu par une AWS Lambda fonction, un conteneur ou un nœud Amazon Elastic Compute Cloud (Amazon EC2), et éventuellement d'autres services, y compris une autre base de données. Cette couche de calcul communique avec DynamoDB. Pour ce faire, elle doit utiliser le point de terminaison local de cette région. Les données de la table globale sont répliquées dans toutes les autres régions participantes et chaque région dispose d’une pile de services similaire autour de sa table DynamoDB. La table globale fournit à chaque pile des différentes régions une copie locale des mêmes données. Vous pouvez envisager de concevoir une pile unique dans une seule région et prévoir de passer des appels distants vers le point de terminaison DynamoDB d’une région secondaire en cas de problème avec la table DynamoDB locale. Ce n’est pas la bonne pratique recommandée. Si un problème dans une région est dû à DynamoDB (ou, plus probablement, à un autre élément de la pile ou à un autre service dépendant de DynamoDB), il est préférable d’acheminer l’utilisateur final vers une autre région pour le traitement et d’utiliser la couche de calcul de cette autre région, qui communiquera avec son point de terminaison DynamoDB local. Cette approche permet de contourner entièrement la région problématique. Pour garantir la résilience, vous avez besoin d’une réplication entre plusieurs régions, avec une réplication de la couche de calcul ainsi que de la couche de données. Il existe de nombreuses techniques alternatives pour acheminer une demande d’utilisateur final vers une région à des fins de traitement. Le choix optimal dépend de votre mode d’écriture et de vos considérations relatives au basculement. Cette section décrit quatre options : piloté par le client, couche de calcul, Route 53 et Global Accelerator. ## Routage des demandes piloté par le client Avec le routage des demandes piloté par le client, illustré dans le schéma suivant, le client de l'utilisateur final (une application, une page Web ou un autre client) garde une trace des points de terminaison d'application valides (par exemple, un point de terminaison Amazon API Gateway plutôt qu'un point de terminaison DynamoDB littéral) et utilise sa propre logique intégrée pour choisir la région avec JavaScript laquelle communiquer. Il peut choisir de façon aléatoire, en fonction des latences les plus faibles observées, des mesures de bande passante les plus élevées observées ou des surveillances de l’état effectuées localement. ![\[Schéma du fonctionnement de l’écriture sur la cible choisie par un client.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/gt-routing-is-clients-choice2_v2.png) L’avantage du routage des demandes piloté par le client est qu’il peut s’adapter à des facteurs tels que les conditions réelles du trafic Internet public pour changer de région en cas de dégradation des performances. Le client doit connaître tous les points de terminaison potentiels, mais il n’est pas courant de lancer un nouveau point de terminaison régional. Avec le mode *Écrire dans n’importe quelle région*, un client peut sélectionner unilatéralement son point de terminaison préféré. Si son accès à une région est perturbé, le client peut effectuer un routage vers un autre point de terminaison. Avec le mode *Écrire dans une région*, le client aura besoin d’un mécanisme pour acheminer ses écritures vers la région actuellement active. Cela peut être aussi simple que de tester de façon empirique quelle région accepte actuellement les écritures (en notant tout rejet d’écriture et en revenant à une autre région) ou aussi complexe que d’appeler un coordinateur mondial pour demander l’état actuel de l’application (ce qui peut-être basé sur le contrôle de routage Amazon Application Recovery Controller (ARC) qui fournit un système piloté par un quorum à 5 régions afin de maintenir l’état global pour des besoins tels que celui-ci). Le client peut décider si les lectures peuvent être acheminées vers n’importe quelle région pour une cohérence éventuelle ou si elles doivent être acheminées vers la région active pour une forte cohérence. Pour plus d’informations, consultez [Fonctionnement de Route 53](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html). Avec le mode *Écrire dans votre région*, le client doit déterminer la région d’origine du jeu de données sur lequel il travaille. Par exemple, si le client correspond à un compte utilisateur et que chaque compte utilisateur est associé à une région, le client peut demander le point de terminaison approprié auprès d’un système de connexion global. Par exemple, une entreprise de services financiers qui aide les utilisateurs à gérer les finances de leur entreprise via le Web peut utiliser des tables globales avec un mode *Écrire dans votre région*. Chaque utilisateur doit se connecter à un service central. Ce service renvoie les informations d’identification et le point de terminaison de la région dans laquelle ces informations d’identification fonctionnent. Les informations d’identification sont valides pendant une courte période. Ensuite, la page Web négocie automatiquement une nouvelle connexion, ce qui permet de rediriger potentiellement l’activité de l’utilisateur vers une nouvelle région. ## Routage des demandes dans la couche de calcul Avec le routage des demandes dans la couche de calcul, illustré dans le diagramme suivant, le code qui s’exécute dans la couche de calcul décide s’il souhaite traiter la demande localement ou la transmettre à une copie de lui-même qui s’exécute dans une autre région. Lorsque vous utilisez le mode *Écrire dans une région*, la couche de calcul peut détecter qu’il ne s’agit pas de la région active et autoriser les opérations de lecture locales tout en transférant toutes les opérations d’écriture vers une autre région. Ce code de couche de calcul doit tenir compte de la topologie des données et des règles de routage, et les appliquer de manière fiable en fonction des derniers paramètres qui spécifient quelles régions sont actives pour quelles données. La pile logicielle externe au sein de la région n’a pas besoin de savoir comment les demandes de lecture et d’écriture sont acheminées par le microservice. Dans une conception robuste, la région réceptrice vérifie s’il s’agit de la région principale actuelle pour l’opération d’écriture. Si ce n’est pas le cas, cela génère une erreur indiquant que l’état global doit être corrigé. La région réceptrice peut également mettre en mémoire tampon l’opération d’écriture pendant un certain temps si la région principale est en cours de modification. Dans tous les cas, la pile de calcul d’une région écrit uniquement sur son point de terminaison DynamoDB local, mais les piles de calcul peuvent communiquer entre elles. ![\[Schéma du routage des demandes dans la couche de calcul.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/gt-compute-layer-routing2.png) [Le Vanguard Group utilise un système appelé Global Orchestration and Status Tool (GOaST) et une bibliothèque appelée Global Multi-Region library (GMRlib) pour ce processus de routage, tel que présenté à re:Invent 2022.](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) Ils utilisent un follow-the-sun seul modèle principal. GOaST conserve l'état global, de la même manière que le contrôle de routage ARC décrit dans la section précédente. Il utilise une table globale pour savoir quelle région est la région principale et quand le prochain commutateur principal est planifié. Toutes les opérations de lecture et d'écriture sont effectuées GMRlib, ce qui est coordonné avec GOa ST. GMRlib permet d'effectuer des opérations de lecture localement, avec une faible latence. Pour les opérations d'écriture, GMRlib vérifie si la région locale est la région principale actuelle. Si tel est le cas, l’opération d’écriture se termine directement. Dans le cas contraire, GMRlib transmet la tâche d'écriture GMRlib à la région principale. Cette bibliothèque réceptrice confirme qu’elle se considère également comme la région principale et génère une erreur si ce n’est pas le cas, ce qui indique un délai de propagation par rapport à l’état global. Cette approche offre un avantage en matière de validation car elle ne permet pas d’écrire directement sur un point de terminaison DynamoDB distant. ## Routage des demandes avec Route 53 Amazon Application Recovery Controller (ARC) est une technologie de service de nom de domaine (DNS). Avec Route 53, le client demande son point de terminaison en recherchant un nom de domaine DNS connu et Route 53 renvoie l’adresse IP correspondante au ou aux points de terminaison régionaux qu’il juge les plus appropriés. Le diagramme suivant en est l’illustration. Route 53 dispose d’une longue liste de politiques de routage qu’elle utilise pour déterminer la région appropriée. Il peut également effectuer un routage de basculement pour acheminer le trafic en dehors des régions où les surveillances de l’état échouent. ![\[Schéma du routage des demandes dans la couche de calcul.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/gt-rt-53-anycast2_v2.png) Avec le mode *Écrire dans n’importe quelle région*, ou en combinaison avec le routage des demandes dans la couche de calcul sur le back-end, Route 53 peut bénéficier d’un accès complet pour renvoyer la région en fonction de règles internes complexes, telles que la région la plus proche du réseau, la zone géographique la plus proche, ou tout autre choix. Avec le mode *Écrire dans une région*, vous pouvez configurer Route 53 pour renvoyer la région actuellement active (à l’aide de Route 53 ARC). Si le client souhaite se connecter à une région passive (par exemple, pour des opérations de lecture), il peut rechercher un autre nom DNS. **Note** Les clients mettent en cache les adresses IP figurant dans la réponse de Route 53 pendant une durée indiquée par le paramètre de durée de vie (TTL) du nom de domaine. Une durée de vie plus longue prolonge l’objectif de délai de reprise (RTO) pour que tous les clients puissent reconnaître le nouveau point de terminaison. Une valeur de 60 secondes est généralement utilisée pour un basculement. Tous les logiciels ne respectent pas parfaitement l’expiration du TTL DNS, et il peut y avoir plusieurs niveaux de mise en cache DNS, par exemple au niveau du système d’exploitation, de la machine virtuelle et de l’application. Avec le mode *Écrire dans votre région*, il est préférable d’éviter Route 53, sauf si vous utilisez également le routage des demandes dans la couche de calcul. ## Routage des demandes avec Global Accelerator Avec [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/), comme illustré dans le diagramme suivant, un client utilise Route 53 pour rechercher le nom de domaine connu. Cependant, au lieu de récupérer une adresse IP correspondant à un point de terminaison régional, le client reçoit une adresse IP statique anycast qui achemine vers l'emplacement AWS périphérique le plus proche. À partir de cet emplacement périphérique, tout le trafic est acheminé sur le réseau AWS privé et vers un point de terminaison (tel qu’un équilibreur de charge ou API Gateway) dans une région choisie par des règles de routage qui sont gérées dans Global Accelerator. Comparé au routage basé sur les règles Route 53, le routage des demandes avec Global Accelerator présente des latences plus faibles car il réduit le volume de trafic sur l’Internet public. De plus, comme Global Accelerator ne dépend pas de l’expiration de la durée de vie du DNS pour modifier les règles de routage, il peut ajuster le routage plus rapidement. ![\[Schéma du fonctionnement de l’écriture client avec Global Accelerator.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/gt-routing-gax-excerpt2_v2.png) Avec le mode *Écrire dans n’importe quelle région*, ou s’il est associé au routage des demandes dans la couche de calcul sur le back-end, Global Accelerator fonctionne parfaitement. Le client se connecte à l’emplacement périphérique le plus proche et n’a pas à se soucier de savoir quelle région reçoit la demande. Avec le mode *Écrire dans une région*, les règles de routage de Global Accelerator doivent envoyer des demandes à la région actuellement active. Vous pouvez utiliser des surveillances de l’état qui signalent artificiellement une défaillance dans une région qui n’est pas considérée par votre système global comme étant la région active. Comme avec DNS, il est possible d’utiliser un autre nom de domaine DNS pour acheminer les demandes de lecture si celles-ci peuvent provenir de n’importe quelle région. Avec le mode *Écrire dans votre région*, il est préférable d’éviter Global Accelerator, sauf si vous utilisez également le routage des demandes dans la couche de calcul. # Processus d’évacuation L’évacuation d’une région est le processus d’activité de migration, généralement des activités de lecture et d’écriture ou des activités d’écriture, hors de cette région. ## Évacuation d’une région active Vous pouvez décider d'évacuer une région active pour plusieurs raisons : dans le cadre de vos activités commerciales habituelles (par exemple, si vous utilisez le mode « écrire dans une région ») follow-the-sun, en raison de la décision commerciale de modifier la région actuellement active, en réponse à des défaillances de la pile logicielle en dehors de DynamoDB, ou parce que vous rencontrez des problèmes généraux tels que des latences plus élevées que d'habitude au sein de la région. Avec le mode *Écrire dans n’importe quelle région*, il est facile d’évacuer une région active. Vous pouvez acheminer le trafic vers d’autres régions via n’importe quel système de routage et laisser les opérations d’écriture dans la région évacuée se répliquer comme d’habitude. Les modes Écrire dans une région et Écrire dans votre région sont généralement utilisés avec les tables MREC. Par conséquent, vous devez vous assurer que toutes les opérations d’écriture dans la région active ont été entièrement enregistrées, traitées en flux et propagées globalement avant de commencer les opérations d’écriture dans la nouvelle région active, afin de garantir que les futures opérations d’écriture seront traitées par rapport à la dernière version des données. Supposons que la région A soit active et que la région B soit passive (soit pour la table complète, soit pour les éléments qui se trouvent dans la région A). Le mécanisme habituel pour une évacuation consiste à suspendre les opérations d’écriture vers A, à attendre suffisamment longtemps pour que ces opérations se propagent entièrement vers B, à mettre à jour la pile d’architecture pour reconnaître B comme étant active, puis à reprendre les opérations d’écriture vers B. Aucune métrique n’indique avec une certitude absolue que la région A a entièrement répliqué ses données vers la région B. Si la région A est saine, suspendre les opérations d’écriture dans la région A et attendre 10 fois la valeur maximale récente de la métrique `ReplicationLatency` serait généralement suffisant pour déterminer si la réplication est terminée. Si la région A n’est pas saine et indique d’autres zones présentant des latences accrues, vous devez choisir un multiple plus élevé pour le temps d’attente. ## Évacuation d’une région déconnectée Il y a un cas particulier à prendre en compte : et si la région A se déconnectait complètement sans préavis ? C’est un cas très peu probable, mais il doit néanmoins être pris en compte. Évacuation d’une table MRSC hors ligne Si cela se produit avec une table MRSC, vous n’avez rien de spécial à faire. Les tables MRSC prennent en charge un objectif de point de reprise (RPO) de zéro. Toutes les opérations d’écriture réussies effectuées sur la table MRSC dans la région hors ligne seront disponibles dans toutes les autres tables de régions. Il n’y a donc aucune lacune potentielle dans les données, même si la région se déconnecte complètement sans préavis. Les entreprises peuvent continuer à utiliser des réplicas situés dans les autres régions. Évacuation d’une table MREC hors ligne Si cela se produit avec une table MREC, toutes les opérations d’écriture dans la région A qui n’ont pas encore été propagées sont conservées et propagées après la remise en ligne de la région A. Les opérations d’écriture ne sont pas perdues, mais leur propagation est retardée indéfiniment. La procédure à suivre dans ce cas dépend de la décision de l’application. Pour la continuité des activités, les opérations d’écriture peuvent devoir être effectuées vers la nouvelle région principale B. Toutefois, si un élément de la région B reçoit une mise à jour alors qu’une opération d’écriture pour cet élément est en attente de propagation depuis la région A, la propagation est supprimée selon le modèle *victoire du dernier auteur*. Toute mise à jour dans la région B peut supprimer une demande d’écriture entrante. Avec le mode *Écrire dans n’importe quelle région*, les opérations de lecture et d’écriture peuvent se poursuivre dans la région B, en sachant que les éléments de la région A finiront par se propager dans la région B et en reconnaissant la possibilité que des éléments soient manquants jusqu’à ce que la région A revienne en ligne. Dans la mesure du possible, comme avec les opérations d’écriture idempotentes, vous devez envisager de rejouer le trafic d’écriture récent (par exemple, en utilisant une source d’événements en amont) afin de combler les lacunes liées aux opérations d’écriture potentiellement manquantes et de laisser la résolution du conflit de la victoire du dernier auteur supprimer la propagation éventuelle de l’opération d’écriture entrante. Avec les autres modes d'écriture, vous devez considérer dans quelle mesure le travail peut se poursuivre avec une légère out-of-date vue du monde. Certaines opérations d’écriture de courte durée, telles que suivies par `ReplicationLatency`, sont absentes jusqu’à ce que la région A revienne en ligne. Les entreprises peuvent-elles aller de l’avant ? Dans certains cas d’utilisation, c’est possible, mais dans d’autres, pas sans des mécanismes d’atténuation supplémentaires. Imaginons par exemple que vous deviez maintenir un solde créditeur disponible sans interruption, même en cas de défaillance complète d’une région. Vous pouvez diviser le solde en deux éléments différents, l’un réservé à la région A et l’autre à la région B, et commencer chacun avec la moitié du solde disponible. Cela utiliserait le mode *Écrire dans votre région*. Les mises à jour transactionnelles traitées dans chaque région seraient comparées à la copie locale du solde. Si la région A est complètement déconnectée, le traitement des transactions pourrait toujours se poursuivre dans la région B et les opérations d’écriture seraient limitées à la partie du solde détenue dans la région B. Le fractionnement du solde introduit des difficultés lorsque le solde baisse ou que le crédit doit être rééquilibré, mais cela fournit un exemple de reprise de l’entreprise sûre, même en cas d’opérations d’écriture incertaines en cours. Autre exemple, imaginez que vous capturez des données de formulaire Web. Vous pouvez utiliser [Optimistic Concurrency Control (OCC)](DynamoDBMapper.OptimisticLocking.md) pour attribuer des versions aux éléments de données et intégrer la dernière version dans le formulaire Web en tant que champ masqué. À chaque envoi, l’opération d’écriture ne réussit que si la version de la base de données correspond toujours à la version avec laquelle le formulaire a été créé. Si les versions ne correspondent pas, le formulaire Web peut être actualisé (ou soigneusement fusionné) avec la version actuelle de la base de données et l’utilisateur peut recommencer. Le modèle OCC offre généralement une protection contre l’écrasement par un autre client et la production d’une nouvelle version des données, mais il peut également être utile en cas de basculement lorsqu’un client peut rencontrer d’anciennes versions des données. Imaginons que vous utilisez l’horodatage comme version. Le formulaire A été créé pour la première fois pour la région A à midi mais qu’il essaie (après le basculement) d’écrire dans la région B et remarque que la dernière version de la base de données est 11 h 59. Dans ce scénario, le client peut soit attendre que la version de 12 h 00 se propage vers la région B, puis écrire sur cette version, soit utiliser la version de 11 h 59 et créer une nouvelle version à 12 h 01 (qui, après écriture, supprime la version entrante une fois la région A rétablie). Troisième exemple, une entreprise de services financiers conserve les données relatives aux comptes clients et à leurs transactions financières dans une base de données DynamoDB. En cas de panne complète de la région A, elle veut s’assurer que toute activité d’écriture liée à ses comptes est entièrement disponible dans la région B, ou elle souhaite mettre ses comptes en quarantaine et les considérer comme partiels jusqu’à ce que la région A revienne en ligne. Au lieu de suspendre toutes les activités, elle a décidé de suspendre uniquement celles de l’infime fraction des comptes qui, selon elle, contenaient des transactions non propagées. Pour ce faire, elle a utilisé une troisième région, que nous appellerons région C. Avant de traiter les opérations d’écriture dans la région A, elle a placé un résumé succinct des opérations en attente (par exemple, un nouveau nombre de transactions pour un compte) dans la région C. Ce résumé était suffisant pour permettre à la région B de déterminer si sa vue était entièrement à jour. Cette action a effectivement verrouillé le compte entre le moment de l’écriture dans la région C et le moment où la région A a accepté les opérations d’écriture et que la région B les a reçues. Les données de la région C n’ont pas été utilisées, sauf dans le cadre d’un processus de basculement, après quoi la région B a pu recouper ses données avec la région C pour vérifier si l’un de ses comptes était obsolète. Ces comptes seraient marqués comme mis en quarantaine jusqu’à ce que la restauration de la région A propage les données partielles vers la région B. En cas de défaillance de la région C, une nouvelle région D pourrait être utilisée à la place. Les données de la région C étaient très transitoires et, au bout de quelques minutes, la région D disposerait d'un up-to-date enregistrement suffisant des opérations d'écriture en vol pour être pleinement utile. En cas d’échec de la région B, la région A pourrait continuer à accepter les demandes d’écriture en coopération avec la région C. Cette entreprise était prête à accepter des écritures à latence plus élevée (vers deux régions : C puis A) et a eu la chance de disposer d’un modèle de données permettant de résumer succinctement l’état d’un compte. # Planification de la capacité de débit pour les tables globales DynamoDB La migration du trafic d’une région vers une autre nécessite un examen attentif des paramètres de la table DynamoDB concernant la capacité. Voici quelques considérations relatives à la gestion de la capacité d’écriture : + Une table globale doit être en mode à la demande ou provisionné avec Auto Scaling activé. + En cas de provisionnement avec Auto Scaling, les paramètres d’écriture (utilisation minimale, maximale et cible) sont répliqués entre les régions. Bien que les paramètres d’autoscaling soient synchronisés, la capacité d’écriture réellement provisionnée peut varier indépendamment entre les régions. + L’une des raisons pour lesquelles vous pouvez constater une capacité d’écriture allouée différente est due à la fonctionnalité de durée de vie. Lorsque vous activez la durée de vie dans DynamoDB, vous pouvez spécifier un nom d’attribut dont la valeur indique l’heure d’expiration de l’élément, au format d’époque Unix, en secondes. Passé ce délai, DynamoDB peut supprimer l’élément sans frais d’écriture. Avec les tables globales, vous configurez la durée de vie dans n’importe quelle région et ce paramètre est répliqué automatiquement dans les autres régions associées à la table globale. Lorsqu’un élément peut être supprimé par le biais d’une règle de durée de vie, ce travail peut être effectué dans n’importe quelle région. L’opération de suppression est effectuée sans consommer d’unités d’écriture sur la table source, mais les tables de réplicas obtiennent une écriture répliquée de cette opération de suppression et entraînent des coûts unitaires d’écriture répliqués. La TTL n’est pas prise en charge dans les tables MRSC. + Si vous utilisez Auto Scaling, assurez-vous que le paramètre de capacité d’écriture maximale provisionnée est suffisamment élevé pour gérer toutes les opérations d’écriture ainsi que toutes les opérations de suppression de la durée de vie potentielles. Auto Scaling ajuste chaque région en fonction de sa consommation d’écriture. Les tables à la demande n’ont pas de paramètre de capacité d’écriture maximale provisionnée, mais la *limite de débit d’écriture maximal au niveau de la table* indique la capacité d’écriture soutenue maximale autorisée par la table à la demande. La limite par défaut est de 40 000, mais elle peut être ajustée. Nous vous recommandons de la définir à un niveau suffisamment élevé pour gérer toutes les opérations d’écriture (y compris les opérations d’écriture de la durée de vie) dont la table à la demande peut avoir besoin. Cette valeur doit être la même dans toutes les régions participantes lorsque vous configurez des tables globales. Voici quelques considérations relatives à la gestion de la capacité de lecture : + Les paramètres de gestion de la capacité de lecture peuvent différer entre les régions car il est supposé que les différentes régions peuvent avoir des modèles de lecture indépendants. La première fois que vous ajoutez un réplica global à une table, la capacité de la région source est propagée. Après sa création, vous pouvez ajuster les paramètres de capacité de lecture, qui ne sont pas transférés de l’autre côté. + Lorsque vous utilisez Auto Scaling de DynamoDB, veillez à ce que les paramètres de capacité de lecture maximale allouée soient suffisamment élevés pour gérer toutes les opérations de lecture dans toutes les régions. Au cours des opérations standard, la capacité de lecture peut être répartie entre les régions, mais lors du basculement, la table doit pouvoir s’adapter automatiquement à l’augmentation de la charge de travail de lecture. Les tables à la demande n’ont pas de paramètre de capacité de lecture maximale provisionnée, mais la *limite de débit de lecture maximal au niveau de la table* indique la capacité de lecture soutenue maximale autorisée par la table à la demande. La limite par défaut est de 40 000, mais elle peut être ajustée. Nous vous recommandons de la définir à un niveau suffisamment élevé pour gérer toutes les opérations de lecture dont la table pourrait avoir besoin si toutes les opérations de lecture devaient être acheminées vers cette région unique. + Si une table d’une région ne reçoit généralement pas de trafic de lecture mais qu’elle doit en absorber une grande partie après un basculement, vous pouvez préchauffer la capacité de la table pour qu’elle accepte un niveau de trafic de lecture supérieur. ARC propose des [contrôles de préparation](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.rules-resources.html) qui peuvent être utiles pour confirmer que les régions DynamoDB possèdent des paramètres de table et des quotas de comptes similaires, que vous utilisiez Route 53 ou non pour acheminer les demandes. Ces contrôles de préparation peuvent également aider à ajuster les quotas au niveau du compte pour s’assurer qu’ils correspondent. # Liste de vérification pour la préparation des tables globales DynamoDB Utilisez la liste de contrôle suivante pour les décisions et les tâches lorsque vous déployez des tables globales. + Déterminez quel mode de cohérence serait plus bénéfique pour votre cas d’utilisation parmi les modes MRSC et MREC. Avez-vous besoin d’une cohérence élevée, même avec une latence supérieure et d’autres compromis ? + Déterminez combien et quelles régions doivent participer à la table globale. Si vous envisagez d’utiliser MRSC, déterminez si vous voulez que la troisième région soit un réplica ou un témoin. + Déterminez le mode d’écriture de votre application. Il est différent du mode de cohérence. Pour de plus amples informations, veuillez consulter [Modes d’écriture avec des tables globales DynamoDB](bp-global-table-design.prescriptive-guidance.writemodes.md). + Planifiez votre stratégie [Stratégies de routage dans DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) en fonction de votre mode d’écriture. + Définissez vos [Processus d’évacuation](bp-global-table-design.prescriptive-guidance.evacuation.md) [ Processus d’évacuation Évacuation d’une région avec des tables globales L’évacuation d’une région est le processus d’activité de migration, généralement des activités de lecture et d’écriture ou des activités d’écriture, hors de cette région. Évacuation d’une région activeRégions actives Évacuation d'une région active Vous pouvez décider d'évacuer une région active pour plusieurs raisons : dans le cadre de vos activités commerciales habituelles (par exemple, si vous utilisez le mode « écrire dans une région ») follow-the-sun, en raison de la décision commerciale de modifier la région actuellement active, en réponse à des défaillances de la pile logicielle en dehors de DynamoDB, ou parce que vous rencontrez des problèmes généraux tels que des latences plus élevées que d'habitude au sein de la région. Avec le mode *Écrire dans n’importe quelle région*, il est facile d’évacuer une région active. Vous pouvez acheminer le trafic vers d’autres régions via n’importe quel système de routage et laisser les opérations d’écriture dans la région évacuée se répliquer comme d’habitude. Les modes Écrire dans une région et Écrire dans votre région sont généralement utilisés avec les tables MREC. Par conséquent, vous devez vous assurer que toutes les opérations d’écriture dans la région active ont été entièrement enregistrées, traitées en flux et propagées globalement avant de commencer les opérations d’écriture dans la nouvelle région active, afin de garantir que les futures opérations d’écriture seront traitées par rapport à la dernière version des données. Supposons que la région A soit active et que la région B soit passive (soit pour la table complète, soit pour les éléments qui se trouvent dans la région A). Le mécanisme habituel pour une évacuation consiste à suspendre les opérations d’écriture vers A, à attendre suffisamment longtemps pour que ces opérations se propagent entièrement vers B, à mettre à jour la pile d’architecture pour reconnaître B comme étant active, puis à reprendre les opérations d’écriture vers B. Aucune métrique n’indique avec une certitude absolue que la région A a entièrement répliqué ses données vers la région B. Si la région A est saine, suspendre les opérations d’écriture dans la région A et attendre 10 fois la valeur maximale récente de la métrique `ReplicationLatency` serait généralement suffisant pour déterminer si la réplication est terminée. Si la région A n’est pas saine et indique d’autres zones présentant des latences accrues, vous devez choisir un multiple plus élevé pour le temps d’attente. Évacuation d’une région déconnectéeRégions déconnectées Évacuation d’une région déconnectée Il y a un cas particulier à prendre en compte : et si la région A se déconnectait complètement sans préavis ? C’est un cas très peu probable, mais il doit néanmoins être pris en compte. Évacuation d’une table MRSC hors ligne Si cela se produit avec une table MRSC, vous n’avez rien de spécial à faire. Les tables MRSC prennent en charge un objectif de point de reprise (RPO) de zéro. Toutes les opérations d’écriture réussies effectuées sur la table MRSC dans la région hors ligne seront disponibles dans toutes les autres tables de régions. Il n’y a donc aucune lacune potentielle dans les données, même si la région se déconnecte complètement sans préavis. Les entreprises peuvent continuer à utiliser des réplicas situés dans les autres régions. Évacuation d’une table MREC hors ligne Si cela se produit avec une table MREC, toutes les opérations d’écriture dans la région A qui n’ont pas encore été propagées sont conservées et propagées après la remise en ligne de la région A. Les opérations d’écriture ne sont pas perdues, mais leur propagation est retardée indéfiniment. La procédure à suivre dans ce cas dépend de la décision de l’application. Pour la continuité des activités, les opérations d’écriture peuvent devoir être effectuées vers la nouvelle région principale B. Toutefois, si un élément de la région B reçoit une mise à jour alors qu’une opération d’écriture pour cet élément est en attente de propagation depuis la région A, la propagation est supprimée selon le modèle *victoire du dernier auteur*. Toute mise à jour dans la région B peut supprimer une demande d’écriture entrante. Avec le mode *Écrire dans n’importe quelle région*, les opérations de lecture et d’écriture peuvent se poursuivre dans la région B, en sachant que les éléments de la région A finiront par se propager dans la région B et en reconnaissant la possibilité que des éléments soient manquants jusqu’à ce que la région A revienne en ligne. Dans la mesure du possible, comme avec les opérations d’écriture idempotentes, vous devez envisager de rejouer le trafic d’écriture récent (par exemple, en utilisant une source d’événements en amont) afin de combler les lacunes liées aux opérations d’écriture potentiellement manquantes et de laisser la résolution du conflit de la victoire du dernier auteur supprimer la propagation éventuelle de l’opération d’écriture entrante. Avec les autres modes d'écriture, vous devez considérer dans quelle mesure le travail peut se poursuivre avec une légère out-of-date vue du monde. Certaines opérations d’écriture de courte durée, telles que suivies par `ReplicationLatency`, sont absentes jusqu’à ce que la région A revienne en ligne. Les entreprises peuvent-elles aller de l’avant ? Dans certains cas d’utilisation, c’est possible, mais dans d’autres, pas sans des mécanismes d’atténuation supplémentaires. Imaginons par exemple que vous deviez maintenir un solde créditeur disponible sans interruption, même en cas de défaillance complète d’une région. Vous pouvez diviser le solde en deux éléments différents, l’un réservé à la région A et l’autre à la région B, et commencer chacun avec la moitié du solde disponible. Cela utiliserait le mode *Écrire dans votre région*. Les mises à jour transactionnelles traitées dans chaque région seraient comparées à la copie locale du solde. Si la région A est complètement déconnectée, le traitement des transactions pourrait toujours se poursuivre dans la région B et les opérations d’écriture seraient limitées à la partie du solde détenue dans la région B. Le fractionnement du solde introduit des difficultés lorsque le solde baisse ou que le crédit doit être rééquilibré, mais cela fournit un exemple de reprise de l’entreprise sûre, même en cas d’opérations d’écriture incertaines en cours. Autre exemple, imaginez que vous capturez des données de formulaire Web. Vous pouvez utiliser [Optimistic Concurrency Control (OCC)](DynamoDBMapper.OptimisticLocking.md) pour attribuer des versions aux éléments de données et intégrer la dernière version dans le formulaire Web en tant que champ masqué. À chaque envoi, l’opération d’écriture ne réussit que si la version de la base de données correspond toujours à la version avec laquelle le formulaire a été créé. Si les versions ne correspondent pas, le formulaire Web peut être actualisé (ou soigneusement fusionné) avec la version actuelle de la base de données et l’utilisateur peut recommencer. Le modèle OCC offre généralement une protection contre l’écrasement par un autre client et la production d’une nouvelle version des données, mais il peut également être utile en cas de basculement lorsqu’un client peut rencontrer d’anciennes versions des données. Imaginons que vous utilisez l’horodatage comme version. Le formulaire A été créé pour la première fois pour la région A à midi mais qu’il essaie (après le basculement) d’écrire dans la région B et remarque que la dernière version de la base de données est 11 h 59. Dans ce scénario, le client peut soit attendre que la version de 12 h 00 se propage vers la région B, puis écrire sur cette version, soit utiliser la version de 11 h 59 et créer une nouvelle version à 12 h 01 (qui, après écriture, supprime la version entrante une fois la région A rétablie). Troisième exemple, une entreprise de services financiers conserve les données relatives aux comptes clients et à leurs transactions financières dans une base de données DynamoDB. En cas de panne complète de la région A, elle veut s’assurer que toute activité d’écriture liée à ses comptes est entièrement disponible dans la région B, ou elle souhaite mettre ses comptes en quarantaine et les considérer comme partiels jusqu’à ce que la région A revienne en ligne. Au lieu de suspendre toutes les activités, elle a décidé de suspendre uniquement celles de l’infime fraction des comptes qui, selon elle, contenaient des transactions non propagées. Pour ce faire, elle a utilisé une troisième région, que nous appellerons région C. Avant de traiter les opérations d’écriture dans la région A, elle a placé un résumé succinct des opérations en attente (par exemple, un nouveau nombre de transactions pour un compte) dans la région C. Ce résumé était suffisant pour permettre à la région B de déterminer si sa vue était entièrement à jour. Cette action a effectivement verrouillé le compte entre le moment de l’écriture dans la région C et le moment où la région A a accepté les opérations d’écriture et que la région B les a reçues. Les données de la région C n’ont pas été utilisées, sauf dans le cadre d’un processus de basculement, après quoi la région B a pu recouper ses données avec la région C pour vérifier si l’un de ses comptes était obsolète. Ces comptes seraient marqués comme mis en quarantaine jusqu’à ce que la restauration de la région A propage les données partielles vers la région B. En cas de défaillance de la région C, une nouvelle région D pourrait être utilisée à la place. Les données de la région C étaient très transitoires et, au bout de quelques minutes, la région D disposerait d'un up-to-date enregistrement suffisant des opérations d'écriture en vol pour être pleinement utile. En cas d’échec de la région B, la région A pourrait continuer à accepter les demandes d’écriture en coopération avec la région C. Cette entreprise était prête à accepter des écritures à latence plus élevée (vers deux régions : C puis A) et a eu la chance de disposer d’un modèle de données permettant de résumer succinctement l’état d’un compte. ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title), en fonction de votre mode de cohérence, de votre mode d’écriture et de votre stratégie de routage. + Capturez des indicateurs sur l’état, la latence et les erreurs dans chaque région. Pour obtenir la liste des métriques DynamoDB, consultez AWS le billet de blog Monitoring [Amazon DynamoDB for Operational Awareness pour obtenir](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) la liste des métriques à observer. Vous devez également utiliser des [canaris synthétiques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (demandes artificielles conçues pour détecter les pannes, du nom du canari de la mine de charbon), ainsi que l’observation en direct du trafic client. Les problèmes n’apparaîtront pas tous dans les métriques de DynamoDB. + Si vous utilisez la MREC, définissez des alarmes en cas d’une augmentation soutenue dans `ReplicationLatency`. Une augmentation peut indiquer une mauvaise configuration accidentelle dans laquelle la table globale possède des paramètres d’écriture différents selon les régions, ce qui entraîne l’échec des demandes répliquées et une augmentation des latences. Cela pourrait également indiquer qu’il y a une perturbation régionale. Un [bon exemple](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) est de générer une alerte si la moyenne récente dépasse 180 000  millisecondes. Vous pouvez également surveiller si la `ReplicationLatency` passe en-dessous de 0, ce qui indique que la réplication est bloquée. + Attribuez des paramètres de lecture et d’écriture maximaux suffisants pour chaque table globale. + Identifiez à l’avance les raisons de l’évacuation d’une région. Si la décision implique un jugement humain, documentez toutes les considérations. Ce travail doit être effectué avec soin à l’avance, sans stress. + Conservez un runbook pour chaque action qui doit avoir lieu lorsque vous évacuez une région. En général, très peu de travail est nécessaire pour les tables globales, mais le déplacement du reste de la pile peut s’avérer complexe. **Note** Avec des procédures de basculement, il est recommandé de se baser uniquement sur les opérations du plan de données et non sur celles du plan de contrôle, car certaines opérations du plan de contrôle peuvent être dégradées en cas de défaillance d’une région. Pour plus d'informations, consultez le billet de AWS blog [Créer des applications résilientes avec les tables globales Amazon DynamoDB](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/) : partie 4. + Testez régulièrement tous les aspects du runbook, y compris les évacuations régionales. Un runbook non testé est un runbook peu fiable. + Envisagez d’utiliser [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) pour évaluer la résilience de l’ensemble de votre application (y compris les tables globales). Il fournit une vue complète du statut de résilience global de votre portefeuille d’applications via son tableau de bord. + Envisagez d’utiliser les contrôles de préparation ARC pour évaluer la configuration actuelle de votre application et suivre tout écart par rapport aux bonnes pratiques. + Lorsque vous écrivez une surveillance de l’état à utiliser avec Route 53 ou Global Accelerator, effectuez une série d’appels qui couvrent l’intégralité du flux de base de données. Si vous limitez votre vérification pour confirmer uniquement que le point de terminaison DynamoDB est actif, vous ne serez pas en mesure de couvrir de nombreux modes de défaillance Gestion des identités et des accès AWS tels que les erreurs de configuration (IAM), les problèmes de déploiement de code, les défaillances de la pile en dehors de DynamoDB, les latences de lecture ou d'écriture supérieures à la moyenne, etc. ## Questions fréquemment posées sur le déploiement des tables globales **Quel est le coût des tables globales ?** + Le prix d'une opération d'écriture dans une table DynamoDB classique est exprimé en unités de capacité d'écriture WCUs (pour les tables provisionnées) ou en unités de demande d'écriture WRUs () pour les tables à la demande. Si vous écrivez un élément de 5 Ko, il implique des frais de 5 unités. Le prix d'une écriture dans une table globale est exprimé en unités de capacité d'écriture répliquées (rWCUs, pour les tables provisionnées) ou en unités de demande d'écriture répliquées (rWRUs, pour les tables à la demande). r WCUs et r WRUs ont le même prix que et. WGUs WRUs + Les changements de rWCU et de rWRU sont facturés dans chaque région où l’élément est écrit directement ou par réplication. Des frais de transfert de données entre régions s’appliquent. + L’écriture dans un index secondaire global (GSI) est considérée comme une opération d’écriture locale et utilise des unités d’écriture normales. + Aucune capacité réservée n'est disponible pour r WCUs ou r pour le WRUs moment. L'achat de capacité réservée WCUs peut être avantageux pour les tables qui GSIs consomment des unités d'écriture. + Lorsque vous ajoutez une nouvelle région à une table globale, DynamoDB démarre automatiquement la nouvelle région et vous facture comme s’il s’agissait d’une restauration de table, en fonction de la taille en Go de la table. Il facture également des frais de transfert de données entre régions. **Quelles sont les régions prises en charge par les tables globales ?** [La version 2019.11.21 (actuelle) de Global Tables](GlobalTables.md) prend en charge toutes les tables MREC et les ensembles de régions suivants Régions AWS pour les tables MRSC : + 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) **Comment sont GSIs gérées les tables globales ?** Dans les [Tables globales version 2019.11.21 (actuelle)](GlobalTables.md), lorsque vous créez un GSI dans une région, il est automatiquement créé dans les autres régions participantes et automatiquement rempli. **Comment arrêter la réplication d’une table globale ?** + Vous pouvez supprimer une table de réplica de la même manière qu’une autre table. La suppression de la table globale arrête la réplication vers cette région et supprime la copie de la table conservée dans cette région. Toutefois, vous ne pouvez pas arrêter la réplication tout en conservant des copies de la table en tant qu’entités indépendantes, ni suspendre la réplication. + Une table MRSC doit être déployée dans exactement trois régions. Pour supprimer les réplicas, vous devez les supprimer entièrement, ainsi que le témoin, afin que la table MRSC devienne une table locale. **Comment DynamoDB Streams interagit-il avec les tables globales ?** + Chaque table globale produit un flux indépendant basé sur toutes ses opérations d’écriture, d’où qu’elles proviennent. Vous pouvez choisir de consommer ce flux DynamoDB dans une région ou dans toutes les régions (indépendamment). Si vous souhaitez traiter des opérations d’écritures locales mais pas répliquées, vous pouvez ajouter votre propre attribut de région à chaque élément afin d’identifier la région d’écriture. Vous pouvez ensuite utiliser un filtre d’événements Lambda pour appeler uniquement la fonction Lambda pour les écritures dans la région locale. Cela facilite les opérations d’insertion et de mise à jour, mais pas les opérations de suppression. + Les tables globales configurées pour une cohérence à terme entre plusieurs régions (tables MREC) répliquent les modifications en lisant ces modifications à partir d’un flux DynamoDB sur une table de réplica et en appliquant cette modification à toutes les autres tables de réplica. DynamoDB est donc activé par défaut sur tous les réplicas d’une table globale MREC et ne peut pas être désactivé sur ces réplicas. Le processus de réplication MREC peut combiner plusieurs modifications en un court laps de temps, en une seule opération d’écriture répliquée. Par conséquent, le flux de chaque réplica peut contenir des enregistrements légèrement différents. Les enregistrements DynamoDB Streams sur les réplicas MREC sont toujours classés par article, mais l’ordre entre les éléments peut différer selon les réplicas. + Les tables globales configurées pour une forte cohérence multi-région (tables MRSC) n’utilisent pas DynamoDB Streams pour la réplication. Cette fonctionnalité n’est donc pas activée par défaut sur les réplicas MRSC. Vous pouvez activer DynamoDB Streams sur un réplica MRSC. Les enregistrements DynamoDB Streams sur les réplicas MRSC sont identiques pour tous les réplicas et sont toujours classés par article, mais l’ordre entre les éléments peut différer selon les réplicas. **Comment les tables globales gèrent-elles les transactions ?** + Les opérations transactionnelles sur les tables MRSC généreront des erreurs. + Les opérations transactionnelles sur les tables MREC offrent des garanties d’atomicité, de cohérence, d’isolation et de durabilité (ACID) uniquement dans la région de laquelle provient l’opération d’écriture. Les transactions ne sont pas prises en charge entre les régions dans les tables globales. Par exemple, si vous avez une table globale MREC avec des réplicas dans les régions USA Est (Ohio) et USA Ouest (Oregon), et que vous réalisez une opération `TransactWriteItems` dans la région USA Est (Ohio), vous remarquerez peut-être des transactions partiellement incomplètes dans la région USA Ouest (Oregon) lorsque les changements sont répliqués. Les modifications seront uniquement répliquées sur les autres régions une fois validées dans la région source. **Comment les tables globales interagissent-elles avec le cache de DynamoDB Accelerator (DAX) ?** Les tables globales contournent le DAX en mettant directement à jour DynamoDB. Ainsi, DAX ne sait pas qu’il contient des données obsolètes. Le cache DAX n’est actualisé que lorsque la durée de vie du cache expire. **Les balises présentes sur les tables se propagent-elles ?** Non, les balises ne se propagent pas automatiquement. **Dois-je sauvegarder des tables dans toutes les régions ou dans une seule ?** La réponse dépend de l’objectif de la sauvegarde. + Si vous souhaitez garantir la durabilité des données, DynamoDB fournit déjà cette garantie. Le service garantit la durabilité. + Si vous souhaitez conserver un instantané des enregistrements historiques (par exemple, pour répondre à des exigences réglementaires), une sauvegarde dans une région doit suffire. Vous pouvez copier la sauvegarde vers d'autres régions en utilisant AWS Backup. + Si vous souhaitez récupérer des données supprimées ou modifiées par erreur, utilisez [DynamoDB point-in-time recovery (PITR](PointInTimeRecovery_Howitworks.md)) dans une région. **Comment déployer des tables globales à l'aide de CloudFormation ?** + CloudFormation représente une table DynamoDB et une table globale sous la forme de deux ressources distinctes : et. `AWS::DynamoDB::Table` `AWS::DynamoDB::GlobalTable` Une méthode consiste à créer toutes les tables susceptibles d’être globales à l’aide de la construction `GlobalTable`, à les conserver dans un premier temps sous forme de tables autonomes et à ajouter des régions ultérieurement, si nécessaire. + Dans CloudFormation, chaque table globale est contrôlée par une seule pile, dans une seule région, quel que soit le nombre de répliques. Lorsque vous déployez votre modèle, il CloudFormation crée et met à jour toutes les répliques dans le cadre d'une opération de pile unique. Vous ne devez pas déployer la même ressource [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) dans plusieurs régions. Cette opération n'est pas prise en charge et entraînera des erreurs. Si vous déployez votre modèle d’application dans plusieurs régions, vous pouvez utiliser des conditions pour ne créer la ressource `AWS::DynamoDB::GlobalTable` que dans une seule région. Vous pouvez également choisir de définir vos ressources `AWS::DynamoDB::GlobalTable` dans une pile distincte de votre pile d’applications et vous assurer qu’elle n’est déployée que dans une seule région. + Si vous avez une table normale et que vous souhaitez la convertir en table globale tout en la gérant, définissez la politique de suppression sur`Retain`, supprimez la table de la pile, convertissez-la en table globale dans la console, puis importez la table globale en tant que nouvelle ressource dans la pile. CloudFormation Pour plus d'informations, consultez le [AWS GitHub référentiel](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk). + La réplication entre comptes n’est pas prise en charge pour le moment. ## 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 : + [Documentation DynamoDB](https://docs.aws.amazon.com/dynamodb/) + [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/) + [Vérification de l'état de préparation dans ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.html) (AWS documentation) + [Politiques de routage 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [AWS Accélérateur mondial](https://aws.amazon.com/global-accelerator/) + [Contrat de niveau de service DynamoDB](https://aws.amazon.com/dynamodb/sla/) + [AWS Principes fondamentaux de plusieurs régions](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) (AWS livre blanc) + [Modèles de conception de résilience des données avec AWS(présentation](https://www.youtube.com/watch?v=7IA48SOX20c)AWS re:Invent 2022) + [Comment Fidelity Investments et Reltio se sont modernisés avec Amazon DynamoDB AWS (](https://www.youtube.com/watch?v=QUpV5MDu4Ys&t=706s)présentation re:Invent 2022) + [Modèles de conception multirégionaux et meilleures pratiques (présentation](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s)AWS re:Invent 2022) + [Architecture de reprise après sinistre (DR) activée AWS, partie III : veilleuse et veille chaude](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (article de AWS blog) + [Utiliser l'épinglage régional pour définir une région d'origine pour les éléments d'une table globale AWS Amazon DynamoDB (](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/)article de blog) + [Surveillance d'Amazon DynamoDB à des fins de connaissance AWS opérationnelle (](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)article de blog) + [Mise à l'échelle de DynamoDB : comment les partitions, les raccourcis clavier et le fractionnement ont un impact sur les performances AWS (article](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/) de blog) + [Forte cohérence multirégionale avec les tables AWS globales de DynamoDB (présentation re:Invent 2024)](https://www.youtube.com/watch?v=R-nTs8ZD8mA)