GitHubが数千のエージェント同時pushを可能にした新Gitストレージ基盤
GitHub's new Git storage architecture
GitHubが新しいGitストレージアーキテクチャ「Project Rubicon」を公開した。内部テストでは1リポジトリに5,000のエージェントが同時接続し、毎秒7,200回のpushを処理しながら低レイテンシの読み取りを維持できたという。鍵は「調整を最小化し、ストレージとコンピュートを分離する」という2原則。Gitオブジェクトは不変なので、順序付けが必要なのは参照更新だけという性質を突き詰め、パックデータをAzure Blob Storageに、参照とパックマニフェストを新開発のRef-CASに分離した。
Gitオブジェクトは不変で内容によって名前が付けられているため、2人の書き手が何も合意せずに同時に保存できる。合意が必要なのはpushのうち参照更新の部分だけで、参照更新はそれに比べてごく小さい。
HNでの議論
32- dwm
これはCursorのContinuityとよく似ているが、GitHubは1桁大きい書き込みスループットを報告している。
- yakkomajuri
正しく読めているなら、これは（本当に堅実な）将来計画であって、現在の障害には役立たないということ？
見出しと冒頭の内容からそう思ったが、その後、水平スケールの手法は基本的に既存のアーキテクチャ（問題があると思われる場所）から引き継いでいると述べており、これは主に彼らが「垂直スケール」（リポジトリ内のスケーラビリティ）と呼ぶものに役立つとしている。またその直後に、今日最も活発なリポジトリでも最大でも数十回の書き込みの短いバーストしか受けないと認めている。
つまりこれは、近い将来にさらなる問題を防ぐのに役立つ可能性が高い、本当に有用な計画だが、現在の問題に役立つことを意図したものではないように思える。この読み方で合っている？
もちろん、このような改善はどちらにせよ常に有用だ。ここでけなしているわけでは全くない。
- pksunkara
これのほとんどは、https://enroute.sh がすでにGitのスケーリングで行ったことと似ている。https://enroute.sh/blog/everyone-is-doing-git-on-s3-wrong
- bob1029
多数の自律エージェントが一つの大きな山の上で協力しようとするなら、Perforceの方が優れたVCSかもしれないと思う。
数テラバイトも標準で問題ない。ファイルの排他ロックが得られる。モノリスから部分チェックアウトも簡単にできる。この特定の文脈では集中化は機能だ。Gitは調整の必要性が中程度なら素晴らしく機能する。何千人もの自動化された開発者がクッキージャーに手を突っ込んでいるなら、排他ロックは非常に魅力的に見え始める。Perforceは高度に分散したチームではひどいが、AIエージェントの群れの場合は、必要ならエージェントのチェックアウトを即座に破棄できる能力がおそらくある。エージェントに連絡してベッドから出るのを待つ必要はない。
- jxramos
エージェントスケールは間違いなく業界で意識されている。GitHubの人々が https://www.anthropic.com/research/redesigning-source-contro... に対して何と言うか気になる。第一原理からソース管理を考え、この新しい体制でどのような品質が重要かというトレードオフを再調整するのは興味深い読み物だ。