Comprendre le défi de la cohérence des données dans les Data Stores sans serveur

Les magasins de données sans serveur tels que Amazon DynamoDB, Azure Cosmos DB et Google Cloud Firestore offrent des tarifs auto-échelle, payants à l'utilisation et des frais généraux d'exploitation réduits. Cependant, leur nature distribuée introduit des compromis fondamentaux en matière de cohérence des données. Lorsqu'une application lit des données immédiatement après l'avoir écrit, l'utilisateur s'attend à voir la dernière valeur. Dans un système distribué à l'échelle mondiale, obtenir cette garantie devient non trivial. Le théorèmeCAP nous rappelle qu'un magasin de données distribué ne peut fournir que deux des trois garanties : Consistance, Disponibilité et Tolérance de Partition.

La cohérence des données n'est pas une propriété unique. Différentes charges de travail nécessitent des garanties différentes. Par exemple, un système d'inventaire du commerce électronique ne doit jamais survendre des articles, ce qui exige une forte cohérence pour les mises à jour des stocks. Un flux social-média, par contre, peut tolérer quelques secondes de décalage alors qu'un nouveau post se propage.

Modèles de cohérence dans les magasins sans serveur

Une forte cohérence

Dans les systèmes sans serveur, cela est souvent obtenu en lisant à partir de la réplique primaire ou en utilisant des protocoles basés sur le quorum. Des services comme DynamoDB support scorely consistent reads (à un coût et une latence supplémentaires) et Azure Cosmos DB offre une forte cohérence pour les comptes distribués à l'échelle mondiale en utilisant la réplication multi-master.Utilisez une forte cohérence lorsque les transactions financières, l'authentification des utilisateurs ou les systèmes de réservation nécessitent une précision absolue.

Cohérence événementielle

La cohérence événementielle est la valeur par défaut pour la plupart des data stores sans serveur. Cela signifie que si aucun nouvel écrit n'est fait à un élément de données, éventuellement (généralement en millisecondes ou secondes) toutes les répliques convergeront à la même valeur. Ce modèle fournit la meilleure disponibilité et la latence la plus faible. Il est idéal pour les charges de travail lourdes de lecture, les catalogues de produits et les systèmes de logage où les lectures discontinues sont acceptables pour les fenêtres courtes.

Cohérence causale

Si l'opération A (image de profil mise à jour) se produit avant l'opération B (affiche un commentaire faisant référence à cette image), alors tout observateur verra A avant B. Ce modèle se situe entre une cohérence forte et une cohérence éventuelle et est supporté par des services comme Google Cloud Datastore. Il est utile pour l'édition collaborative, les flux sociaux et les applications de chat où l'ordre des événements compte.

Meilleures pratiques pour maintenir la cohérence

1. Sélectionnez le modèle de cohérence approprié pour chaque opération

Au lieu de choisir un seul niveau de cohérence pour toute votre application, concevez chaque opération critique de lecture ou d'écriture avec sa propre exigence de cohérence. Dans DynamoDB, vous pouvez spécifier pour les appels individuels ou tout en laissant d'autres lectures éventuellement cohérentes.

2. Utiliser les transactions distribuées avec Sagas ou un engagement à deux phases

Lorsqu'un processus d'entreprise couvre plusieurs dépôts de données ou services, vous avez besoin d'un mécanisme pour maintenir l'atomique. Les transactions distribuées – comme le protocole commit (2PC) en deux phases – garantissent que chaque partie participante s'engage ou avorte ensemble. Cependant, 2PC peut être lent et réduire la disponibilité. Une alternative est le Saga pattern, où chaque opération émet un événement qui déclenche des actions compensatoires si quelque chose échoue.

3. Mettre en oeuvre des stratégies de règlement des conflits

