Liste de vérification pour la préparation des tables globales DynamoDB

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 en savoir plus, consultez Modes d’écriture avec des tables globales DynamoDB.

Planifiez votre stratégie Stratégies de routage dans DynamoDB en fonction de votre mode d’écriture.

Définissez vos Processus d’évacuation , 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 le billet de blog AWS Surveillance d’Amazon DynamoDB pour la connaissance opérationnelle pour une liste des métriques à 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.

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

Pour plus d’informations, consultez le billet de blog AWS Création d’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 AWS 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 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. En limitant votre vérification uniquement à la confirmation que le point de terminaison DynamoDB est actif, vous ne serez pas en mesure de couvrir de nombreux modes de défaillance tels que les erreurs de configuration AWS Identity and Access Management (IAM), les problèmes de déploiement de code, les défaillances de la pile externe à DynamoDB, les latences de lecture ou d’écriture supérieures à la moyenne, etc.

Le coût d’une opération d’écriture dans une table DynamoDB classique est exprimé en unités de capacité d’écriture (WCU) pour les tables provisionnées ou en unités de demande d’écriture (WRU) pour les tables à la demande. Si vous écrivez un élément de 5 Ko, il implique des frais de 5 unités. Le coût d’une écriture dans une table globale est exprimé en unités de capacité d’écriture répliquée (rWCU pour les tables provisionnées) ou en unités de demande d’écriture répliquée (rWRU, pour les tables à la demande). Les rWCU et les rWRU possèdent le même tarif que les WGU et WRU.

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 les rWCU ou les rWRU pour le moment. L’achat de capacité réservée pour les WCU peut être avantageux pour les tables dont les GSI 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.

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)

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.

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.

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.

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 la récupération ponctuelle (PITR) de DynamoDB dans une région.

CloudFormation représente une table DynamoDB et une table globale sous la forme de deux ressources distinctes : AWS::DynamoDB::Table et 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éplicas. Lorsque vous déployez votre modèle, CloudFormation crée et met à jour tous les réplicas dans le cadre d’une opération de pile unique. Vous ne devez pas déployer la même ressource AWS::DynamoDB::GlobalTable 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 possédez une table traditionnelle et que vous souhaitez la convertir en table globale tout en la maintenant gérée par CloudFormation, puis 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. Pour plus d’informations, consultez le référentiel GitHub AWS.

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