Pilier Performance Efficiency sur OUTSCALE

Le pilier Performance Efficiency couvre le sizing des instances, les IOPS des volumes, la latence inter-AZ, les caches applicatifs, et le choix entre types d’instances selon le profil de charge. Sur OUTSCALE, les gammes TINA (tinavW.cXrYpZ) offrent un éventail aligné sur les usages classiques, complété par les fGPU pour les charges IA et calcul intensif. Cette page formule les questions clés, propose une checklist actionnable, deux ADR types et les points d’audit correspondants.

Le pilier en deux phrases

Performance Efficiency évalue la capacité d’une architecture à utiliser efficacement les ressources cloud disponibles, et à s’adapter aux variations de charge sans surdimensionnement permanent. Sur OUTSCALE, il se matérialise par un sizing TINA ajusté au profil de charge, un type de volume BSU choisi sur des mesures d’IOPS, une latence inter-AZ acceptée et compensée par les patterns architecturaux, et des caches applicatifs placés au bon endroit dans la chaîne.

Les questions clés

Une architecture qui revendique une posture Performance doit pouvoir répondre aux questions suivantes :

Sizing initial — chaque famille d’instance TINA est-elle choisie sur la base d’hypothèses de charge documentées, ou par habitude ? La règle « démarrer petit, mesurer, ajuster » est-elle appliquée ?
Mesure réelle — la consommation CPU, mémoire, IOPS est-elle mesurée en production sur une fenêtre représentative (au moins 7 jours) ? Existe-t-il des dashboards de p50/p95/p99 ?
Right-sizing — les instances surdimensionnées (CPU < 30 % en p95 sur 7 jours) sont-elles identifiées et redimensionnées ?
Type de volume BSU — les volumes data utilisent-ils le bon type (standard, gp2, io1) selon le profil IOPS attendu ? Les mesures réelles confirment-elles le choix ?
Latence inter-AZ — les workloads sont-ils conscients du coût en latence d’un appel inter-AZ ? Les chaînes critiques sont-elles co-localisées sur la même AZ quand le RPO le permet ?
Caches applicatifs — les requêtes récurrentes lentes sont-elles cachées (Redis, Memcached, cache HTTP) ? Le cache est-il dimensionné sur la base de métriques de hit ratio ?
Scaling — le service peut-il scaler horizontalement (ajouter des instances) ou est-il limité au scaling vertical (changer la taille d’instance) ?
Benchmarks — un benchmark de référence existe-t-il pour le service principal, exécuté périodiquement, dont les résultats sont comparés aux versions précédentes ?
Profilage applicatif — l’équipe profile-t-elle le code applicatif (CPU profiler, memory profiler) en pré-production avant de blâmer l’infrastructure pour des latences anormales ?

Une architecture qui répond « non » à plus de quatre questions est statistiquement surdimensionnée ou mal dimensionnée, ce qui se traduit en coût excessif ET en latence applicative inutile.

Application sur OUTSCALE

Format TINA et choix de famille

Les instances OUTSCALE suivent le format tinavW.cXrYpZ :

v — génération du processeur (v4, v5, v6…). Les générations récentes offrent un meilleur rapport performance/coût.
c — nombre de vCPU.
r — quantité de RAM en GiB.
p — flag de performance : p1 = highest (capacité maximale stable), p2 = high (défaut, performance correcte avec variabilité), p3 = medium (performance variable, économique).

Quelques familles courantes :

tinav5.c2r4p2 — équilibrée (2 vCPU, 4 GiB RAM, performance high). Démarrage standard pour un service web typique.
tinav6.c4r16p1 — orientée mémoire avec performance highest (16 GiB pour 4 vCPU). Pour bases de données critiques.
tinav6.c8r4p1 — orientée CPU avec performance highest (1 GiB RAM par vCPU). Compute pur, encoding, batch sensible aux SLA.

La règle pragmatique : démarrer avec une famille équilibrée c2r4p2, mesurer la consommation réelle pendant 7 à 14 jours, ajuster vers une famille mieux profilée si nécessaire. Le détail est traité dans Calcul — instances TINA et sizing.

