Patterns d'architecture serverless

1Un système à cohérence à terme marche comme un café bondé

Première famille : les faits, en commençant par ce qu'ils remplacent. Le matin, un café est bondé. Si une seule personne prenait la commande, préparait la boisson et faisait payer, la file déborderait sur le trottoir. Le café découpe donc le travail en étapes. Vous payez à la caisse, vous recevez un reçu, puis vous attendez votre boisson au comptoir.

Le reçu est le cœur de l'exemple : il atteste que vous avez payé (leçon 29). Vous savez que la boisson viendra, et le café sait qu'il doit la servir ou vous rembourser. Personne n'a bloqué la caisse le temps de préparer le café. Le livre en tire sa règle : « les faits sont le sang d'un système à cohérence à terme » (leçon 30).

Chaque étape fait donc une seule action atomique, c'est-à-dire tout ou rien, puis publie un fait quand elle a fini. La suivante réagit à ce fait. Le système entier avance ainsi par une chaîne d'actions courtes.

Le café a aussi ses pannes, et le livre les raconte. L'équipe perd votre café et en remet un en tête de file. Puis elle retrouve l'original, dont l'étiquette était effacée : vous avez deux cafés. Gilbert conclut qu'« une sortie en double vaut mieux que pas de sortie du tout » (leçon 30). L'étape suivante doit simplement savoir gérer les doublons.

Le même café ne garantit pas l'ordre. Une boisson simple sort avant une boisson compliquée, et le client trie à la sortie. Les programmes qui lisent les événements doivent faire pareil, car l'ordre d'arrivée n'est jamais garanti (leçon 30). Ces deux pannes, le doublon et le désordre, reviennent à l'idée 5.

2L'event sourcing de Gilbert range l'historique hors du service

Ces faits, encore faut-il les garder. Prenez un compte bancaire. Le livre en compare trois versions (leçon 34) :

• Sans event sourcing : une ligne par compte, avec le solde, écrasé à chaque opération. Le livre l'avoue : « nous perdons de l'information ».
• Event sourcing classique (Traditional Event Sourcing) : une ligne par opération, crédit ou débit. Rien ne se perd, mais lire le solde oblige à relire toutes les opérations à chaque requête.
• Event sourcing à l'échelle du système (system-wide event sourcing) : le service garde le seul solde courant, et chaque changement est envoyé aux autres services comme un fait.

Le troisième modèle est celui du livre. Son pivot est le CDC (Change Data Capture). C'est le flux des changements qu'une base de données publie à chaque écriture. Une petite fonction du service lit ce flux et envoie chaque changement au hub d'événements (event hub). Ce hub distribue les événements aux services intéressés. Le livre l'appelle aussi « le bus ».

Le service lui-même ne garde donc aucun historique. Le livre le confie à un lac d'événements (event lake). C'est un stockage de fichiers, un par sous-système, qui reçoit tous les événements et les garde à perpétuité. Pour Gilbert, ce lac sert de « journal des transactions de tout le système » (leçon 34).

Le lac sert aussi à rejouer. Un service a raté des événements à cause d'un bug ? On lui renvoie la période manquante. Un nouveau service arrive ? On lui envoie quelques semaines ou quelques mois d'événements. Le livre insiste : « nous ne republions pas les événements », sinon tous les services les recevraient (leçon 35). On les envoie au seul service concerné.

3Un service n'écrit qu'à un seul endroit, puis le CDC publie

Garder les faits ne suffit pas : il faut aussi les publier sans en perdre. Imaginez un service qui enregistre une commande dans sa base, puis l'envoie au hub d'événements. Le programme plante entre les deux. La base a la commande, mais personne en aval ne l'apprendra jamais.

Le livre pose donc la règle : « nous ne pouvons pas enregistrer de façon fiable dans plus d'un stockage à la fois » (leçon 36). La raison vient des transactions distribuées. Le protocole qui valide deux écritures ensemble, la validation en deux phases, ne passe pas à l'échelle. Il faut choisir un seul premier endroit :

