Architectures serverless et basées sur l’espace

Deux réponses à la question de la capacité

Tous les styles vus jusqu’ici dans ce chapitre supposent que quelqu’un exploite des serveurs et les dimensionne en fonction de la charge. Cette section présente deux styles qui répondent à la question de la capacité de manières opposées. L’architecture serverless confie entièrement les serveurs à un fournisseur cloud et paie à l’usage, ce qui convient à un travail de petite taille, piloté par les événements et souvent inactif. L’architecture basée sur l’espace garde en mémoire tout ce dont une requête a besoin en période de forte charge, réparti sur de nombreuses unités identiques, afin que la base de données ne soit plus sur le chemin critique, ce qui convient à des pics extrêmes et soudains comme une mise en vente de billets. Ce sont deux outils spécialisés ; tous deux sont souvent choisis pour de mauvaises raisons.

Serverless : fonctions et back-ends managés

Le serverless ne veut pas dire qu’il n’y a pas de serveurs ; cela signifie que l’équipe n’a pas à provisionner, corriger, dimensionner ni payer des serveurs inactifs. L’article de Mike Roberts, publié en 2018 et largement cité, distingue deux ingrédients. Les fonctions en tant que service (FaaS) exécutent de petits morceaux du code propre à l’équipe en réponse à des événements, dans des conteneurs que le fournisseur crée, met à l’échelle et détruit, et qui peuvent ne vivre que le temps d’une seule invocation. AWS Lambda, annoncé en novembre 2014 et disponible pour tous en avril 2015, a démocratisé ce modèle ; Azure Functions, Google Cloud Run functions et Cloudflare Workers en sont d’autres exemples. Le backend en tant que service (BaaS) remplace des composants côté serveur par des services tiers entièrement managés, que le client ou la fonction appelle directement : authentification (Auth0, Amazon Cognito), bases de données (Firebase, DynamoDB), stockage d’objets, e-mail et files d’attente.

Une application serverless est généralement une combinaison : les fonctions contiennent la logique métier propre à l’organisation, et tout le reste, y compris tout l’état durable, réside dans des services managés. Le fournisseur gère la capacité, la disponibilité entre zones et le système d’exploitation. L’équipe reste responsable de son code, de ses données, de sa configuration et de ses paramètres de sécurité, comme l’explique le modèle de responsabilité partagée présenté dans les serveurs et le cloud.

Comment se comportent les fonctions : les caractéristiques qui façonnent la conception

Déclencheurs d’événements. Les fonctions s’exécutent en réponse à des événements : une requête HTTP passant par une gateway, un message dans une file ou un flux, un fichier déposé dans un stockage d’objets, une modification de base de données, ou une planification. Les déclencheurs qui invoquent la fonction de façon asynchrone, comme les files et les notifications de stockage, livrent généralement au moins une fois et réessaient en cas d’échec : les gestionnaires doivent donc être idempotents, exactement comme dans l’architecture pilotée par les événements.

Mise à l’échelle jusqu’à zéro et à l’horizontale. Sans trafic, aucune instance ne tourne et aucun calcul n’est facturé. À mesure que les événements arrivent, la plateforme démarre davantage d’instances en parallèle, jusqu’à une limite de concurrence fixée pour le compte ou pour la fonction ; sur AWS Lambda, la limite régionale par défaut est de 1000 exécutions simultanées au moment de la rédaction, et peut être relevée sur demande. Ce passage à l’échelle rapide est à la fois un atout et un danger : mille fonctions simultanées peuvent ouvrir mille connexions à la base de données et submerger une base de données relationnelle conçue pour quelques centaines, d’où l’existence des proxys de connexions et des plafonds de concurrence par fonction.

Facturation par invocation. Le coût est généralement une petite somme par requête, plus un montant pour la mémoire multipliée par le temps d’exécution (en gigaoctets-secondes). Un code qui attend sans rien faire une API en aval lente paie donc pour attendre.

Démarrages à froid (cold starts). La première requête adressée à une nouvelle instance doit attendre que la plateforme démarre un conteneur, charge l’environnement d’exécution et exécute le code d’initialisation : de quelques dizaines de millisecondes à plusieurs secondes, selon le langage, la taille du paquet et la configuration réseau. Les instances sont réutilisées pour les requêtes suivantes tant qu’elles restent chaudes, si bien que les démarrages à froid frappent surtout le trafic peu fréquent et les pics soudains. Parmi les parades figurent des paquets de déploiement plus petits, des environnements d’exécution plus légers, l’initialisation en dehors du gestionnaire, et le fait de payer pour garder des instances pré-initialisées (AWS appelle cela la concurrence provisionnée, ou provisioned concurrency), ce qui réintroduit en partie un coût permanent.

