【ITニュース解説】The physics of build systems

ビルドシステムとは、ソースコードをコンパイルし、リンクして、実行可能なソフトウェアやテスト可能な形式に変換する一連の仕組みのことだ。小さなプロジェクトでは、ファイルを変更してビルドコマンドを実行すれば、すぐに結果が得られるため、特にその複雑さを意識することはない。しかし、プロジェクトが大規模になり、多くの開発者が関わるようになると、ビルドの速度や安定性が大きな課題として浮上する。

「あるファイルを少し変更しただけなのに、プロジェクト全体の半分が再ビルドされてしまう」「高性能なCPUを搭載した新しいマシンを導入しても、ビルド速度が思ったほど速くならない」「キャッシュを利用するとビルドが驚くほど速くなることもあれば、全く効果がないこともある」といった状況は、多くの開発者が経験することだ。これらの問題は、単に特定のコンパイラが遅いとか、キャッシュの設定が間違っているといった単純な原因によるものではなく、ビルドシステムが持つ根源的な制約、つまり「ビルドの物理学」とでも呼ぶべきものによって引き起こされている。

ビルドを理解する第一歩は、それを「タスクのグラフ」として捉えることだ。例えば、二つのソースファイルをコンパイルし、その結果をリンクして一つの実行ファイルを作成する場合を考えてみよう。このプロセスは「ファイルAをコンパイルする」「ファイルBをコンパイルする」「コンパイル済みのファイルAとBをリンクする」という三つのタスクとして表現できる。ここで重要なのは、ファイルAとファイルBのコンパイルは互いに独立して行えるが、リンク作業は両方のコンパイルが完了しなければ開始できないという関係性だ。この関係性を図で表したものがタスクグラフであり、これは単にビルドの様子を後から説明するためのものではない。このグラフこそが、どのタスクを同時に実行できるか、どのタスクが他のタスクの完了を待たなければならないかを決定する「設計図」なのだ。

このタスクグラフが機械上で実行されるとき、マシンが持つ処理能力がその制約となる。仮に、各タスクが同じ量の作業で、一つのCPUコアを10秒間占有するとしよう。一つのCPUコアしか持たないマシンでは、ファイルAとBのコンパイルが順番に実行され、その後リンク作業が行われるため、合計30秒かかる。もし二つのCPUコアを持つマシンであれば、ファイルAとBのコンパイルは同時に実行できるため、10秒で両方が完了し、その後リンク作業が10秒で完了するため、全体のビルド時間は20秒に短縮される。これは、より大きなマシンを購入した際に人々が期待する効果であり、もしビルドに十分な独立した作業があれば、実際にこのような効果が得られる。

しかし、もし同じビルドを32個のCPUコアを持つマシンで実行しても、やはり20秒しかかからないだろう。なぜなら、ビルド開始時にはファイルAとBのコンパイルという二つのタスクしか準備ができておらず、それが終わるとリンク作業という一つのタスクしか準備ができていないからだ。残りの30個のCPUコアは、実行すべきタスクがないためアイドル状態となる。どんなに多くのCPUコアがあっても、必要な入力が揃わなければタスクは開始できない。大規模なプロジェクトには数千のタスクがあるが、この基本法則は変わらない。

この限界を理解する上で重要な二つの視点がある。一つは、すべての作業量をCPUコア数で割った値だ。独立したタスクが十分に多ければ、コア数を増やすことでこの値は小さくなる。もう一つは、「最長依存チェーン」と呼ばれる、順番に実行しなければならないタスクの最も長い連続だ。どんなに多くのコアを追加しても、この最長チェーンの時間は短縮できない。ビルドは、この二つの限界のうち、より長い方が示す時間よりも早く完了することはない。したがって、ビルドを高速化するには、単にマシンを増強するだけでなく、タスクグラフがより多くの独立した作業を生み出すように最適化することが重要となる。