IOPS et type de volume BSU

OUTSCALE propose trois types de volumes BSU (paramètre VolumeType à la création) :

standard — pour les volumes peu sollicités (archivage, volumes log peu actifs).
gp2 — pour la plupart des workloads applicatifs sans contraintes IOPS strictes.
io1 — pour les bases de données et workloads exigeants en IOPS. Le Iops est provisionné explicitement à la création, avec un plafond de 13 000 IOPS par volume et un ratio maximum de 300 IOPS/GiB (selon la spec OAPI CreateVolume).

Pour les valeurs précises de performance par type (baseline gp2, IOPS du standard), se référer à la documentation officielle « About Volumes » d’OUTSCALE — les valeurs exactes peuvent évoluer avec les versions de l’API.

Le choix doit reposer sur une mesure : pendant la phase de pré-production, lancer un fio ou équivalent, mesurer les IOPS réellement consommés en p95, comparer aux capacités de chaque type. Choisir le moins cher qui couvre le besoin avec une marge raisonnable (20 à 30 %).

L’erreur classique : choisir io1 par confort sans mesure, sur des workloads qui consomment moins de 1 000 IOPS — surcoût significatif sans bénéfice.

Latence inter-AZ

Sur OUTSCALE, la latence entre deux sous-régions (eu-west-2a ↔ eu-west-2b) est typiquement de 1 à 3 ms. C’est faible mais non négligeable pour des chaînes d’appels :

5 appels inter-AZ ajoutent 5 à 15 ms de latence pure.
Une transaction BDD avec replica synchrone inter-AZ paie 1 à 3 ms par commit.

Le pattern : pour les services critiques en latence, co-localiser la chaîne (frontend → backend → cache → BDD) sur la même AZ, et basculer la chaîne entière en cas de défaillance. Pour les services peu sensibles à la latence (batch, reporting), ne pas se contraindre.

La multi-AZ ne s’oppose pas à la performance — elle demande simplement de la conscience architecturale.

Caches applicatifs

Le cache est l’un des leviers de performance les plus efficaces : un hit cache à 1 ms remplace une requête SQL à 50 ms. Les patterns courants sur OUTSCALE :

Redis ou Memcached déployés sur OKS ou sur des VMs dédiées dans le subnet privé.
Cache HTTP au niveau du load balancer (LBU) ou via un reverse proxy (nginx, Varnish) dans le subnet public.
Cache CDN pour les assets statiques (images, JS, CSS) — CDN tiers à choisir selon les contraintes de souveraineté.

La mesure clé est le hit ratio : un cache à 70 % de hit est efficace, un cache à 30 % est probablement mal dimensionné ou mal cléfié.

Scaling horizontal vs vertical

Le scaling horizontal (ajouter des instances) est généralement préférable au scaling vertical (changer de famille TINA) :

Plus de résilience — la perte d’une instance n’affecte qu’une fraction du trafic.
Plus de granularité — passer de 4 à 5 instances est moins disruptif que passer de c4r8p2 à c8r16p2.
Compatible avec le multi-AZ — la répartition se fait naturellement entre les AZ.

Le scaling horizontal demande des workloads stateless (pas d’état local persisté). Pour les workloads stateful (bases de données, files de messages), le scaling reste majoritairement vertical, complété par de la réplication.

Checklist Definition of Done

Sizing initial documenté (hypothèses de charge, famille TINA choisie, justification).
Métriques CPU/mémoire/IOPS collectées via Prometheus, dashboards p50/p95/p99 disponibles.
Right-sizing revu trimestriellement, instances surdimensionnées identifiées et corrigées.
Type de volume BSU choisi sur la base d’une mesure d’IOPS (fio ou équivalent).
Co-localisation AZ appliquée sur les chaînes critiques en latence.
Caches applicatifs dimensionnés sur la base d’un hit ratio mesuré.
Capacité de scaling horizontal documentée pour les workloads stateless.
Benchmarks de référence versionnés, exécutés à chaque release majeure.
Profilage applicatif réalisé en pré-production avant toute hypothèse infrastructure.

ADR types