Limites. Les fonctions s’exécutent sous des limites strictes de durée d’exécution, de mémoire, de taille des données transmises et de disque temporaire ; pour AWS Lambda, au moment de la rédaction : 15 minutes, de 128 Mo à 10 240 Mo de mémoire (avec un CPU alloué en proportion) et 6 Mo pour une requête ou une réponse synchrone. Les tâches longues doivent être découpées en étapes, et les grosses données transmises par référence au stockage d’objets.

Absence d’état. Rien de ce qui se trouve dans la mémoire ou sur le disque local d’une instance n’est garanti de survivre jusqu’à l’invocation suivante. La mise en cache en mémoire entre deux appels est une optimisation qui peut fonctionner ou non, jamais un endroit où mettre des données importantes.

Où va l’état

Comme les fonctions ne conservent rien, le travail d’architecture se déplace vers le choix de l’endroit où réside chaque type d’état. Les données métier durables vont dans une base de données managée, souvent une base qui gère bien de nombreuses connexions de courte durée (bases clé-valeur ou orientées documents, ou base de données relationnelle derrière un proxy de connexions). Les gros objets vont dans le stockage d’objets et passent d’une fonction à l’autre par leur clé. L’état partagé de courte durée, comme les compteurs de limitation de débit, va dans un cache managé. La progression d’un processus en plusieurs étapes va dans un service de workflow (AWS Step Functions, Azure Durable Functions ou équivalent), qui joue le rôle d’orchestrateur de saga durable, comme décrit dans la section sur les sagas. Les sessions utilisateur vont dans des jetons conservés par le client ou dans un magasin de sessions.

La conséquence est qu’un système serverless est par construction un système distribué, avec toutes les préoccupations de ce chapitre : latence réseau entre chaque fonction et ses données, défaillance partielle, événements en double, cohérence à terme et besoin de traçage distribué. Une seule action métier peut traverser une gateway, trois fonctions, une file et deux bases de données. L’observabilité (voir observabilité) n’est pas facultative.

Couplage au fournisseur : le prix de ne pas exploiter de serveurs

Le serverless couple un système à son fournisseur plus étroitement que la location de machines virtuelles ou l’exécution de conteneurs. Les formats d’événements, la configuration des déclencheurs, les modèles d’identité et de permissions, les définitions de workflows et les services managés eux-mêmes sont tous propres au fournisseur. Migrer une application serverless mature vers un autre cloud tient davantage de la réécriture que de la migration.

Les praticiens ne s’accordent pas sur l’importance de ce point. Selon un premier point de vue, la dépendance au fournisseur (lock-in) est le prix d’une forte réduction du travail d’exploitation, et la plupart des organisations ne changent jamais de cloud : optimiser pour la portabilité serait donc un effort perdu. Selon l’autre, les changements de tarifs, les exigences réglementaires ou les acquisitions imposent bel et bien des migrations, et un couplage profond retire tout pouvoir de négociation. Une voie médiane consiste à accepter le couplage en périphérie et à le contenir dans le cœur : garder la logique métier dans des modules ordinaires derrière des ports, avec de minces gestionnaires de fonctions jouant le rôle d’adaptateurs (l’approche de l’architecture hexagonale), gérer l’infrastructure en tant que code, et consigner le couplage comme une décision explicite. Le coût et la dépendance au fournisseur sont approfondis dans FinOps et dépendance au fournisseur.

Quand le serverless convient, et quand il ne convient pas

Le serverless convient aux charges de travail en pics, imprévisibles ou de faible volume, pour lesquelles payer des serveurs inactifs est du gaspillage ; au code de liaison piloté par les événements, par exemple pour réagir à des envois de fichiers, à des messages de file et à des modifications de base de données ; aux tâches planifiées et à l’automatisation du back-office ; aux prototypes et nouveaux produits, pour lesquels l’équipe doit consacrer son temps au produit plutôt qu’à l’infrastructure ; et aux équipes sans capacité de plateforme ni d’exploitation.

