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. # 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.