Deuxième élément fondamental pour plusieurs régions : comprendre les données

La gestion des données n'est pas un problème trivial lorsque vous adoptez des architectures multirégionales. La distance géographique entre les régions impose une latence inévitable qui se traduit par le temps nécessaire pour répliquer les données entre les régions. Des compromis entre la disponibilité, la cohérence des données et l'introduction d'une latence plus élevée dans une charge de travail utilisant une architecture multirégionale seront nécessaires. Que vous utilisiez la réplication asynchrone ou synchrone, vous devez modifier votre application pour gérer les changements de comportement imposés par la technologie de réplication. Les défis liés à la cohérence des données et à la latence font qu'il est très difficile de transformer une application existante conçue pour une seule région en une application multirégionale. Il est essentiel de comprendre les exigences de cohérence des données et les modèles d'accès aux données pour des charges de travail particulières pour évaluer les compromis.

2.a : Comprendre les exigences de cohérence des données

Le théorème CAP fournit une référence pour raisonner sur les compromis entre la cohérence des données, la disponibilité et les partitions du réseau. Seules deux de ces exigences peuvent être satisfaites en même temps pour une charge de travail. Par définition, une architecture multirégionale inclut des partitions réseau entre les régions. Vous devez donc choisir entre disponibilité et cohérence.

Si vous sélectionnez la disponibilité des données entre les régions, vous ne subirez pas de latence importante lors des opérations d'écriture transactionnelles, car le recours à la réplication asynchrone des données validées entre les régions réduit la cohérence entre les régions jusqu'à la fin de la réplication. Avec la réplication asynchrone, en cas de défaillance dans la région principale, il est fort probable que les opérations d'écriture soient en attente de réplication depuis la région principale. Cela conduit à un scénario dans lequel les données les plus récentes ne sont pas disponibles tant que la réplication ne reprend pas, et un processus de rapprochement est nécessaire pour gérer les transactions en cours qui n'ont pas été répliquées depuis la région ayant subi l'interruption. Ce scénario nécessite de comprendre votre logique métier et de créer un processus spécifique pour rejouer la transaction ou comparer les banques de données entre les régions.

Pour les charges de travail où la réplication asynchrone est privilégiée, vous pouvez utiliser des services tels qu'Amazon Aurora et Amazon DynamoDB pour la réplication asynchrone entre régions. Les bases de données mondiales Amazon Aurora et les tables globales Amazon DynamoDB disposent de métriques CloudWatchAmazon par défaut pour faciliter le suivi du délai de réplication. Une base de données globale Aurora se compose d'une région principale dans laquelle vos données sont écrites et d'un maximum de cinq régions secondaires en lecture seule. Les tables globales DynamoDB se composent de tables de répliques multiactives couvrant un nombre illimité de régions dans lesquelles vos données sont écrites et lues.

L'ingénierie de la charge de travail pour tirer parti des architectures axées sur les événements constitue un avantage pour une stratégie multirégionale, car cela signifie que la charge de travail peut inclure la réplication asynchrone des données et permet la reconstruction de l'état en rejouant les événements. Étant donné que les services de streaming et de messagerie mettent en mémoire tampon les données utiles des messages dans une seule région, un processus de basculement ou de retour en arrière régional doit inclure un mécanisme permettant de rediriger les flux de données d'entrée des clients. Le processus doit également concilier les charges utiles en vol ou non livrées stockées dans la région qui a subi la perturbation.

Si vous optez pour l'exigence de cohérence CAP et que vous utilisez une base de données répliquée de manière synchrone entre les régions pour prendre en charge vos applications exécutées simultanément à partir de plusieurs régions, vous éliminez le risque de perte de données et vous maintenez les données synchronisées entre les régions. Cependant, cela introduit des caractéristiques de latence plus élevées, car les écritures doivent être validées dans plusieurs régions, et les régions peuvent se trouver à des centaines ou des milliers de kilomètres les unes des autres. Vous devez tenir compte de cette caractéristique de latence dans la conception de votre application. En outre, la réplication synchrone peut entraîner des défaillances corrélées, car les écritures devront être validées dans plusieurs régions pour réussir. S'il y a un handicap dans une région, vous devrez réunir un quorum pour que les écritures soient couronnées de succès. Cela implique généralement de configurer votre base de données dans trois régions et d'établir un quorum de deux régions sur trois. Les technologies telles que Paxos peuvent aider à répliquer et à valider les données de manière synchrone, mais nécessitent un investissement important pour les développeurs.

Lorsque les écritures impliquent une réplication synchrone entre plusieurs régions pour répondre à de fortes exigences de cohérence, la latence d'écriture augmente d'un ordre de grandeur. Une latence d'écriture plus élevée n'est généralement pas quelque chose que vous pouvez intégrer à une application sans modifications importantes, telles que la révision du délai d'expiration et de la stratégie de nouvelle tentative de votre application. Idéalement, il doit être pris en compte lors de la conception initiale de l'application. Pour les charges de travail multirégionales où la réplication synchrone est une priorité, les AWS Partner solutions peuvent être utiles.

2.b : Comprendre les modèles d'accès aux données

Les modèles d'accès aux données de charge de travail nécessitent beaucoup de lecture ou d'écriture. Comprendre cette caractéristique pour une charge de travail particulière vous aidera à sélectionner une architecture multirégionale appropriée.

