Modèles d'architecture d'application sur AWS

Déployer des applications sur AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Faites connaissance avec votre formateur

Formateur du cours Dunieski Otano, AWS Solutions Architect, avec environ dix ans d'expérience cloud

Pourquoi la bonne architecture compte

Schéma décisionnel en thème clair : un nœud de choix d'architecture se branche vers trois facteurs : couplage, état et communication, au-dessus d'une petite icône de balance pour les compromis

L'architecture est un ensemble de compromis, pas une unique bonne réponse
- Trois questions guident chaque choix :
  - À quel point les composants sont-ils couplés ?
  - Où réside l'état ?
  - La communication est-elle synchrone ou asynchrone ?
- Adaptez le modèle à la charge de travail, pas à la mode

La cascade du vendredi soir

Une API de paiement lente fige tout le passage en caisse
Tous les services attendaient dessus de façon synchrone
La solution est architecturale, pas une API plus rapide

Comparaison côte à côte : services fortement couplés qui bloquent vs services découplés par une file de messages

Pourquoi les choix d'architecture conditionnent le déploiement

Schéma comparant une architecture fragile fortement couplée où une panne se propage à tous les services, et une conception résiliente où une file tampon isole la panne pour que les autres services continuent de répondre

Le modèle choisi détermine comment l'app monte en charge et tombe en panne
- Un fort couplage casse sous la charge
Le bon modèle rend le déploiement prévisible
- Même code, comportements très différents en production

Les modèles d'architecture essentiels

Monolithique : une unité déployable, simple au départ
Microservices : services indépendants, déployés séparément
Orienté événements : composants réagissent à des événements, pas à des appels directs
- Le fanout est un sous-modèle : un événement touche de nombreux consommateurs

Trois modèles d'architecture d'application côte à côte : monolithique comme un seul bloc empilé, microservices comme services déployables indépendants, et orienté événements avec un bus d'événements ; le fanout apparaît comme un sous-modèle publiant un événement vers de multiples consommateurs

Avec état vs sans état

Sans état (stateless) : aucune donnée client conservée entre requêtes
- Toute instance peut traiter n'importe quelle requête
Avec état (stateful) : l'instance se souvient des interactions
Le « sans état » permet de monter en charge horizontalement
- Externalisez l'état partagé vers DynamoDB ou ElastiCache

À gauche, instance sans état joignable par toute requête ; à droite, instance avec état liée à une session client

Fort vs faible couplage

Fort couplage avec l'appelant bloqué en attendant un appelé lent vs faible couplage avec une file SQS tampon qui permet au producteur de continuer

Fort couplage : l'appelant attend la réponse de l'appelé
Un service lent bloque toute la chaîne
Faible couplage : une file Amazon SQS entre les services
Le producteur continue même si le consommateur est à l'arrêt

Synchrone vs asynchrone

Synchrone : l'appelant bloque et attend le résultat
À utiliser quand la réponse est requise immédiatement
Asynchrone : l'appelant délègue le travail et revient
À utiliser pour des tâches lentes, en rafales, ou non urgentes

À gauche, appel synchrone avec appelant bloqué jusqu'à la réponse ; à droite, délégation asynchrone avec retour immédiat et traitement en arrière-plan

Modèles de résilience pour les appels tiers

Reprise avec backoff exponentiel : attendre plus longtemps entre tentatives
Disjoncteur : arrêter d'appeler un service en échec un moment
File de lettres mortes : garer les messages qui échouent encore
Combinez-les ; des reprises aveugles aggravent les pannes

Trois modèles de résilience : courbe de reprise avec backoff exponentiel, disjoncteur stoppant les appels vers un service en échec, et file de lettres mortes capturant les messages après épuisement des reprises

Passons à la pratique !

Déployer des applications sur AWS