Guide d’optimisation des instances Spot

Les Spot Instances (AWS), Spot VMs (Azure) et Spot/Preemptible VMs (GCP) sont une capacité cloud de réserve offerte à 70 à 90 pour cent de remise sur le prix à la demande. La condition est que le fournisseur cloud peut reprendre l’instance avec un préavis aussi court que 30 secondes quand la demande pour le matériel sous-jacent augmente. Pour les charges qui tolèrent l’interruption — et seulement celles-là — spot est le compute le moins cher du cloud public par une large marge.

Quelles charges vont sur Spot

Spot convient aux charges stateless, fault-tolerant et interruptibles :

• Jobs batch et HPC — rendu d’images, transcodage vidéo, simulations Monte Carlo. Checkpoint le progrès et reprendre sur une instance de remplacement.
• Runners CI/CD — les files de jobs peuvent attendre une instance de remplacement sans manquer les deadlines de release.
• Tiers web stateless — derrière un load balancer avec autoscaling, une instance expulsée est remplacée en secondes.
• Traitement Big Data — clusters Spark, Hadoop et data warehouse conçus pour gérer la perte de nœuds.
• Environnements dev et test — charges non-production où une interruption de 2 minutes est acceptable.

Spot n’est pas approprié pour les bases de données stateful, les applications mono-instance sans réplica, les sessions interactives avec utilisateurs, ou les jobs batch qui ne peuvent pas être checkpointés.

Comparaison des fournisseurs

Les GCP Spot VMs offrent la remise la plus profonde, et GCP envoie un script d’arrêt 30 secondes avant l’expulsion. AWS Spot offre la notification la plus douce (2 minutes), donnant aux jobs batch le temps de checkpoint.

Concevoir pour l’interruption

Les quatre patterns qui rendent spot fiable :

1. Checkpoint et reprise — écrire le progrès vers un stockage durable (S3, Cloud Storage) toutes les quelques minutes, et redémarrer depuis le dernier checkpoint sur une instance de remplacement.
2. File de travail distribuée — utiliser une file (SQS, Pub/Sub, Service Bus) pour distribuer les unités de travail. Si une instance est expulsée, l’unité de travail retourne à la file pour qu’une autre instance la prenne.
3. Multi-instance + autoscaler — faire tourner au moins 2 instances spot derrière un load balancer et configurer un autoscaler pour lancer un remplacement quand une est expulsée.
4. Mix spot + à la demande — faire tourner 70 à 90 pour cent de la capacité sur spot et le reste sur à la demande ou réservé, pour que la charge dégrade gracieusement plutôt que de s’arrêter totalement quand spot n’est pas disponible.

Spot Fleet et Capacity Rebalancing

AWS Spot Fleet et Azure Spot VM Scale Sets permettent de demander une capacité cible à travers plusieurs types d’instances et zones de disponibilité, ce qui réduit dramatiquement la probabilité que toute votre capacité spot soit reprise d’un coup. Configurez la flotte pour couvrir 3 à 5 types d’instances sur 2 à 3 zones, et la probabilité de perte totale tombe sous 1 pour cent par mois.

GCP n’a pas d’équivalent direct à Spot Fleet, mais MIG (Managed Instance Group) avec plusieurs templates d’instances et le paramètre proactiveRefresh atteint un effet similaire.

Suivi des coûts

Les prix spot fluctuent avec la demande, donc une charge qui coûte $0.029/heure aujourd’hui pourrait coûter $0.058/heure la semaine prochaine. Définissez des alertes de facturation à 110 pour cent de la moyenne mobile 30 jours, et configurez votre flotte pour retomber sur à la demande automatiquement quand le prix spot dépasse le prix à la demande — à ce point spot n’offre plus d’économie et n’ajoute que du risque d’interruption.

Voir la comparaison AWS vs Azure Compute pour la remise spot par instance, et le guide des instances réservées pour la stratégie d’engagement à appliquer à la portion à la demande de votre flotte mixte.