Bonnes pratiques

Ce guide présente des modèles, principes et stratégies éprouvés dans des milliers de déploiements.

Principes de conception

1. Commencer simplement, évoluer progressivement

Évitez la surarchitecture initiale. Commencez par le design le plus simple répondant aux besoins actuels, puis faites-le évoluer.

Bon choix : une base, un serveur applicatif et un répartiteur de charge. Mauvais choix : des microservices dans 5 régions avec stockage par événements dès le premier jour.

2. Prévoir les défaillances

Supposez que les composants tomberont en panne. Prévoyez redondance et dégradation contrôlée.

Bon choix : base Multi-AZ, réplicas de basculement et disjoncteurs logiciels. Mauvais choix : tout point de défaillance unique.

3. Mesurer avant d’optimiser

N’optimisez pas sans données. Utilisez les analyses et la supervision.

Bon choix : identifier les goulets réels avec l’analyseur de montée en charge. Mauvais choix : « La base est probablement lente, ajoutons du cache. »

4. Comprendre les compromis

Toute décision implique des compromis. Documentez-les.

Bon choix : « Nous choisissons un monolithe pour lancer vite, puis des microservices à 100k utilisateurs. » Mauvais choix : « Ajoutons des microservices pour monter en charge », sans comprendre la complexité.

5. Tout automatiser

Les processus manuels ne passent pas à l’échelle. Automatisez déploiement, supervision et capacité.

Bon choix : infrastructure comme code avec Terraform, groupes de capacité automatique et pipelines CI/CD. Mauvais choix : provisionnement et décisions de capacité manuels.

Modèles courants

Modèle : application web monolithique

Quand l’utiliser : MVP, équipe unique et <100k utilisateurs.

Topologie :

Users
  ↓
Load Balancer (ELB)
  ↓
App Servers (3+ instances, auto-scaled)
  ↓
Cache Layer (Redis)
  ↓
Database (Primary + Read Replicas)
  ↓
Object Storage (S3)

Avantages :

• Développement et débogage simples.
• Déploiement et extension horizontale faciles.
• Faible charge opérationnelle.

Inconvénients :

• Un code volumineux devient difficile à maintenir.
• La base partagée limite la capacité.
• Dépendance au langage et au framework.

Quand évoluer : lorsque la base limite le système à 50k+ utilisateurs.

Modèle : architecture de microservices

Quand l’utiliser : grandes équipes, >100k utilisateurs et plusieurs services.

Topologie :

API Gateway
├─ Auth Service
├─ User Service
├─ Product Service
├─ Order Service
├─ Payment Service
├─ Notification Service
└─ Analytics Service

Shared Infrastructure:
- Service Mesh (Istio, Linkerd)
- Message Bus (Kafka, RabbitMQ)
- Distributed Tracing
- Centralized Logging

Avantages :

• Capacité indépendante par service.
• Autonomie des équipes.
• Flexibilité technologique et plusieurs langages.
• Déploiement individuel facile.

Inconvénients :

• Complexité opérationnelle accrue.
• Difficultés distribuées : cohérence à terme et débogage.
• Latence entre services.
• Pratiques DevOps matures nécessaires.

Quand l’utiliser : quand le monolithe limite le système ET que l’organisation de l’équipe le permet.

Modèle : sans serveur, FaaS

Quand l’utiliser : charges événementielles, variables et sensibles aux coûts.

Topologie :

API Gateway
  ↓
Lambda Functions (auto-scaled to zero)
  ├─ DynamoDB (serverless database)
  ├─ S3 (object storage)
  ├─ SQS/SNS (messaging)
  └─ CloudWatch Logs

Avantages :

• Paiement du seul temps de calcul utilisé.
• Réduction automatique à zéro au repos.
• Développement et déploiement simples.
• Aucune infrastructure à gérer.

Inconvénients :

• Latence au démarrage à froid.
• Personnalisation limitée de l’environnement.
• Dépendance à AWS Lambda ou GCP Functions.
• Débogage plus difficile qu’avec des serveurs classiques.

Quand l’utiliser : pics soudains, tâches rares et jeunes entreprises avec peu de moyens d’exploitation.

Modèle : lac de données et analytique

Quand l’utiliser : données massives, apprentissage automatique et analyses.

Topologie :

Data Sources (streaming + batch)
  ↓
Data Ingestion (Kafka, Kinesis, SQS)
  ↓
Data Lake (S3, Blob Storage)
  ↓
ETL/Transform (Spark, Glue, Dataflow)
  ↓
Data Warehouse (Redshift, BigQuery, Snowflake)
  ↓
BI/ML Tools (Tableau, DataStudio, SageMaker)

Points à examiner :

• Qualité et gouvernance des données.
• Schéma défini à la lecture ou à l’écriture.
• Données personnelles et confidentialité.
• Performance des requêtes.

