Instances TINA OUTSCALE : choisir le bon type et bien dimensionner

Choisir le bon type d’instance est la décision qui détermine directement les performances applicatives et la facture mensuelle. OUTSCALE expose un système flexible au format tinavW.cXrYpZ qui permet d’exprimer exactement le couple vCPU / RAM / flag de performance dont vous avez besoin, sans être limité à une grille figée. Cette page décrit le format, les flags de performance, et propose une méthode de sizing pragmatique. Page tagguée pour les piliers Well-Architected Performance Efficiency et Cost Optimization.

Ce que vous allez apprendre

Décoder le format TINA tinavW.cXrYpZ — ce que chaque lettre signifie.
Choisir une génération CPU parmi les générations actuellement disponibles.
Comprendre les performance flags (1/2/3) et leur impact réel sur les charges.
Comprendre la correspondance pédagogique avec les familles AWS (t / m / c / r) pour transposer ses repères.
Appliquer une méthode de sizing : commencer petit, mesurer, ajuster.
Créer une VM avec le bon type via oapi-cli.

Prérequis

Avoir lu Réseau — design Net + Subnets et Security Groups — une VM se crée dans un Subnet avec un SG.
Connaître le vocabulaire OUTSCALE ↔ AWS (VM ≈ EC2 instance, OMI ≈ AMI).
oapi-cli configuré.

Le format TINA — anatomie d’un type d’instance

OUTSCALE expose un système de types d’instances flexibles sous le format tinavW.cXrYpZ, où chaque lettre est un paramètre indépendant.

Position	Signifie	Plage de valeurs
`W`	Génération du processeur (TINA version)	de 2 à 7 (la v3 n’est plus disponible à la création)
`X`	Nombre de vCores	jusqu’à 78
`Y`	Mémoire en GiB	jusqu’à 1039 GiB
`Z`	Performance flag	1 (highest), 2 (high), 3 (medium)

Exemples :

tinav5.c2r4p2 : génération 5, 2 vCPU, 4 GiB RAM, performance high.
tinav6.c8r16p1 : génération 6, 8 vCPU, 16 GiB RAM, performance highest.
tinav4.c4r8 : génération 4, 4 vCPU, 8 GiB RAM, performance par défaut (high).

Cette flexibilité est l’une des particularités d’OUTSCALE — vous n’êtes pas limité à une grille figée comme sur certains hyperscalers.

Les performance flags — comprendre 1, 2 et 3

Le flag de performance détermine la stabilité de la puissance CPU allouée à la VM.

Flag	Niveau	Caractéristiques	Cas d’usage typique
`p1`	highest	Capacité maximale stable sur tous les vCPU pendant toute la durée de vie	Bases de données critiques, calcul intensif, applications à SLA strict
`p2`	high (par défaut)	Capacité élevée mais variable dans le temps	Workloads applicatifs classiques, web, API métier
`p3`	medium	Performance avec variabilité significative, sans garantie de constance	Postes de développement, environnements de test, batchs occasionnels

Conséquences pratiques

p1 est plus cher mais offre une performance prévisible — choix par défaut pour la production sensible à la latence.
p2 est le bon compromis pour la majorité des cas — performance correcte, coût raisonnable.
p3 convient pour dev / staging ou des charges peu sensibles à la performance — économie réelle, mais variations possibles.

Si vous spécifiez un VmType qui contient déjà un flag (...p1, ...p2, ...p3), ce flag prime sur le paramètre Performance éventuellement passé à part. Pour rester explicite, toujours préciser le flag dans le VmType.

Types AWS-style — supportés mais déconseillés sur OUTSCALE

OUTSCALE accepte techniquement les noms d’instances AWS (t2.small, m5.xlarge, c5.2xlarge, etc.) dans le paramètre VmType. Ces noms sont traduits en interne vers un type TINA correspondant.

Pourquoi nous déconseillons cette approche dans la formation :