ADR-PERF-01 — Méthode de sizing « démarrer petit »

Contexte : les instances OUTSCALE sont sizées par habitude (toujours c8r16p3 par exemple), sans rapport avec la charge réelle. Surcoût annuel significatif sur les services peu chargés.

Décision : appliquer la méthode « démarrer petit, mesurer, ajuster ». Tout nouveau service démarre sur tinav5.c2r4p2. Pendant 14 jours, les métriques CPU/mémoire/IOPS sont collectées. À l’issue, la famille est ajustée selon la consommation observée (cible : 50–70 % d’utilisation en p95 sur les ressources contraintes).

Conséquences : effort de mise en place du dashboard initial (1 à 2 jours). Bénéfices durables : économies récurrentes (typiquement 20–40 % sur le compute), workloads correctement profilés.

ADR-PERF-02 — Type de volume BSU sur mesure

Contexte : tous les volumes data sont en io1 par confort, indépendamment du profil IOPS. Coût élevé sans bénéfice mesurable sur les volumes peu sollicités.

Décision : avant tout choix io1, mesurer les IOPS réellement consommés via fio sur 24 à 48 heures en pré-production. Choisir gp2 quand les IOPS p95 sont sous le plafond de la taille de volume cible. Réserver io1 aux volumes BDD exigeants documentés.

Conséquences : 0,5 à 1 jour de mesure par nouveau volume critique. Bénéfices : réduction significative du coût stockage, choix défendable en revue technique.

Points d’audit correspondants

Sur un compte OUTSCALE réel, ces contrôles peuvent être menés via oapi-cli. Quelques exemples :

oapi-cli ReadVms --Filters.VmStateNames[] running

Pour chaque VM, vérifier la famille VmType choisie. Croiser avec les métriques Prometheus pour identifier les instances surdimensionnées.

oapi-cli ReadVolumes

Lister les volumes et leur type (VolumeType). Identifier les volumes io1 peu sollicités à reclasser en gp2.

L’audit complet est traité dans une page dédiée du Volet 5, à venir.

Antipatterns à éviter

Sizing par confort. Choisir c8r16p3 pour tout, parce que « ça donne de la marge ». Le résultat est une facture mensuelle 2 à 3 fois trop élevée et des instances qui tournent à 10 % d’utilisation moyenne.

Type de volume au pifomètre. Mettre tout en io1 pour « être tranquille ». Coût significativement supérieur à gp2 sur des workloads qui n’ont pas besoin des IOPS provisionnés.

Multi-AZ sans conscience de la latence. Distribuer les composants d’une chaîne critique entre AZ pour « la résilience » sans mesurer la latence introduite. Le résultat est un service plus fragile (chaîne plus longue) et plus lent (latence cumulée).

Cache mal cléfié. Mettre en place un Redis et le considérer comme magique. Sans réflexion sur les clés (granularité, TTL, invalidation), le hit ratio reste bas et le cache devient une dépense sans bénéfice.

Blâmer l’infrastructure avant le code. Demander une instance plus grosse à chaque fois qu’une latence anormale apparaît, sans profiler le code applicatif. Souvent, le goulot est une requête SQL non indexée ou une boucle N+1, pas le CPU.

À retenir

Sizing TINA par mesure — démarrer petit, mesurer 7 à 14 jours, ajuster.
Type de volume BSU choisi sur mesure d’IOPS — gp2 par défaut, io1 justifié.
Latence inter-AZ consciente — co-localiser les chaînes critiques en latence.
Caches applicatifs dimensionnés sur hit ratio mesuré, pas postulés.
Scaling horizontal privilégié pour les workloads stateless.
Profilage applicatif avant hypothèse infrastructure — c’est souvent le code, pas la machine.

Prochaines étapes

Volet 5 — Vue d'ensemble Le sommaire des 7 piliers Well-Architected appliqués à OUTSCALE.

Calcul — instances TINA et sizing Le guide opérationnel sur le sizing TINA.

Stockage — BSU, volumes, IOPS Les types de volumes et la mesure d'IOPS.

fGPU — GPU NVIDIA à la demande Pour les charges IA et calcul intensif.