Liste de contrôle pour la préparation des tableaux globaux et des questions fréquemment posées

Utilisez la liste de contrôle suivante pour les décisions et les tâches lorsque vous déployez des tables globales.

• Déterminez combien et quelles régions doivent participer à la table globale.

• Déterminez le mode d'écriture de votre application. Pour de plus amples informations, veuillez consulter Modes d'écriture avec des tables globales.

• Planifiez votre stratégie Routage des demandes avec des tables globales en fonction de votre mode d'écriture.

• Définissez votre plan d'évacuation en fonction 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 le AWS article de blog Surveillance d'Amazon DynamoDB à des fins de sensibilisation opérationnelle pour obtenir une liste de mesures à observer. Vous devez également utiliser des canaris synthétiques (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.

• Réglez des alarmes en cas d'une augmentation soutenue de la 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 est de générer une alerte si la moyenne récente dépasse 180 000  millisecondes. Vous pouvez également surveiller la ReplicationLatency chute à 0, ce qui indique un blocage de la réplication.

• 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

  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 AWS billet de blog Créez des applications résilientes avec les tables globales Amazon DynamoDB : 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 Resilience Hub 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 des contrôles de ARC préparation pour évaluer la configuration actuelle de votre application et suivre tout écart par rapport aux meilleures pratiques.

• Lorsque vous rédigez une surveillance de l'état à utiliser avec Route 53 ou Global Accelerator, il ne suffit pas d'effectuer simplement un ping pour vérifier que le point de terminaison DynamoDB est opérationnel. Cela ne couvre pas les nombreux modes de défaillance tels que les erreurs de IAM configuration, les problèmes de déploiement du code, les défaillances de la pile en dehors de DynamoDB, les latences de lecture ou d'écriture supérieures à la moyenne, etc. Il est préférable d'effectuer une série d'appels qui sollicitent un flux de base de données complet.

Questions fréquemment posées (FAQ) pour le déploiement de tables globales

Quels sont les principes utiles pour l'utilisation générale des tables globales DynamoDB ?

Les tables globales DynamoDB ne comportent que très peu de boutons de commande, mais elles nécessitent tout de même un certain nombre de considérations. 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. Votre récompense est de disposer d'un jeu de données distribué dans le monde entier avec une faible latence de lecture et d'écriture et un contrat de niveau de service de 99,999 %.

Quel est le coût des tables globales ?

Une écriture dans une table DynamoDB traditionnelle est facturée 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 (rWCUspour les tables provisionnées) ou en unités de demande d'écriture répliquées (rWRUs, pour les tables à la demande).

Les rWCUs et rWRUs incluent le coût de l'infrastructure de streaming nécessaire pour gérer la réplication. En tant que tels, leur prix est 50 % plus élevé que WCUs etWRUs. Des frais de transfert de données entre régions s'appliquent.

Des frais d'unité d'écriture répliquée sont facturés dans chaque région où l'élément est écrit directement ou en écriture répliquée.

L'écriture dans un index secondaire global (GSI) est considérée comme une écriture locale et utilise des unités d'écriture normales.

Aucune capacité réservée n'est disponible pour le rWCUs moment. L'achat de capacité réservée peut toujours être avantageux pour les tables GSIs consommant des unités d'écriture.

L'amorçage initial lors de l'ajout d'une nouvelle région à une table globale est facturé comme une restauration par Go de données restaurées, plus les 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 est disponible dans la plupart des régions. Vous pouvez consulter la liste la plus récente dans la liste déroulante des régions de la console DynamoDB lorsque vous ajoutez un réplica.

Comment sont GSIs gérées les tables globales ?

Dans la version 2019.11.21 (actuelle) de Global Tables, lorsque vous créez un fichier 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.

Comment DynamoDB Streams interagit-il avec les tables globales ?

Chaque table globale produit un flux indépendant basé sur toutes ses écritures, 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 malheureusement pas les opérations de suppression.

Comment les tables globales gèrent-elles les transactions ?

Les opérations transactionnelles fournissent des garanties d'atomicité, de cohérence, d'isolation et de durabilité (ACID) uniquement dans la région où l'opération d'écriture a eu lieu initialement. Les transactions ne sont pas prises en charge entre les régions dans les tables globales. Par exemple, si vous avez une table globale 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 l'accélérateur DynamoDB () ? DAX

Les tables globales contournent DynamoDB DAX en mettant directement à jour DynamoDB. Elle ne se rend DAX donc pas compte qu'elle contient des données périmées. Le DAX cache est actualisé uniquement lorsque le cache TTL 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 () dans une région. PITR

Comment déployer des tables globales à l'aide de AWS 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 approche consiste à créer toutes les tables susceptibles d'être globales à l'aide de la construction GlobalTable. Vous pouvez les conserver sous forme de tables autonomes pour commencer, puis les ajouter ultérieurement aux régions 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 GlobalTable ressource AWS: :DynamoDB : : 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

La réplication entre comptes n’est pas prise en charge pour le moment.