Perte de précision — un nom AWS comme t2.small mappe vers une définition figée, alors que le format TINA natif vous laisse exprimer exactement le couple vCPU/RAM/flag dont vous avez besoin (par exemple tinav6.c4r12p1, qui n’a pas d’équivalent direct AWS).
Mapping pas toujours intuitif — le flag de performance et la génération CPU appliqués lors de la traduction ne sont pas évidents à la lecture du nom AWS, ce qui complique la review et le diagnostic.
Lecture éditoriale — un type natif comme tinav6.c4r8p2 documente lui-même son contenu (génération, vCPU, RAM, flag), tandis qu’un type AWS demande de connaître le mapping interne.
Cas d’usage limité — la seule raison de garder un type AWS-style est une migration en cours depuis AWS où l’on souhaite minimiser les modifications de scripts existants. C’est une étape transitoire, pas un état cible.

Recommandation : utiliser systématiquement le format TINA natif dans tous les nouveaux déploiements, scripts et modules Terraform. Migrer progressivement les types AWS-style vers leur équivalent TINA explicite, à l’occasion d’une revue de sizing ou d’une refonte d’architecture.

Choisir le bon profil de charge

Trois familles classiques couvrent la majorité des besoins.

Charges « général »

Équilibre vCPU / RAM standard, par exemple 2 vCPU / 4 GiB ou 4 vCPU / 8 GiB. Bon défaut pour des applications web, API, petits services métier.

TINA : tinav5.c2r4p2, tinav6.c4r8p2
Équivalent pédagogique AWS (à titre de repère, pas pour usage en production OUTSCALE) : familles t (burst) ou m (général) — préférer le format TINA natif

Charges « mémoire » (bases de données, caches)

Ratio RAM / vCPU élevé, par exemple 2 vCPU / 16 GiB ou 4 vCPU / 32 GiB. Pour PostgreSQL, Redis, Elasticsearch, ou applications avec gros caches en mémoire.

TINA : tinav6.c4r32p1
Équivalent pédagogique AWS : famille r (mémoire) — préférer le format TINA natif

Charges « CPU » (compute intensif)

Ratio vCPU / RAM élevé, par exemple 8 vCPU / 4 GiB. Pour le calcul scientifique, encodage vidéo, batch, build CI/CD.

TINA : tinav6.c8r4p1
Équivalent pédagogique AWS : famille c (compute) — préférer le format TINA natif

Charges GPU

Pour l’IA, le calcul scientifique ou le rendu graphique, OUTSCALE propose les fGPU (Flexible GPU) — GPU NVIDIA (A100, V100, P100, P6, K2) attachables dynamiquement à une instance compute. C’est une particularité OUTSCALE sans équivalent AWS direct (chez AWS, on prend une famille p3, g4… avec GPU intégré). Détail dans le Volet 4 — Services managés et alternatives.

Méthode de sizing — commencer petit, mesurer, ajuster

Le sizing par intuition est la meilleure manière de payer trop cher ou de sous-dimensionner. La discipline qui marche en pratique tient en trois étapes.

Étape 1 — Démarrer petit

Pour un nouveau projet sans historique de charge, commencer par une petite instance : tinav6.c2r4p2 ou équivalent. C’est suffisant pour les premières mises en service et permet de mesurer le comportement réel.

Démarrer trop gros est tentant (« on aura de la marge ») mais coûte cher en attendant que la charge réelle se stabilise.

Étape 2 — Mesurer pendant 2 à 4 semaines

Collecter les métriques applicatives sur au moins deux à quatre semaines de fonctionnement nominal :

Utilisation CPU moyenne et p95 — la VM est-elle saturée régulièrement ?
Utilisation mémoire — y a-t-il du swap, des OOM ?
Latence applicative — l’application tient-elle ses SLO de latence ?
IOPS sur le disque BSU — un goulot stockage peut être confondu avec un manque de CPU/RAM.

Sans ces données, toute décision de redimensionnement est arbitraire.

Étape 3 — Ajuster

Trois cas typiques :

