Originaire de l'essor des ordinateurs durables des années 2020 et des engagements d'atteindre zéro émission nette des entreprises. Les organisations ont réalisé que les charges de travail cloud pouvaient être temporairement et spatialement déplacées vers des régions ou des moments avec une intensité carbone plus faible. Les planificateurs traditionnels n'optimisaient que pour le coût et la performance, ignorant les sources d'énergie. Cette question teste la compréhension de l'infrastructure hétérogène, de l'autoscaling prédictif et de l'optimisation multi-objectifs dans les systèmes distribués.
Les centres de données consomment 1-2% de l'électricité mondiale. Faire fonctionner des charges de travail sur des réseaux lourds en combustibles fossiles par rapport à des réseaux lourds en énergie renouvelable peut différer par un facteur de 10 en empreinte carbone. Cependant, migrer des charges de travail avec état vers des AWS Spot Instances ou différentes régions risque d'entraîner des interruptions et des pénalités de latence. Le défi consiste à construire un système qui ingère des API d'intensité carbone en temps réel, prédit le turn-over des charges de travail et prend des décisions de migration qui équilibrent la réduction du carbone avec les SLO de disponibilité, sans qu'un planificateur central ne devienne un goulet d'étranglement.
Un maillage de planification décentralisé basé sur des agents utilisant Kubernetes avec des politiques de Descheduler personnalisées et des intégrations de Cluster Autoscaler. Chaque nœud exécute un Agent Conscient du Carbone qui surveille l'intensité locale du réseau via des métriques Prometheus. Les charges de travail sont classées par élasticité (sans état vs avec état) et criticité pour déterminer l'éligibilité à la migration.
Les charges de travail sans état sont planifiées sur des AWS Spot Instances ou des Azure Spot VMs dans des régions à faible intensité carbone via Karpenter ou Cluster API. Les exécuteurs Apache Spark vérifient les progrès vers Amazon S3 pour gérer gracieusement la préemption. Cette approche maximise les économies de carbone pour un calcul tolérant aux pannes.
Les charges de travail avec état nécessitent un traitement différent. Les bases de données critiques utilisent la migration en direct via KubeVirt ou VMware vMotion, tandis que d'autres tirent parti de la réplication asynchrone avec Redis ou le streaming PostgreSQL vers des clusters secondaires. Un plugin de planification basé sur WASM met en œuvre une optimisation multi-objectifs utilisant Reinforcement Learning à la périphérie. Istio gère le déplacement du trafic pendant les migrations, et etcd maintient un état distribué sans verrous globaux.
Une entreprise fintech mondiale traite des calculs de risque par lots nocturnes sur 50 000 cœurs. Son centre de données en Allemagne fonctionne sur des réseaux chargés en charbon le soir, tandis que la région hydroélectrique norvégienne offre de l'énergie plus propre mais à des prix au comptant plus élevés par intermittence. Le pipeline existant basé sur Apache Airflow déclenchait des travaux à minuit CET, créant des pics de carbone.
Le problème est apparu lorsque l'équipe de durabilité a mandaté une réduction de 40% des émissions de carbone sans augmenter les dépenses informatiques. Les modèles de risque sans état prenaient 6 heures à terminer, mais les déplacer vers des instances au comptant risquait une recomputation induite par la préemption qui pourrait enfreindre les délais de reporting réglementaires. De plus, les journaux de transactions PostgreSQL pour les traces d'audit ne pouvaient pas quitter la zone économique de l'UE, compliquant les stratégies de migration.
Solution A : Décalage temporel statique proposait de retarder les débuts de lot jusqu'à ce que l'intensité carbone du réseau diminue en fonction des moyennes historiques. Cette approche reposait sur de simples ajustements de CronJob au sein des clusters Kubernetes existants et ne nécessitait aucune infrastructure supplémentaire. Cependant, elle échouait lors d'événements imprévus de stress sur le réseau tels que des jours d'hiver sans vent, ignorait la volatilité en temps réel des marchés de l'énergie et créait des retards de pipeline affectant les analyses Spark en aval. De plus, elle négligeait complètement les occasions de profiter des réductions d'instances au comptant pour des économies de coûts.
Solution B : Planificateur mondial centralisé proposait le déploiement d'un planificateur monolithique basé sur Go en US-East qui interrogeait les API de carbone chaque minute et commandait à tous les clusters de migrer des charges de travail. Ce design offrait une vue d'optimisation globale et facilitait l'audit, mais introduisait un point de défaillance unique catastrophique. La latence du réseau vers les clusters périphériques dépassait souvent 100 ms, provoquant des décisions obsolètes et des moutons des neiges lorsque le carbone tombait globalement. Plus gravement, il violait les exigences de résidence des données GDPR pour les données financières de l'UE et se dégradait mal au-delà de dix clusters.
Solution C : Planification fédérée hiérarchique a mis en œuvre Karmada pour le contrôle fédéré associé à des extensions Carbon-Aware Kubelet locales à chaque nœud. Chaque cluster régional s'est abonné aux API locales du réseau via MQTT, tandis que les exécuteurs Spark sans état fonctionnaient sur des AWS Spot dans des régions à faible carbone avec pointage vers S3. Les primaires PostgreSQL avec état sont restés en Allemagne mais ont été répliqués vers Norvège en utilisant pglogical, les promouvant via un basculement Patroni uniquement pendant des événements extrêmes de carbone. Cette approche a réduit le carbone de 45% tout en maintenant des SLA de récupération sub-2 heures et en respectant la souveraineté des données.
L'équipe a sélectionné la Solution C après l'avoir testée dans l'environnement non productif. Ils ont déployé Karmada pour les politiques de propagation et des contrôleurs personnalisés analysant les données des Electricity Maps, intégrées avec Spot.io pour la gestion des océans. Cette solution a le mieux équilibré les contraintes concurrentes de réduction du carbone, d'efficacité des coûts et de conformité réglementaire.
Après trois mois, les émissions de carbone ont diminué de 47%, les coûts ont diminué de 12% grâce à une utilisation agressive des spots, et seulement 0,3% des travaux nécessitaient une recomputation due à la préemption, bien en deçà du seuil SLA de 1%. Le système a réussi à naviguer dans une fenêtre de maintenance de centrale à charbon d'une semaine en déplaçant automatiquement 80% du calcul vers des régions hydro sans intervention manuelle. L'architecture s'est révélée résiliente face à la fois à la volatilité du réseau et aux résiliations de droits des fournisseurs de cloud.
Question 1 : Comment maintenez-vous la cohérence des données lors de la migration d'un PostgreSQL primaire d'une région à forte émission de carbone vers une veille à faible émission de carbone pendant une transaction en cours, sans violer les propriétés ACID ?
Utilisez la réplication synchronisée avec engagement de quorum (synchronous_commit = remote_apply) pour garantir que la veille dans la région cible a appliqué la transaction avant d'accuser réception du primaire. Avant la migration, promeut la veille en utilisant pg_ctl promote ou l'API REST de Patroni seulement après avoir défini synchronous_standby_names comme vide pour éviter les scénarios de double prise. Pendant la courte fenêtre de promotion durant quelques secondes, mettez en file les écritures dans un flux Redis ou un cache de terrain côté application pour absorber la latence. Après la promotion, redirigez le trafic applicatif via les mises à jour du service virtuel Istio et vérifiez la cohérence à l'aide de pg_dump checksums ou de comparaisons de slots de décodage logique pg_dumpall. Cela garantit aucune perte de données tout en permettant une relocalisation inspirée du carbone.
Question 2 : Pourquoi une implémentation naïve de la planification consciente du carbone viole souvent le théorème CAP lors de partitions réseau entre l'API carbone et le planificateur de charge de travail ?
Si le planificateur considère les données d'intensité carbone comme une contrainte dure—par exemple, refusant de planifier lorsque l'API est indisponible—il sacrifie Disponibilité pour Tolérance aux partitions et la cohérence des données sur le carbone. L'approche correcte considère le carbone comme une contrainte molle avec des heuristiques de secours, mettant en œuvre un modèle de disjoncteur utilisant Hystrix ou Resilience4j autour des appels d'API carbone. En cas de partitions, le système revient à une planification basée sur le coût ou la performance en utilisant des valeurs d'intensité carbone mises en cache avec des seuils de péremption TTL. Cela maintient la Disponibilité (les charges de travail s'exécutent toujours) tout en acceptant une dégradation temporaire de la Cohérence de l'optimisation du carbone, adhérant au CAP en choisissant AP avec cohérence éventuelle sur les métriques de carbone.
Question 3 : Comment empêchez-vous les problèmes de moutons des neiges lorsque des milliers de clusters détectent simultanément un événement à faible intensité carbone dans la même région et tentent d'y migrer des charges de travail ?
Mettez en œuvre un backoff exponentiel jitteré dans la logique de décision de migration en utilisant des retards randomisés entre 0 et 300 secondes semés par l'ID du cluster pour désynchroniser les actions. Utilisez un sémaphore distribué ou un mécanisme de bail via etcd ou Consul pour limiter les migrations simultanées par région de destination, faisant respecter un quota maximum. De plus, employez un scaling prédictif au lieu d'une migration réactive en prédisant des creux de carbone à l'aide de modèles Prophet ou LSTM formés sur les données historiques du réseau. Cela permet un positionnement échelonné des charges de travail avant l'ouverture de la fenêtre à faible carbone, lissant les pics de demande et empêchant l'épuisement des ressources dans la région verte tout en maintenant la décentralisation du planificateur.