Transactions distribuées, sagas et patron outbox

Le problème : une action métier, plusieurs bases de données

Dans une seule base de données, une transaction rend atomiques plusieurs modifications : la ligne de la commande, ses articles et la référence du paiement sont tous enregistrés, ou aucun ne l’est (section 0.5). Dès que les données sont réparties entre des services qui possèdent chacun leur base de données, comme le recommandent les microservices et la base de données par service, une seule action métier, comme passer une commande de repas, touche plusieurs bases de données appartenant à des services différents : celle du service de commandes, celle du service de paiement et celle du service d’affectation. Aucune transaction locale ne peut les couvrir toutes.

Il existe deux familles de réponses. La première consiste à faire agir de nombreux gestionnaires de ressources comme un seul, au moyen d’un protocole de validation atomique distribuée, dont la validation en deux phases est l’exemple classique. La seconde consiste à accepter que l’action soit une suite de transactions locales et à concevoir en fonction des moments intermédiaires : c’est la saga. Une troisième réponse, souvent la meilleure, consiste à remarquer que la frontière de la transaction et celle du service ne coïncident pas, et à déplacer l’une des deux. Cette section couvre les trois et se termine par un guide pour choisir.

La validation en deux phases et XA

La validation en deux phases (2PC) est un protocole, qui remonte à la fin des années 1970, assurant une atomicité tout-ou-rien entre plusieurs participants, par exemple deux bases de données, ou une base de données et un courtier de messages (message broker). Un coordinateur (le gestionnaire de transactions) le pilote. En phase 1, préparation, le coordinateur demande à chaque participant s’il peut valider. Un participant qui répond oui doit d’abord rendre les modifications durables et conserver les verrous concernés, car en votant oui il renonce au droit d’annuler de lui-même. Si tous les votes sont oui, le coordinateur écrit sa décision, COMMIT, dans son propre journal ; si un vote est non ou qu’un participant ne répond pas, la décision est ABORT. En phase 2, validation, il communique le résultat à chaque participant, qui l’applique et libère ses verrous.

La faiblesse est que le 2PC est un protocole bloquant. Un participant qui a voté oui est en doute : il ne connaît pas le résultat et ne peut pas le deviner sans risque, car un autre participant a peut-être déjà validé. Si le coordinateur tombe en panne à ce moment-là et le reste, les participants en doute conservent leurs verrous jusqu’à son rétablissement, et les autres transactions qui touchent ces lignes attendent elles aussi. Les opérateurs peuvent forcer une décision heuristique pour libérer les verrous, au risque de rompre l’atomicité.

La spécification XA, publiée par X/Open en 1991, a normalisé l’interface entre un gestionnaire de transactions et des gestionnaires de ressources, de sorte que, par exemple, un serveur d’applications Java puisse valider atomiquement une mise à jour de base de données et un envoi de message. De nombreuses bases de données relationnelles et certains courtiers de messages la prennent en charge.

Pourquoi on évite le 2PC entre microservices

Le 2PC fonctionne et reste utilisé à l’intérieur des frontières d’un même système. Entre services détenus de manière indépendante, il convient généralement mal, pour des raisons qui se renforcent mutuellement.

La disponibilité se multiplie à la baisse. Chaque participant et le coordinateur doivent être disponibles pour qu’une transaction soit validée : la disponibilité de la transaction est donc le produit des leurs, le même calcul que pour une chaîne d’appels synchrones (voir pourquoi distribuer). Les verrous sont maintenus à travers le réseau pendant au moins deux allers-retours, et bien plus longtemps si quelque chose est lent, ce qui réduit le débit et accroît la contention. Le couplage revient : tous les participants doivent parler le même protocole, partager un gestionnaire de transactions et s’accorder sur les délais d’expiration, ce qui sape la déployabilité indépendante qui justifiait de séparer les services. De nombreux participants ne peuvent pas y prendre part : la plupart des API HTTP, les services tiers comme les prestataires de paiement, de nombreuses bases de données NoSQL et plusieurs courtiers populaires ne prennent pas en charge XA. Et l’API du prestataire de paiement ne maintiendra jamais un verrou pour votre coordinateur.

Le tableau est différent à l’intérieur des bases de données distribuées. Des systèmes comme Google Spanner exécutent la validation en deux phases en interne entre des groupes de répliques eux-mêmes maintenus cohérents par consensus, si bien qu’un coordinateur tombé en panne est remplacé plutôt qu’attendu. Cela rend praticables les transactions entre partitions au sein d’une même base de données ; cela ne rend pas praticables les transactions entre des services détenus séparément, qui reposent sur des technologies différentes.

Les sagas : une suite de transactions locales

Hector Garcia-Molina et Kenneth Salem ont introduit la saga en 1987, dans un article présenté à SIGMOD sur les transactions de longue durée, celles qui maintiendraient des verrous de base de données pendant des heures. Leur idée était de découper une telle transaction en une suite de transactions ordinaires T₁, T₂ … T_n, dont chacune est validée séparément, et d’associer à chacune une transaction compensatoire C_i qui l’annule sur le plan sémantique. Le système garantit alors soit que la suite entière aboutit, soit que les étapes ayant abouti sont suivies de leurs compensations dans l’ordre inverse : T₁ … T_j, C_j … C₁.