Constat	Action
CPU > 70 % en p95	Passer à plus de vCPU (`c2 → c4`) ou monter le flag de performance (`p2 → p1`)
Mémoire saturée, swap actif	Passer à plus de RAM (`r4 → r8`), changer de famille si nécessaire
Latence élevée mais CPU/RAM OK	Investiguer le stockage (passer en SSD io1 ou augmenter les IOPS BSU — voir page suivante)
Utilisation < 30 % constante	Descendre en taille pour réduire la facture

Réflexes complémentaires

Right-sizing trimestriel : revoir les types d’instance tous les 3 mois pour repérer les VMs sur-dimensionnées qui ne le sont plus restées par inertie.
Dev/staging en p3 : descendre les flags de performance sur les environnements non-production donne un gain immédiat sans impact métier.
Profils différents par tier : un frontend a souvent besoin de c (CPU pour TLS), un backend de général, une base de données de r (mémoire). Penser par tier plutôt que d’utiliser le même type partout.

Créer une VM avec le bon type via `oapi-cli`

CreateVms exige uniquement ImageId (l’OMI à utiliser). Le VmType est optionnel mais doit toujours être précisé explicitement avec un type TINA natif (tinavW.cXrYpZ) pour ne pas dépendre du type appliqué par défaut.

oapi-cli CreateVms \
  --ImageId "ami-12345678" \
  --VmType "tinav6.c4r8p2" \
  --SubnetId "subnet-private-a-id" \
  --SecurityGroupIds '["sg-87654321"]' \
  --KeypairName "ma-cle-ssh" \
  --MinVmsCount 1 \
  --MaxVmsCount 1

Points à noter :

VmType doit utiliser le format TINA natif (tinav6.c4r8p2) — précis, lisible et adapté à OUTSCALE.
MinVmsCount / MaxVmsCount permettent de créer plusieurs VMs d’un coup. Utile pour un cluster, en spécifiant MinVmsCount: 3, MaxVmsCount: 3.
Performance (paramètre séparé) accepte medium, high, highest. Si VmType contient déjà un flag (...p2), ce flag prime sur Performance.
SubnetId est requis pour créer la VM dans un Net (rappel : toujours dans un Net).
SecurityGroupIds est un tableau — vous pouvez attacher plusieurs SG.

Tagger ensuite la VM avec CreateTags pour appliquer la stratégie de tagging (env, project, tier, cost-center).

Bonnes pratiques (par pilier Well-Architected)

1. Démarrer petit, mesurer, ajuster — piliers Performance + Cost

Pas de sizing à l’aveugle. Première mise en service avec une instance modeste (tinav6.c2r4p2 ou équivalent), mesure pendant 2-4 semaines, redimensionnement basé sur les métriques observées. Cette discipline élimine la principale source de gaspillage sur les factures cloud.

2. Generation CPU récente — pilier Performance

Privilégier les générations récentes (tinav6 ou tinav7 quand disponible) pour bénéficier des dernières optimisations matérielles et d’un meilleur ratio prix / performance. Une génération ancienne (par exemple tinav4) reste fonctionnelle, mais coûte généralement plus cher pour la même performance perçue.

3. Performance flag adapté à l’environnement — piliers Performance + Cost

Environnement	Flag conseillé
Production sensible à la latence (DB, API critiques)	`p1` (highest)
Production standard (web, API métier)	`p2` (high) — par défaut
Staging / pré-production	`p2` ou `p3` selon réalisme attendu
Dev / sandbox	`p3` (medium) — gain immédiat

4. Profil par tier — pilier Performance

Choisir une famille adaptée au rôle : c (CPU) pour les frontaux qui font du TLS, général (m-style) pour les backends, r (mémoire) pour les bases de données. Utiliser le même type partout est suboptimal — surcoût ou sous-performance selon le tier.

5. Right-sizing trimestriel — pilier Cost

Réviser les VMs tous les trois mois pour repérer celles qui sont sur-dimensionnées par inertie (charge réduite mais type pas adapté). Combiné avec les logs OMS et un export CSV de la consommation, c’est un poste de gain régulier en FinOps.

