Diagramme d'architecture serverless sur AWS : API Gateway, Lambda, DynamoDB et événements

Dans un système serverless, les serveurs disparaissent, et avec eux la forme habituelle d'un diagramme d'architecture. Ce qui compte à la place, c'est la façon dont chaque fonction est déclenchée, ce qui se passe quand elle échoue et quels événements relient une partie du système à la suivante. Un diagramme qui montre vingt boîtes Lambda et aucun déclencheur a l'air complet et n'explique rien.

Ce guide montre comment dessiner un diagramme d'architecture serverless sur AWS qu'une nouvelle recrue puisse suivre : un exemple complet, une notation pour les types d'invocation et les chemins d'échec, et les erreurs qui rendent ces diagrammes trompeurs.

Commencer par la façon dont chaque fonction est invoquée

Toute fonction Lambda du diagramme est démarrée par quelque chose, et AWS propose trois modèles d'invocation qui se comportent différemment en cas de problème. C'est l'information la plus utile qu'un diagramme serverless puisse montrer.

Modèle d'invocation	Sources typiques	Qui réessaie en cas d'échec	Où finissent les échecs
Synchrone	API Gateway, une URL de fonction, un appel SDK	L'appelant décide	Une réponse d'erreur à l'appelant
Asynchrone	EventBridge, notifications S3, SNS	Lambda réessaie deux fois par défaut	Une destination en cas d'échec ou une file de lettres mortes (DLQ), si vous en configurez une
Mappage de source d'événements (Lambda interroge la source)	SQS, DynamoDB Streams, Kinesis	Lambda continue de réessayer le lot	SQS : la file de lettres mortes de la file. Streams : une destination en cas d'échec, sinon les enregistrements expirent

Étiquetez chaque lien de déclenchement avec sa source et son modèle : sync, async ou poll, batch 10. Quand un incident commence par « les messages s'accumulent », c'est ce lien que tout le monde cherche.

L'exemple : une API de commandes serverless

Un petit service de commandes entièrement construit sur des services managés :

1. Les clients appellent une API HTTP API Gateway. Un mécanisme d'autorisation JWT vérifie les jetons émis par un groupe d'utilisateurs Amazon Cognito.
2. API Gateway invoque createOrder de façon synchrone. La fonction valide la requête et écrit la commande dans la table DynamoDB orders.
3. Un flux DynamoDB sur la table déclenche publishOrderEvents, qui envoie OrderPlaced à un bus EventBridge personnalisé. Comme l'événement provient du flux, il n'est publié que pour les écritures réussies.
4. Une règle EventBridge sélectionne OrderPlaced et l'envoie dans la file SQS receipts.
5. Lambda interroge la file et invoque sendReceipt par lots de dix messages au maximum ; la fonction envoie un e-mail au client via Amazon SES.
6. Un message qui échoue cinq fois part dans receipts-dlq, où une alarme prévient l'équipe.

Le chemin de requête s'arrête à l'étape 2 : le client reçoit sa réponse dès que la commande est enregistrée. Tout ce qui suit est asynchrone, et le diagramme trace ces déclencheurs avec des liens en tirets.

Règles pour les diagrammes serverless

Dessiner les déclencheurs comme des liens étiquetés

Le lien qui entre dans une fonction indique ce qui la démarre : POST /orders, DynamoDB stream, rule: OrderPlaced, SQS, batch 10. Une fonction sans lien entrant est soit du code mort, soit un lien qui manque sur votre diagramme.

Séparer le chemin de requête du travail asynchrone

Utilisez des liens pleins pour les appels synchrones et des liens en tirets pour tout ce qui se passe plus tard. Le lecteur doit pouvoir suivre le chemin qui ajoute de la latence pour l'utilisateur sans lire chaque étiquette.

Dessiner délibérément le chemin d'échec

Pour chaque lien asynchrone, décidez où vont les échecs et dessinez-le : une file de lettres mortes, une destination en cas d'échec ou une note qui dit « les enregistrements expirent au bout de 24 heures ». DynamoDB Streams conserve les enregistrements pendant 24 heures : un consommateur qui échoue en boucle perd donc les événements dès qu'ils expirent. Une destination en cas d'échec S3 garde une copie des enregistrements en échec ; une destination SQS ou SNS ne reçoit que des métadonnées, donc quelque chose doit relire les enregistrements dans le flux pendant ces 24 heures.

Une fonction par nœud

