Aller au contenu

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

  1. Partir de la charge cible : transactions par seconde, utilisateurs concurrents, volume de données
  2. Appliquer les ratios de ressources : combien de CPU/RAM par 100 req/s selon le profil applicatif
  3. Ajouter la marge headroom : 20-30 % au-dessus du pic prévu
  4. 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

  1. Définir l'objectif : mesurer quoi ? (throughput, latence p99, IOPS maximales)
  2. Isoler le composant : éviter les interferences avec d'autres charges
  3. Répéter les mesures : au moins 3 runs pour les variantes statistiques
  4. Varier la charge : courbe charge/latence, pas seulement le pic
  5. 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