Mode Écrire dans une région (primaire unique)

Le mode d'écriture dans une région, illustré dans le schéma suivant, est actif-passif et achemine toutes les opérations d'écriture de table vers une seule région active. (DynamoDB n'a pas la notion de région active unique ; c'est la couche extérieure à DynamoDB qui gère cela.) Le mode écriture dans une région fonctionne bien pour les tables MREC qui doivent éviter les conflits d'écriture en veillant à ce que les opérations d'écriture ne soient effectuées que vers une seule région à la fois. Ce mode d'écriture est utile lorsque vous souhaitez utiliser des expressions conditionnelles et que vous ne pouvez pas utiliser 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 à une seule région disposant des données les plus récentes.

Lorsque vous utilisez un tableau MRSC, vous pouvez choisir d'écrire généralement à 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 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.

À terme, des opérations de lecture cohérentes peuvent être effectuées dans n'importe quelle région de réplication afin de réduire les latences. Les opérations de lecture hautement cohérentes doivent être dirigées vers la seule région principale.

Il est parfois nécessaire de changer de région active en réponse à un échec régional, comme nous le verrons plus loin. Certains utilisateurs modifient régulièrement la région actuellement active, par exemple en mettant en œuvre un follow-the-sundé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 le code qui change de région tous les jours et de s'assurer qu'il est bien testé avant toute reprise après sinistre.

La ou les régions passives peuvent conserver une infrastructure réduite entourant DynamoDB qui ne sera construite que si elle devient la région active. Ce guide ne couvre pas les modèles de veilleuse et de veille chaude. Pour plus d'informations, vous pouvez lire le billet de blog Disaster Recovery (DR) Architecture on AWS, Part III : Pilot Light and Warm Standby.

L'utilisation du mode écriture dans une région fonctionne bien lorsque vous utilisez des tables globales pour des opérations de lecture distribuées dans le monde entier à 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. Ils ne mettent pas souvent à jour les données, mais lorsqu'ils le font, ils n'écrivent que dans une seule région afin d'éviter tout conflit d'écriture potentiel. Les opérations de lecture sont toujours autorisées depuis n'importe quelle région.

Prenons comme autre exemple la société de services financiers mentionnée précédemment qui a mis en œuvre le calcul du remboursement quotidien. Ils ont utilisé le mode écriture dans n'importe quelle région pour calculer le solde, mais écrire dans un mode 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 une écriture dans un mode Région.