Un seul nœud « Lambda » pour trente fonctions cache les déclencheurs, et les déclencheurs sont l'architecture. S'il y a trop de fonctions, découpez le diagramme par service plutôt que de fusionner des boîtes.

Encadrer par unité de déploiement

Regroupez dans un cadre les ressources déployées ensemble, par exemple une stack SAM, CDK ou Terraform. Cela montre à qui elles appartiennent et ce qui change ensemble.

Garder les permissions et les limites en notes

Chaque fonction a un rôle d'exécution IAM, et certaines ont une simultanéité réservée ou des timeouts longs. Ne dessinez pas un rôle par fonction. Ajoutez une note pour ce qui compte lors d'une revue : « seul createOrder peut écrire dans orders », « déclencheur SQS de sendReceipt : simultanéité maximale de 5 pour protéger les limites SES ».

Erreurs courantes

• API Gateway dessiné comme un répartiteur de charge. Il authentifie, limite le débit et transforme aussi les requêtes, et le mécanisme d'autorisation a sa place sur le diagramme.
• Pas de file de lettres mortes, ou des files de lettres mortes que personne ne surveille. Dessinez aussi l'alarme.
• Des bus d'événements sans règles. Un bus EventBridge distribue les événements selon ses règles ; étiquetez le lien avec la règle, pas seulement avec le bus.
• Aucune distinction entre sync et async. C'est la différence entre une API lente et un e-mail lent.
• Le bruit d'infrastructure. Les groupes de journaux, les couches et chaque politique IAM ont leur place dans le template, pas dans la vue d'ensemble.

Construire le diagramme dans Archboard

Les nœuds du pack Cloud d'Archboard sont indépendants du fournisseur et dotés de ports ; vous étiquetez donc chaque nœud avec le nom du service AWS :

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez des nœuds Boîte du pack Base pour les clients et pour Amazon SES, une Passerelle API du pack Cloud et un Fournisseur d'identité du pack Sécurité, étiqueté Amazon Cognito.
3. Ajoutez une Fonction du pack Cloud pour chaque fonction Lambda, nommée exactement comme dans votre template.
4. Ajoutez une Base de données gérée du pack Cloud étiquetée DynamoDB: orders, un Sujet du pack Données étiqueté EventBridge bus, des nœuds File d'attente du pack Cloud pour la file et sa file de lettres mortes, et une Alerte du pack DevOps pour l'alarme.
5. Connectez les ports. Gardez le chemin de requête en trait plein, passez les liens asynchrones en tirets et étiquetez chaque déclencheur avec sa source et son modèle d'invocation.
6. Placez la stack dans un Cadre du pack Base, ajoutez des notes pour les permissions et les limites, puis partagez le lien en direct avec l'équipe.

L'exemple utilise 13 nœuds de diagramme, ce qui tient dans l'offre Free. Pour le réseau autour d'une charge de travail serverless ou conteneurisée, consultez le guide sur le diagramme VPC AWS, et pour d'autres modèles cloud, la page de cas d'usage cloud.

FAQ

Dois-je dessiner chaque fonction Lambda ? Sur le diagramme du service, oui, car chacune a son propre déclencheur et son propre comportement en cas d'échec. Sur une vue d'ensemble du système, représentez le service par un seul nœud et ajoutez un lien vers son diagramme.

Puis-je utiliser les icônes AWS officielles ? Archboard n'a pas de pack spécifique à AWS : construisez le diagramme avec les nœuds typés et dotés de ports des packs Cloud, Réseau et Sécurité, et étiquetez chacun avec le nom du service, comme Amazon SES ou DynamoDB: orders. Si vous voulez aussi des logos, Rechercher et insérer propose des icônes de marque pour les services AWS, comme AWS Lambda, que vous pouvez placer comme nœuds icône.

Comment représenter Step Functions ? Par un seul nœud sur le diagramme d'architecture, étiqueté avec le nom de la machine d'état, et le workflow lui-même dans un logigramme ou un diagramme BPMN séparé.

Où mettre les démarrages à froid et la simultanéité ? Dans des notes à côté des fonctions concernées, par exemple la simultanéité provisionnée sur un endpoint sensible à la latence.

Dois-je représenter les rôles IAM ? Pas comme des nœuds. Notez les permissions qui façonnent la conception, et gardez les politiques complètes dans votre code d'infrastructure.

Commencez gratuitement — un siège, sans carte bancaire.