2020年代の持続可能なコンピューティングや企業のネットゼロ目標への取り組みから生まれた。組織は、クラウドワークロードを炭素強度の低い地域や時間に時系列で、空間的に移動できることを認識した。従来のスケジューラはコストとパフォーマンスの最適化のみを行い、エネルギー源を無視していた。この質問は、異種インフラ、予測自動スケーリング、および分散システムにおける多目的最適化の理解を試すものだ。
データセンターは世界の電力の1～2％を消費している。化石燃料が多いグリッドでのワークロード実行と再生可能エネルギーが多いグリッドでのワークロード実行では炭素排出量が10倍異なることがある。しかし、ステートフルなワークロードをAWSスポットインスタンスや異なる地域に移動することは、中断やレイテンシーのペナルティのリスクがある。この課題は、リアルタイムの炭素強度APIを取り込み、ワークロードの変動を予測し、可用性のSLOと炭素削減をバランスさせる移行判断を行うシステムを構築することだ。中央のスケジューラがボトルネックとならないようにする。
カスタムDeschedulerポリシーおよびCluster Autoscalerの統合を使用した、Kubernetesを基にした分散型エージェントベースのスケジューリングメッシュ。各ノードはPrometheusメトリックを通じてローカルグリッドの炭素強度を監視する炭素意識エージェントを実行する。ワークロードは弾力性（ステートレス対ステートフル）および重要度によって移行の適格性を決定するために分類される。
ステートレスバーストワークロードは、KarpenterまたはCluster APIを介して低炭素の地域にAWSスポットインスタンスやAzureスポットVMにスケジュールされる。Apache Sparkのエグゼキュータは、事前の再計算が優雅に処理できるようにAmazon S3に進捗をチェックポイントする。このアプローチは、フォールトトレラントなコンピュートのための炭素削減を最大化する。
ステートフルなワークロードは異なる取り扱いが必要だ。重要なデータベースは、KubeVirtまたはVMware vMotionを介してライブ移行を使用し、他のものはRedisまたはPostgreSQLストリーミングを使用して二次クラスターへの非同期レプリケーションを活用する。WASMベースのスケジューリングプラグインは、エッジでの強化学習を使用して多目的最適化を実装する。Istioは移行中のトラフィックシフトを管理し、etcdはグローバルロックなしで分散状態を保持する。
あるグローバルなフィンテック企業は、50,000コアでの夜間バッチリスク計算を処理している。彼らのドイツのデータセンターは石炭が多い夜間グリッドで稼働し、ノルウェーの水力発電地域はよりクリーンなエネルギーを提供しているが、スポット価格が時折高くなる。既存のApache Airflowベースのパイプラインは、中央ヨーロッパ時間で真夜中にジョブをトリガーし、炭素スパイクを生み出していた。
持続可能性チームは、コンピューティング支出を増やすことなく40％の炭素削減を義務付けたため、問題が発生した。ステートレスなリスクモデルは完了に6時間かかるが、スポットインスタンスに移動すると、規制報告の締切を破る可能性のある再計算による中断のリスクがあった。加えて、監査証跡のためのPostgreSQLトランザクションログはEU経済圏を離れることができず、移行戦略が複雑になった。
解決策A: 静的時間シフトは、グリッドの炭素強度が過去の平均に基づいて低下するまでバッチ開始を遅延させることを提案した。このアプローチは、既存のKubernetesクラスター内での単純なCronJobの調整に依存しており、追加のインフラは必要なかった。しかし、風がない冬の日など、予期しないグリッドストレスイベントの際に失敗し、エネルギー市場のリアルタイムの変動を無視し、下流のSpark分析に影響を与えるパイプラインのバックログを招いた。さらに、コスト削減のためのスポットインスタンスの割引利用の機会を完全に逃してしまった。
解決策B: 中央集権的グローバルスケジューラは、US-EastにモノリシックなGo基盤のスケジューラを展開し、一分ごとに炭素APIをポーリングし、すべてのクラスターにワークロードを移行するよう命令することを提案した。この設計は、グローバルな最適化ビューを提供し、監査を簡単にするが、壊滅的な単一障害点を導入した。エッジクラスターへのネットワーク遅延はしばしば100msを超え、古い判断や炭素が世界的に低下したときの雷鳴のような群衆を引き起こした。最も重要なのは、EUの金融データに対するGDPRデータ居住要件に違反し、10クラスターを超えるとスケールしにくくなったことだ。
解決策C: 階層的フェデレーテッドスケジューリングは、フェデレーテッド制御のためにKarmadaを実装し、ノードローカルな炭素意識Kubelet拡張と組み合わせた。各地域クラスターはMQTTを介してローカルグリッドAPIにサブスクライブし、ステートレスなSparkエグゼキュータは低炭素地域のAWSスポットで実行され、S3へのチェックポイントが行われる。重要なステートフルPostgreSQLプライマリはドイツに留まるが、極端な炭素イベントの際にpglogicalを使用してノルウェーにレプリケーションされ、Patroniのフェイルオーバーで昇格される。このアプローチは炭素を45％削減し、2時間未満のリカバリーSLAを維持し、データ主権を尊重した。
チームは非生産環境でのパイロットを経て解決策Cを選定した。彼らはKarmadaを展開し、Electricity Mapsデータを解析するカスタムコントローラーを導入し、海洋管理のためのSpot.ioとの統合を行った。このソリューションは、炭素削減、コスト効率、規制コンプライアンスの競合する制約のバランスを最もよくとった。
3か月後、炭素排出量は47％減少し、コストはスポット利用の積極的な活用により12％減少し、中断による再計算を必要とするジョブはわずか0.3％にとどまり、1％のSLA閾値内に収まった。このシステムは、手動介入なしに80％のコンピューティングを水力地域に自動的にシフトさせ、1週間にわたる石炭プラントのメンテナンスウィンドウをうまくナビゲートした。このアーキテクチャは、グリッドの変動性やクラウドプロバイダーのスポット終了に対しても回復力があることが証明された。
質問1: 高炭素地域から低炭素待機チューブにPostgreSQLプライマリを移行する際、進行中のトランザクション中にデータの一貫性をどのように維持し、ACIDの特性に違反しないようにしますか？
synchronous replicationを用いて、応答を確認する前にターゲット地域のスタンバイがトランザクションを適用したことを確認します。移行前に、pg_ctl promoteまたはPatroniのREST APIを使用してスタンバイを昇格させますが、分割脳シナリオを防ぐためにsynchronous_standby_namesを空にします。昇格ウィンドウの間、Redisストリームまたはアプリケーション側のライトビハインドキャッシュに対して書き込みをキューします。昇格が完了したら、Istioの仮想サービス更新を介してアプリケーショントラフィックをリダイレクトし、pg_dumpチェックサムまたはpg_dumpall論理デコーディングスロット比較を使用して一貫性を確認します。これにより、炭素駆動の移動を許可しながら、データの損失をゼロにすることができます。
質問2: 炭素意識型スケジューリングの単純な実装が、炭素APIとワークロードスケジューラの間のネットワーク分離中にしばしばCAP定理に違反するのはなぜですか？
スケジューラが炭素強度データをハード制約として扱う場合、例えばAPIが利用できないときにスケジューリングを拒否すると、可用性を分割耐性と炭素データの一貫性のために犠牲にします。正しいアプローチは、炭素をソフト制約として扱い、フォールバックヒューリスティックを実装し、HystrixやResilience4jを使用して炭素API呼び出しの周囲にサーキットブレーカーパターンを実装することです。ネットワーク分断の際、システムはキャッシュされた炭素強度値を使用してコストベースまたはパフォーマンスベースのスケジューリングにデフォルトし、TTLの古さのしきい値を設けます。これにより、可用性が維持され（ワークロードは引き続き実行される）、一時的な整合性の劣化を受け入れつつ、炭素の最適化を実施し、CAPに従ってAPでの最終一致を選択します。
質問3: 数千のクラスターが同時に同じ地域で低炭素強度イベントを検出し、ワークロードをそこに移動しようとする際に、どのように雷鳴の群れの問題を防ぎますか？
移行決定ロジックにジッター式指数バックオフを実装し、クラスターIDによってシードされた0～300秒の間にランダム化された遅延を取り入れてアクションを非同期にします。etcdまたはConsulを介して分散セマフォまたはリースメカニズムを使用し、宛先地域ごとの同時移行を制限し、最大の割当を強制します。さらに、Prophetや歴史的なグリッドデータに基づいて訓練されたLSTMモデルを使用して、炭素の谷を予測することで反応的な移行の代わりに予測スケーリングを採用します。これにより、低炭素ウィンドウが開く前にワークロードの事前配置を段階的に行い、需要のスパイクを緩和し、グリーン地域のリソースの枯渇を防ぎつつ、スケジューラの分散化を維持します。