【ITニュース解説】I Tried to Build Persistent Compute on an Xbox SSD. The Failed Tests Changed the Architecture.

Xbox Series Xというゲーム機には、通常ゲームを開発するための「Developer Mode」という特別な機能が備わっている。このモードを利用して、XCPというプロジェクトでは、Xboxを単なるゲーム機としてだけでなく、複雑な計算処理を実行できる汎用的なコンピュータとして活用しようと試みた。特に、メモリの制限を乗り越え、処理が途中で中断されてもそこから再開できるような「永続的な計算」の仕組みをXbox上で実現することが大きな目標であった。

Xbox Series Xのアプリケーションは、Developer Modeでも約5ギガバイト（GiB）というメモリの上限が設定されている。しかし、実行したい処理の中には、このメモリ容量よりもはるかに大きなデータを扱う必要がある場合がある。一般的なPCのように、メモリが足りなければストレージ（SSDなど）を仮想メモリとして使うという単純な話ではない。XCPプロジェクトの目的は、SSDを一時的なメモリの代替として利用することではなく、処理中のデータや既に完了した作業をストレージに永続的に保存し、必要に応じてメモリに読み込み、そしてシステムが何らかの理由で中断された後でも、保存された状態から正確に処理を再開できるような実行システムを構築することだった。

この課題に取り組むにあたり、まず検討されたのは、メインの処理を実行するプロセスとは別に、もう一つ別のプロセスを立ち上げて、計算処理を補助させることができないかという点である。Xbox上で動くアプリケーションは、UWP（Universal Windows Platform）パッケージという形式で提供される。Windowsのデスクトップ環境では、複数のプロセスを立ち上げることは比較的容易だが、XboxのDeveloper Modeで同じ挙動が保証されるわけではないため、実際に検証する必要があった。調査の結果、メインプロセスと補助プロセスはそれぞれ独立した活動が可能で、プロセス間通信（IPC）を通じてメッセージを交換できることが分かった。しかし、これは各プロセスがそれぞれ独立した5GiBものメモリ予算を持っていることを意味するわけではなかった。むしろ、メインプロセスとリソースを共有しつつ、限られたリソースで動作する「調整役」としての小さな補助プロセスが実現可能であるという結論に至った。この調整役プロセスは、システムのライフサイクル（起動や停止など）の監視や、心拍（システムが生きていることを示す定期的な信号）の管理、ストレージの予約といった、メインプロセスの実行をサポートする役割を担うことになった。

次に重要となったのは、システムが中断してもデータを安全に保存し、再開時にその信頼性を保証できるストレージの仕組みを構築することである。単にファイルをSSDに書き込むだけでは不十分だ。例えば、数百ページの出力データを生成する処理中に、途中でシステムが停止した場合、どのページが正しく書き込まれ、どの時点から処理を再開すべきかをどう判断すれば良いだろうか。書き込まれたデータのハッシュ値は正しいか、ジャーナル（作業記録）はコミットされているか、といった検証が必要になる。XCPでは、この問題を解決するために、「コンテンツアドレス型データ」と「追記型ジャーナル」という二つの技術を中心にストレージシステムを構築した。コンテンツアドレス型データとは、データの内容そのものから一意な識別子（ID）を生成する方式で、これによりデータが改ざんされていないかを容易に確認できる。追記型ジャーナルは、作業の履歴を過去の記録を上書きせずに新しい記録として次々と追加していく方式で、システムが途中で停止しても、どこまで作業が進んだかを正確に追跡し、最も信頼できる状態から回復できるようにする。

開発の過程では、多くの試行錯誤と失敗があった。例えば、初期のテストでは、ストレージへの書き込み自体は成功しているにもかかわらず、システムの異なる部分で設定されたタイムアウトによって処理全体が失敗するという問題に直面した。また、別のテストでは、補助プロセスが実際に動作しているにもかかわらず、テスト側の期待値が誤っていたために失敗と判断されるケースもあった。メモリの割り当てに失敗した際も、単に「メモリが足りない」というエラーメッセージだけでは、何が原因で、どのコンポーネントが責任を負っているのか判断できず、詳細な情報収集が必要になった。

特に重要な発見は、永続データ（SSDに保存されたデータ）の寿命と、実行中のプロセスの寿命が異なるという点である。処理が中断された後、システムを再開した際に、以前のプロセスが持っていたストレージの「予約（リース）」をそのまま使い続けようとすると失敗することが判明した。永続データは中断後も残るが、実行中のプロセスの予約は、そのプロセスの以前の活動に紐付いているため、再開時には新しい世代の予約を改めて取得し、保存された作業の正当性を再検証してから処理を続行する必要があった。この発見は、システムの設計に大きな変更をもたらし、永続データとライブプロセスの予約管理を明確に分離することになった。

さらに、ストレージ容量の検証では、8GiBのデータをSSDに書き込むテストが成功した。これは、4MiBのページを2,048枚書き込み、その内容を検証し、最終的に削除する一連の処理がXbox上で完全に機能することを意味する。しかし、さらに大きな64GiBへの拡張を試みたところ、Xboxが報告する利用可能なファイルシステム容量が不足しており、要求が拒否された。これは、設定上で割り当て可能な最大容量と、実際に利用可能な物理容量やプラットフォームが提供する容量が異なることを明確に示しており、無理に大きな容量を要求するのではなく、実際に検証できた8GiBという数字を目標とすることが適切であると判断された。

これらの多くの失敗と、それらから得られた知見が、最終的にXCPの能力を向上させた。Xboxの持つ制約を無視しようとするのではなく、その制約の中で何が可能かを探求し、信頼性のある能力を組み合わせることでシステムは進化していったのだ。最終的に確立されたのは、8GiBの容量を持つ、内容が検証済みで回復可能な永続ストレージであり、これを利用して、計算が中断されても以前の作業を検証し、未完了の部分から正確に再開できる永続計算ワークフローである。これはSSDをRAMのように扱う魔法のような方法ではないが、計算の履歴を、それを実行するプロセスの寿命とは独立して永続化させるための、堅牢なストレージと回復アーキテクチャを実現した。

このプロジェクトで開発されたコード、例えばコンテンツアドレス型ストレージや永続タイル計算ランタイムなどは現在オープンソースとして公開されており、他の開発者もその設計を検証し、利用することが可能になっている。Xboxという特定の環境で得られたこの成果は、計算のライフサイクルがそれを実行するプロセスのライフサイクルと必ずしも同一である必要はないという重要な概念を実証したものであり、今後のより複雑なワークロードへの適用に向けた第一歩となる。