6. Tagging discipliné dès la création — pilier Operational Excellence

Chaque VM doit porter les tags structurants (env, project, owner, tier, cost-center) dès la création. C’est ce qui permet ensuite le reporting FinOps par projet et l’inventaire opérationnel par tier.

Antipatterns à éviter

Antipattern	Conséquence	Discipline correcte
Sur-dimensionner « pour avoir de la marge »	Facture multipliée par 2-3 sans bénéfice	Démarrer petit, mesurer, ajuster
Même type partout (frontend, backend, DB)	Sous-performance ou surcoût selon le tier	Profil adapté par tier (`c`, général, `r`)
`p1` partout par sécurité	Surcoût significatif sur dev/staging	Flag adapté à l’environnement
Génération CPU ancienne sans raison	Performance / prix sous-optimal	Génération récente (`tinav6`+) par défaut
VM créée sans tags	Pas de FinOps possible, audit difficile	Tagging dès la création
Pas de revue de sizing	Inertie qui s’installe, surcoût qui s’accumule	Right-sizing trimestriel

Sizing sous l’angle Well-Architected

Performance Efficiency — adapter la taille à la charge

Le pilier Performance repose sur l’idée que chaque ressource doit être adaptée à sa charge — ni trop petite (saturation), ni trop grosse (gaspillage). Sur OUTSCALE, la flexibilité du format TINA rend cet ajustement particulièrement simple : vous pouvez préciser exactement le couple vCPU/RAM/flag dont vous avez besoin, sans être contraint par une grille figée.

Les questions clés du pilier Performance adressées par cette page :

Comment mesure-t-on le besoin réel d’une VM ? — métriques CPU/mémoire/IOPS sur 2-4 semaines.
Comment ajuste-t-on quand le profil change ? — redimensionnement (avec arrêt/redémarrage de la VM) selon les métriques.
Comment évite-t-on que le sous-dimensionnement n’impacte les utilisateurs ? — alertes sur saturation, sizing initial avec un peu de marge à p2.

Cost Optimization — payer ce qu’on consomme

Sur le pilier Cost, le sizing est le levier numéro un. Une infrastructure sur-dimensionnée par inertie peut coûter 2 à 3 fois ce qu’elle devrait. Trois leviers cumulables :

Right-sizing initial : démarrer petit, monter selon les métriques.
Flag de performance adapté : p3 sur dev/staging, p2 sur prod standard, p1 réservé aux charges critiques.
Right-sizing trimestriel : revue régulière pour ajuster les VMs dont la charge a évolué.

Combinée au tagging discipliné (cf. Multi-comptes / projets), cette démarche alimente directement le reporting FinOps par projet ou centre de coût.

À retenir

Format TINA : tinavW.cXrYpZ où W = génération CPU (2-7), X = vCores, Y = RAM en GiB, Z = flag de performance (1=highest, 2=high, 3=medium).
Les types AWS-style sont techniquement acceptés mais déconseillés sur OUTSCALE — préférer le format TINA natif, plus précis et lisible.
Performance flag par défaut : p2 (high). p1 pour la prod critique, p3 pour dev/staging.
Choix par tier : c pour CPU, général pour backend, r pour bases de données et caches.
Méthode de sizing : démarrer petit, mesurer 2-4 semaines, ajuster selon les métriques.
Right-sizing trimestriel est le levier FinOps le plus rentable.
Tagging dès la création non négociable pour le reporting FinOps et l’audit.

Prochaines étapes

Stockage — BSU, volumes, IOPS Choisir le bon type de volume et calibrer les IOPS pour ne pas saboter la performance.

Réseau — IGW, NAT, EIP, bastion Architecture réseau dans laquelle s'inscrivent les VMs.

EIM patterns multi-comptes Tagging unifié par compte pour le reporting FinOps.

Volet 4 — Services managés et alternatives fGPU pour les charges IA et calcul intensif.