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.

Modes d'écriture avec les tables globales DynamoDB

Les tables globales sont toujours actives-actives au niveau de la table. Toutefois, 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 d'éventuels conflits d'écriture.

Il existe trois catégories principales de modèles d'écriture gérés :

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 bonnes pratiques générales peuvent varier en fonction 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 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. C'est le mode le plus simple. Il ne peut être utilisé qu'avec certains types d'applications. Il convient 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 lorsque le risque d'écritures conflictuelles est acceptable.

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 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, les services de streaming vidéo utilisent souvent des tables globales pour suivre les favoris, les avis, les indicateurs du statut des visionnages, etc. Ces déploiements peuvent utiliser le mode Écrire dans n'importe quelle région, à condition de s'assurer que chaque écriture est idempotente et que la valeur correcte suivante pour un élément ne dépend pas de sa valeur actuelle. C'est le cas pour les mises à jour utilisateur qui attribuent directement le nouvel état à l'utilisateur, telles que la définition d'un nouveau code horaire, l'attribution d'un nouvel avis ou la définition d'un nouveau statut de surveillance. 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. Les nouvelles transactions arrivent du monde entier et vont vers plusieurs régions. Pour leur conception actuelle, qui ne tire pas parti des tableaux globaux, ils utilisent un seul article Running Balance par client. Les actions du client mettent à jour le solde avec une ADD expression, qui n'est pas idempotente car la nouvelle valeur correcte dépend de la valeur actuelle. Cela signifie que le solde n'était plus synchronisé si deux opérations d'écriture étaient effectuées sur le même solde à peu près au même moment dans différentes régions.

Cette même entreprise a pu mettre en œuvre le mode Écrire dans n'importe quelle région grâce à une nouvelle conception minutieuse des tables globales de DynamoDB. La nouvelle conception pourrait suivre un modèle de « diffusion d'événements », essentiellement un registre avec un flux de travail à ajout seulement. Chaque action du client ajoute un nouvel élément à la collection d'éléments gérée pour ce client. La collection d'éléments est l'ensemble des éléments qui partagent une clé primaire, avec des clés de tri différentes. Chaque action d'écriture qui ajoute l'action du client est une insertion idempotente, utilisant l'ID client comme clé de partition et l'ID de transaction comme clé de tri. Cette conception rend le calcul du solde plus complexe, car elle nécessite une Query pour récupérer les éléments, puis quelques calculs côté client. Mais l'avantage est qu'elle rend toutes les écritures idempotentes, ce qui simplifie considérablement le routage et le basculement. Pour plus d'informations, voir Routage des demandes avec les tables globales DynamoDB.

Comme troisième exemple, supposons qu'un client mette des publicités en ligne. Il 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'il diffuse des publicités, il ne dispose que de quelques millisecondes pour récupérer 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 pour cet utilisateur. Grâce aux tables globales, il peut obtenir à la fois des lectures à faible latence pour les utilisateurs finaux du monde entier et des écritures à faible latence. Il peut enregistrer toutes les impressions publicitaires d'un utilisateur au sein d'un seul élément et le représenter sous la forme d'une liste croissante. Il peut utiliser un seul élément au lieu de l'ajouter à une collection d'éléments, car il peut ainsi supprimer les anciennes impressions publicitaires à chaque écriture sans avoir à payer pour une suppression. Cette opération d'écriture est NOT idempotente. Ainsi, si le même utilisateur final voit des publicités diffusées depuis plusieurs régions à peu près au même moment, il est possible qu'une impression publicitaire remplace l'autre. Pour la mise en ligne de publicités, le risque qu'un utilisateur voie occasionnellement une publicité répétée vaut la peine d'opter pour cette conception plus simple et plus efficace.

Primaire unique (« Écrire dans une région »)

