Architecture Cloud & Patterns
Concevoir des systèmes distribués, résilients et évolutifs. De la théorie (CAP) à la pratique (Circuit Breakers).
HA & Résilience
Active-Active, Multi-AZ vs Multi-Region, RTO/RPO et calculs de SLA.
Patterns Architecturaux
Monolith, Microservices, Strangler Fig, Saga Pattern & CQRS.
Design for Failure
Circuit Breaker, Bulkhead, Retry + Jitter, Rate Limiting.
Data & Consistance
Théorème CAP, Eventual Consistency, SQL vs NoSQL, Polyglot.
Event-Driven & Serverless
Pub/Sub, Event Sourcing, Idempotence, Choreography vs Orchestration.
Well-Architected
Les 6 piliers standards (AWS/Azure) pour auditer une solution.
Haute Disponibilité (HA) & Disaster Recovery (DR)
Comprendre les "9" (Nines)
La HA vise à éliminer les SPOF (Single Point of Failure). Le SLA composé diminue si dépendances en série, augmente si en parallèle.
| Disponibilité | Downtime / An | Downtime / Mois | Architecture Typique |
|---|---|---|---|
| 99.0% (2 nines) | 87h 36m | 7h 18m | Single VM, Backup journalier. |
| 99.9% (3 nines) | 8h 46m | 43m 49s | VMs en Auto-Scaling sur 2 AZ + Load Balancer. |
| 99.99% (4 nines) | 52m 36s | 4m 23s | Multi-AZ Database (RDS Multi-AZ), Clustering avancé. |
| 99.999% (5 nines) | 5m 15s | 26s | Active-Active Multi-Region, Chaos Engineering constant. |
App (99.9%) -> DB (99.9%) = 0.999 * 0.999 = 99.8% (Moins bon !)
Calcul SLA Redondant (Parallèle) :
Region A (99.9%) || Region B (99.9%) = 1 - (0.001 * 0.001) = 99.9999% (Bien meilleur !)
Active-Passive vs Active-Active
- Active-Passive (Failover) : Région B coûte moins cher (Pilot Light), mais temps de bascule (RTO) > 0. Risque de perte de données (RPO) selon lag réplication.
- Active-Active : Le trafic va sur A et B. Zéro downtime si A tombe. Complexité extrême (conflits d'écriture DB, latence).
Indicateurs de Performance DR
RPO (Recovery Point Objective)
"Combien de données puis-je me permettre de perdre ?"
Si RPO = 4h, je dois faire des backups toutes les 4h. En cas de crash, je perds max 4h de données.
RTO (Recovery Time Objective)
"Combien de temps le système peut-il rester HS ?"
Si RTO = 1h, l'infra doit être remontée (via IaC/Restore) en moins de 60min.
Patterns Architecturaux
| Style | Caractéristiques | Pros | Cons |
|---|---|---|---|
| Monolith | Single codebase, Single DB. | Simple à dev/deploy/test initialement. Transactionnel (ACID). | Scalabilité limitée, couplage fort, "Deployment Fear". |
| Modular Monolith | Code unique mais modules isolés par domaine (DDD). | Bon compromis. Performance in-memory. | Discipline de code requise pour ne pas coupler. |
| Microservices | Services autonomes, DB propre par service. Comm via API/Events. | Scale indépendant, techno hétérogène, équipes autonomes. | Complexité distribuée, latence réseau, Eventual Consistency. |
Le problème des transactions distribuées
Dans les microservices, pas de BEGIN TRANSACTION ... COMMIT entre deux services. On utilise le pattern Saga.
1. Service "Orchestrator" -> Appelle Service Vol (Réserver Siège). OK
2. Service "Orchestrator" -> Appelle Service Hôtel (Réserver Chambre). FAIL (Complet)
3. Service "Orchestrator" -> Déclenche Compensation vers Service Vol.
4. Service Vol -> Annule le siège (Rollback logique).
Deux types de Saga : Choreography (Events) vs Orchestration (Chef d'orchestre central).
Strangler Fig Pattern (Migration Legacy)
Ne jamais réécrire un monolithe "Big Bang". On l'étouffe petit à petit.
On place une "Facade" (API Gateway) devant. Les nouvelles routes vont vers le nouveau microservice, les anciennes vers le monolithe, jusqu'à disparition du monolithe.
Design for Failure
1. Circuit Breaker
Empêche d'appeler un service mort pour éviter l'épuisement des threads.
2. Retry + Exponential Backoff
Réessayer c'est bien, mais pas tous en même temps (Thundering Herd).
- Retry : Réessayer 3 fois si erreur 503.
- Backoff : Attendre 1s, puis 2s, puis 4s.
- Jitter : Ajouter du random (4s + 132ms) pour désynchroniser les clients.
3. Bulkhead (Cloisonnement)
Isoler les ressources. Si le service "Image" est lent, il ne doit pas consommer le Pool de connexion du service "Auth".
Data Architecture
En système distribué (Partition Tolerance obligatoire), vous devez choisir :
- CP (Consistency) : Tous les nœuds voient la même donnée en même temps. Si un nœud tombe, on bloque les écritures.
Banque - AP (Availability) : On répond toujours, même avec des données périmées (Eventual Consistency).
Réseaux Sociaux
| Type | Usage Idéal | Exemple Cloud | Anti-Pattern |
|---|---|---|---|
| Relational (SQL) | Données structurées, Transactions ACID, Joins complexes. | RDS, Azure SQL | Binary data, Logs massifs, Schéma ultra-changeant. |
| Key-Value | Session state, Shopping cart, Cache haute performance. | DynamoDB, Redis | Requêtes complexes, Analytics. |
| Document | Catalogues, Profils utilisateurs, CMS (JSON). | MongoDB, DocumentDB | Relations très interconnectées. |
| Graph | Réseaux sociaux, Détection de fraude (Relations > Data). | Neptune, Neo4j | Simple stockage clé-valeur. |
Event Driven Architecture (EDA)
Concepts Clés
- Producer/Consumer : Découplage total. Le producteur ne connait pas le consommateur.
- Idempotence : Capacité à traiter le même message 2 fois sans effet de bord (ex: ne pas débiter 2 fois). Crucial en architecture "At-least-once".
Queue (SQS)
Point-to-Point. Un message est traité par UN seul consommateur.
Usage: Load leveling, Jobs asynchrones.
Topic / Stream (SNS/Kafka)
Pub/Sub. Un message est lu par PLUSIEURS abonnés.
Usage: Notifications, Event Sourcing.
Well-Architected Framework
Les 6 piliers pour auditer n'importe quelle architecture cloud.
IaC, CI/CD, Observabilité, Post-mortems.
IAM, Data Protection (Encryption), Incident Response.
Recovery planning, Distributed design (HA), Change management.
Selection des types d'instances, Serverless, Innovation.
FinOps, Spot instances, Right-sizing.
Maximiser l'utilisation, Hardware efficient, Régions vertes.