【ITニュース解説】No daemon, on purpose

システム開発において、プログラムのソースコードをコンピューターが実行できる形に変換する「ビルド」という作業は非常に重要だ。特に、複数のプロジェクトを一つのリポジトリで管理する「モノレポ」と呼ばれる開発手法では、多くのプログラムが複雑に連携し合うため、ビルドの効率がプロジェクト全体の生産性を大きく左右する。ビルドを高速化するためには、前回ビルドしてから何が変わったのかを素早く検出し、変更があった部分だけを再ビルドしたり、過去のビルド結果を再利用する「ビルドキャッシュ」の仕組みが広く使われている。

NxやTurborepoといった主要なビルドツールは、この「何が変わったか」を効率的に知るために、「デーモン」という特別なプログラムを利用してきた。デーモンとは、コンピューターのバックグラウンドで常に動き続けるプログラムのことで、ファイルシステムの変更を監視し、ビルドに必要な情報（どのファイルがいつ変更されたかなど）を常に最新の状態に保つ役割を担う。これにより、毎回ファイルシステム全体を調べて変更を探すという時間のかかる作業を省き、ビルドを高速化するのが狙いだった。

しかし、デーモンにはいくつかの問題が指摘されている。デーモンは、ファイルシステムの状態を自分自身の内部に「モデル」として保持する。これは、実際のファイルシステムの状態とは別に、もう一つ「真実のコピー」を持つようなものだ。この二つの情報源が同期を失ってしまうことがある。例えば、デーモンがクラッシュしてしまい、途中で処理が止まってしまったり、開発者がGitのブランチを切り替えたときに、デーモンが持つ情報が古いままになってしまったり、コンピューターが非常に忙しい時にファイル変更のイベントを見落としてしまったり、デーモンが起動する前にファイルが変更されてしまったり、といったケースが考えられる。

このようなズレが発生すると、デーモンは「何が変更されたか」という問いに対して間違った情報を返してしまう可能性がある。ビルドキャッシュにとっては、実際にはファイルが変更されているにもかかわらず、「変更がない」と誤判断して古いビルド結果を再利用してしまうことにつながる。開発者から見れば、ビルドが成功したかのように表示されても（「グリーンチェック」）、実際には古い、間違った成果物が使われているという困った状況が発生してしまうのだ。

さらに、デーモン自体にも運用上のコストがかかる。デーモンは起動に時間がかかり、初期設定（ウォームアップ）も必要となる。ビルドツールのバージョンアップがあった場合には、デーモンも再起動が必要になるし、コンピューターのメモリも常に消費し続ける。結局、その日の最初のビルドなど、状況によってはデーモンがあってもなくても、最初からの起動（コールドスタート）にかかる時間を支払うことになる場合が多い。

こうしたデーモンの課題に対し、vxという新しいビルドツールは、デーモンを使わないという全く異なるアプローチを取っている。vxは、デーモンが答えていた「どのファイルのハッシュを再計算する必要があるか」という問いそのものの重要性を低くすることを目指した。つまり、再計算にかかるコストを十分に低くしたのだ。

その核となるのが、Gitの仕組みを最大限に活用することだ。vxはファイルシステムの変更を監視するデーモンに頼るのではなく、Gitが持つ情報を直接参照する。具体的には、git ls-files -sというコマンドを使って、リポジトリ内のすべてのファイルリストと、クリーンな（変更されていない）ファイルのコンテンツを一意に識別する「ブロブID」という情報を非常に高速に取得する。また、git statusコマンドを同時に使うことで、現在変更されているファイル（ダーティなファイル）の名前も素早く特定できる。これにより、何千ものファイルがある大規模なプロジェクトであっても、実際にソースファイルの内容をすべて読み込むことなく、必要なファイル情報（ハッシュなど）を瞬時に、かつ正確に把握することが可能になる。

さらに、vxは設定ファイルの評価方法にも工夫を凝らしている。GitのブロブIDをキーとして、安全にキャッシュできる設定情報はキャッシュし、そうでないものはリアルタイムで評価する。これにより、設定の変更にも素早く対応しつつ、無駄な再評価を避けることができる。タスクの依存関係を解決する「グラフアルゴリズム」も最適化されており、ビットセットという効率的なデータ構造を使うことで、数千ものタスクの優先順位付けをミリ秒単位で完了させる。これは従来のビルドツールが秒単位で処理していた部分と比べると大幅な高速化だ。

変更がない場合の「ウォームヒット」（キャッシュの再利用）も非常に効率的だ。vxは、どのファイルがどのタスクによって生成されたかを厳密に把握しているため、わずかなファイルの状態チェック（N回のstatsコール）と、ファイルへの書き込みなしで、正しいキャッシュを再利用できる。

これらの工夫の結果、vxはデーモンを使わないにもかかわらず、驚くべき性能を発揮する。例えば、1,090個のパッケージと3,270個のタスクからなる大規模な合成モノレポのベンチマークでは、vxはすべてのタスクをわずか393ミリ秒で実行し、しかも実行後にプロセスを一切残さない。これはTurborepoの463ミリ秒（vxが約18%高速）や、Nxの6.45秒（vxが約16倍高速）と比較しても、圧倒的な速さを示している。

デーモンがないことの最大の利点は、「真実の第二のコピー」による情報のズレや陳腐化のリスクが完全に排除されることだ。タスクの依存関係やビルドに必要な情報源は、常にGitが認識するワーキングツリーのみであり、これは実行のたびに新鮮に読み込まれる。そのため、情報が古くなる「陳腐化の窓」というものが存在しない。開発環境のターミナルで実行しようと、継続的インテグレーション（CI）環境のサーバーで実行しようと、コンテナ内で実行しようと、あるいはファイル監視のリソースが枯渇した環境であっても、vxは常に同じパスを辿り、同じ正確な結果を返すことができる。

vxは、デーモンが最も良いパフォーマンスを発揮する「最良のケース」よりも価値があり、デーモンの「平均的なケース」にかかるコストよりもはるかに安価であると主張している。デーモンによる複雑さや不確実性を排除し、Gitという開発者にとって最も信頼性の高いシステムを最大限に活用することで、vxは高速かつ堅牢なビルドキャッシュを実現している。システムエンジニアを目指す上で、このような設計思想の違いが、ツールの性能や信頼性にいかに大きく影響するかを理解することは非常に重要だ。