Économisez jusqu'à 90 % sur vos coûts de compute grâce aux instances Spot. Nous vous expliquons ce qu'elles sont, pourquoi les utiliser et dans quels cas.
Bien qu'elles puissent réduire vos coûts de compute de 20 à 80 % et rendre indirectement vos applications plus résilientes, les instances Spot (ou Spot VMs sur Google Cloud) restent largement sous-exploitées par rapport à ce qu'elles devraient être.
Les raisons sont variées : nature peu prévisible, crainte d'interruptions des workloads, complexité de mise en place et de gestion. Mais la raison la plus courante reste tout simplement le manque de familiarité avec ces instances.
Pourtant, comprendre comment franchir ces obstacles perçus vous permettra de débloquer des économies de compute jusqu'ici inexploitées.
Dans cette série en deux parties, nous abordons tout ce qu'il faut savoir pour tirer pleinement parti des instances Spot.
Dans cette première partie, nous verrons ce que sont les instances Spot, pourquoi les utiliser et quand y recourir. Dans la seconde partie, nous expliquerons comment optimiser leur utilisation avec les Auto Scaling groups et maximiser vos économies grâce à Spot Scaling.
Que sont les instances Spot ?
Les instances Spot s'apparentent à ces vols à prix cassés disponibles le jour même, libérés par des annulations de dernière minute ou des places invendues. Les compagnies aériennes baissent fortement leurs tarifs pour remplir rapidement ces sièges vides avant le décollage.
Côté compute, les fournisseurs cloud proposent leurs ressources on-demand inutilisées à des tarifs nettement inférieurs à ceux des instances on-demand classiques — jusqu'à 90 % de remise — afin de valoriser leur capacité excédentaire.
Vous fixez simplement un prix d'enchère pour l'instance Spot — le maximum que vous acceptez de payer par heure — et tant que le prix Spot (le prix actuel sur le marché) reste inférieur à votre enchère, l'instance fonctionne.
Le fournisseur cloud peut toutefois récupérer une instance Spot avec seulement deux minutes de préavis si la demande pour des instances on-demand au tarif standard augmente, ce qui peut interrompre votre application.
Instances Spot et billets d'avion offrent tous deux la possibilité d'obtenir quelque chose (de la puissance de calcul pour les unes, des places pour les autres) à moindre coût. Le tout avec une part d'incertitude et de risque : une instance Spot peut être récupérée si le prix du marché dépasse votre enchère, et un billet de dernière minute peut disparaître si quelqu'un l'achète avant vous.
Les deux situations d'interruption les plus courantes sont :
- Une hausse soudaine de la demande pour des instances on-demand ou réservées
- Une remontée du prix Spot au-dessus de l'enchère (moins probable aujourd'hui)
Pourquoi utiliser les instances Spot (indice : ce n'est pas qu'une question d'économies)
Les économies potentielles sur EC2 (jusqu'à 80 % !) sont souvent mises en avant comme l'avantage majeur des instances Spot, mais ce n'est pas le seul.
Les instances Spot ne rendent pas vos applications plus résilientes en soi : elles exigent souvent qu'elles le soient déjà pour absorber efficacement les interruptions potentielles qui leur sont liées.
Par exemple, comme les applications qui tournent sur des instances Spot doivent idéalement être conçues pour gérer les interruptions de manière fluide, vous devriez avoir déjà prévu des points de contrôle, des mécanismes de sauvegarde automatique ou la répartition des workloads sur plusieurs instances.
De cette façon, votre infrastructure :
- Absorbe mieux les fluctuations,
- Maintient ses performances en période de pointe, et
- Atténue les risques liés aux interruptions ou défaillances potentielles.
Lors des pics de charge, les instances Spot peuvent être intégrées à votre système pour absorber la demande accrue, en garantissant qu'il s'adapte aux variations de trafic ou de workload sans dégradation des performances.
Avec des instances moins chères, vous pouvez allouer davantage de ressources aux mécanismes de redondance et de bascule, et répartir vos workloads sur un plus grand nombre d'instances.
Et si une instance subit une interruption, les autres peuvent continuer à traiter une partie du workload, minimisant ainsi l'impact d'une défaillance isolée. Vos workloads basculent ainsi sans heurts vers une autre instance, sans incidence financière notable.
Les EC2 Instance Pools expliqués
Pour tirer le meilleur parti des instances Spot AWS, il est essentiel de bien comprendre la notion d'EC2 instance pool. Un EC2 instance pool désigne la capacité totale d'un type d'instance (par exemple m5.xlarge) dans une région donnée.
Lorsqu'un instance pool comporte de la capacité inutilisée, cette capacité disponible est appelée Spot Capacity pool.
Chaque famille d'instances, taille d'instance, zone de disponibilité et région possède ses propres EC2 instance pools, et donc ses propres Spot capacity pools.
D'où l'importance de ne pas mettre tous vos œufs dans le même panier. Plus vous puisez dans un grand nombre de pools, plus votre sélection d'instances sera diversifiée — ce qui réduit le risque de ne pas trouver d'instances Spot disponibles pour votre application.
Quand utiliser les instances Spot
De manière générale, les instances Spot conviennent particulièrement aux workloads qui :
- Sont flexibles,
- N'ont pas de contraintes temporelles strictes,
- Sont distribuables et peuvent être découpés en tâches exécutées en parallèle,
- Tolèrent les interruptions.
Nous détaillerons les cas d'usage où les instances Spot ont du sens, mais voici trois questions pour déterminer si vos workloads sont éligibles :
- Mes workloads sont-ils tolérants aux pannes ?
Comme les instances Spot peuvent être interrompues, les workloads doivent être conçus pour gérer ces interruptions sans provoquer de défaillance critique ni de perte de données. Les workloads tolérants aux pannes peuvent continuer à fonctionner ou récupérer rapidement lorsqu'une instance est interrompue ou résiliée. 2. Le workload peut-il être arrêté en moins de 2 minutes ? Les workloads doivent pouvoir être arrêtés dans un court délai pour éviter toute perte de données ou interruption de service. Si votre workload peut être stoppé en moins de deux minutes, il sera plus simple de réagir aux interruptions des instances Spot. C'est pourquoi les applications stateless conviennent particulièrement aux instances Spot, puisqu'elles ne stockent pas de données de session. Elles peuvent ainsi migrer en toute fluidité d'une instance à l'autre sans perdre de fonctionnalités ni de données, ce qui les rend résilientes face aux interruptions. 3. Puis-je être flexible sur les types d'instances et les zones de disponibilité ? Répartir vos workloads sur plusieurs instances et zones de disponibilité réduit leur vulnérabilité aux interruptions en diluant le risque. Rappelez-vous : la capacité est une caractéristique d'un Spot instance pool. Chaque type d'instance dans chaque zone de disponibilité forme un pool distinct. Lorsque vous puisez dans plusieurs pools, le risque d'interruptions simultanées dans tous les pools est plus faible que celui d'une interruption dans un pool unique. S'étendre sur plusieurs zones de disponibilité réduit la dépendance à un seul pool et garantit la continuité même si une zone subit des contraintes de capacité ou des hausses de prix.
Plus précisément, vous devriez envisager les instances Spot dans les situations suivantes.
Environnements de test et CI/CD
Les environnements de test/dev et les tâches CI/CD n'ont généralement pas besoin d'une disponibilité continue, car ils sont sollicités ponctuellement pour développer des fonctionnalités ou tester des modifications. Les tâches de développement et de test peuvent par ailleurs être redémarrées, ou mises en pause puis reprises (si cela est anticipé), sans perte critique de données, ce qui les rend plus tolérantes aux interruptions.
Ces workloads sont souvent flexibles en matière de besoins en ressources et peuvent s'adapter à différents types d'instances ou zones de disponibilité sans compromettre le travail effectué.
Traitement par lots
Les jobs de traitement par lots et d'ETL ne sont généralement pas critiques sur le plan temporel, ce qui leur confère la flexibilité idéale pour les instances Spot.
Ces tâches peuvent aussi être découpées en unités plus petites et indépendantes, distribuables sur plusieurs instances sans impact significatif si l'une d'elles est interrompue.
L'interruption d'une instance n'empêche donc pas l'achèvement du job, le workload pouvant être réparti entre les autres instances disponibles. Et si aucune n'est disponible, les jobs peuvent être structurés pour sauvegarder des états intermédiaires et reprendre au dernier point de contrôle en cas d'interruption.
Calcul haute performance (HPC) et traitement big data
Les tâches de calcul haute performance impliquent de manipuler et d'analyser d'énormes volumes de données. Les instances Spot sont pertinentes pour ce type de workloads, car ces tâches peuvent être distribuées sur de nombreuses instances et permettent une montée et une descente en charge faciles.
Ces traitements sont généralement coûteux puisque l'analyse de grands jeux de données exige des ressources de compute importantes ; mais avec les instances Spot, le coût unitaire chute fortement — et sur des milliers d'instances, cela représente des économies considérables.
Serveurs web
Les serveurs web sont d'excellents candidats aux instances Spot, car ils sont généralement stateless. Ils ne stockent pas de données localement et ne dépendent pas d'informations issues de sessions précédentes ; ils peuvent donc être interrompus sans impact significatif.
Dans la plupart des cas, chaque requête est traitée indépendamment, sans recours à des informations de session stockées.
Workloads conteneurisés / Kubernetes
Les applications conteneurisées sont souvent conçues pour être stateless, ce qui en fait de bonnes candidates aux instances Spot.
Comme les conteneurs ne stockent généralement pas de données propres à une session, on peut en lancer ou en arrêter sans affecter le système global.
De plus, comme les conteneurs découpent les applications en unités plus petites et indépendantes, les workloads conteneurisés s'adaptent facilement à différents types d'instances ou zones de disponibilité. Cette flexibilité s'accorde parfaitement avec la nature variable des instances Spot.
Nous avons fait le tour de l'essentiel à savoir sur les instances Spot — du concept à la façon d'en tirer pleinement parti, en passant par les cas d'usage qui en maximisent les avantages.
Dans la seconde partie de notre série, nous aborderons les Auto Scaling groups (ASGs), qui aident à gérer les interruptions Spot et à en optimiser l'utilisation, ainsi que Spot Scaling, qui simplifie la configuration et la gestion des ASGs pour maximiser vos économies Spot et la disponibilité de vos applications.