Pour les charges de travail intensives en lecture, telles que le contenu statique entièrement en lecture seule, vous pouvez obtenir une architecture multirégion active-active qui présente une complexité d'ingénierie moindre par rapport à une charge de travail intensive en écriture. La diffusion de contenu statique à la périphérie à l'aide d'un réseau de diffusion de contenu (CDN) garantit la disponibilité en mettant en cache le contenu le plus proche de l'utilisateur final ; l'utilisation d'ensembles de fonctionnalités tels que le basculement d'origine au sein d'Amazon CloudFront peut y contribuer. Une autre option consiste à déployer le calcul sans état dans plusieurs régions et à utiliser le DNS pour acheminer les utilisateurs vers la région la plus proche afin de lire le contenu. Pour ce faire, vous pouvez utiliser Amazon Route 53 avec une politique de routage par géolocalisation.

Pour les charges de travail intensives en lecture dont le pourcentage de trafic en lecture est supérieur à celui du trafic en écriture, vous pouvez utiliser une stratégie globale de lecture locale et d'écriture globale. Cela signifie que toutes les demandes d'écriture sont envoyées à une base de données d'une région spécifique, que les données sont répliquées de manière asynchrone dans toutes les autres régions et que les lectures peuvent être effectuées dans n'importe quelle région. Cette approche nécessite une charge de travail pour garantir la cohérence finale, car les lectures locales peuvent devenir obsolètes en raison de l'augmentation de la latence lors de la réplication interrégionale des écritures.

Les bases de données globales Aurora peuvent aider à fournir des répliques de lecture dans une région de secours qui peut uniquement gérer l'ensemble du trafic de lecture localement, et à fournir un seul magasin de données principal dans une région spécifique pour gérer le trafic d'écriture. Les données sont répliquées de manière asynchrone de la base de données principale vers les bases de données de secours (répliques en lecture), et les bases de données de secours peuvent être promues au statut principal si vous devez transférer des opérations vers la région de secours. Vous pouvez également utiliser DynamoDB dans le cadre de cette approche. Les tables globales DynamoDB peuvent fournir des répliques de tables réparties dans différentes régions, chacune pouvant être dimensionnée pour prendre en charge n'importe quel volume de trafic local de lecture ou d'écriture. Quand une application écrit des données dans une table de réplique dans une région, DynamoDB propage automatiquement l'écriture aux autres tables de réplique dans les autres régions . Avec cette configuration, les données sont répliquées de manière asynchrone depuis une région principale définie vers des tables de réplication dans des régions de secours. Les tables de réplication de n'importe quelle région peuvent toujours accepter des écritures. La promotion d'une région de secours au statut de région principale est donc gérée au niveau de l'application. Encore une fois, la charge de travail doit être cohérente, ce qui peut nécessiter une réécriture si elle n'a pas été conçue pour cela dès le départ.

Pour les charges de travail intensives en écriture, une région principale doit être sélectionnée et la capacité de basculer vers une région de secours doit être intégrée à la charge de travail. Par rapport à une approche active-active, une approche de veille primaire comporte des compromis supplémentaires. En effet, pour une architecture active-active, la charge de travail doit être réécrite pour gérer le routage intelligent vers les régions, établir une affinité de session, garantir des transactions idempotentes et gérer les conflits potentiels.

La plupart des charges de travail qui utilisent une approche multirégionale pour la résilience ne nécessiteront pas une approche active-active. Vous pouvez utiliser une stratégie de sharding pour renforcer la résilience en limitant l'impact d'une dépréciation sur l'ensemble de la clientèle. Si vous pouvez partager efficacement une base de clients, vous pouvez sélectionner différentes régions principales pour chaque partition. Par exemple, vous pouvez partager des clients de manière à ce que la moitié des clients soient alignés sur la région 1 et l'autre moitié sur la région deux. En traitant les régions comme des cellules, vous pouvez créer une approche cellulaire multirégionale, ce qui permet de réduire l'impact sur votre charge de travail. Pour plus d'informations, consultez la présentation AWS re:Invent sur cette approche.

Vous pouvez combiner l'approche de partitionnement avec une approche de veille principale afin de fournir des fonctionnalités de basculement pour les partitions. Vous devrez concevoir un processus de basculement testé adapté à la charge de travail ainsi qu'un processus de réconciliation des données, afin de garantir la cohérence transactionnelle des banques de données après le basculement. Elles sont abordées plus en détail plus loin dans ce guide.

Principaux conseils

• Il est fort probable que les écritures en attente de réplication ne soient pas validées dans la région de secours en cas d'échec. Les données ne seront pas disponibles jusqu'à ce que la réplication reprenne (dans l'hypothèse d'une réplication asynchrone).

• Dans le cadre du basculement, un processus de réconciliation des données sera nécessaire pour garantir le maintien d'un état de cohérence transactionnelle pour les magasins de données utilisant la réplication asynchrone. Cela nécessite une logique métier spécifique et n'est pas géré par le magasin de données lui-même.

• Lorsqu'une forte cohérence est requise, les charges de travail doivent être modifiées pour tolérer la latence requise d'un magasin de données qui se réplique de manière synchrone.