Les architectures de microservices ont adopté cette idée parce qu’elle correspond exactement à leurs contraintes : chaque étape est une transaction ACID locale dans la base de données propre à un service, et les étapes sont reliées par des messages. Une saga offre l’atomicité au sens métier et à terme (toutes les étapes ont lieu, ou leurs effets sont annulés), mais pas l’isolation : entre deux étapes, d’autres transactions peuvent voir l’état intermédiaire.

Il est utile de classer les étapes, comme le fait Chris Richardson dans Microservices Patterns (2018). Les transactions compensables peuvent être annulées par une compensation. La transaction pivot est le point de non-retour : une fois qu’elle est validée, la saga ira jusqu’au bout. Les transactions rejouables viennent après le pivot et doivent être conçues pour finir par réussir si on les réessaie. Placer avant le pivot les étapes susceptibles d’échouer, et après lui celles qui ne peuvent pas être annulées, est une décision de conception essentielle.

Chorégraphie ou orchestration

Les étapes d’une saga doivent être coordonnées d’une manière ou d’une autre, et les deux options reprennent la chorégraphie et l’orchestration présentées à propos de l’architecture pilotée par les événements.

Dans une saga chorégraphiée, il n’y a pas de coordinateur. Chaque service écoute des événements et y réagit en effectuant sa transaction locale et en publiant un nouvel événement : le service de commandes publie OrderCreated, le service de paiement réagit et publie PaymentAuthorised, le service d’affectation réagit à son tour, et ainsi de suite ; des événements d’échec déclenchent des compensations dans les services qui les écoutent. C’est simple pour deux ou trois étapes, et cela garde les services faiblement couplés. À mesure que les étapes se multiplient, le flux n’existe plus que de façon implicite, éparpillé entre les services, si bien qu’il devient difficile à voir, à tester et à modifier ; et des dépendances cycliques entre services, par le jeu des événements, s’installent insidieusement.

Dans une saga orchestrée, un orchestrateur unique, généralement situé dans le service responsable du processus métier, envoie des commandes aux participants et réagit à leurs réponses. L’orchestrateur est une machine à états persistante : il enregistre dans sa propre base de données l’étape où il en est, ce qui lui permet de reprendre après une panne. Le flux est explicite et testable en un seul endroit, et les participants n’ont pas besoin de se connaître. Le risque est que l’orchestrateur accumule une logique métier qui relève des participants. Des moteurs de workflow comme Temporal, Camunda et AWS Step Functions fournissent une orchestration durable sous forme de plateforme, au prix d’une dépendance supplémentaire. Au-delà de trois étapes environ, ou pour tout flux comportant des branchements et des délais d’expiration, la plupart des praticiens préfèrent l’orchestration.

Exemple commenté : la saga de commande

La saga de commande de la plateforme de livraison de repas est orchestrée par le service de commandes. L’ordre des étapes est délibéré : l’autorisation de paiement est un blocage de fonds peu coûteux et facile à annuler, la réservation du livreur est l’étape la plus susceptible d’échouer aux heures de pointe, et la confirmation au restaurant est le pivot, car une fois qu’une cuisine a commencé à préparer la commande, celle-ci ne peut plus simplement être annulée.

La compensation n’est pas un retour arrière

Un retour arrière (rollback) de base de données fait comme si la transaction n’avait jamais eu lieu : personne d’autre n’a jamais vu ses modifications. Une compensation est une nouvelle transaction, tournée vers l’avant, qui contrebalance sur le plan sémantique une transaction antérieure qui a bel et bien eu lieu et qui a pu être vue. Dans la saga de commande, la banque du client affiche peut-être déjà un montant bloqué, et un e-mail a peut-être annoncé « paiement autorisé ». La compensation ne peut pas annuler l’envoi de l’e-mail ; elle peut seulement lever le blocage et envoyer un autre message. Certaines actions ne peuvent pas du tout être compensées, comme un repas déjà cuisiné ou une notification déjà lue ; elles ont leur place après le pivot, ou nécessitent une compensation métier comme un bon d’achat ou un remboursement.

Les compensations demandent donc le même soin que les étapes qui vont de l’avant. Elles doivent être idempotentes, car le message qui les déclenche peut être livré deux fois. Elles doivent être rejouables jusqu’à ce qu’elles réussissent, car une compensation qui échoue définitivement laisse le système dans un état que personne n’a conçu ; si elles ne peuvent vraiment pas réussir, elles doivent déclencher une alerte pour qu’une personne règle le problème. Elles peuvent devoir être commutatives avec l’étape qu’elles compensent : si un VoidAuthorisation arrive avant l’AuthorisePayment qu’il annule (ce qui est possible après des délais d’expiration et des nouvelles tentatives), le service de paiement doit mémoriser l’annulation et refuser l’autorisation tardive plutôt qu’échouer. Enfin, elles doivent être visibles pour le métier : « rejetée, pas de livreur » est une information que l’équipe des opérations veut voir sur un tableau de bord.

