Styles d'architecture et modes de communication

Développer des applications sur AWS

Ricardo Sueiras

Principal Technologist

Votre formateur

Qu'est-ce qu'un modèle d'architecture ?

 

 

 

• Solution reproductible à un problème courant.
• Les modèles aident à assembler les services AWS.
• L'architecture détermine le comportement sous charge.
• Plusieurs modèles d'architecture à connaître.

Monolithes

 

 

 

 

• Un seul bloc fortement couplé.
• Un codebase, un déploiement.
• Simple au départ.
• Difficile à faire évoluer : tout scale ensemble.

Microservices

 

 

• Petits services indépendants : chacun gère une capacité métier.
• Déployer, scaler et mettre à jour chaque service séparément.
• Compromis : plus de complexité opérationnelle et de communication inter-services.

Serverless

• Aucune infrastructure à gérer : seulement code et configuration.
• Construire en composant des services AWS managés.
• AWS gère le provisionnement, le scaling et la maintenance.
• Compromis : limites de temps d'exécution, cold starts, verrou fournisseur.
• Surcharge opérationnelle quasi nulle et scalabilité automatique.

 

Architecture pilotée par les événements (EDA)

• Les composants communiquent via des événements, pas par appels directs.
• Un événement enregistre un fait (commande passée, paiement reçu, article expédié).
• Les producteurs émettent des événements.
• Les consommateurs s'abonnent aux événements utiles.

 

Systèmes fortement et faiblement couplés

• Les apps cloud modernes combinent plusieurs services.
• Les services doivent communiquer et se coordonner.
• La communication synchrone est fortement couplée.
• L'asynchrone est faiblement couplée.

Communication synchrone

 

• Un service envoie une requête et attend la réponse.
• L'appelant est bloqué jusqu'à réponse ou expiration.
• Simple à implémenter et à comprendre.
• Fort couplage : lenteur/panne en aval peut se propager.
• Atténuer via timeouts, retries et coupe-circuits.

Modèle : requête/réponse

• Ossature de la plupart des interfaces applicatives.
• Comportement prévisible.
• Retour immédiat pour les utilisateurs.

Communication asynchrone

 

• L'émetteur n'attend pas de réponse.
• Envoie un message/événement, puis continue.
• Le récepteur traite le message indépendamment.
• Faible couplage : meilleure scalabilité et tolérance aux pannes.
• Gère mieux pics de trafic et pannes partielles.
• Défis : doublons, ordre, cohérence éventuelle.

Modèle : découplage via file d'attente

• Le producteur envoie des messages à une file d'attente.
• Le consommateur tire et traite les messages de façon indépendante.
• Évite l'effet domino des défaillances.
• Producteur et consommateur scalent séparément.

 

Modèle : file de travailleurs

• Plusieurs workers tirent des messages d'une même file.
• Traitement en parallèle.
• Permet le scaling horizontal et un débit accru.
• Ordre des messages non garanti.

Modèle : publication/abonnement

• Les éditeurs envoient des messages à un sujet SNS.
• Plusieurs abonnés reçoivent le même message.
• Diffusion en temps réel à de nombreux consommateurs.

 

Modèle : fan-out

• Un message livré simultanément à plusieurs consommateurs.
• Très utilisé en architectures événementielles.
• Utile quand plusieurs services doivent réagir au même événement.

Ordonnancement des messages

• Certains traitements exigent l'ordre exact des messages.
• Amazon SQS FIFO et Kinesis prennent en charge l'ordre.
• L'ordre strict réduit le débit.
• Équilibrer justesse et scalabilité.

Passons à la pratique !

Développer des applications sur AWS