質問への回答。

アーキテクチャは、制御平面を中心に構成され、クラウドプロバイダーのメタデータ信号（例：AWSスポットインスタンスの中断通知、GCPのプレエンプション警告）を傍受し、ライブワークロードの移行をオーケストレーションします。スケジューラは、スポットインスタンスの健康状態とオンデマンドおよび第二クラウド領域の事前暖機スタンバイ容量プールのリアルタイムヒートマップを維持します。終了警告を受けると、システムはアプリケーション一貫性のあるチェックポイント作成を分散ストレージ（例：CephまたはS3）に開始し、同時に予約された容量で置き換えポッドを起動します。サービスメッシュサイドカー（例：Istio）は、接続の排出とHTTP/2 GOAWAY信号を使用して、リクエストのドロップを防ぐためにトラフィックの移行を優雅に処理します。最後に、グローバルロードバランサーは、健康確認が成功した後にトラフィックをリダイレクトするように健康チェックを更新します。これにより、地理的に近いスタンバイゾーンを優先的に選択することにより、レイテンシが100msの閾値を下回るようにします。

実生活の状況。

高頻度取引会社は、計算コストを60％削減するために、AWS EC2スポットインスタンスをKubernetesベースのリスク計算エンジンに利用しました。市場のボラティリティのスパイク中に、AWSは主要なus-east-1可用性ゾーン全体に大量のスポット終了通知を発しました。これは、厳格な50msのレイテンシ要件でライブ取引を処理しながら、500ポッドを2分以内に終了させる危機をもたらしました。

ソリューションA: ネイティブKubernetesポッド中断予算。

チームは、標準のポッド中断予算（PDB）をクラスターオートスケーラーと組み合わせて、ポッドをオンデマンドノードに優雅に追い出すことに依存することを検討しました。このアプローチはシンプルで、カスタムコードを必要としませんでした。しかし、120秒の終了ウィンドウは、ステートフルなリスクエンジンがその複雑なメモリ内デリバティブモデルを永続的ストレージにシリアル化するには不十分であり、不acceptableなデータ損失と計算のギャップをもたらしました。

ソリューションB: Veleroを使用したカスタムプレエンプティブルノードコントローラー。

別の選択肢は、持続的ボリュームスナップショットにVeleroを使用し、迅速なノードプロビジョニングにKarpenterを利用するカスタムコントローラーを展開することを含みました。Karpenterは迅速なノード起動（30秒未満）で優れていましたが、50GBのメモリ状態のVeleroによるスナップショットおよびリストアサイクルは平均で3分かかりました。この遅延はゼロダウンタイム要件に違反し、キューに入っている取引がシステムのバッファ容量を超えて蓄積されるリスクをもたらしました。

ソリューションC: アプリケーションレベルのチェックポイント化とマルチクラウドスタンバイ。

選択されたソリューションは、CRIU（ユーザー空間でのチェックポイント/リストア）を使用してアプリケーション認識のチェックポイントを実装し、30秒ごとにプロセス状態をRedis Persistentクラスターにフリーズし、シリアル化しました。アーキテクチャは、Anthosを利用してクロスクラスターサービスメッシュの連携を行うGCP Compute Engineに暖かいスタンバイプールを維持しました。AWSの終了信号を受け取ると、コントローラーは即座にRedisへの最終デルト同期をトリガーし、事前にプルされたコンテナイメージを使用してGCPに置き換えポッドを生成し、Istioのローカリティフェイルオーバーを利用してトラフィックを移行しました。このアプローチは、一部のアプリケーションの複雑さを犠牲にしましたが、ゼロデータ損失で60秒未満のフェイルオーバーを保証しました。

結果。

この会社は、大量終了イベント中に90秒以内に98％のワークロードを避難させることに成功しました。平均フェイルオーバーレイテンシは45msで、SLOの範囲内であり、システムは事件全体で99.99％の可用性を維持しました。実装後の分析では、純粋なオンデマンド利用と比較して55％のコスト削減が確認され、マルチクラウドスポットインスタンス戦略の弾力性が検証されました。

候補者が見落とすことが多いこと。

スポットインスタンスのネットワークが分割されているが、終了信号が遅延または失われた場合、スプリットブレインシナリオをどのように防ぎますか？

候補者はしばしば2分の警告が保証されていると仮定します。実際には、ネットワークの分割が信号の配信を遅延させる可能性があります。この解決策では、etcdやConsulを使用してワークロードが時間制限付きロックを保持するリースメカニズムを実装します。制御平面が分割のためにリースを更新できない場合、それはノードを疑わしいとマークし、新しいトラフィックのルーティングを停止します。同時に、分散ログ（例：Apache Kafka）にトムストーンレコードが存在し、隔離されたインスタンスが処理を続けた場合でも、その結果は再接続時に古くなったものとして拒否され、競合状態の更新を防ぎます。

インスタンスがチェックポイントの途中で強制的に終了される可能性がある最終同期中にデータの整合性をどのように確保しますか？

多くの人が単純なチェックポイント化を提案しますが、「ラストマイル」の整合性問題を無視しています。正しいアプローチは、Copy-on-Write（COW）セマンティクスと原子コミットプロトコルを使用します。最終同期の前にアプリケーションは割り当てを一時停止（GCの一時停止またはアプリケーションのフックを介して）し、CRIUを使用してメモリのスナップショットを作成し、S3のS3 Strong Consistencyまたは原子RADOSトランザクションを使用してCephに書き込みます。システムは2フェーズコミット（2PC）パターンを採用します：チェックポイントを準備し、制御平面に確認し、その後接続を排出します。コミットフェーズの間に終了が発生した場合、スタンバイインスタンスは前の整合性のあるチェックポイントにロールバックし、Kafkaオフセットログからイベントを再生します。

数千のスポットインスタンスが同時に終了通知を受け取り、限られたスタンバイ容量を競うとき、サンダリングハード問題をどのように軽減しますか？

候補者は、大量排出中のリソース競合を見落とすことがよくあります。この解決策では、制御平面層でトークンバケットアルゴリズムを実装し、スタンバイプールの吸収率に合わせて移行をスロットルします。さらに、優先クラス（KubernetesのPriorityClass）を利用して、重要な金融ワークロードがスタンバイ容量の重要度が低いバッチジョブをプレエンプトします。バックプレッシャーメカニズムがAPIゲートウェイに受信リクエストを一時的にキューに入れるように信号を送り、新しいインスタンスが移行後にトラフィックスパイクに圧倒されるのを防ぎます。最後に、予測機械学習モデルがAWSスポット価格の履歴を分析し、予想される終了波の15分前にスタンバイ容量を事前にスケールアップし、遷移曲線をスムーズにします。