• Database-first (la base d'abord) : le service écrit dans sa base, et le CDC de cette base publie l'événement. Le livre le réserve aux services où l'utilisateur doit relire tout de suite ce qu'il vient d'écrire.
• Stream-first (le flux d'abord) : le service publie l'événement, et les services en aval l'enregistrent. Le livre le garde pour les services sans utilisateur direct, ou pour une base sans CDC.

Le cas database-first a un bonus (leçon 61). La fonction qui lit le CDC publie d'abord chaque changement brut, avec la ligne avant et après. Ce flux est un journal d'audit : ce qui a changé, quand, et par qui. Ensuite seulement, une règle repère le vrai événement métier, par exemple un statut qui passe à « soumis ».

4Des cloisons étanches empêchent une panne de passer d'un service à l'autre

Publier par le hub d'événements rend chaque service indépendant de ceux qui le lisent. Le livre étend l'idée aux pannes. Un navire est découpé en compartiments étanches : une voie d'eau en noie un, pas le bateau entier. En anglais, ces cloisons s'appellent des bulkheads, et le livre en pose deux, une de chaque côté du service :

• Cloison sortante : le hub d'événements. Le service publie et passe à la suite, sans savoir qui lit. Une panne en aval ne le bloque donc pas (leçon 31).
• Cloison entrante : la vue matérialisée, une copie locale des données d'un autre service, mise à jour par ses événements. Si le service d'origine tombe, la copie répond encore avec les dernières données reçues (leçon 53).

Le contre-exemple est l'appel direct. Un service qui en interroge un autre à chaque requête tombe avec lui. Le livre est net : « les services qui dépendent directement d'autres services sont moins résilients » (leçon 53). Ses services d'interface (BFF, backend for frontend), ceux qui servent un frontend précis, « n'enveloppent pas d'autres services ». Ils possèdent tout ce qu'il leur faut pour continuer pendant une panne (leçon 65).

Ce confort a un prix, que le livre nomme dès le café : la transparence. Pendant une panne en amont, la copie locale vieillit. L'utilisateur doit donc voir l'âge possible des données qu'il lit (leçon 29).

5Le verrou inversé jette les événements trop vieux au lieu de réessayer

Seconde famille : garder le système juste quand tout tourne mal, en commençant par les doublons. Le livre part d'un constat : « la livraison exactement une fois des messages est irréaliste » (leçon 55). Un même événement arrivera donc parfois deux fois. Le recevoir deux fois ne doit rien changer : c'est l'idempotence, comme le bouton d'un ascenseur qu'on presse cinq fois.

L'exemple du livre montre d'où viennent ces doublons (leçon 41). Un programme lit les événements par lots de 100, et l'événement n° 60 fait planter le traitement à chaque essai. Le lot entier repart alors en boucle, et « les 59 premiers événements mettent à jour la cible encore et encore ».

Le désordre s'ajoute aux doublons, et le livre traite les deux d'un même geste. Il part du verrou optimiste classique. La ligne garde un numéro de version, et si quelqu'un a écrit entre-temps, votre écriture échoue et vous réessayez. Le verrou optimiste inversé (inverse optimistic locking) fait le contraire : « nous jetons les événements entrants dont l'horodatage est plus ancien ou égal à la valeur de verrou en base » (leçon 56).

Concrètement, chaque ligne garde dans une colonne oplock (de optimistic lock) l'horodatage du dernier événement appliqué. Un événement de même horodatage est un doublon, un événement plus ancien arrive en retard : dans les deux cas, on l'ignore. Le livre l'écrit pour DynamoDB. En SQL, la même règle tient en une condition. Voici ma traduction, pas celle du livre :

INSERT INTO commandes (id, statut, oplock)
VALUES ($1, $2, $3)
ON CONFLICT (id) DO UPDATE
    SET statut = EXCLUDED.statut, oplock = EXCLUDED.oplock
    WHERE commandes.oplock < EXCLUDED.oplock;
-- 0 ligne touchée : doublon ou événement en retard, ignoré

Le ON CONFLICT change l'insertion en mise à jour quand la commande existe déjà. EXCLUDED désigne la ligne qu'on voulait insérer, donc l'événement entrant. Toute la règle du livre tient dans le WHERE final : on n'écrit que si l'événement est plus récent.

Un dernier piège reste. Une même ligne peut assembler plusieurs types d'événements, par exemple la commande et l'affectation du livreur. Avec un seul verrou, une commande récente avance l'horodatage, et l'affectation, plus ancienne, est jetée à tort avec ses champs. La parade est un verrou par type d'événement, que le livre appelle Inverse Oplock Join (leçon 56).

6Un service de contrôle orchestre par événements, sans jamais appeler personne

Les doublons réglés, reste le processus qui échoue en route. Dans la livraison de repas du livre, la commande part au restaurant, un livreur est choisi, et chaque étape a ses chemins d'erreur. Au début, chaque service réagit aux événements des autres. C'est la chorégraphie : des danseurs sans chef, qui se règlent les uns sur les autres.

Quand les chemins d'erreur se multiplient, la logique s'éparpille dans tous les services. Le livre juge alors la chorégraphie « plus difficile à comprendre, tracer, déboguer, tester et maintenir » (leçon 83). Il regroupe cette logique dans un control service (service de contrôle), qui orchestre le processus. Sa définition : il « réagit aux événements en produisant d'autres événements » (leçon 84).

Ce chef d'orchestre n'appelle jamais un autre service. Il émet un événement d'entrée, « tâche demandée », et attend l'événement de sortie, « tâche terminée » (leçon 87). Le contrat d'un participant se réduit à cette paire d'événements.

Le même contrat sert la saga, un processus long découpé en actions atomiques, une idée que le livre date de 1987. Si une étape échoue sans issue, on défait les précédentes par des compensations. Or, prévient le livre, « une transaction de compensation n'est pas un rollback » (leçon 88). Elle ressemble à la comptabilité : rien ne s'efface, on corrige par des écritures de régularisation.

Pour savoir quand compenser, le livre distingue deux échecs (leçon 89) :

• Fault (panne) : une erreur imprévue, technique. On la corrige, puis on resoumet l'événement pour avancer.
• Abort (abandon) : une condition prévue, métier, sans issue. Elle déclenche les compensations en amont.

L'exemple du livre montre un abandon, sur deux étapes. La demande est soumise, l'étape 1 réussit, puis l'étape 2 est abandonnée. Le service de contrôle émet alors « étape 1 annulée », la compensation de l'étape 1, puis « demande annulée ». Deux règles suffisent : tout abandon annule la demande, et l'abandon de l'étape 2 annule aussi l'étape 1.

7Un snapshot devient un événement, et pour un solde l'ordre ne compte plus

Les compensations réparent un processus. Reste le calcul d'un état, comme un solde, quand les événements arrivent dans le désordre. Le livre reconnaît que l'event sourcing « a la réputation d'être trop complexe pour la plupart des cas d'usage » (leçon 90). En cause, il faut recalculer l'état en rejouant les événements.

La parade classique est le snapshot : une photo de l'état à un instant, pour ne rejouer que les événements suivants. Gilbert la déplace. Un service de contrôle collecte les dépôts et les retraits, calcule le solde, et publie un événement « solde » (leçon 91). Le calcul suivant part du dernier solde publié et ajoute les événements arrivés depuis.

Ce calcul supporte le désordre grâce à ACID 2.0, quatre propriétés reprises de Pat Helland : associatif, commutatif, idempotent, distribué. Commutatif veut dire que l'ordre ne change pas le résultat, comme 2 + 3 et 3 + 2. L'exemple du livre est chiffré. Dans les deux ordres ci-dessous, chaque solde entre parenthèses est un snapshot : le total publié après un groupe d'événements. Les deux ordres ne regroupent pas les événements de la même façon :

• Premier ordre : dépôts de 100 et 30 (solde 130), retrait de 50 et dépôt de 70 (solde 150), dépôt de 20, solde final 170.
• Second ordre : dépôt de 100 et retrait de 50 (solde 50), dépôts de 30 et 20 (solde 100), dépôt de 70, solde final 170.

Le livre conclut : « les événements sont arrivés dans des ordres différents, et le solde final des deux scénarios est 170 » (leçon 91).

Le livre avoue la limite de son exemple. Il suit le chemin heureux et ignore le cas d'un vieil événement arrivé après un snapshot. Gilbert laisse ce cas au lecteur « comme exercice de réflexion » (leçon 91). Or c'est justement le cas difficile.

8Entre deux régions, on réplique le résultat, pas le travail

Les doublons et le désordre ont un dernier terrain : plusieurs régions, c'est-à-dire plusieurs centres de données du fournisseur, dans des zones du monde différentes. Gilbert a vécu la panne S3 de 2017 avec un système dans une seule région, sans rien pouvoir faire (leçon 95). D'après son expérience, une grosse panne régionale arrive environ tous les deux ou trois ans.

Pour tourner dans deux régions, la tentation est de répliquer le hub d'événements : chaque région reçoit tous les événements et refait tout le travail. Gilbert refuse : « je déconseille de répliquer au niveau du bus » (leçon 102). Chaque région ferait le même traitement, paierait deux fois, et pourrait même obtenir des résultats différents.

Il réplique plutôt les changements de la base, déjà calculés. Sa formule : « nous faisons le travail une fois et nous répliquons le résultat » (leçon 102). Un piège suit : la région qui reçoit la copie ne doit pas republier l'événement. Le livre marque donc chaque ligne de sa région d'origine. Une commande traitée dans la région Est est copiée dans la région Ouest. À l'Ouest, la fonction qui lit le CDC voit arriver la ligne, lit « Est » comme origine, et ne publie rien.

La reprise après une panne s'appuie sur l'idempotence de l'idée 5. Quand une région prend le relais, elle reprend aussi l'interrogation des systèmes extérieurs au sous-système. Elle relit alors les 30 dernières minutes environ pour combler les trous (leçon 105). Les doublons que cela crée sont absorbés par l'idempotence.

9Pour effacer une personne d'un lac immuable, on détruit sa clé

Dernière idée : protéger ces faits, gardés à perpétuité dans le lac. Le livre ouvre sur une histoire vraie, celle de Code Spaces en 2014 (leçon 108). Un pirate prend le compte cloud de l'entreprise en otage, puis efface tout, sauvegardes comprises, car elles étaient dans le même compte. L'entreprise fait faillite.

Le livre en tire une règle : chaque sous-système a son compte cloud, et les sauvegardes vivent dans un compte isolé. Gilbert se méfie aussi du seul chiffrement du disque, qui « ne protège les données que lorsque le disque est retiré du système » (leçon 114). Or un accès privilégié lit les données en clair.

Le livre chiffre donc les champs sensibles dans le code, par chiffrement d'enveloppe : une clé de données chiffre le champ, et une clé maître chiffre la clé de données. Chaque événement transporte, dans un champ eem (envelope encryption metadata), la clé de données chiffrée et la liste des champs protégés (leçon 115). Une nouvelle clé de données sert à chaque enregistrement, donc une clé volée n'ouvre qu'un seul objet.

Reste le droit à l'effacement du RGPD, le règlement européen sur les données personnelles. Il semble incompatible avec un lac où l'on ne modifie rien. La réponse du livre est le crypto-shredding : une clé maître propre à chaque personne. Quand elle demande l'effacement, « il suffit de supprimer la clé propre à ce sujet » (leçon 115). Ses données restent dans le lac, mais personne ne peut plus les déchiffrer.