開発者は通常、プロジェクト全体をゼロからビルドする「クリーンビルド」ではなく、一部のファイルを変更し、その変更に関連する部分だけを再ビルドする「インクリメンタルビルド」を行う。インクリメンタルビルドは、変更されたファイルと、その変更によって結果が変わる可能性のある下流のタスクだけを特定し、それ以外の部分はそのままにしておく。これにより、ビルドのタスク数を大幅に減らし、結果的にビルド時間を短縮できる。しかし、ここで重要なのは、どのファイルがどれくらいの頻度で変更され、その変更がタスクグラフのどの部分に影響を与えるか、という実際の開発チームの活動パターンを把握することだ。例えば、多くのモジュールに依存されている共通の基盤モジュールがあったとしても、それが頻繁に変更されなければビルド時間の大きなボトルネックにはならない。しかし、それが日常的に変更されるようなら、そのモジュールと依存関係の設計を見直す必要がある。システムのアーキテクチャ設計において、頻繁に変わる部分は独立させ、安定した共通部分は小さく保つことが、ビルドを速くするための鍵となる。

複数の開発者が同時に異なる機能を開発する際、それぞれが異なる「作業ツリー」（例えばGitのブランチ）で作業することがよくある。このような場合、それぞれの作業ツリーでビルドを行うが、多くの場合、同じソースコードをコンパイルしたりリンクしたりする作業が重複して発生してしまう。これは、ビルドシステムが「場所による増分性」に依存しているためだ。つまり、前回のビルド結果が特定のディレクトリ（XcodeのDerivedDataなど）に保存されている場合、同じディレクトリでビルドを再開すれば増分的に進められるが、別の作業ツリーではそのディレクトリが異なるため、新規のビルドとして扱われ、既に行った作業を繰り返してしまうのだ。

これに対し、「同一性による増分性」というアプローチがある。これは、タスクの入力ファイル、ツールチェーン、設定、依存関係など、そのタスクの結果を決定するすべての要素をまとめてハッシュ値として識別し、そのハッシュ値に対応する成果物があれば、それを再利用するという考え方だ。この方式であれば、たとえ異なる作業ツリーや異なるマシン上であっても、同じ入力から生成されるべき成果物は同じハッシュ値を持つため、キャッシュから再利用できる。Xcodeのコンパイルキャッシュや、Bazelといったビルドシステムは、この仕組みを利用して、作業の重複を大幅に削減している。

継続的インテグレーション（CI）環境で、前回のビルドディレクトリを永続的に保持する「スティッキーボリューム」という方法でビルドを速くしようと試みられることがある。これは一時的に効果があるように見えるが、どの履歴を継承させるか、複数のビルドが同時に書き込むのをどう防ぐかといった複雑なスケジューリング問題を引き起こす。また、ビルドディレクトリには、ソースファイル以外の情報（絶対パス、環境変数など）も含まれることがあり、それが原因でビルドの正確性が損なわれたり、特定の環境でしか再現しない問題を引き起こしたりするリスクもある。スティッキーボリュームは、特定のランナー（CIサーバーの実行環境）が以前の作業を「覚えている」ようにするだけで、作業そのものを広く共有可能にするものではない。

同一性による増分性を持つビルドシステムでは、ビルドは前回のディレクトリではなく、キャッシュされた成果物を求める。このとき、リモートキャッシュの利用が不可欠となる。しかし、オブジェクトストレージ（クラウド上のファイル保存サービス）が安価だからといって、そこにキャッシュを置けば全て解決するわけではない。キャッシュからのデータ取得にかかる時間には、「レイテンシ」（データ転送開始までの待ち時間）と「帯域幅」（データ転送速度）の二つの要素が大きく影響する。特に、小さなファイルを大量にキャッシュする場合、それぞれのファイルを取得する際の待ち時間（レイテンシ）が積もり積もって、大きなボトルネックとなることがある。

この問題を解決するには、キャッシュとビルドを実行する計算リソースを、地理的に近く、高速なネットワークで接続する「インフラストラクチャの併置（Collocation）」が非常に重要だ。例えば、CIサーバーとキャッシュを同じデータセンター内のプライベートネットワークで繋ぐことで、レイテンシを低く保ち、帯域幅を高く維持できる。しかし、開発者のPCは世界中に分散しているため、すべての環境を一つの中心的なキャッシュに物理的に近づけるのは難しい。そこで、Tuistチームが開発を進めているKuraのような「分散型キャッシュメッシュ」は、各地域の近くにキャッシュノードを配置し、それらが連携して成果物を共有することで、レイテンシを削減しつつグローバルなキャッシュ共有を実現しようとしている。リモートキャッシュからの取得が、ローカルで再ビルドするよりも速い場合にのみ、リモートキャッシュは真のメリットとなる。