Stratégies d’optimisation

Optimisation des coûts

1. Dimensionnement adapté

• Supervisez l’usage réel, pas la capacité maximale.
• Repérez les tendances avec CloudWatch ou équivalent.
• Réduisez les instances surdimensionnées.

2. Instances réservées

• Prévoyez la charge stable.
• Réservez pour 1-3 ans avec 20-40% de réduction.
• Combinez avec la capacité automatique pour la variabilité.

3. Instances Spot

• Pour les tâches tolérant les pannes et non critiques.
• 70% moins chères qu’à la demande.
• Prévoir 2-5% d’interruptions.

4. Stratégie de cache

• Gardez les données fréquentes en mémoire avec Redis.
• Réduit la charge de la base de 50-80%.
• CDN pour les ressources statiques : 80%+ de baisse des coûts.

5. Transfert des données

• Poste coûteux souvent négligé.
• Utilisez les points d’accès VPC pour éviter les frais de transfert.
• Compressez les données en transit.
• Utilisez CloudFront pour la distribution mondiale.

Optimisation de la montée en charge

1. Extension horizontale

• Ajoutez des serveurs derrière le répartiteur.
• Base : réplicas de lecture, primaire et secondaires.
• Cache : nœuds supplémentaires.

2. Partitionnement des bases

• Répartissez par utilisateur, région ou date.
• Chaque partition évolue indépendamment.
• Compromis : coordination plus complexe.

3. Pool de connexions

• Réutilisez les connexions à la base.
• Débit amélioré de 2-3x.
• Moins de surcharge de connexion.

4. Stratégie de cache

• Données fréquentes dans la couche applicative.
• Réponses d’API avec invalidation prévue.
• Requêtes mises en cache dans l’ORM.

Bonnes pratiques de sécurité

1. Chiffrement

• En transit : TLS 1.3 sur tous les points d’accès.
• Au repos : AES-256 avec clés KMS.
• Base : volumes chiffrés et chiffrement applicatif des données personnelles.

2. Authentification et autorisation

• MFA sur tous les comptes.
• OAuth 2.0 pour les intégrations tierces.
• IAM au moindre privilège.
• RBAC pour les utilisateurs.

3. Réseau

• Isolation VPC et sous-réseaux privés pour les bases.
• Groupes de sécurité limités aux ports nécessaires.
• NACL pour une couche supplémentaire.
• WAF protégeant les applications web sur le répartiteur.

4. Protection des données

• Tokenisation et masquage des données personnelles.
• Chiffrement par champ sensible.
• Conservation limitée et suppression des anciennes données.
• Restauration des sauvegardes testée.

5. Supervision et audit

• CloudTrail ou journaux d’audit pour tous les appels API.
• Alarmes CloudWatch sur les anomalies.
• Audits réguliers.
• Guide opérationnel de réponse aux incidents.

Bonnes pratiques de performance

1. Latence

• CDN pour les ressources statiques.
• Index sur les requêtes fréquentes.
• Optimisation des requêtes, éviter N+1.
• Regroupement des requêtes API.

2. Débit

• Répartition de charge entre serveurs.
• Pool de connexions à la base.
• Traitement asynchrone des tâches longues.
• Extension verticale des charges limitées par le processeur.

3. Fiabilité

• Contrôles de santé et récupération automatique.
• Disjoncteurs pour les dépendances.
• Nouvelles tentatives avec attente exponentielle.
• Dégradation contrôlée.

Bonnes pratiques de déploiement

1. Infrastructure comme code

• Tout dans Terraform ou CloudFormation.
• Contrôle de version.
• Revue par les pairs avant application.
• Tests en préproduction d’abord.

2. Déploiement continu

• Tests unitaires, d’intégration et e2e automatisés.
• Déploiement canari progressif.
• Déploiement bleu-vert sans interruption.
• Stratégie de retour arrière.

3. Supervision et observabilité

• Journaux structurés en JSON.
• Traçage distribué avec X-Ray ou Jaeger.
• Métriques Prometheus ou CloudWatch.
• Alertes sur les SLO, pas seulement les erreurs.

Antimodèles : à éviter

❌ Point de défaillance unique, sans redondance. ❌ Surconception, avant que la croissance ne la justifie. ❌ Coûts ignorés, pour des fonctions inutiles. ❌ Capacité manuelle, au lieu d’automatique. ❌ Aucune supervision, donc aucune visibilité. ❌ Aucun plan de reprise : espérer n’est pas une stratégie. ❌ Tout dans une seule zone, exposé aux pannes du centre de données.

Étapes suivantes

• Explorez les modèles → Bibliothèque de modèles
• Apprenez l’analyse → Modules d’analyse
• Bonnes pratiques de gouvernance → Gouvernance