Il convient mal à un trafic régulier et à fort volume, pour lequel la tarification par requête dépasse le coût d’une capacité toujours active (comme dans l’exemple commenté) ; aux processus de longue durée ou avec état, comme le transcodage vidéo au-delà de la limite de durée ou les serveurs WebSocket qui maintiennent de nombreuses connexions ; aux exigences strictes de faible latence de queue que les démarrages à froid ne permettraient pas de respecter ; aux charges de travail nécessitant du matériel spécial ou un contrôle fin de l’environnement d’exécution ; et aux conceptions à grain fin dans lesquelles de nombreuses fonctions s’appellent les unes les autres de façon synchrone, ce qui ajoute à chaque étape des sauts réseau, des coûts et des points de défaillance. Le chapitre 1 a décrit comment Amazon Prime Video, en 2023, a fait passer un service de supervision d’étapes serverless distribuées à un processus unique, et a fait état d’une baisse de plus de 90 % du coût d’infrastructure (pourquoi l’architecture compte) : ce n’est pas un verdict sur le serverless, mais un rappel que l’adéquation compte plus que la mode.

L’architecture basée sur l’espace : sortir la base de données du chemin critique

La plupart des architectures font facilement passer à l’échelle les niveaux web et applicatif, mais finissent par buter sur la base de données, que chaque requête sollicite. Ajouter des serveurs en amont ne fait que déplacer la file d’attente vers la base de données. L’architecture basée sur l’espace (space-based), telle que la décrivent Mark Richards et Neal Ford dans Fundamentals of Software Architecture, retire complètement la base de données du chemin synchrone. Chaque requête est traitée entièrement en mémoire par l’une des nombreuses unités de traitement identiques, et la base de données est mise à jour de façon asynchrone, en coulisses.

Le nom vient de l’espace de tuples, une mémoire associative partagée introduite en 1985 par Linda, le langage de coordination de David Gelernter : les processus communiquent en écrivant des tuples dans un espace partagé et en y lisant ou en y prélevant les tuples correspondants, sans se connaître les uns les autres. JavaSpaces, de Sun, a apporté l’idée à Java à la fin des années 1990, et des plateformes commerciales ont bâti sur elle des espaces distribués et répliqués, qui ont évolué vers les grilles de données en mémoire actuelles comme Hazelcast, Apache Ignite et Oracle Coherence.

Collisions de données et autres coûts

Conserver des copies répliquées dans de nombreuses unités transpose en mémoire les problèmes de cohérence vus dans les sections précédentes. Avec un cache répliqué, chaque unité dispose d’une copie complète et les modifications sont copiées de façon asynchrone, ce qui permet des lectures locales rapides, mais deux unités peuvent mettre à jour le même élément avant que la réplication ne rattrape son retard. Richards et Ford appellent cela une collision de données et en estiment le taux comme le nombre d’unités multiplié par le carré du taux de mise à jour, divisé par le nombre d’éléments, multiplié par la latence de réplication. Avec 5 unités, 20 mises à jour par seconde, 50 000 éléments et 100 ms de latence, on obtient 5 × 400 ÷ 50 000 × 0,1 = 0,004 par seconde, soit environ 115 collisions sur une journée de huit heures ; réduire la latence à 1 ms ramène ce chiffre à environ une.

Pour les données qui ne doivent jamais entrer en collision, comme la dernière place d’une rangée, les alternatives sont un cache distribué, dans lequel chaque élément réside dans une seule partition, où chaque unité le lit et l’écrit (c’est cohérent, mais chaque accès est un appel réseau et les partitions de la grille doivent rester disponibles), ou l’acheminement de toutes les requêtes portant sur un même événement ou une même section vers la même unité, pour qu’une seule unité modifie jamais ces places. La plupart des conceptions réelles combinent les deux : partitionner par clé les données chaudes et disputées, et répliquer les données surtout lues, comme les plans de salle et les prix.

Les autres coûts sont importants. Les données conservées en mémoire sont limitées par la taille de la mémoire et doivent être reconstruites après un redémarrage complet. La base de données est cohérente à terme avec la grille : les rapports et les autres systèmes voient donc les modifications avec retard, et la perte de modifications en file d’attente est un risque réel que la durabilité des pompes doit couvrir. Les tests à une charge de pointe réaliste sont coûteux et difficiles. Et ce style est complexe et coûteux à construire : Richards et Ford lui attribuent une note faible en simplicité et en testabilité, et élevée en coût. Il n’en vaut la peine que lorsque la charge ne peut vraiment pas être absorbée par la mise en cache, les répliques en lecture et une base de données bien réglée.