GitHubがGitの基盤を再構築：5000のAIが並行して作業し、単一リポジトリで毎秒7200回のコードプッシュを処理

動察 Beating AI速報、GitHubはコードネーム「Rubicon」と呼ばれる次世代Gitストレージアーキテクチャを公開した。内部テストによると、5000個のAIエージェントが同時に1つのコードリポジトリで作業でき、毎秒7200回のコードプッシュを完了しながら、低い読み取りレイテンシを維持できるという。

これまで、GitHubで最も忙しいコードリポジトリでも、毎秒の書き込みは短時間で数十回程度だった。現在では、大量のAIエージェントが24時間並行して開発し、絶えず新しいコードをコミットできる。各コミットは自動テストをトリガーする可能性があり、他のエージェントが最新バージョンをダウンロードするため、リポジトリの読み書き負荷が増大する。

GitHubの解決策は、「コードの保存」と「ブランチの更新」を分けて処理することだ。

Gitはコードをプッシュするたびに、2つのことを完了する必要がある。第一ステップは、新規または変更されたコードの内容を保存することだ。Gitは古いバージョンを直接上書きせず、変更された内容を新しいオブジェクトとして保存し、変更されていない部分は引き続き再利用できる。第二ステップは、ブランチポインタを更新し、このブランチが現在どの最新バージョンを指しているかを記録することだ。

例えば、1000個のエージェントが同時にソフトウェアを開発し、あるものはログイン機能を修正し、あるものは決済機能を修正している。それらが異なるブランチで作業している限り、新しいコードは同時に保存でき、ブランチもそれぞれ更新できる。2つのエージェントが同時に同じブランチの更新を争う場合にのみ、システムはどちらの更新が先に成功するかを判断する必要がある。

GitHubは当初、すべてのブランチで1つの更新記録を共有していた。異なるAIエージェントが異なるブランチを修正していても、同じファイルの更新を争うため、毎秒数百回のプッシュしか処理できなかった。GitHubは次に、記録を複数に分割し、異なるブランチが同時に更新できるように試みた。しかしこの方法では、リポジトリに変更があるかどうかを確認するたびに、1つずつ照会する必要があり、かえって読み取り速度が低下した。

最終的に、GitHubはブランチ更新を専門に管理するRef-CASサービスを開発した。これにより、異なるブランチが同時に更新でき、同じブランチを修正する場合にのみ競合を処理する必要がある。同時に、リポジトリ全体に統一バージョン番号を維持する。他のプログラムはこのバージョン番号を確認するだけで、リポジトリに変更があるかどうかを知ることができ、すべてのブランチを個別に照会する必要がない。

GitHubはさらに独立したマシンを配置し、バックグラウンドで蓄積し続けるコードデータパックをマージし、データパックが増え続けて読み取り速度を低下させるのを防いでいる。新アーキテクチャは最終的に内部テストで毎秒7200回のプッシュを達成した。

GitHubのRubiconは現在も限定的な非公開テスト段階にあり、2027年初めに提供拡大を予定している。