Vivre sans isolation : anomalies et contre-mesures

Comme chaque étape est validée séparément, les sagas n’ont pas le I d’ACID, et des sagas concurrentes peuvent interférer. Richardson décrit trois anomalies qui en résultent. Une mise à jour perdue se produit quand une saga écrase une modification faite par une autre sans l’avoir lue, par exemple quand une saga d’annulation marque une commande comme annulée et que la saga de commande la passe ensuite à confirmée. Une lecture sale se produit quand une saga lit des données qu’une autre saga a modifiées mais risque encore de compenser, comme une vérification de plafond de crédit qui compte un blocage sur le point d’être annulé. Une lecture floue, ou non reproductible, se produit quand deux étapes d’une même saga lisent les mêmes données et obtiennent des valeurs différentes parce qu’une autre saga les a modifiées entre-temps.

Il recense aussi des contre-mesures, des techniques de conception qui réduisent ces anomalies, en s’appuyant sur des travaux de recherche antérieurs consacrés aux transactions portant sur plusieurs bases de données. Voici les plus utilisées.

Publier de façon fiable : l’outbox transactionnelle

Chaque étape de saga fait deux choses : elle met à jour sa propre base de données et elle envoie un message (un événement ou une réponse). Les faire séparément crée le problème de la double écriture (dual write). Si le service valide puis plante avant de publier, le reste de la saga n’entend jamais parler de l’étape. S’il publie d’abord et que la validation échoue ensuite, d’autres services agissent sur quelque chose qui n’a jamais eu lieu. Envelopper la base de données et le courtier dans un 2PC est précisément ce que nous voulions éviter.

L’outbox transactionnelle (transactional outbox) le résout avec une seule transaction locale. Le service écrit la modification métier et le message sortant, sous la forme d’une ligne dans une table outbox, dans la même transaction de base de données ; soit les deux sont validés, soit aucun ne l’est. Un relais séparé lit ensuite l’outbox et publie chaque message vers le courtier. Deux conceptions de relais sont courantes. Un éditeur par interrogation (polling publisher) interroge régulièrement la table outbox pour y trouver les lignes non publiées et les marque comme envoyées : c’est simple, mais cela ajoute de la charge et de la latence. La lecture du journal des transactions (transaction log tailing) utilise la capture des données modifiées (CDC) : un outil lit le journal de réplication de la base de données elle-même (le write-ahead log de PostgreSQL ou le binary log de MySQL) et transforme les nouvelles lignes de l’outbox en messages. Debezium, une plateforme de CDC open source généralement exécutée avec Kafka Connect, en est l’exemple le plus connu ; elle comprend un routeur d’événements outbox (outbox event router) qui achemine chaque ligne vers un topic en fonction d’une colonne comme le type d’agrégat.

Le relais peut planter après avoir publié et avant d’avoir enregistré qu’il l’a fait : il publiera donc parfois un message deux fois. L’outbox assure ainsi une livraison au moins une fois, et les consommateurs doivent gérer les doublons. L’ordre de publication est préservé pour chaque agrégat si le relais publie les lignes dans l’ordre de validation et utilise l’ID de l’agrégat comme clé de message.

BEGIN;

INSERT INTO orders (id, customer_id, state, total_pence)
VALUES ('1042', 'c-77', 'PENDING', 2350);

INSERT INTO outbox (id, aggregate_type, aggregate_id, type, payload)
VALUES ('e-9f1c', 'order', '1042', 'OrderCreated',
        '{"orderId":"1042","customerId":"c-77","totalPence":2350}');

COMMIT;
-- A relay (poller or CDC such as Debezium) later publishes e-9f1c to the broker.

Recevoir de façon fiable : récepteurs idempotents et inbox

Comme l’outbox, les nouvelles tentatives du courtier et celles de la saga produisent toutes des doublons, chaque participant doit être un récepteur idempotent (Idempotent Receiver), nom que Gregor Hohpe et Bobby Woolf ont donné à ce patron dans Enterprise Integration Patterns (2003). Certaines opérations sont naturellement idempotentes (« passer la commande 1042 à CONFIRMED ») ; d’autres nécessitent un contrôle des doublons. L’implémentation habituelle est une inbox : une table des ID de messages traités, écrite dans la même transaction locale que la modification métier, de sorte que « traiter le message » et « se souvenir qu’il a été traité » soient validés ensemble. Un message livré une nouvelle fois trouve son ID déjà présent et est acquitté sans rien faire. Le code côté consommateur figure dans la section sur l’architecture pilotée par les événements.

Ensemble, l’outbox, la livraison au moins une fois et les récepteurs idempotents donnent le résultat pratique que l’on désigne généralement par « exactement une fois » : chaque effet métier se produit une seule fois, même si les messages peuvent circuler plus d’une fois.