Le mode Écrire dans une région 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 évite les conflits d'écriture en garantissant que les écritures ne circulent que vers une région à la fois. Ce mode d'écriture est utile lorsque vous souhaitez utiliser des expressions conditionnelles ou des transactions, car elles ne fonctionnent que si vous savez que vous agissez en fonction des données les plus récentes. L'utilisation d'expressions conditionnelles et de transactions nécessite donc d'envoyer toutes les demandes d'écriture à la région disposant des données les plus récentes.

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.

Il est parfois nécessaire de modifier la région active en réponse à une défaillance régionale, afin de faciliter la gestion des données. Évacuation d'une région à l'aide de tables globales DynamoDBest un exemple de ce cas d'utilisation. Certains clients modifient la région actuellement active selon un calendrier régulier, par exemple dans le cadre d'un déploiement 24 h/24. La région active est ainsi placée à proximité de la zone géographique la plus active, ce qui lui confère la latence de lecture et d'écriture la plus faible. Cela présente également l'avantage d'appeler quotidiennement le chemin de 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. Pour une discussion plus approfondie sur les conceptions de veilleuse et de veille chaude, voir 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 exploitez des tables globales pour des lectures distribuées à l'échelle mondiale à faible latence. Par exemple, une grande entreprise de réseaux sociaux compte des millions d'utilisateurs et des milliards de publications. Chaque utilisateur se voit attribuer une région au moment de la création de son compte, située géographiquement à proximité de son emplacement. Toutes leurs données sont enregistrées dans cette table non globale. L'entreprise utilise une table globale distincte pour cartographier les utilisateurs à leur région d'origine, à l'aide d'un mode Écrire dans une région. Elle conserve des copies en lecture seule dans le monde entier afin de pouvoir localiser directement les données de chaque utilisateur avec un minimum de latence supplémentaire. Les mises à jour sont rares (uniquement lors du passage de la région d'origine d'un utilisateur à une autre) et passent toujours par une région pour l'écriture, afin d'éviter tout risque de conflit d'écriture.

Autre exemple : un client du secteur des services financiers a mis en œuvre un calcul de remise en argent quotidien. Il utilise le mode Écrire dans n'importe quelle région pour calculer le solde, mais utilise le mode Écrire dans une région pour suivre les paiements de remise en argent réels. S'il souhaite récompenser un client d'un centime pour chaque tranche de 10 $ dépensés par jour, il devra utilise Query pour toutes les transactions effectuées la veille, calculer le montant total dépensé, inscrire la décision de remise en argent sur une nouvelle table, supprimer l'ensemble des éléments demandé pour les marquer comme consommés et les remplacer par un élément unique contenant le montant restant qui devrait être pris en compte dans les calculs du jour suivant. Ce travail nécessite des transactions et fonctionne donc mieux avec le mode Écrire dans une région. Une application peut mélanger les modes d'écriture, même sur la même table, tant que les charges de travail ne risquent pas de se chevaucher.

Primaire mixte (« Écrire dans votre région »)

Le mode Écrire dans votre région attribue différents sous-ensembles de données à différentes régions et n'autorise les opérations d'écriture qu'aux éléments de sa région d'origine. Ce mode est actif-passif mais attribue 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 écritures doivent être protégées pour garantir une localisation correcte.

Ce mode est similaire à Écrire dans une région, sauf qu'il permet des écritures à faible latence, car les données associées à chaque utilisateur final 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.

La région d'origine des éléments peut être déterminée de diverses manières :

Imaginons que vous travaillez pour une entreprise de jeux vidéo. Vous avez besoin de lectures et d'écritures à faible latence pour tous les joueurs du monde entier. Vous pouvez placer chaque joueur dans la région la plus proche de lui. Cette région prend en charge toutes leurs lectures et écritures, garantissant ainsi une read-after-write cohérence constante. Toutefois, si ce 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. Ainsi, le joueur peut être affecté à une région d'origine différente, si nécessaire.

Autre exemple, imaginez que vous travaillez pour une entreprise de visioconférence. Les métadonnées de chaque conférence téléphonique 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.