キャッシュがヒットせず、新しい作業や無効化された作業を再実行しなければならない場合、ビルドは再び単一マシンのCPUコア数という物理的な限界に直面する。このとき、次の段階として「リモート実行」が有効な手段となる。これは、ビルドシステムが、実行準備ができたタスクを、ネットワーク上にある複数のワーカーマシンに送り、そこで実行させる仕組みだ。これらのワーカーは、適切なツールチェーンや環境が整っており、すぐにタスクを実行できる状態である必要がある。ワーカーがタスクを実行し、その結果を共有キャッシュに返すことで、単一マシンの処理能力を超えた並列処理が可能になる。しかし、ここでもタスクグラフの最長依存チェーンの制約は変わらないため、リモート実行は、グラフの幅広く独立した部分で特に効果を発揮する。

BazelやBuck2といったビルドシステムは、このリモート実行機能を標準で提供しており、ビルドやテストのアクションを複数のマシンに分散処理するよう設計されている。これらのシステムでは、タスクの入力、出力、ツールチェーン、設定、環境など、アクションに必要な全ての情報が明確に記述されているため、ワーカーマシンが依頼元マシンの状態に依存せずに安全にタスクを実行できる。多くのネイティブな開発ツール（例えばXcode）は、単一マシン上での並列コンパイルはサポートしているものの、このリモート実行機能を一般的なビルドの進め方として提供しているわけではない。リモートキャッシュだけでも作業を大幅に削減できるが、キャッシュミス時の処理は依然として単一マシンの能力に限定されるため、リモート実行は、大規模な組織が生成する膨大なビルド作業を効率的に消化するための「もう一歩進んだ」解決策と言える。

ビルドの最適化において、タスクグラフ自体の改善を怠ることはできない。キャッシュは繰り返し発生する作業を排除し、リモート実行は残った作業を実行するためのキャパシティを増やす。しかし、どちらも深い依存チェーンを並列化したり、小さな変更がプロジェクトの大部分を再ビルドさせるのを止めたりすることはできない。タスクグラフが、あらゆるビルドの根本的な構造を決定し、そして開発チームの実際の変更履歴が、そのビルドコストがどれだけ頻繁に支払われているかを示す。したがって、ビルドの速度を改善するためには、単に高速なハードウェアやインフラを導入する前に、タスクグラフ、ビルドの実行履歴、実際の変更パターンを総合的に分析し、どこを修正すべきかを判断する必要がある。

また、リモートキャッシュやリモート実行が安全に機能するためには、各タスクの「密閉性（Hermeticity）」と「決定論的なハッシュ化（Deterministic hashing）」が不可欠となる。密閉性とは、タスクがその実行に必要なすべての入力を明示的に宣言し、外部の不確実な要素に依存しないことを意味する。決定論的なハッシュ化とは、宣言された入力、ツールチェーン、設定が常に同じキャッシュキーを生成することを保証する。これらの条件が満たされて初めて、分散ビルドは高速かつ正確に機能するようになるのだ。

既存のツールチェーンの中には、Xcodeのコンパイルキャッシュのように、同一性に基づくキャッシュ機能を導入しているものもある。これにより、リモートキャッシュに近い効果が得られるが、現状では分散実行の機能は提供されていない。これは、多くのネイティブツールチェーンが、一人の開発者が一台のマシンでビルドするモデルを中心に設計されているためで、現代の組織が求める並列ビルドワークに対応するにはまだ進化が必要な部分だ。BazelやBuck2のようなシステムは、リモートキャッシュとリモート実行をそのモデルの一部として最初から設計しているため、この点で有利だが、プロジェクトがその独自のビルドルールに従う必要があるという導入障壁がある。Tuistチームが開発するOnceのようなプロトタイプは、既存のプロジェクトやスクリプトを活かしつつ、段階的にキャッシュやリモート実行の恩恵を受けられるようにすることを目指している。ビルドシステムの未来は、これらの技術がどのように進化し、開発チームが直面する課題をいかに解決していくかにかかっている。