Les magasins sans serveur utilisent généralement les derniers writers-wins (LWW)[, qui conserve le plus récent chronomètre. Bien que simple, LWW peut perdre des données si les horloges sont hors de synchronisation. Pour la sémantique plus riche, utilisez les vecteurs de version[ ou les CRD (Types de données repliés libres de conflits)[. DynamoDB=s met à jour et les champs de version conditionnelles vous permettent d'implémenter un verrouillage optimiste avec une résolution de conflits personnalisée. Cosmos DB fournit des politiques de résolution de conflits multiples, y compris des procédures stockées sur mesure qui fusionnent des versions contradictoires.

4. Tirer parti des opérations et des retraits d'idéopôts

Les défaillances réseau ou les erreurs transitoires peuvent entraîner des retraits clients, ce qui pourrait entraîner un traitement en double. La conception des opérations est idempotent élimine ce risque. Par exemple, assigner une clé unique d'idempotency à chaque requête écrite; le serveur peut ensuite dédoubler les requêtes qui partagent la même clé.

5. Surveiller l'intégrité des données avec les flux de changement et les vérifications

Dans un environnement sans serveur, vous pouvez utiliser change data capture (CDC) des fonctionnalités comme DynamoDB Streams, Cosmos DB Change Feed ou Firestore. Configurez une fonction lambda ou cloud pour valider les invariants de données après chaque changement. Par exemple, une application bancaire peut s'abonner aux transactions de compte et vérifier que le solde est toujours égal à la somme des crédits moins les débits.

6. Optimisez la réplication des données pour votre cas d'utilisation

La réplication mondiale améliore la latence pour les utilisateurs du monde entier, mais augmente la fenêtre pour les incohérences. Configurez la réplication avec le niveau de cohérence approprié et envisagez d'utiliser active-active[ vs. active-passive topologies. Active-active (multi-master) offre une latence d'écriture inférieure, mais nécessite une résolution de conflit robuste. Active-passive (unique primaire avec répliques lues) offre une cohérence plus forte pour les écrits tout en servant encore les lectures de la réplique la plus proche.

Les modèles architecturaux qui préservent la cohérence

Ségrégation des responsabilités des requêtes de commandement (CQRS)

Les écrits vont à un magasin fortement cohérent; les lectures proviennent de projections finalement cohérentes. Ce modèle est particulièrement puissant lorsqu'il est combiné avec une approche de l'approvisionnement d'événements[, où tous les changements d'état sont stockés comme des événements immuables. Les modèles de lecture peuvent être reconstruits à partir du journal d'événements si des problèmes de cohérence se posent. Martin Fowlers article sur CQRS fournit un excellent aperçu.

Sourcing événementiel et cohérence événementielle

Les services comme DynamoDB ou Cosmos DB peuvent agir comme magasins d'événements. Les consommateurs traitent les événements de façon asynchrone, ils finissent par construire des modèles de lecture. Dans le cas rare d'un conflit, vous pouvez rejouer le flux d'événements à partir d'un point de contrôle connu. Ce modèle assure durabilité et auditabilité[ tout en rendant simple à raisonner sur les limites de cohérence.

Motif de boîte de réception pour la messagerie fiable

Lorsqu'une fonction sans serveur écrit à une base de données et envoie ensuite un message à une file d'attente, les deux opérations peuvent ne pas être atomiques. Le modèle outbox résout cela en stockant le message dans la même base de données dans la même transaction. Un processus séparé (comme un processeur de flux) lit la boîte de sortie et publie le message. Cela garantit que la base de données écrit et le message envoyé sont à la fois engagés ou roulés, préservant la cohérence entre les services.

Traitement des cas spéciaux : Geo-Distribution et écritures hors ligne

Les applications mobiles et IoT fonctionnent souvent hors ligne et se synchronisent plus tard. Les SDK fournisseurs sans serveur fournissent une persistance hors ligne avec synchronisation qui gère les conflits via des résolveurs de conflits personnalisés. Par exemple, AWS AppSync avec DynamoDB peut fusionner des versions basées sur des horodatages ou une logique définie par le client.

Pour une cohérence multi-régions, utilisez groupes de cohérence[ si possible—un concept soutenu par Cosmos DB qui regroupe les éléments liés de sorte qu'ils soient toujours reproduits ensemble. Cela empêche les scénarios où une image de profil utilisateur est mise à jour dans la région A mais leur mise à jour biologique (dans le même groupe) n'est pas encore arrivée dans la région B.

Stratégies d'essai et de validation

Les bogues de cohérence ne se retrouvent souvent que sous des charges distribuées. Les tests d'intégration qui fonctionnent contre un réel émulateur sans serveur ou une instance cloud et simulent des écritures et des lectures simultanées. Des outils comme Jepsen peuvent vérifier que votre data store se comporte correctement sous des partitions réseau. Pour la production, implémentez des déploiements canari et déplacez progressivement le trafic vers de nouveaux chemins de code tout en surveillant les mesures de cohérence.

Résumé

La cohérence des données dans les magasins de données sans serveur nécessite des choix architecturaux délibérés. En comprenant les modèles de cohérence disponibles, en utilisant des transactions distribuées ou le modèle de saga, en concevant des opérations idéopontiques et en tirant parti des mécanismes de résolution de conflits, vous pouvez construire des applications à la fois évolutives et fiables. Surveillez votre système grâce à des flux de changement et des audits, et adoptez des modèles comme CQRS, le sourcing d'événements et le modèle de boîte de réception pour maintenir l'intégrité au-delà des limites des services.