Concevoir un tissu informatique auto-réparateur qui évacue de manière autonome les charges de travail critiques des instances cloud préemptibles vers des zones de disponibilité alternatives et des fournisseurs cloud secondaires dès la réception de signaux de terminaison, tout en garantissant une continuité de service sans temps d'arrêt et une stricte conformité aux SLO de latence en dessous de 100 ms.

Réponse à la question.

L'architecture repose sur un Plan de Contrôle qui intercepte les signaux de métadonnées du fournisseur cloud (par exemple, les avis d'interruption des instances Spot AWS, les avertissements de préemption GCP) et orchestre la migration en direct des charges de travail. Un Planificateur maintient une carte thermique en temps réel de la santé des instances Spot ainsi que des pools de capacité de réserve pré-chauffés dans les régions cloud On-Demand et secondaires. Lors d'un avertissement de terminaison, le système initie un point de contrôle cohérent au niveau de l'application vers un stockage distribué (par exemple, Ceph ou S3), tout en lançant simultanément des pods de remplacement sur la capacité réservée. Les sidecars de Service Mesh (par exemple, Istio) gèrent le transfert de trafic en douceur en utilisant l'évacuation des connexions et les signaux HTTP/2 GOAWAY pour éviter les demandes refusées. Enfin, un Équilibreur de Charge Global met à jour les vérifications de santé pour rediriger le trafic uniquement après vérification réussie de la santé, garantissant que la latence reste en dessous du seuil de 100 ms en choisissant de préférence les zones de réserve géographiquement proches.

Situation concrète.

Une société de trading à haute fréquence utilisait des instances Spot EC2 de AWS pour leur moteur de calcul des risques basé sur Kubernetes afin de réduire les coûts de calcul de 60%. Lors d'une flambée de volatilité du marché, AWS a émis des avis de terminaison en masse sur leur zone de disponibilité principale us-east-1. Cela menaçait de tuer 500 pods en moins de deux minutes tout en traitant des transactions en direct avec des exigences strictes de latence de 50 ms, risquant des millions de pertes de transactions.

Solution A : Budgets de Perturbation des Pods Kubernetes.

L’équipe a envisagé de s’appuyer sur des Budgets de Perturbation des Pods (PDBs) standard associés à l’Autoscaler de Cluster pour évincer les pods de manière fluide vers des nœuds à la demande. Cette approche offrait simplicité et ne nécessitait aucun code personnalisé. Cependant, la fenêtre de terminaison de 120 secondes s'est révélée insuffisante pour que les moteurs de risque basés sur l'état sérialisent leurs modèles dérivés complexes en mémoire vers le stockage persistant, entraînant une perte de données et des lacunes de calcul inacceptables.

Solution B : Contrôleur de Nœud Préemptible Personnalisé avec Velero.

Une autre option consistait à déployer un contrôleur personnalisé utilisant Velero pour les snapshots de volumes persistants et Karpenter pour la rapidité de configuration des nœuds. Bien que Karpenter se soit avéré excellent pour un démarrage rapide des nœuds (moins de 30 secondes), le cycle de snapshot et de restauration de Velero pour des états de 50 Go de mémoire a en moyenne pris trois minutes. Ce retard a violé l'exigence de zéro temps d'arrêt et a risqué des pannes en cascade alors que les transactions en attente s'accumulaient au-delà de la capacité de tampon du système.

Solution C : Point de Contrôle au Niveau de l'Application avec Standby Multi-Cloud.

La solution choisie a mis en œuvre un point de contrôle conscient de l'application utilisant CRIU (Checkpoint/Restore in Userspace) pour geler et sérialiser les états des processus vers des clusters Redis Persistent toutes les 30 secondes. L'architecture maintenait un pool de réserve préchauffé dans GCP Compute Engine en utilisant Anthos pour la fédération de maillage de services entre clusters. À la réception du signal de terminaison AWS, le contrôleur a immédiatement déclenché une synchronisation finale de delta vers Redis, créé des pods de remplacement dans GCP en utilisant des images de conteneur pré-récupérées, et utilisé Istio pour le basculement de proximité afin de déplacer le trafic. Cette approche a sacrifié une certaine complexité d'application mais a garanti un basculement sous 60 secondes sans perte de données.

Résultat.

L'entreprise a réussi à évacuer 98% des charges de travail en 90 secondes durant l'événement de terminaison massive. La latence de basculement moyenne mesurée était de 45 ms, largement dans les limites du SLO, et le système a maintenu une disponibilité de 99,99% tout au long de l'incident. L'analyse post-implémentation a révélé une réduction de 55% des coûts par rapport à l'utilisation pure à la demande, validant la résilience de la stratégie d'instance Spot multi-cloud.

Ce que les candidats oublient souvent.

Comment empêche-t-on les scénarios de double cerveau lorsque le réseau d'instance Spot partitionne mais que le signal de terminaison est retardé ou perdu ?

Les candidats supposent souvent que l'avertissement de 2 minutes est garanti. En réalité, les partitions réseau peuvent retarder la livraison des signaux. La solution met en œuvre un mécanisme de Bail utilisant etcd ou Consul où les charges de travail détiennent des verrous avec limite de temps. Si le plan de contrôle ne peut pas renouveler le bail en raison de la partition, il marque le nœud comme suspect et arrête le routage de nouveau trafic. Simultanément, un enregistrement de Tombstone dans un journal distribué (par exemple, Apache Kafka) garantit que même si l'instance isolée continue à traiter, ses résultats sont rejetés comme obsolètes lors de la reconnexion, empêchant les mises à jour conflictuelles de l'état.

Quelle stratégie assure la cohérence des données lors de la synchronisation finale lorsque l'instance peut être forcée de se terminer en plein point de contrôle ?

Beaucoup proposent un simple point de contrôle mais ignorent le problème de cohérence du "dernier km". L'approche correcte utilise la sémantique Copy-on-Write (COW) et les protocoles d'engagement atomiques. Avant la synchronisation finale, l'application suspend les allocations (via des pauses de GC ou des hooks d'application), crée un instantané en mémoire à l'aide de CRIU, et écrit dans S3 avec la Cohérence Forte S3 ou dans Ceph en utilisant des transactions RADOS atomiques. Le système emploie un modèle de Commit en Deux Phases (2PC) : préparer le point de contrôle, accuser réception au plan de contrôle, et seulement alors évacuer les connexions. Si la terminaison survient pendant la phase d'engagement, l'instance de réserve revient au point de contrôle cohérent précédent et rejoue les événements du journal de décalage Kafka.

Comment atténuer les problèmes de troupeau tonnerre lorsque des milliers d'instances Spot reçoivent simultanément des avis de terminaison et se disputent une capacité de réserve limitée ?

Les candidats négligent fréquemment la contention des ressources lors des évictions massives. La solution met en œuvre un algorithme de Seau de Jetons au niveau du plan de contrôle, régulant les migrations pour correspondre au taux d'absorption du pool de réserve. De plus, elle utilise des Classes de Priorité (PriorityClass dans Kubernetes) pour garantir que les charges de travail financières critiques préemptent les travaux par lot moins critiques sur la capacité de réserve. Un mécanisme de Contre-pression signale à la Passerelle API de mettre temporairement en file d'attente les demandes entrantes, empêchant les nouvelles instances d'être submergées par des pics de trafic immédiatement après la migration. Enfin, des modèles de machine learning prédictifs analysent les historiques de prix spot AWS pour pré-scaler la capacité de réserve 15 minutes avant les vagues de terminaison anticipées, lissant la courbe de transition.