Dimensionnement¶
Sizing initial, right-sizing après production, benchmarking et tests de charge.
Sizing initial¶
Le sizing initial est l'estimation de la capacité nécessaire avant la mise en production. Il combine la baseline existante (migration) ou les projections (nouveau service) avec une marge de sécurité.
Méthodologie de sizing initial¶
- Partir de la charge cible : transactions par seconde, utilisateurs concurrents, volume de données
- Appliquer les ratios de ressources : combien de CPU/RAM par 100 req/s selon le profil applicatif
- Ajouter la marge headroom : 20-30 % au-dessus du pic prévu
- Prévoir la croissance : dimensionner pour 6-12 mois, pas pour aujourd'hui seul
Ratios courants (ordres de grandeur)¶
| Type de charge | CPU (vCPU) | RAM (Go) | Notes |
|---|---|---|---|
| API REST légère (100 req/s) | 2 | 4 | Stateless, faible I/O |
| API avec base de données (100 req/s) | 4 | 8 | Connexions pool |
| Worker batch CPU-intensif | 8-16 | 16 | Parallélisme explicite |
| Cache distribué (Redis) | 2 | 16-64 | Priorité RAM |
| Base de données relationnelle | 8 | 32-128 | Ratio I/O critique |
Ne jamais dimensionner sur la charge actuelle seule
Dimensionner pour la charge actuelle sans marge = saturation garantie au prochain pic ou à la prochaine livraison. Toujours intégrer la croissance prévue sur 6 mois minimum.
Right-sizing après production¶
Le right-sizing est l'ajustement des ressources après observation du comportement réel en production.
graph LR
A["Sizing initial\n(estimation)"] --> B["Deploiement\nen production"]
B --> C["Mesure\n2-4 semaines"]
C --> D{"Utilisation\nmoyenne ?"}
D -->|"< 20 %"| E["Reduire\n(downsize)"]
D -->|"20-70 %"| F["Maintenir\n(correct)"]
D -->|"> 70 %"| G["Augmenter\n(upsize)"]
E --> C
F --> H["Revue\ntrimestrielle"]
G --> C Outils de recommandation cloud¶
| Outil | Cloud | Fonctionnement |
|---|---|---|
| AWS Compute Optimizer | AWS | ML sur 14 jours, recommande instance type |
| Azure Advisor | Azure | Analyse utilisation, propose SKU adapté |
| GCP Recommender | GCP | Recommandations CPU/RAM par instance |
| Datadog Cloud Cost | Multi-cloud | Correlation coûts/utilisation |
| Infracost | Multi-cloud | Estimation coûts dans CI/CD |
Benchmarking¶
Le benchmarking mesure les performances réelles d'une infrastructure ou d'un composant.
Méthodologie¶
- Définir l'objectif : mesurer quoi ? (throughput, latence p99, IOPS maximales)
- Isoler le composant : éviter les interferences avec d'autres charges
- Répéter les mesures : au moins 3 runs pour les variantes statistiques
- Varier la charge : courbe charge/latence, pas seulement le pic
- Documenter l'environnement : version OS, drivers, configuration kernel
Outils de benchmarking système¶
| Outil | Ressource | Usage typique |
|---|---|---|
| sysbench | CPU, RAM, IOPS | Benchmark VM, comparaison types d'instances |
| fio | Stockage IOPS | Caracterisation disques SSD/NVMe |
| iperf3 | Réseau | Débit entre deux nœuds |
| stress-ng | CPU, RAM | Stress test multi-ressources |
| pgbench | PostgreSQL | Transactions par seconde base de données |
Tests de charge applicatifs¶
Les tests de charge valident le comportement du système complet sous stress.
Comparatif des outils¶
| Outil | Langage scripts | Points forts | Limites |
|---|---|---|---|
| k6 | JavaScript | Léger, CI/CD natif, métriques Prometheus | Pas de GUI natif |
| Locust | Python | Scriptable, distribué, UI web | Plus gourmand en ressources |
| JMeter | XML/GUI | Très complet, plugins nombreux | Interface lourde, courbe d'apprentissage |
| Gatling | Scala/DSL | Rapports HTML riches, haute performance | Scala débutants rebute |
| Artillery | YAML/JS | Simple, serverless-friendly | Moins mature |
Types de tests¶
| Type | Objectif | Durée typique |
|---|---|---|
| Smoke test | Vérifier le fonctionnement de base | 1-2 minutes |
| Load test | Valider les performances a charge nominale | 15-30 minutes |
| Stress test | Trouver le point de rupture | Jusqu'à la saturation |
| Soak test | Détecter les fuites mémoire / dégradation | 4-8 heures |
| Spike test | Simuler un pic soudain | Montee rapide en 30s-2min |
Profiling et identification des bottlenecks¶
Lorsque les tests révèlent une dégradation, le profiling identifie la cause racine.
| Symptome | Outil de profiling | Ce qu'il révélé |
|---|---|---|
| CPU élevé | perf, flamegraphs | Fonctions CPU-intensives |
| Latence base de données | EXPLAIN ANALYZE (SQL) | Index manquants, full scans |
| Mémoire croissante | pmap, valgrind, heap profiler | Fuites mémoire |
| I/O lente | iostat, blktrace | Contention disque, fragmentation |
| Réseau | tcpdump, Wireshark | Retransmissions, latence réseau |
Flamegraphs pour les bottlenecks CPU
Les flamegraphs (Brendan Gregg) visualisent l'utilisation CPU par fonction en une image exploitable. Disponibles pour la plupart des langages via perf (Linux), async-profiler (JVM), py-spy (Python).
Points clés¶
- Le sizing initial est une estimation — le right-sizing en production le complète
- Une marge de 20-30 % est le minimum raisonnable pour absorber les pics
- Les tests de charge doivent couvrir plusieurs scenarios (nominal, stress, soak)
- Le profiling identifie le vrai goulot d'étranglement — sans lui, on optimise au hasard